Interrupt and Resume Program Control

    KRC4

    KSS 8.5.8


    I have a fairly simple question that I seem to cant find clarification in the manual. When the Interrupt condition is completed and it resumes, does it go to the program the interrupt was declared on or the program that was interrupted?

    For my situation the Kuka has one Main program and a multitude of subroutines, so what I want to do I would declare the Interrupt in the main and then signal an interrupt the in a subprogram the interrupt calls the Homing and goes back to the main routine after the interrupt is complete. Is this correct to assume this is how Interrupt and Resume work or would I need different style of logic?

    • Best Answer

    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 SkyeFire

    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.

    Actually after implementing it there seems to be a few issues,

    It has a $advance error and $gearstop error on the interrupt program, Is the interrupt program suppose to formatted differently than a normal subprogram?

    Quote from hermann

    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.

    The final error is $Gear_Jerk variable write-protected in module, BAS line 1131

    Main Code

    Interrupt Program

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

    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

    Remove the Interrupt section and the code work fine.

    Quote from panic mode

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

    Can you Expand on the "Pointer" and the trigger event further, When reading the manual it states that you should trigger it.

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

    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

    To the pointer makes sense, To the code most of it was missing since i had a character limit. I just placed the important part in it. But there is checks and balances.

    Quote from panic mode

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

    I think POS_ACT_MES is what i need since i don't care about where it is when it when the Interrupt function is triggered, I care about where it is when it starts the program. Were dealing with molds and i rather not slam into them while its homing.

    Do you have a good example of how this function is written, i would love to take a look at a working real life application

    Quote from hermann

    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.

    Yeah i tried to make it simpler so and in that but now I have an error,KSS01425 Instruction sint() inadmissible (module INTERline:3)

    The simplified code

    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.

Advertising from our partners