Understanding the difference between motion types

"S" motions are newer and generally perform better. i stated here generally as there may be situation where this is not the case.

hence good idea is to always test it and see for yourself.

traditional motions LIN.PTP,CIRC are part of "legacy" motion planner. KSS5x included spline blocks. KSS8.x had more additions. the most recent one was SPTP which allowed to stay within new motion planner because switching back and fort between old(legacy) and new (spline) motion planner resets motion planner and result is advance run stop. so there is nothing wrong with mixing new and old motions but blending does not work if instructions are not from same motion planer.

so if you have to run search that is long (find top pallet in a stack) SLIN can be faster than LIN. one can get more performance from LIN too by using KRL and increasing acceleration (note that inline forms are not too liberal here).

new motion planner should have better path accuracy as well (which is what you are asking). one example often used to demonstrate this is circular motion for example (older CIRC was not perfect). this is why in the old days to get really good circle one would write own loop and blend bunch of short LIN segments. SCIRC is supposed to fix this (plus add some more things) though i have not run any tests.

about your last question.... there may be also special applications where one or another motion command may be needed (like ConveyorTech). or there may be a special motion instruction added (like DLIN which is faster than LIN). note that paths are very similar but NOT exactly the same if you compare old and new motion planner. even more so if approximation is used but was not possible - in this case older motion planner was going to programmed point and stop, new motion planner stops at the begin of approximation segment which is quite notable difference. i was having some problems with SLIN and very slow motions, for some reason programmed speed was exceeded and that was not usable. did not have much time to dwell on it so i replaced it with LIN in that part of the program.

the point is.... you have a controller with set of instructions. use it all... don't turn your back on part of the instruction set, you never know when it will come handy. I am glad that KUKA did not ditch the old motions and simply replaced them all with new ones. i like to have choice even when difference may be subtle.

Quote from MNMRoboter

I came across a similar issue. This was when doing first tests in auto mode, programmed really slow SLIN speeds but programmed speed was exceeded. Ignored this as we would be running at faster speed anyway.

I'm far from an expert on the Splines, but my understanding is that they have some hidden complexities that can trip you up under certain circumstances without being obvious.

One of these is that the motion has to be "twice differentiable" -- that is, the first derivative of the path (velocity) and the second derivative of the path (acceleration) have to be continuous. If you were to plot all three elements (Position, Velocity, Acceleration) of a Spline path over time, all three would have to be smooth curves without any "steps".

Most of the time, the path planner handles this invisibly, but I've run into a couple situations where a simple-looking Spline motion would either throw speed errors like this, or reduce its speed to a dead slow crawl, for no apparent reason. Spline motions involve a lot more calculation than pre-Spline motions, and have a lot more model complexity hidden "under the hood." Which means that there's more chances to trip over something.

Also, the Spline path planner has been evolving rather rapidly over the past ten years. The early versions were sufficiently unpleasant to work with that I, and probably other people with lots of KRL programming experience, got into the habit of habitually avoiding Splines in favor of the more predictable and better-understood LINs and PTPs unless we hit a situation where the Spline motions were definitely superior. It's only recently (KSS 8.5, I think) where the Inline Forms began defaulting to Spline motions instead of the older types. KUKA is definitely pushing Spline over the older types as the default choice now, but there's going to be some deep-set inertia to overcome.

For a simple pick&place with no approximations, I'm not sure that Splines offer you any advantage over "classic" KRL motions, but I'm also not sure that there's a penalty. In my (limited) experience, the "weird stuff" in Splines only shows up when you're using approximation to produce a smoothly blended path.

you should read the manual too. as mentioned paths are not exactly the same but this is not obvious. the only time this is obvious is if there was advance run stop and you can see robot pause at different places and take a different path.

but there is more to it. new motions have nice additional features such as stopping on some condition. the true power is when stop condition is not active and robot just moves along without pause. this is not the same thing as placing CONTINUE before WAIT FOR.

Re: Spline motion

Just a few advantages. Main advice use spline blocks whenever possible.

Fubini

with spot welding all motions are PTP and normally all are inline form instructions. there is no reason to use anything else and hence no performance issue.