# Change of Turn bits destroys continuous curve

• 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?

• 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.

Code
``````\$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}``````

1) read pinned topic: READ FIRST...

2) if you have an issue with robot, post question in the correct forum section... do NOT contact me directly

3) read 1 and 2

Edited once, last by panic mode ().

• 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,...)

1) read pinned topic: READ FIRST...

2) if you have an issue with robot, post question in the correct forum section... do NOT contact me directly

3) read 1 and 2

• 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!

• Thank panic mode and BrianR!
My machine is KR C4, KR6 R900 sixx, KSS 8.2
Actually I tried approximation to PTP at the outset:

Code
``````\$APO.CPTP=75
PTP {X 25,Y 150,Z -8,A -180,B -45,C 180}
PTP {X 25.3,Y 142.2,Z -8,A -175.5,B -45,C 176.81} C_PTP
PTP {X 26.2,Y 134.4,Z -8,A -171,B -45,C 173.61} C_PTP
PTP {X 27.8,Y 126.7,Z -8,A -166.5,B -45,C 170.37} C_PTP``````

I mentioned “non-continuous”, it means the robot arm makes a very big turn (and takes very lone time) to reach the next point that is very close to the previous one. Adding C_PTP or C_DIS doesn’t change the situation.

The CIRC codes to make the same curve:

Code
``````PTP {X 25,Y 150,Z -8,A -180,B -45,C 180}
CIRC {X 54.3,Y 79.3,Z -8},{X 125,Y 50,Z -8,A -90,B -45,C 90}
CIRC {X 195.7,Y 79.3,Z -8},{X 225,Y 150,Z -8,A 0,B -45,C 0}
CIRC {X 195.7,Y 220.7,Z -8},{X 125,Y 250,Z -8,A 90,B -45,C -90}
CIRC {X 54.3,Y 220.7,Z -8},{X 25,Y 150,Z -8,A 180,B -45,C -180}``````

The robot stops at the last CIRC command where the unexpected turn occurs in the PTP version.

The SPLINE codes to make the same curve:

Code
``````PTP {X 25,Y 150,Z -8,A -180,B -45,C 180}
SPLINE
SCIRC {X 54.3,Y 79.3,Z -8,A -180,B -45,C 180},{X 125,Y 50,Z -8,A -90,B -45,C 90}
SCIRC {X 195.7,Y 79.3,Z -8,A -90,B -45,C 90},{X 225,Y 150,Z -8,A 0,B -45,C 0}
SCIRC {X 195.7,Y 220.7,Z -8,A 0,B -45,C 0},{X 125,Y 250,Z -8,A 90,B -45,C -90}
SCIRC {X 54.3,Y 220.7,Z -8,A 90,B -45,C -90},{X 25,Y 150,Z -8,A 180,B -45,C -180}
ENDSPLINE``````

The robot doesn’t run at all, because the last SCIRC motion is impossible for the robot.

In order to calculate the movement (with status and turn) of TCP in PTP, LIN, CIRC…, how can I find out the formula (I use Java to solve geometric problems and export .src files) identical to my machine?

• 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:

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

Edited once, last by Fubini ().

• Thank Fubini!
INVERSE() function works fine inside the KRL codes. However, I need to predicate the turn of the arm off-line (when I calculate the points of the curve in Java).Now I am going to program the direct and the inverse kinematics by myself, with the help of some papers(e.g. Kinematical and dynamical models of KR6 KUKA robot, by Johan Diaz).

Seriously, yesterday I contacted the KUKA company in my region but there is no relevant course.

## Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account
Sign up for a new account in our community. It's easy!
Sign in
Already have an account? Sign in here.