Interrupt not working when program is stopped

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.

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).

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.

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:

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.

Spline motions have option to check input on fly.

it is called "CONDITIONAL STOP". my SI manual mention this in chapter 10.

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.)

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?

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:

DEF interrupt_test( )
;FOLD INI;%{PE}
;FOLD BASISTECH INI
GLOBAL INTERRUPT DECL 3 WHEN $STOPMESS==TRUE DO IR_STOPM ( )
INTERRUPT ON 3
BAS (#INITMOV,0 )
;ENDFOLD (BASISTECH INI)
;FOLD USER INI
;Make your modifications here
;ENDFOLD (USER INI)
;ENDFOLD (INI)

;FOLD PTP HOME Vel=100 % DEFAULT;%{PE}
WAIT SEC 0.0

; Flag used to see if interrupt has been triggered
$FLAG[10] = FALSE

; input 3 can be triggered manually
INTERRUPT DECL 10 WHEN $in[3] DO interrupt_handler()
INTERRUPT ON 10

; Wait time to make sure interrupt is ready
WAIT SEC 0.1

move_func()

INTERRUPT OFF 10
;FOLD PTP HOME Vel=100 % PDAT1;%{PE}

END


def move_func()

;FOLD PTP P1 Vel=10 % PDAT2 Tool[1]:Tcp_Tool Base[0];%{PE}
;FOLD LIN P2 Vel=0.5 m/s CPDAT1 Tool[1]:Tcp_Tool Base[0] ;%{PE}
WAIT SEC 0

end


def interrupt_handler()
BRAKE
INTERRUPT OFF 10
$FLAG[10] = TRUE
RESUME
end

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

Quote from Fubini

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().

After the resume of interrupt_handler.

Fubini

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.