Interrupt not working when program is stopped

  • Hello guys,


    Im haveing a issue with the use of interrupt, tried to search the forum but couldn't find the answer to this specific case.


    KSS version: 8.5.6

    Robot: KR 120 R3100-2


    The problem happens when the program on the robot is stopped either because of operator safety is broken or the robot program is stopped on the KCP. If the trigger signal for the interrupt gets activated while the robot program is stopped, the interrupt will not be triggered before the next motion without approximation or something else stops advance runner.


    So this kind of ruins my failsafe, cause I got a machine that the robot works on that isnt ready anymore if the operator safety is broken since it then will loose vacuum, and when starting the cell again we have to do some things on the PLC to make it ready for the robot again. But the robot keeps on going all the way till the advance runner stops and if that occurs the robot would crash with the machine. In my interrupt routine I only have brake signal to stop the robot and a WAIT FOR the machine to be ready again.


    When the robot program is running the interrupt works as planned, as soon as we get the signal for the interrupt the robot does exactly as planned and the interrupt routine is called.


    So the code on the robot is like this:


    Wait for machine ready


    Turning interrupt ON


    Local home position for machine


    Stopping program here, and signal that triggers interrupt occurs.


    Approach position for machine


    In position for machine (motion without CONT)


    Interrupt will be triggered and robot goes into interrupt routine.

  • Place your Ad here!
  • not sure what the problem is but....

    if you want some code to work (do something) even when robot interpreter is not running - don't put that code into robot interpreter.

    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

  • Couple options here. You could add the signal settings you need to the User sections of IR_STOPM, which gets called by most fault-based program halts (assuming you're using the standard templates). It also has a "restore" section that executes when the program is resumed. It's used a lot in MIG and laser welding, to avoid burn-through but also enable resuming a weld without interruption.


    Even if IR_STOPM isn't suitable for your purposes, studying it and how it's called via interrupt can be very instructive.


    Second option would be to use the Level 0 interpreter (SPS or Sumbit).

  • Couple options here. You could add the signal settings you need to the User sections of IR_STOPM, which gets called by most fault-based program halts (assuming you're using the standard templates). It also has a "restore" section that executes when the program is resumed. It's used a lot in MIG and laser welding, to avoid burn-through but also enable resuming a weld without interruption.


    Even if IR_STOPM isn't suitable for your purposes, studying it and how it's called via interrupt can be very instructive.


    Second option would be to use the Level 0 interpreter (SPS or Sumbit).

    Yeah I could do something in the submit. But I tought interrupts would work even tough the program is not running. I tought the robot checked for changes in the signal used in the interrupt also when the program is not running. And since the robot runs the interrupt program on the next fine point or wait sec then it has to know that the signal that triggers the interrupt has been set. Find this a bit strange tbh.

  • Since Interrupts in the Level 1 Interpreter are often used for initiating motion, KUKA probably made the decision that allowing L1 interrupts to be triggered when the interpreter was stopped to be a bad idea. There are lots of times, especially during program/debug, where someone might walk away from a robot in T1 for an hour, then come back to it and try to resume where they left off. If, during that time, some transient event had (unbeknownst to the programmer) left an interrupt "hanging fire" in the halted robot, the results could range from expensive to downright dangerous.


    Basically, since the SPS was available, the L1 interpreter's primary job is (safe, predictable, and reliable) motion control, and there really wasn't much (if any) customer demand for "halting state" L1 interrupt servicing, I suspect KUKA went for the choice with the highest safety and lowest technical risk.

  • interrupt is just a way to call subprogram.

    you can call subprogram using either static linking or interrupt.

    first option means sub is called every time main program reaches certain point.

    second option means sub is called when certain condition is met... not necessarily in same place.


    when the interpreter is stopped, then main program as well as all of its subprograms are no longer executed - regardless if statically linked subs or ISRs.


    so if you want some code to do something, don't put it in a task or interpreter that may not work when you need it.

    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 will see if I find a way to solve this using the SPS. I have a tight cycle time on this cell so I cannot afford the robot to stop.


    As I tried to explain earlier this problem occurs when the operator safety is broken when the robot has passed its signal check to see if the machine is ready. The machine then will loose its air pressure since it can be dangerous with pressure on, hence machine is not ready for robot anymore. Then when starting again robot will continue where it left and it still believes the machine is ready, which will result in a crash.


    One thing I can do is checking the ready signal again right before going into the machine, but then I would get a little stop on my motion since I have to stop to check the signal. Which is something that is critical for my cycle time.

  • This sounds like something that could be solved using IR_STOPM, in particular the recovery section. You would have to set a flag in your regular program to indicate when this condition needs to be watched for, and in the recovery section of IR_STOPM put a IF Flag THEN WAIT FOR MachineReadyInput type of logic.


    Another option would still use that flag, but use the SPS to monitor it and the input, and "stop" the robot by manipulating $OV_PRO:

    Code
    IF Flag AND NOT MachineReadyInput THEN
      $OV_PRO = 0 ; could use a "$CMD STOP" here, but that would require an external start to recover from
    ENDIF


    Or, instead of setting a flag in your regular program, you could set up a WorkSpace and use that to monitor the robot's physical location in realtime, and halt the robot any time the robot is within a certain distance of the machine and the machine-ready input is not active.

  • Hello,


    May I ask if in this case after safety broke, Program start again interupt was not trigger and we want to Skip the motion, What should we do?


    More specificly when we search for workpiece we go down until motion interupt by signal. However after safety was broke and robot starts again. Interupt did not happened

  • read programming manual and choose proper recovery. if some program phase was not performed correctly, one can react in a suitable manner (abort, retry, ask for attention and let human decide etc.)

    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

  • Hi,


    I know this is an old topic, but have a similar problem as the original poster, so I can add some details. Maybe this can help other people that may encounter it.


    I have made a test where I make a linear movement between two points. Lets call them P1 and P2. Before P1 I enable an interrupt. The interrupt handler calls BRAKE, so if the interrupt is triggered between P1 and P2, the robot will not finish the movement. So far, so good.


    In our office we have two KRC4 robots. A KR6 running KSS 8.3.174 and a KR10 running KSS 8.5.385


    During the test I release the run button while the program is between P1 and P2 (I am running in T1 mode) so that the program stops. I then manually trigger the interrupt condition (by pushing a piston back).


    The behavior is not the same on the two robots. On the one running KSS 8.3, the interrupt routine will be activated as soon as I press the run button again (this is what I want!).


    On the one running KSS 8.5, the interrupt routine will be triggered at the end of the movement, so in P2 - and it doesn't matter if the interrupt signal is switched on and off several times on the way from the "stop" point to P2.


    However, if I on the KSS 8.5 robot release the run button, and press it again without triggering the interrupt, and then trigger the interrupt when the program is running again, then it works as it should (robot stops immediately).


    As far as I remember, the behavior on our KRC2 robots is the same as on the KSS 8.3 robot (I haven't tested this recently).


    I find this difference in behavior between KSS 8.3 and 8.5 pretty weird. Does KUKA release changelogs/ release notes for the KSS software, so that one can see what the differences are between the different versions?


    /RoboticsMan

  • before we go down the rabbit hole and question what KUKA has done... how about you show us what you have done? are you sure that code on both units is really the same?

    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

  • Well, I cannot show you the original code, since that is part of a bigger system. So I have now boiled it down to a small example, and tested this on both robots. The test gave the same result as I mentioned earlier.


    I had to redo the movements on the robot with KSS 8.3, (since it didn't understand the movements in the file from KSS 8.5) but otherwise the program is the same.


    The code:


  • You should take care that the advance run pointer stays inside the Interrupt. This has been discussed multiple times in this forum and is a common programming error with Interrupts.


    Fubini

    Just to be sure, when you say "inside the Interrupt", do you mean that I should have an advance pointer stop before I disable the interrupt? Because I have that in line 38, in move_func().

  • Program looks ok to me. I think the issue is with testing conditions. Do not stop program... Keep it running... do not pause to trigger the interrupt. And make sure input is off before each test.

    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

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

Advertising from our partners