use relative motion such as
LIN_REL {Z -100}
assuming that current coordinate system has Z pointing up.
"Straight down" in what coordinate system? The Tool or the Base?
There are two main ways.
The easy way is to use the LIN_REL command. This moves in Base by default, but you can also append the optional #TOOL argument to change it to a Tool coordinate move:
LIN_REL {X 0,Y 0, Z -100,A 0,B 0,C 0} #TOOL
One weakness of LIN_REL is that if the command is interrupted by something like an E-Stop, the command will start over when the program resumes. So in the above example, if an E-Stop occurred when the robot have completed 50mm of the 100mm Z move, after resuming the robot will end up moving 150mm in Z.
The less easy, but stronger, way is to use the Geometric Operator. There are lots of discussions of this in the forum archives, but basically it's a way to calculate the end result of a Cartesian coordinate and a Cartesian offset. So, to perform the same Tool -Z move as in the LIN_REL example, one would
DECL E6POS eTempPos
eTempPos = xP1 : {X 0,Y 0,Z -100,A 0,B 0,C 0}
LINE eTempPos
or
PTP eTempPos
One advantage the GO method has over LIN_REL is that LIN_REL can only perform Linear motions, and the joint equivalent PTP_REL cannot work with Cartesian coordinates, only Joint (E6AXIS) coordinates, while the "normal" PTP command can move to either E6AXIS or E6POS coordinates.
as i recall resuming relative motion after EStop or similar, robot still goes to the exact same point. only when instruction is re-selected (block select), robot would do complete new motion and thus adding distance to part already travelled. but... that is just my recollection, to be sure i would have to check that on a real robot.
as i recall resuming relative motion after EStop or similar, robot still goes to the exact same point. only when instruction is re-selected (block select), robot would do complete new motion and thus adding distance to part already travelled. but... that is just my recollection, to be sure i would have to check that on a real robot.
I'm not sure I ever actually tried it. But I got (gently) raked over the coals by a KUKA Germany engineer for using LIN_REL instead of the Geo Operator, because (according to them) LIN_REL had this issue, and told in no uncertain terms to remove LIN_REL from all my code.
Granted, that particular project would have incurred damage between 5 and 7 figures every time the robot over-travelled on those LIN_RELs, so... but I took that instruction to heart and avoided LIN_REL religiously ever since.
Should be as panic said. The motion is only planned anew in case of a line selection. After an e stop the old motion is resumed after repostioning onto the previous path if needed. No difference here to non rel motions.
A former KUKA Germany R&D engineer 😁
i did try it at some point (long ago) and it was as i stated but did not want to generalize since things could be different from KSS to KSS...
