Interrupt and Resume Program Control

RESUME sends the program pointer back to the level where the Interrupt was declared. Could be one level up, could be ten. So if Main has the DECL INTERRUPT, then calls Sub1, which calls Sub2, which calls Sub3, which calls Sub4, and Sub4 is where the program pointer is when the Interrupt fires, the program pointer will jump back to Main, one line after the call to Sub1, once the RESUME command executes.

So you get a lot of control over what the program does, but you also have to structure your programs, subroutines, and interrupts very carefully, with this in mind.

Quote from macraesk

It has a $advance error and $gearstop error on the interrupt program

This is no error message of the robot. You should describe the issue clear and precise. Do you get a compile error, or a runtime error, and what exactly are the messages.

Quote from macraesk

Is the interrupt program suppose to formatted differently than a normal subprogram?

No.

first of all, do your programs work otherwise - if interrupt logic is removed? this is easy to check and confirm if messages are result of something else or interrupts.

also your interrupt strategy simply cannot work for several reasons.

you can NOT use RESUME command with GLOBAL interrupt.

you are not taking care of advance run pointer.

you are using input 22 to trigger start of the search, instead of using it to end the search, so if the search is started robot would keep on moving and crash into target it looks for. etc....

"pointer" here is an instruction pointer.

an example of pointer is a little arrow that follows program and shows you what line is being executed. but there are actually two of them....

the arrow you see on the HMI is a main instruction pointer which executes motion and few other things.

another is advance run pointer, it is a scout or GPS that runs ahead and gives clues for motion planner to compute path for robot. this is happing (and maybe it also executes few things so main pointer does not have to). if you think of a advance run pointer like a dog on a leash, $ADVANCE variable tells the length of the leash (0-5 motion instructions, other instructions are ignored). default is 3. so advance run tries really hard to be ahead... at least one motion.... which is good enough to have smoothly blended motion segments)... but once it is ahead, pressure to run forward and explore drops so leash is not always stretched to that permitted length.

if the pointers are in different blocks of code at them moment RESUME is executed, it is possible (and very likely) that program will crash and burn...

btw you can also declare signal and look at group of inputs as an integer. then you don't have to have all those IF statements before SWITCH.

it is also cleaner, your code does not seem to account for more than one input on at any time (missing cases in SWITCH?)

you mentioned reading manual but not specifying which one. i have several version of programming manual for system integrators for KSS8.5. one i normally refer to is V7 from 2019. chapter 11.10.5 has example with RESUME.

oh, and you should not use $POS_ACT_MES to check position. by the time program gets there robot already traveled some distance. use $POS_INT, even if instruction is processed later (you have there 1 sec delay), it will still tell you same position ... not where robot is now but where robot was when input was triggered..

Quote from panic mode

if you think of a advance run pointer like a god on a leash,

Now that's a proper ambition for an engineer Inspirational!! Thank you.

Juar check older discussions, this was posted several times.

Think using that much movements in an ISR is not a good idea. Specially if you want to cancel the job and move to home.

Have a look at: RE: taking Robot to Home Position in EXT mode?

and of course the whole thread. May be you can use something from that thread.

still way too many things are in there, how about this

DEF INTER( )
  INTERRUPT off 20
  Brake
  PTP Xhome2
  RESUME
END

I recommend a

WAIT FOR TRUE

after RESUME, to prevent the advance run pointer to leave the sub-routine

you need to interpret error... which line of code it really is... line numbers in message and display rarely coincide with KUKA.

so clearly interrupt does get triggered but ISR is not exactly your regular program, there are some peculiar things about it to keep in mind.

btw. i see no instruction that should be a problem in ISR so you are doing something wrong in the main program, probably not initializing motion parameters since we stripped them out from ISR. also you need to ensure BCO before doing anything else anyway. are you sure you did?

here is an example of RESUME command in action. note that motion parameters are initialized and BCO is done BEFORE doing anything else (like using interrupt). since i did this in OL, i used jog speed as a trigger because did not want to bring variable display. i also display messages so you can check timestamps of each part. and interrupt is edge triggered... so the jog speed was already high (at or above threshold) so first it had to be reduced bellow 50, then increased to trigger the interrupt.

Quote from Mentat

Now that's a proper ambition for an engineer Inspirational!! Thank you.

been there, done that

Quote from Florida

I recommend a

WAIT FOR TRUE

after RESUME, to prevent the advance run pointer to leave the sub-routine

why?

ISR does not need that. this should be added at the end of a subprogram that is aborted by RESUME.