Program stuck executing motion command (LIN_REL), but robot is not moving.

    Greetings

    First time poster. I've read the READ FIRST post and will try to give all the relevant information. If something is missing I can specify.

    Problem description

    I've been programming a KUKA KR 120 R3200 PA robot arm. In one of the sections of the program the robot arm starts descending and waits for a signal ($IN[6]) from a ultrasonic sensor to trigger an interrupt. The interrupt switches a boolean variable in the main program, which the program interprets as a signal to stop descending. This works 99% of the time, but there are some (seemingly random) instances where the robot just stops moving after the interrupt is triggered and doesnt continue executing the rest of the program. When I look at the main pointer it is still at LIN_REL {Z -10} portion of the program (aka still descending), but the robot itself is at a standstill. When the program is reset and run from the beginning, this stopping problem persists, but when I reboot the system (with "Reboot control PC" button) the problem disappears and the rest of the program is executed as intended.

    Additional information: When the issue occurs there are no errors displayed on screen (see image below). All the drives seem to be active, because when I move the robot and then press the play/start button the robot moves to the previous position. I've also checked the $VEL and $APO variables which seem to have normal values, meaning that the speed, acceleration values are ok. Also when observing the $POS_ACT value there seems to be no change, so the robot is not moving even in the slightest.

    According to one of the operators the issue occurs when the program is reset and ran after one of the safeguards is activated and the program stops the robot. The safeguard is a pressure cylinder on the robot which stops the robot when it presses too hard against something. It is possible that this safeguard isn't triggered on time and the KUKA internal safeguards stop the robot, but from what I've seen my safeguard catches the issue and the program reset works fine.

    Thoughts: I have a gut feeling that it has something to do with the interrupt (as it happens right after interrupt is triggered), but can't figure out what I'm doing wrong. The robot is operational 5 times a week around 5 hours a day and this kind of problem occurs once almost every day. Any guidance on how to solve or debug this issue when it reoccurs is much appreciated.

    Code and screenshots

    Descending to pack (code)

    Code
       PalletOriginPos=$POS_ACT
   BAS(#VEL_CP, 2.0)
   ; MÕÕDAB KÕRGUSE (Z KOORDINAAT)
   StopZMoveOnInterrupt=TRUE
   INTERRUPT ON 17   ;JYRGEN: Ultraheliandur.
   WHILE StopZMoveOnInterrupt==TRUE
      LIN_REL {Z -10} C_DIS
   ENDWHILE
   INTERRUPT OFF 17   ;JYRGEN: Ultraheliandur. 
   PalletOriginPos.Z=HitPoint.Z-78

    Stop descending interrupt declaration and code:

    Image of program on SmartPad when robot is not moving but program is running:

    robot-forum.com/attachment/31109/

    Robot information

    Robot "KUKA KR 120 R3200 PA"

    Firmware version "8.6.6"

    Software Architecture "KRC4"

    Interrupt off 17 should be at the beginning of heightmeasure(). Otherwise you can get one or more interrupts in between the interrupt routine, some kind of recursion.

    But things like that should be done in a different way: use the interrupt with a resume, use search function of forum to find many examples.

    The problem in your solution is, that after the interrupt in mid of the 10 mm the robot will do one some more movements, the amount depends on the value of $Advance.

    hermann Disabling the interupt earlier is a good suggestion. Will make that change and update this post, if this fixes the issue.

    To your second point, I am aware that the robot moves downwards after INTERRUPT 17 is triggered, but this "additional" movement after the interrupt causes no problemse. Currently RESUME variant can not be implemented easily and therefore changing this is not a priority (unless it could fix the issue at hand).

    hermann When moving downwards on the Z axis, the pressure cilinder will generate an interrupt when it encounters an object and presses on it. This INTERRUPT is enabled at the beginning of the main program and can be considered a stop criterion.

    I will try to rework the code today so it will use RESUME and add some additional stop criterion coordinates wise.

    UPDATE (Post #3): The operator seems to think that the change, where I turned the interrupt off immediately after function call, might have done the trick. Since the error was this rare of I am yet to be convinced, but will see.

    Greetings from a fellow estonian.

    Are you sure you cannot do the "by the book" solution with essentially three programs.

    - Main()

    - search()

    - found()

    The concept is that you declare the interrupt in the main program.

    Call a search() from your main program

    The interrupt is turned ON in the search program

    This search program is tasked to go to the bottom of your stack... PTP SeachEnd. (You are just looping Z -10mm)

    You have a "WAIT FOR TRUE" at the end to prevent the advance run pointer to process anything more.

    "When the RESUME statement is activated, the advance run pointer must not
    be at the level where the current interrupt was declared. To prevent this, an
    advance run stop is triggered here via WAIT FOR TRUE."


    Code
    DEF PROG()
INI
...
INTERRUPT DECL 21 WHEN $IN[15] DO FOUND()
PTP HOME
...
SEARCH()
...
END
    Code
    DEF SEARCH()
INTERRUPT ON 21
SPLINE 
SPL START_SEARCH 
SPL IN_BETWEEN 
SPL END_SEARCH
ENDSPLINE
WAIT FOR TRUE
...
END

    You have a third program Found() that turns the Interrupt OFF, brakes and reverses back to the point where the interrupt was called because braking takes some time and distance.

    Code
    DEF FOUND()
INTERRUPT OFF 21
BRAKE
LIN $POS_INT
... ;The robot grips the found part.
RESUME
END

    RESUME causes the main program to be resumed after the part has been
    gripped. Without the RESUME statement, the subprogram SEARCH() would
    be resumed after END.

    Hello :smiling_face:

    Thank you for your input. This way of doing things works. I hope that implementing a INTERRUPT-RESUME system and turning the INTERRUPT off right after method call works. Since most of the factory side staff is on holiday I cant be 100% sure but I do believe that the issues pointed out solved the problem.

    Thanks hermann and Koppel.

Advertising from our partners