KUKA Dynamic Movementparameters

  • Hi,

    I'm a previous ABB-Programmer and have just started to program KUKA-robots.


    When programming ABB-robots each movement has to have the given parameters like velocity, aproximation-distance, tool and work object (Base in KRL)


    The example I'd like to use is:

    Code
    MoveJ Offs(PickPosition,0,0,250),v2500,z50,tGripper1,wWorkobject; (This position is far away from the actual "PickPosition")
    MoveL Offs(PickPosition,0,0,50),v800,z30,tGripper1,wWorkobject; (This one is closer than the previous point with less distance, velocity and aproximation-distance)
    MoveL Offs(PickPosition,0,0,10),v100,z10,tGripper1,wWorkobject;  (This one as well)
    
    MoveL PickPosition,v50,fine,tGripper1,wWorkobject; (The actual "PickPosition")


    KRL Corresponding I assume would be:


    Code
    PTP {X 0,Y 0,Z 250,A 0,B 0,C 0} : xPickPosition C_DIS
    LIN {X 0,Y 0,Z 20,A 0,B 0,C 0} : xPickPosition C_DIS
    LIN {X 0,Y 0,Z 10,A 0,B 0,C 0} : xPickPosition C_DIS
    LIN xPickPosition


    How do you code this when for example want to lower speed and approximation while getting closer to the point like the ABB-example above? (In a nice-code-way)

    I Could assign the velocity and APO in-between the movements but it would look like crap and would not be easy to re-use.


    I could make a DEF/DEFCT which is like the ABB-way and use Position, Approximation etc in the program-call but I'm not into doing that either, when programming KUKA-robots I'd like to do it like it should be done (?) :D


    This is not a problem, just a tip on how you guys do this? (Maybe most of you use the same speed & aproximation during the entire program cycle idk)

    Edited 2 times, last by EXOR ().

  • AD
  • Also I'm not into using inline forms because its lack of offset functionality and "dynamic" PDAT/LDAT.

  • If you use spline type movements you can add the parameters behind a WITH, e.g.


    SLIN XP1 WITH $VEL.CP=0.2, $ACC_AXIS[1]=100, .... C_SPL


    Also using the predefined BAS.SRC functions can be handy, e.g.


    BAS(#CP_PARAMS, 0.2)

    LIN XP1


    For geometric offsets you can use the : operator, e.g.


    PTP XP1:SHIFT C_DIS

    PTP SHIFT:XP2 C_PTP


    with SHIFT before or after the : depending whether you want to shift in base or tool system.


    At best download system integrators manual from kuka xpert portal, see pinned topic READ FIRST in this subforum.


    Fubini

  • In KRL, unlike RAPID, motion commands are completely separate from Velocity, Tool, Base/WObj, etc settings. Setting the motion parameters is separate executable lines from the motion commands themselves. Even if you're not using ILFs, you can still make use of the system BAS functions to make this easier.


    You don't have to avoid ILFs if you want to do offsets. ILFs just don't include offsets, but you can still do them. Also, your example KRL is not going to do what you want -- it will generate a tool offset, not an offset in the active WObj/Base:

    PTP P1 : {X 0,Y 0,Z -100,A 0,B 0,C 0}

    PTP {X 0,Y 0,Z -100,A 0,B 0,C 0} : P1


    The order matters, since that's not an offset command, it's an actual mathematical equation. It works like a function call, the result of the equation goes into the PTP/LIN command. The offset after the point takes the point, and shifts along the point's Z axis. The second line applies a shift along the Z axis of the active Base/WObj to the point, before taking the point's orientation into account.


    To use offsets with ILFs, the simplest method is to use Base offsets. This works just like applying offsets to a Work Object in RAPID, except KRL Bases don't have a second OFrame element, only the primary frame. So, something like:


    The key here is that Base2 is being written to. BASE_DATA[1] is your "reference" base, set up once, and should never be altered by the program. This can work for "raw" KRL, or for ILFs. You simply have to alter the Base values before the ILF executes.


    Doing tool offsets with ILFs is harder -- either you dynamically apply adjustments to the TOOL_DATA value, or apply offsets to the actual E6POS value of the point itself, before the ILF.


  • Well thanks for that input!

    Any tips on how to lower/set speed and approximation during continuous movements else then the stuff fubini just wrote?

  • you could make subprograms called MovJ, MovL and function Offs that behave like what you are familiar with.


    for programming info check key manuals as mentioned in READ FIRST. your friends are

    Programming Manual for System Integrators

    System Variables Manual


    both should be for your KSS version but most of info will apply even if you use documentation for a very different version. few variables have changed over time and newer KSS have more motions instruction at disposal (two motion planners).

    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

  • Any tips on how to lower/set speed and approximation during continuous movements else then the stuff fubini just wrote?

    Not really. If you have a series of motions, and want each motion to have different speed/accel/approximation/tool/base settings, you have no choice but to add non-motion KRL commands in between the motion commands to set those values. If you unpack a motion ILF, you can see how to do this. Frankly, just making your own calls to BAS, like the ILFs do, is probably the easiest approach. Making your own subroutine that accepts values for TCP velocity, joint velocity, approximation radius, accel, Tool, Base, and then sets CPDAT_ACT, PDAT_ACT, and FDAT_ACT before calling BAS will save the most linecount in your motion program.

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!
Register a new account
Sign in
Already have an account? Sign in here.
Sign in Now