Change of Turn bits destroys continuous curve

you need to take some training or read manual (check system integrators manual).

all motions listed in your code will cause robot to stop at each point.
to make the motions continuous, you need to use approximation

you don't mention any info about your system so I assume it is KRC4
approximation is done by adding C_DIS after motion command, for example.

$APO.CDIS=50 ; set approximation distance to 50mm
PTP {X 25,Y 150,Z -8,A 180,B -45,C -180 }  ; robot will stop here
PTP {X 25.3,Y 157.8,Z -8,A 175.5,B -45,C -176.81} C_DIS  ; will not stop here, it will approximate this point because of C_DIS
PTP {X 26.2,Y 165.6,Z -8,A 171,B -45,C -173.61} ; will not stop here
PTP {X 27.8,Y 173.3,Z -8,A 166.5,B -45,C -170.37}

Quote from whitegreen

A continues curve is interpolated by points as follows:

Code

PTP {X 25,Y 150,Z -8,A 180,B -45,C -180 }
PTP {X 25.3,Y 157.8,Z -8,A 175.5,B -45,C -176.81} 
PTP {X 26.2,Y 165.6,Z -8,A 171,B -45,C -173.61} 
PTP {X 27.8,Y 173.3,Z -8,A 166.5,B -45,C -170.37} 
...

Two situations occur:
1. Turn bits change, while the movement of TCP still appears continuous.
2. Turn bits change, but the movement is not continuous in between. The arm makes a lot of movement (and takes time) to reach the next point which is very close to the previous one.

Thus I get some questions:
1. Is there a way to examine whether the robot will make a ‘non-continuous’ movement between two PTP commands (even the two points are very close to each other)?
2. I tried CIRC instead of PTP to make the same movement, however, it gets ‘software limit switch point cannot be reached’ error. I think the real problem is the robot arm cannot make the arc continuously, rather than the points on the arc cannot be reached.
3. How to make a continuous interpolated curve with Kuka in general? More precisely, how to segment the whole curve into several 'continuous' parts?

Display More

status and turn bits have everything to do with arm configuration as to interpret a position with only 1 kinematic solution. The points you are using there are not using turn bits. This can be OK on a 6 axis in some situations, but not all. They'll generally be predictable if you are coming FROM a point with status and turn bits. I do a lot of palletizing, so I can ignore S and T as there is only 1 solution to positions with a 4 axis robot.

Continuous points are made by the following modifiers:

PTP POINT1 C_PTP
LIN POINT2 C_DIS

This will cause the robot to not stop at these points, but it also will not go to these points and round them off. Circular motions are programmed completely differently, they just don't interpolate positions as it sounds you tried. There are some other variables to set up as well that control how close to the point you get as well.

panic mode is correct though, get some training, or read the manuals.

movement of TCP is not predictable in PTP. if you are trying to create motions that guide TCP through space you need to use CP motions (LIN, CIRC,...)

Quote from panic mode

movement of TCP is not predictable in PTP. if you are trying to create motions that guide TCP through space you need to use CP motions (LIN, CIRC,...)

I'm sure you could calculate it out if your REALLY wanted to. But even if you didn't want to (because it would be very time consuming to say the least), they are at the very least repeatable!

You wouldn't happen to be a student at UVA would you?

Hi,

first of all you have to understand how status and turn are applied if left out:

http://www.robot-forum.com/rob…rn-(-t-)-and-state-(-s-)/.

Next you have to realise that in PTP-movements there is a feature if a desired target position can not be reached due to software limit switches the controller automatcally chooses the other solution. And that is choosing a different turn leading to your long run. In Cp-movements this feature is not available, hence the robot runs into the limit switch. Reading about $CP_STATMON should be helpful too. This feature if applied correctly allows you to avoid such PTP-long runs, because at the end of a CP-sequence you did not reach the desired status and turn:

http://www.robot-forum.com/rob…fl-off/msg66879/#msg66879

Finally you have to understand how robot inverse kinematics works. Using the built in INVERSE function you could calculate the necessary axis positions to reach your cartesian position beforehand:

http://www.robot-forum.com/rob…r-axes/msg61600/#msg61600

And Last but not least seriously consider taking some KUKA training courses.

Fubini