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.

  • 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
    1. IF Flag AND NOT MachineReadyInput THEN
    2.   $OV_PRO = 0 ; could use a "$CMD STOP" here, but that would require an external start to recover from
    3. 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.

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