PTP AXIS weird behavior

    Hi,
    I'm using a KUKA kr10 1100sixx with compact krc4 running kss 8.3.35.

    I'm having a really tough time with this problem.
    I know from other robots (not kuka) that when PTP AXIS (AXIS is the AXIS type defined in KUKA), the robot should go explicitly to the angles I tell it for each joint.
    However, sometimes, when I issue PTP AXIS in a middle of a program (usually in order to change the wrist position (a5 >0 to a5<0 for example) it moves in such a way to preserve the STATUS of the previous position.
    It ignores the exact a is valus I give, and instead move to the position resulted from the axes I sent, but with different axes valus to keep the STATUS.

    It's driving me nuts :waffen100:

    I tried using PTP POS with different STATUS and TURN values, nothing works! The robots persist in keeping the last STATUS (a5 >0 to a5<0 for example).

    All I just want is to PTP AXIS to work properly -> move each axis to the exact location It's given.

    Does anyone know how to solve it?

    Thanks!!!

    Edited once, last by ManMan88 (December 24, 2018 at 6:28 PM).

    [size=2]post your code... sounds like you are thinking of AXIS bot commanding robot to mode to POS. [/size]
    [size=2]AXIS and POS are different structures. if you are specifying your target position as AXIS, then PTP will take go to to values you specified.[/size]

    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

    [size=2]and what is the axis position when you try to run this command?[/size]
    [size=2]what is the axis position when command completes?[/size]
    [size=small]and why do you think that status should change?[/size]

    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'll need to check it tomorrow, but as I remember, for example, moving from:
    {A1 41.4800,A2 -50.9000,A3 152.200,A4 -6.70000,A5 -10.3000,A6 -54.2600}
    to:
    {A1 26.0000,A2 -69.6000,A3 136.100,A4 -1.00000,A5 23.4400,A6 26.0300}

    would end with A4 179 and A5 -23.44 (maybey A6 is also different, and all the rest is the same)

    As I understand, A5<0 and A5>0 are different STATUS. But for some reason the robot persists on A5<0 in this example.

    Can it be a bug in KUKA's software?

    Edited once, last by ManMan88 (December 24, 2018 at 9:22 PM).

    [size=2]you suspect bug in software but you keep editing posts, share only cherry-picked bits and pieces and your story keeps on changing...[/size]

    [size=2]can you please stick on one version and keep your facts straight? it will help you and us keep track of what really goes on.[/size]

    [size=2]your post 2 suggests that A5=-10.3deg is a commanded (target) position. Then in post 4 you suggest that A5=-10.3deg is a start position and target is A5= -23.44deg.[/size]
    [size=2]then you say that robot moves A5 to +23.44 which i have hard time believing...[/size]

    [size=2]then you say that this happens in program that you execute in EXT mode. why don't you test your code in T1 first? what KUKA training did you have?[/size]


    [size=2]what is the position you move from?[/size]
    [size=2]what is the position you are moving to? [/size]
    [size=2]is robot able to reach it?[/size]
    [size=2]if you are using joint space, why are you bringing up status? Status and turn may change when robot moves but not all motions will cause the change. this is by design and it is explained in KUKA documentation.[/size]

    [size=2]if this was older robot i would question if wrist altered in any way (extension added or removed) but this is Agilus. [/size]
    [size=2]are you SURE your MADA is correct? are you SURE wrist was not involved in collision etc. (are the wrist belts slipping)?[/size]
    [size=small]Are you SURE your robot is mastered correctly? are you SURE correct axis moves (and moves correct angle) when you jog it? [/size]
    [size=2]Post photo of robot in both standard cannon position {A1 0, A2 -90, A3 90, A4 0, A5 0, A6 0},[/size]
    [size=2]and palletizer position [/size][size=small] [/size][/size][size=small]{A1 0, A2 -90, A3 90, A4 0, A5 0, A6 0}[/size]

    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

    Quote

    Are axis 4 and 6 set to endless? In this case the controller runs axis 4 and 6 to move minimal axis distances using a shortest path rule.


    How can I check it?

    I'll explain better the problem and how to reproduce it (it's long - BOTTOM LINE AT THE END OF THIS REPLY).
    As I mentioned earlier, this behavior happens for several cases, here I give an example just for one.

    Attached are the files which are in MADA folder, I did not change them.

    I start by running cell.src:

    the init_rsi and init_eki and eki_interrupt programs are attached.

    this is the clear camera program:

    Now I call program num 4 -

    Code
    return_tool(safe_pos_base2, return_switch_wrist2, approach_base_fast2, approach_base_slow2, pull_up2, safe_pos_base_ax2)

    the values of these passed vars are:

    The return_tool program is:

    This program perform as I would expect (however, I can reproduce the behavior here if I replace PTP return_switch_wrist with PTP safe_pos_base_ax)

    Now, I run program number 0:

    Code
    pick_tool(safe_pos_tool1, change_wrist1, approach_tool_fast1, approach_tool_slow1, take_out_tool1, rotate_tool1, safe_pos_tool_ax11)

    these are the values of the vars:

    This is the pick_tool program:

    The weird behavior occurs at the beginning, with: PTP safe_pos_tool_ax

    #############################################################
    BOTTOM LINE: THE PROBLEM THAT OCCURS:
    #############################################################
    I move with PTP from:

    Code
    AXIS return_switch_wrist2={A1 -29.5, A2 -50.6, A3 139.6, A4 20.86, A5 -3.45, A6 -98.05}


    which gives the position ~=

    Code
    {X 378.2,Y -210,Z 246.1 A 131.6,B -0.04,C 174.70}

    to:

    Code
    AXIS safe_pos_tool_ax11={A1 26.0000,A2 -69.6000,A3 136.100,A4 -1.00000,A5 23.4400,A6 26.0300}


    which should give the position of: ~=

    Code
    {X 411.500,Y -200.800,Z 382.0 A 180,B 0.0,C 180.000}


    (Note, I set #VEL_PTP 0.1 because the robot stops due to a4 crossing max vel if it's moving faster(because of singularity?!?!))

    WHAT HAPPENS IS:
    The robot move to:

    Code
    {A1 26.0000,A2 -69.6000,A3 136.100,A4 -181.00000,A5 -23.4400,A6 206.0300}


    and the position is: ~=

    Code
    {X 411.500,Y -200.800,Z 382.0 A 180,B 0.0,C 180.000}

    it means that it rotates A4 -180deg and A6 +180 deg, and it is doing it very fast, as if it is crossing a singularity point with LIN motion

    well, that's it. I really appreciate your help!

    Quote

    Post photo of robot in both standard cannon position {A1 0, A2 -90, A3 90, A4 0, A5 0, A6 0},
    and palletizer position [/size]{A1 0, A2 -90, A3 90, A4 0, A5 0, A6 0}

    did you mean: palletizer position [/size]{A1 0, A2 -90, A3 90, A4 0, A5 90, A6 0} ?

    attached are the images

    I have some more information that I've just noticed.

    During the described motion, A5 starts with -3.45 and during the motion it approach the value of 0 (where A4 and A6 spins fast) but then moves to the negative side again towards -23.44.

    It seems to behave just as a LIN motion, but the velocity is controlled by VEL_PTP

    Quote from ManMan88


    did you mean: palletizer position {A1 0, A2 -90, A3 90, A4 0, A5 90, A6 0} ?


    yes, mastering seem to be ok.
    your machine data is for correct robot type.
    i still find that your program and description are too convoluted to follow.


    if you have an issue with PTP AXIS, i would suggest writing separate small program
    with just 2-3 lines of code that replicates the problem (or proves that problem is not the PTP).
    no interrupts, no RSI, no global variables... just a small test program.

    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 had some time today to try and simple down the problem.
    I found out the if I don't use the line:

    Code
    RSI_MOVECORR()

    The problem disappears. But I must use this feature, so I need to find some solution.
    I'll try using some other RSI commands (maybe RESET?) to solve it.

    I'll update later with a detailed short program that reproduces the problematic behavior.

    I was able to find a solution :cheer:.

    Apparently the problem is that I use RSI with relative Cartesian correction.
    This correction is accumulated and applied to each motion command given to the controller.
    Then, when a PTP motion is issued, I guess the controller ignores it, and instead commands the robot to move to the corresponding Cartesian position plus the accumulated RSI correction.

    I tried using RSI_OFF and then RSI_ON in order to initialize to 0 the accumulated correction, but it did not solve it for me (I think it should).
    However, the way I solve it is using RSI_OFF, then issue the PTP motion, and then reactivating the RSI with RSI_ON.
    For example:

    Code
    GLOB_RSI_RET=RSI_OFF()
   IF (GLOB_RSI_RET <> RSIOK) THEN
      HALT
   ENDIF
   PTP change_wrist
   GLOB_RSI_RET=RSI_ON(#RELATIVE)
   IF (GLOB_RSI_RET <> RSIOK) THEN
      HALT
   ENDIF

    Many thanks to anyone who took the time to help!

Advertising from our partners