KRC4 Spline Continuous Movement

    Hi all - first time poster here,
    I have a gluing application that reqires a continuous fixed speed path movement, I have been able to get a test program (rectangle with rounded corners) working using LIN/CIRC and C_VEL using hard coded points (actual point data to be taken from CAD model of part to be glued). However I have read that I could use a SPLINE block movement to give better results, so I set about duplicating my test program with a SPLINE. If I teach the points I can get a nice smooth movement, but if I feed the SPLINE block with my hard coded points then the movement is not smooth (decel / accel around each point). I also get the following messages :-


    KSS01123 Approximate positioning not possible (module TEST, block 76) (=> 1442)
    KSS01442 Sequence of instructions that cannot be approximated (module TEST, block 96)


    Example of KRL code I am using :-


    SPLINE
    SLIN POINT[1] C_VEL
    SPL POINT[2] //Mid point of arc
    SPL POINT[3] //End of arc
    SLIN POINT[4]
    SPL POINT[5]
    SPL POINT[6]
    SLIN POINT[7]
    SPL POINT[8]
    SPL POINT[9]
    SLIN POINT[10]
    SPL POINT[11]
    SPL POINT[12]
    SLIN START_POS
    ENDSPLINE C_SPL


    Can anyone please shed some light on what I am doing wrong here or point me at some further documentation on the use of SPLINE - the documentation I have does not go into any detail on the use of SPLINE outside of using taught points (Kuka System Software 8.22 - Operating and Programming Instructions for System Integrators)

    Hi,


    I do not have the documentation with me but I remember there are conditions for the movement to be smooth. (like tangent between two move).
    Especially if you use SLIN with SPL ou SCIRC.
    You should look in the manual on the SPLINE section.


    I will have access to it tomorrow in cas you did not find.

    Hi Alex, thanks for the reply, I have indeed read the spline section in the manual with particular care to look at the section on reduction of velocity. The method I have used SLIN -> SPL -> SLIN is taken directly from this manual under the replacing an approximated motion with a spline block section.


    The part I can't understand is how I can get the desired motion when using taught points but get approximation errors when using hard coded positions (exactly the same points for both methods)


    Any help would be much appreciated

    It's been a long time since I did Splines (since KRC2s), but from what I recall, the hand-taught inline forms might include additional data that you don't have in your hard-coded points. Also... maybe I'm out of date, but I didn't think you could put an approximation on the first point of a SPLIN block -- when I was using it, every SPLIN block had to start and end at a full stop, there was no way to approximate in/out at either end.


    Hm... another possibility: teach some Spline motions, then examine their entries in the DAT file vs your offline-programmed ones. Could be there's some critical bit of detail going missing.

    Thanks for the replies.


    SkyFire,
    I cant see any additional info in the DAT file file for the taught points vs the offline programmed points:

    Code
    DECL E6POS XP8={X 290.911926,Y 300.000,Z 50.0000,A -0.000756374036,B 15.0000067,C 179.997025,S 2,T 35,E1 0.0,E2 0.0,E3 0.0,E4 0.0,E5 0.0,E6 0.0}
