Yes they are. Your diagram is correct.
Posts by Marco
-
-
Yes, that's the thing. The image was to show you the orientation of the saw respect the the spindle axis.. I suppose I need to code a matrix in krl to carry out the calculation. Am I right?
-
Yes, I did. The saw is 90 degrees respect to the TCP axis. My TCP with the saw is (X 455.0659, Y-1.288, Z 457.559, A-0.007, B 90.084,C 0.000). The move-away plane will be always the TCP XY plane passing by the centre of the saw. I'm looking into the $POS_BACK, $POS_FOR, $POS_INT variables to calculate the current vector of the movement of the saw when the job is paused (the saw always go straight from one point to another with the same angle respect to the material) . With this vector I should be able to calculate the normal vector for the move-away on the saw plane.
Any suggestion? -
Failing that... it sounds like you want the robot to determine which move to used based on whether the Tool Z axis is parallel to the World Z axis (End Mill) or perpendicular to it (saw). Is that correct?
The case switch is not a big deal as I set the tool at the beginning of every program so whenever I would pause the job the proper move away case will be selected. The issue is how to program the move away in the saw case. I was looking at the system variables manual to find a variable that tells the program line just before the one that is currently executed. Is there such a variable? With that and the coordinates of the tcp at the instanct I would pause the job I would now the vector normal to which I should move away. The link provides useful information about the math actually, thanks. But still I think I need the vector along which the saw is moving. -
Well, I have my raw plates fixed on the table oriented as XY world plane. So ideally, the saw should move out of the piece sliding over its plane for 150 mm to be sure that the tool is out of the part. Since I hold the raw plates flat on the table, the saw, independently on the orientation of the TCP should slide along its plane toward positive Z world coordinates (otherwise it would crash into the table). However, to get the correct direction of the move away, I might have to:
1) get the previews TCP position (A) respect to the one (B) registered when I hit the pause button
2) calculate the displacement vector (AB) between the 2 positions (this vector will be on the plane of the saw since when you cut with the circular saw you move on one plane along a straight line)
3) given the TCP position and orientation registered when I hit the pause, I should be able to calculate the normal to the displacement (AB) passing by (B) on the saw plane.Unfortunately these steps go beyond my current programming skills.
-
Hi there,
My Kuka is equipped for milling and I have an external remote control to set certain useful parameters. Among these I have a pause and resume buttons. When I press the pause button, spindle switches off and the robot moves away from the part. This is my code:Code
Display MoreDEF MoveAway() BRAKE ; need to pause current robot motion $OUT[10] = FALSE ;fieldbus reference values $VEL.CP = 0.005 $ACC.CP = 0.01 LIN_REL {Z 50} ; move robot up $TIMER[12] = -10000 $TIMER_STOP[12] = FALSE WHILE NOT $TIMER_FLAG[12] ENDWHILE WAIT FOR NOT $OUT[7] ; wait until PAUSE is released $OUT[10] = TRUE ;fieldbus reference values $TIMER[13] = -10000 $TIMER_STOP[13] = FALSE WHILE NOT $TIMER_FLAG[13] ENDWHILE LIN $POS_RET ; return to last position to resume work END
By now, the tool moves away along Z world axis, so I want to replace LIN_REL {Z 50} with LIN_REL {X-50} #TOOL, to move away 50 mm along the milling tool axis.
But I'm also facing a different situation as I'm to cut some plates with a circular saw. In this case, if I would press the pause button during a cut with the saw immersed into a plate, the saw would move along tool axis (which is the tool holder axis, same direction of a regular milling bit) and I would get the saw moving against the material and damaging all stuff. I understand I should move the saw out of the material moving on the same plane of the saw but in opposite direction respect to the axis passing by the centre of the saw (i.e. the TCP) and the point where the saw touches the material in the moment I pause the job). I'm wondering what is the best manner to code this out? Of course the moveout case should be automatically selected depending on the tool loaded for the current job, so I imagine there will be also and other if statement that checks what tool is loaded.
Any suggestion?
Best,
Marco -
Yes, robots are far more vulnerable to backlash than typical gantry-style milling machines. Any axis that reverses direction during a cut will leave marks. For example, imagine a robot making a linear move along the World Y axis, essentially drawing a straight line from left to right (Y position value going from + to -)in front of itself. Over the course of this motion, A1, A4, A5, and A6 will probably maintain a constant direction of motion, though at varying rates. But A2 and A3 will both reverse direction as A1 passes through 0deg. And this will leave behind definite evidence in the cut being made.
That's an easy example, but A2 and A3 are some of the most backlash-immune axes on the robot, thanks to gravity and the counterbalance (although A2 has definite issues near -90deg). The wrist axes are vulnerable, and any reversal of A1 is likely to have large effects simply because A1's backlash usually has the longest "lever arm" to act over.Thanks for this explanations. So it is not about some trick to tweak this issue. So I should check again load, if I can set my Sprutacam as to avoid the robot passing by the zero of the all axis. I will also check the effect of climbing and traditional setup as I'm actually using both to save some milling time reducing idle time.
-
Usually concern is A1 and problem is solved by:
a) mounting robot tilted slightly (10 deg)
b) squaring world coordinatte system by entering tilt angle into $robrootWell, in may case I would not say that the issue is with the A1. My spindle axis is mounted parallel to the x flange axis and sometimes I notice strange movements, like pitching, given be the A5 (I would say). My TCP is 450 mm away from the center of the flange (due to a tool changer+spindle support+spindle assembly which make this strange movements quite evident. I calibrated the load with kukaload determination software and my load is admitted (52kg)...Is there any other thing I could do to correct this strange pitching?
-
Hi there, did anyone here succeeded in reducing or getting rid of backlash. Especially when you mill a flat surface, backlash is a very disappointing trouble as it leaves marks over the surface. Any advise about that to get closer to a gantry surface quality?
Very Best,
Marco -
Try the linear move without the c_dis approximation. Also, instead of $base = ... you could use bas(#base,1) to set the base.I there,
I solved the issue using bas (#base,basenumber) and I also had to use bas (#tool,toolnumber). I don't know why it works fine in this way and not with the other syntax $BASE=BASE_DATA[1] and $TOOL=TOOL_DATA[2].Does BAS work also for BAS (#load,loadnumber)?
Anyway, it works. Thanks for your help!
Best,
Marco -
Ok, now I used bas (#base,1) but still the same result, I stop the robot at point A and Z is 17.59 measured with the caliper while $pos_act says Z= 20. Then $pos_act says Z=17.59 if I check again the monitor after I deselect the program (the robot is still in the same position), set manually the tool and base with the same values i should have to run my program ...
(btw the $act_base in the monitor is now changing from 0 to 1 while the program runs),
-
OK then there is something strange going on here with the base:
I have base 1 with Z=-36.787
my digital model from which I get the CAM has the 0 at Z=-36.787
I program the linear movement you have in the program above from point A to B with A at Z=20
I run the program and stop it in A and the $POS_ACT shows Z=20
I measure with the caliper the distance of the tool tip from the base and I get a measure of Z = 17.59
$ACT_base shows value 0 rather then 1 (as programmed) during the run and after stop
I leave the robot in the same position, I deselect the program, I set the tool (2) and the base (1) as from the program using the configure menu
I go to the variable monitor and $pos_act shows Z= 17.59709 which matches with my measure done with the caliperSo my conclusion is that the base loaded to run the program is not the right one. Am I right? Is my program syntax wrong?
-
You mean that the $ACT_BASE is not actually showing the base value changing during the run if there is change of the base along the program? I did some test and it seems that the value changes
-
Hello Everyone,
I'm monitoring the actual base with the $ACT_BASE variable while running a program and I noticed that the base value is not changing to base 1 as supposed but the variable monitor shows 0 (I've set the continuous update of the monitor with the shift+enter). Here is my code, I do not see what is wrong. Can you help me with this?
Very Best,
MarcoCode
Display MoreDEF BCT_A() GLOBAL INTERRUPT DECL 3 WHEN $STOPMESS==TRUE DO IR_STOPM ( ) INTERRUPT ON 3 BAS (#INITMOV,0) $LOAD=LOAD_DATA[1] $BASE=BASE_DATA[1] $TOOL=TOOL_DATA[2] HSD_LOGIC_SET=5 $OUT[13] = FALSE HSD_SPEED_SET=0 $TIMER[10] = -10000 $TIMER_STOP[10] = FALSE WHILE NOT $TIMER_FLAG[10] ENDWHILE $VEL_AXIS[1]=15 $VEL_AXIS[2]=15 $VEL_AXIS[3]=15 $VEL_AXIS[4]=15 $VEL_AXIS[5]=15 $VEL_AXIS[6]=15 $ACC_AXIS[1]=70 $ACC_AXIS[2]=70 $ACC_AXIS[3]=70 $ACC_AXIS[4]=70 $ACC_AXIS[5]=70 $ACC_AXIS[6]=70 $VEL.CP=0.167 $ACC.CP=2.3 $VEL.ORI1=200 $VEL.ORI2=200 $ACC.ORI1=100 $ACC.ORI2=100 $advance=5 $APO.CDIS=0.2 PTP $POS_ACT $VEL.CP=0.167 PTP {A1 46.934, A2 -35.843, A3 121.072, A4 0.105, A5 -85.313, A6 -0.016, E1 0, E2 0, E3 0, E4 0, E5 0, E6 0} LIN {X -0.188, Y 0.03, Z 100, A 133.204, B 0.086, C 179.933} C_DIS $VEL.CP=0.008 LIN {X -0.038, Y 0.006, Z 20, A 133.204, B 0.086, C 179.933} C_DIS LIN {X 1499.959, Y 0.871, Z 22.828, A 152.602, B 0.104, C 179.965} C_DIS $VEL.CP=0.167 LIN {X 1499.809, Y 0.895, Z 102.827, A 152.602, B 0.104, C 179.965} C_DIS HSD_SPEED_SET=0 $TIMER[10] = -10000 $TIMER_STOP[10] = FALSE WHILE NOT $TIMER_FLAG[10] ENDWHILE PTP {A1 0.000, A2 -100.000, A3 120.000, A4 0.000, A5 -20.000, A6 0.000, E1 0, E2 0, E3 0, E4 0, E5 0, E6 0} END
I'm running the program above through this program
Code
Display MoreDEF alo_processing_cam_A( ) ; --- DECLARATIONS --- DECL INT s,a s = 10 a = 70 ; --- INITIALIZATION $base = $world $tool = TOOL_DATA[1] $load = LOAD_DATA[1] $vel_axis[1]=s $vel_axis[2]=s $vel_axis[3]=s $vel_axis[4]=s $vel_axis[5]=s $vel_axis[6]=s $acc_axis[1]=a $acc_axis[2]=a $acc_axis[3]=a $acc_axis[4]=a $acc_axis[5]=a $acc_axis[6]=a ;$vel.cp = 2 ;$vel.ori1 = 0.3 ;$vel.ori2 = 0.3 ;$acc.ori1 = 2 ;$acc.ori2 = 2 ;$advance = 2 $OUT[6] = TRUE $OUT[7] = FALSE ; --- MAIN $OUT[9] = TRUE ;com led on WAIT FOR HSD_SPEED_IN < 50 PTP $POS_ACT ;LIN_REL {Z 100} PTP XHOME $OUT[9]=FALSE ;com led off ; specify interrupt level and program name to call ; when PAUSE button is pressed... (wired to $IN[7]) INTERRUPT DECL 10 WHEN $OUT[7] DO MoveAway() ;activate interrupt INTERRUPT ON 10 ;enable fieldbus reference values for HSD $OUT[10] = TRUE ; pick tool ; PT0101() ; call CAM program to execute BCT_A() ; release tool ; RT0101() ; after milling program is finished, deactivate interrupt... INTERRUPT OFF 10 HSD_LOGIC_SET = 5 HSD_sPEED_SET = 0 HSD_LOGIC_SET = 0 $OUT[9] = TRUE WAIT FOR HSD_SPEED_IN < 50 PTP XHOME $OUT[9] = FALSE $OUT[6] = FALSE $OUT[10] = FALSE END DEF MoveAway() BRAKE ; need to pause current robot motion $OUT[10] = FALSE ;fieldbus reference values $VEL.CP = 0.005 $ACC.CP = 0.01 LIN_REL {Z 50} ; move robot up $TIMER[12] = -10000 $TIMER_STOP[12] = FALSE WHILE NOT $TIMER_FLAG[12] ENDWHILE WAIT FOR NOT $OUT[7] ; wait until PAUSE is released $OUT[10] = TRUE ;fieldbus reference values $TIMER[13] = -10000 $TIMER_STOP[13] = FALSE WHILE NOT $TIMER_FLAG[13] ENDWHILE LIN $POS_RET ; return to last position to resume work END
-
Good one, I will check the effect of this. I have the feeling that all this approx and acceleration parameters must be set in a very strategic manner to reduce vibrations and improve accuracy and have speed more constant to achieve high precision for milling operations of tiny details. I do a lot of interlocking wooden parts and precision is important. Of course I can accept that milling with a robot is not precise as milling with a Router, but still I'm trying to get the best out of the Kuka. I'm actually wondering if my settings about acceleration are good. I guess I will have to develop a milling test program to fine tune these parameters.
-
Ok, I found the description of these variables in the manual, I will explore how to use them. Because to calculate the % of program executed I just need to read automatically the total number of lines (blocks) and the number of the current block being executed, from there through Arduino I can do all other steps I need. Thanks!
-
Got it, I guess that a little interface developed through Arduino (even if it is not a solid industrial solution) is going to be the most suitable option considering my knowledge then. I was looking at the system variable book to find out if there is a variable that tells the total length of the program (total number of lines) and current line while the program is running but I could not find it. Having access to the number of line showed in the KCP at the bottom of the display when the program is running would be perfect. Do you know how to get this numbe out?
-
I have krc2 ed05 with system version 5.6.11, no tech packages. I could implement it using an Arduino board with an Internet shield, but of course I would prefer to use the KRC hardware directly.
-
Hi there,
Maybe some of you already did it. I would like to get my Kuka to send an email to a specific address when a program is started, when it is finished, possibly every 25% of completion of the program and whenever there is a stop for some mistake within the code. I did some research on this but I could not find any litterature about any of this goals. When I process very long milling files would be good to have this updates system. Do you have any suggestion?
Best,
Marco -
Got it. As the $PRO_ACT shifts from TRUE to FALSE when you press the RUN or STOP softkeys it solves this aspect. That's very useful to link actions to this softkeys.