LIN_REL Includes off Axis Tilt

    Hi I'm using a KR500 with a KRC 4 with KSS 8.6.5.


    I am handling some 5'x12' sheet metal with a vacuum gripper and am trying to move from a position with the sheet parallel to the ground into one where the sheet is perpendicular to the ground. The relevant section of code looks like this:


    Code
    $VEL.CP = .1
$ACC.CP = .1
LIN_REL {Z 1000}
LIN_REL {X 1000}
$OV_PRO = 30
LIN_REL {A -90}
LIN_REL {B -90}


    During the LIN_REL{B -90} move, the sheet tilts in the -C direction about 10-20 degrees before correcting and completing the 90 degree move to where it is supposed to end up. I want the edge of the sheet to remain parallel to the ground throughout the duration of the move. I know the robot can make this move because I can jog it through the exact series of moves I want it to make in T1 mode and the tilt is not there. I've included a GIF of the move in question. What am I missing here?

    are you using correct coordinate system? the way you programmed it, rotation is done about base but position when you start rotation is not square with the base. why not rotate using tool coordinate system?

    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

    I really dislike _REL commands as they start over if you block select them, and just use the current position as the source. Calculating/offsetting the moves with the geometric operator is far more robust. Also using $OV_PRO to adjust the speed is not a very good solution for atleast 2 reasons, 1. the user can change it. 2. It happens when the advance run pointer runs over the command, not in between the moves where you put it unless you really force the ARP to stop.


    If you want the actual edge of the sheet to stand in place while flipping you just make/calculate a tool that has its coordinate system aligned and on the edge of the sheet. And use that tool while making those moves.


    another tip would be using SPTP and SLIN instead of the old motions, you get access to $DIST_NEXT with SPTP moves (that may come in handy), TRIGGER WHEN PATH works on SPTP and also WITH statements can shorten your code a bit. Disregarding all the fancy stuff that the newer motion types actually bring.

    Quote from panic mode

    the way you programmed it, rotation is done about base but position when you start rotation is not square with the base.

    Before the rotation, the orientation angles with respect to the base are {A 135, B 0, C 0} so my understanding is that if I rotate with LIN_REL{B -90}, after the move my rotation angles should be {A 135, B -90, C 0} and A and C should remain constant throughout the move while only B changes. Is that incorrect? I haven't tried changing coordinate frame yet, I figured I was doing something fundamentally wrong.

    Quote from hermann

    Make a quick test and try two movements for 45 degrees.

    I broke down the move into smaller steps. The smaller the steps the smaller the intermediate unwanted tilt. This may be the solution but I'd prefer to understand what is going on and truly correct the issue.


    I 'm ok with the edge of the sheet moving. The real issue is I want to understand exactly where it will be in the future and why so that when the workspace has more stuff in it later or I carry a bigger sheet or a sheet isn't gripped straight it won't crash. Thanks for the info on motions, I'm reading about them now.


    Quote from Hes

    another tip would be using SPTP and SLIN instead of the old motions

    SLIN completely fixed the problem!!!!! It uses a different path planner right? That would explain it but wow what an easy solution, literally add one letter to the code. I was having difficulty changing the speeds multiple times but now that I have my path doing what I want I'll revisit and get rid of the $OV_PRO.


    Thank you to all

    Edited once, last by steezus ().

    Post
    RE: Kuka Axis 6 as mobile lathe
    Option 1 would definetly be the easier one. In case of the second option you need to know exactly how orientation control works on a kuka robot. This is not straightforward since the Eulerangles ABC can not be treated seperatly. For example if you want to turn around z axis it is not sufficient to simply modify A and BC need to be adapted accordingly. Hence values ABC will have in general exactly the desired values at start position and target position but not inbeetween. Also using circs will…
    Fubini


    Post
    RE: Limit rotational speed on LIN move
    Swivel and Rotation is special type of orientation transistion that allows to reach any orientation on a half sphere by two degrees of freedom. Think about holding a pen on its tip between thumb and index finger in a fixed position. The pen itself is the fixed axis. Now you can either rotate the pen by moving thump and index finger against each other or turn/swivel it by moving your wrist.

    Fubini
    Fubini


    Unfortunatly orientation control is not as simple as you expect. Is done using rotation and swivel with respect to a qualified axis usually the tool x axis.


    Fubini

    starting with your post #5


    is this checked or just guessed?


    If you want to do any rotation do the correct calculations!

    Sometimes Math is smarter than you - Iearned it the hard way)

Advertising from our partners