Spline motion

    From the manual:


    tl;dr: If you have 10 points in your program, your robot will reach and stops at each point. If these points are grouped in a spline, the robot will move through the points without stopping.

    ...no, that's not what Spline does. Continuous motion is entirely possible with non-spline motion.


    In "traditional" approximated motion, the robot simply "cuts the corner" past a programmed point, beginning and ending the "shortcut" at a distance based on the approximation radius (and the distance to the previous/next points -- it gets a bit complicated). This means that the robot never passes through the programmed point exactly -- the point acts more like a "handle" on the overall path.


    In a Spline motion, the motion path is calculated to pass through each point, and the path between points is pre-shaped to a constant velocity and/or smoothing. This is much more computationally expensive, which is why it's a more recent development. It's best suited to things like converted CNC programs, where the intent of the program is that the tool pass through each point, rather than simply passing "near" it.

    Just to add a few advantages:


    - Faster cycle time when using spline blocks
    - Far less situations where approximation not possible happen
    - Faster CP-motions (SCIRC, SLIN) due to model based planning: The robot automatically drives as fast as allowed by physical limits
    - Occurances of torque limit violations minimized compared to old motion LIN,CIRC
    - Better path accuracy: no more velocity dependant path deviations, what you teach is what you get
    - Better "Start-" behaviuor
    - New features only available for spline: constant velocity sections inside spline blocks, conditional stop, time based moves, move_backward, path trigger for PTP motion commands, automatic $ORI-TYPE = #JOINT, Optimal
    distribution of orientation and external axis path ($ORI_TYPE = #IGNORE, $EX_AX_IGNORE) to the cartesian path
    - ...


    Fubini

    Edited once, last by Fubini ().

    Interesting research which i found regarding improving the cycle time and comparing the old PTP and SPTP, LIN,SLIN moves, which motion type causes more vibrations...


    In this research they measured that old PTP was faster then SPTP moves...

    Intresting. But in my opinion has some fundamental flaws. E.g. method how to correctly measure timing are wrong. Doing it like this you also measure planning and not execution time alone. In general the difference between PTP and SPTP is far less. For old motion you always constantly loose filter time from stop to stop . For spline it depends on gear_jerk. Probably setting up gear_jerk was neglected. Also the conclusion to reduce vibrations by reducing velocity is surprising to me. Yes it works but will lead to a highly negative result in cycle times. For old motion is far better to reduce accelerations and for spline jerk (and maybe also a bit acceleration).


    ...


    Sorry, no offense for the authors but I think a lot of essential info and tweaks where not considered resulting in imprecise conclusions. But based on how academics currently works it is not surprising to me. More and more quality is replaced for quantity setting limits on how fast publications need to be produced. E.g. we had cooperation partners from academia promising more then 40 percent improvements compared to kuka that customers where never able to reproduce in reality. Asked by the customer why this happened we looked together with the University people we found their measurements where complete bull... du to many programming errors. Evaluating how these errors happened they only said compared to kuka many years of experience they had no time to learn krl due to publication deadlines. So I am always sceptical on such results.


    But finally do not get me wrong. Kuka is not perfect either and a lot of improvements are possible and also needed. But from my knowledge of Kuka they are completely aware of these deficiencies and try to work on them. But as always and probably all of you know daily business sometimes hinders you on doing the right things in the right order.


    Fubini

    Well... I only skimmed the report, maybe will check it later in more detail. but as i see it, there are some problems with it.


    It shows picture of tooling on the robot yet there is no mention of load values, actual positions used, no programs are posted etc. In other words there is no way for anyone to reproduce the exact test setup and findings. For something that is supposed to be a scientific study, this is a big no-no. Basically they are able to print almost any results they like without anyone having fair chance to comment on or challenge those results directly.


    Btw. here is something from couple of years ago while i was working at KUKA. It is not a scientific study, it was a real world application. Colleague created really nice palletizer. He was tweaking it for weeks trying to get the absolutely maximum performance. We had few conversations about it and I asked him to consider comparing results with new motion instruction (SPTP, SLIN) which he did.


    After very laborious and detailed optimization, the (barely) winner was still the program using legacy motions (PTP,LIN). And that was in a program where robot practically never stops, gripper opens and closes while robot is in motion (product was both picked up and dropped on the go, "air-bomber" style) and cycle time was measured on many levels: individual transfer, one layer, entire pallet...


    If i recall that was some eighty bags of 45kg each per pallet. That is well over 3 tons or material moved in rather large working envelope and this is a real world application created by an expert with heavy optimizations, use of interrupts/triggers, all motions are approximated and tweaked to the limits, loads are constantly updated (gripper full or empty) etc.


    It is worth noting that in case of this palletizer 99.9% of path are PTP motions so the conclusion was that PTP is indeed slightly faster than SPTP. in application where PTP motions are not so dominant, results could be (and should be) different.


    Btw. this program is used in numerous plants to move all kinds of products (grain, ice, etc), usually in bags. This is part of the challenge as bags are not fixed shape and therefore do not line up as nicely as boxes. So to get 10-12 layers stack up nicely while dropping bags from the air is quite a feat.

    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

    Thumbs Up 1 Like 1

    Yes usually in practical applications SPTP is a little bit slower than PTP. Well no surprise here since PTP is a second order trajectory planning algorithm and SPTP is a third order trajectory planning method. Hence PTP produces infinite jerk while SPTP is bounded by jerk. So PTP needs another technique to restrict jerk to be able to run trajectory. That is filtering the trajectory (leading to path deviances). Filtering leads to a constant time loss proportional to the filter length. If jerk limitation leads to less time loss than filter SPTP is faster otherwise PTP. My personal experience is that SPTP is up to 10 % slower depending on application. But considering the use cases of spline being essentially for Cartesian processing like glueing this is ok since usually SLIN is much faster than LIN out of the box (with heavy expensive tuning LIN can get similar fast, but that is a very dull and tedious process). So the main use case for SPTP is connecting in between Cartesian spline. This can not be done by faster PTP since it needs limited jerk for spline to work so a spline conform PTP was needed if you want features like blending motions.


    Fubini

    Thank you both Panic and Fubini for sharing the detailed info and experience with using PTP and SPTP.


    Regarding the SLIN and LIN with inline forms, with SLIN i managed to get faster and more constant path velocity even for very sharp turns (90 degrees) ... especially for gluing. And also for the milling converting the LIN moves from postprocesor(still didn't came across the program with SPLINE postprocessor) to SLIN or SPLINE blocks... So in this cases in complex path motions using SPLINE moves there is a big advantage over old LIN like mentioned.

Advertising from our partners