DECL FDAT FP8={TOOL_NO 1,BASE_NO 0,IPO_FRAME #BASE,POINT2[] " ",TQ_STATE FALSE}


    I don't need to put approximation between SPLINE blocks, it's the movements inside the SPLINE declaration that seem to decel/accel between points - but only when using offline programmed points. Also from one SPL to another SPL point i get this - not just SLIN to SPL.


    Eusty,
    I will try the SPLINE path with just SPL moves and see how that goes. I have also read that I can add a C_DIS command to the end of an SLIN instruction to approximate the end point - this may also help here.

    Hi,


    please note the following suggestions we always consider to get best Spline results:



      • New Motion (SPLINE, PTP_SPLINE, SLIN,SCIRC,SPL, SPTP) ist not old Motion (LIN,CIRC,PTP), hence teaching the same positions will not lead to the same results.

      • Inside a CP-spline block (SPLINE ... ENDSPLINE ) always use SPL as standard motion type. SCIRC and SLIN should be the exception.

      • Don't use use long distances inbeetween points in combination with very short distances inbeetween points. Try to use a somewhat equidistant allocation of your teached positions.

      • If you need to recreate "old motion approximation" inside a Spline block do not teach the position you want to approximate. Instead teach the positions where you want approximation to start and where you want approximation to end.

      • Our personal experience: If you need to recreate "old motion approximation" inside a Spline block people most of the time tend to teach the position where approximation should start and stop to close to the "idealised" position they want to approximate. This leads to slow velocities during "approximation".

      • Use $ORI_TYPE = #IGNORE and $EX_AX_IGNORE as often as possible: Teaching positions always gives you specific orientation and external axis positions the robot has to drive to at the teached positions. Most applications do not need specific orientations and external axis positions at each teached position. Setting these options allows the system to choose orientaion and external axis in a optimal fashion.

      • Do not teach two positions to close to each other or SLIN-SLIN transitions. Due to the condition that the spline is C2 (smooth up to second order derivative) this leads to unwanted robot stops inside a spline block.

    Edited once, last by Fubini ().

    Thanks to all for their suggestions on this, I have now proved that the issue I was seeing was down to trying to move the tool orientation (which was following the SPLINE path) too quickly which was causing a reduction in velocity. The manual does state that "major reorientation" can cause reduction in velocity, so I ran my test program with a fixed tool orientation and it runs without any reduction in velocity. Although this is not ideal for my application (I would get better results by allowing the tool to follow the path while applying glue) it is more important that I have the constant velocity and be able to make tight curved path changes.

    Hi,
    An idea I have when reading this, if you set a lower speed, you would be able to move at constant speed with reorientation. In order to keep the same amount of glue, you would need to reduce the flow.
    However, this would increase the cycle time.
    Or maybe, by increasing the number of points and anticipating the orientation of the tool as much as possible you would be able to keep a high speed.


    Regards,
    Alex

    Thank Alex for the reply, I have indeed considered slowing the motion to get around this issue. But I don't think I'll get away with it as my test pattern was basically a square with rounded 90 degree corners of a 10mm radius and I had this issue at a moderate speed. However the actual part contains some corners with a 1mm radius which will surely cause me problems unless I run at a crawl which is impractical.

    Hi,


    just in case:


    Spline has a feature called CONST_VEL. This reduces automatically all velocities to the velocity that can be maintained constant along the path. You do not have to find this velocity by trial and error anymore.


    Fubini

    That's very interesting Fubini, can I ask where you learned about that and if you have any documentation? I have not seen mention of this in the documentation I have. I will be sure to investigate this and let you know.

    Hi,


    KUKA System Software 8.3
    Operating and Programming Instructions for System Integrators
    (in my version section 11.6.9)


    Just search for keyword CONST_VEL.


    Unfortunatly I can not post it here. The file seems to big.


    Fubini

    Edited once, last by Fubini ().

    The feature is available in V8.2 too, even if documentation does not mention it. Spline documentation is improved a lot in V8.3. So here a short example:


    Description:
    In a CP spline block, a range can be defined in which the robot maintains the programmed velocity constant where possible. This range is called the “constant velocity range”.
     1 constant velocity range can be defined per CP spline block.
     A constant velocity range is defined by a start statement and an end statement.
     The range cannot extend beyond the spline block.
     There is no lower limit to the size of the range.
    If it is not possible to maintain the programmed velocity constant, the robot controller indicates this by means of a message during program execution. Still the robot executes with the fastest possible velocity.


    1 PTP P0
    2 SPLINE WITH $VEL.CP = 2.5
    3 SLIN P1
    4 CONST_VEL START = +100
    5 SPL P2 WITH $VEL.CP = 0.5
    6 SLIN P3 WITH $VEL.CP = 0.2
    7 SPL P4 WITH $VEL.CP = 0.4
    8 CONST_VEL END = -50
    9 SCIRC P5, P6
    10 SLIN P7
    11 ENDSPLINE


    The feature is only available inside a CP-Splineblock SPLINE ... ENDSPLINE.


    You always have to define a path position where your CONST_VEL area starts by setting CONST_VEL START =Offset_xx. Offset _xx defines the position on the path using the same rules you would use for a trigger command with path = xx.


    Furthermore you need a position where your CONST_VEL area ends by setting CONST_VEL END=Offset_yy. Offset_yy defines the position on the path using the same rules you would use for a trigger command with path = yy.


    You can also use CONST_VEL START/END = Offset <ONSTART> the same way as in trigger commands.


    For diagnosis you have the following variables:


    $CONST_VEL: specifies the velocity (mm/s) in the constant velocity range for the CP spline block that is currently being planned. The value remains valid until a different spline block with constant velocity range is planned.


    $CONST_VEL_C: corresponds to $CONST_VEL, but with the difference that $CONST_VEL_C refers to the CP spline block that is currently being executed.

    Thanks Fubini, this is exactly what I was looking for. I managed to get hold of the KSS 8.3 Programming Guide and this does indeed have more info on the use of splines (Not in the 8.22 I was using). I have tried CONST_VEL with my test pattern on my KRC4 and it shows me exactly how slow I would have to run to get a continuous movement for my path with the tool being reoriented - you can clearly see how hard the wrist is having to work during the turns. Unfortunately this shows me without any doubt that I will need to keep a fixed tool orientation to be able to execute my required path at a reasonable speed with the much tighter turns required by my path. But it is all usefull info for the future, so thanks again
    :merci:

    Hello everyone:


    Do you have any document about the SPLINE. I am looking the document to describe the SPLINE in detail.
    Would you please share with me.
    Thanks a lot.


    Steven Dong

    Hi there! I've recently opened for myself SPLINE as a type of movement. Big thanks to this forum!
    And before the upcoming work day, I wanna ask if there is a possibility to change LIN movements generated via Symtech program into SPLINE. To be certain, I ask about those points which appeared in CL-DATA of CAM software. Greatly appreciate any help!

Advertising from our partners