Executing movement inside using an interrupt

emerald_geni · July 1, 2022 at 9:48 AM

Hi everyone,

i am trying to get a homing sequence working for my robot.

I have setup my CELL.SRC with an interrupt. which will be triggered by a homing button.

my questions are:

1)I have commented out the CHECK HOME and PTP HOME in my CELL.SRC. Since when the interrupt is triggered the robot would not be at home. Will this cause any unforseen issues?

2)While in interrupt i get $Advance and $GEAR JERK Variable write-protected in module BAS, Errors. how do i fix these?

i believe for $advance i can set a WAITFOR but im not sure whats the best way to do so. i have read the INTERRUPT threads in the manuals page as well.

I have tried initiating my interrupt_test.src from a .SUB as well and get the same errors as above.

MY CELL.SRC

Code

&ACCESS RVP
&COMMENT HANDLER on external automatic
DEF  CELL ( )

;FOLD EXT DECL
  EXT assytray();EXT EXAMPLE1 ( )
  EXT CYL();EXT EXAMPLE2 ( )
  EXT P15_inlet_to_platform45()
  EXT P16_inlet_to_rightassy()
  EXT P17_inlet_to_leftassy()
  EXT P18_recipe_rose()
  EXT P19_recipe_lavender()
  EXT P20_recipe_eucalyptus()
  EXT P21_recipe_teatree()
  EXT P22_recipe_sadalwood();EXT EXAMPLE3 ( )
  EXT P23_recipe_citronella()
  EXT P24_recipe_peppermint()
  EXT P25_rightassy_to_home()
  EXT P26_leftassy_to_home()
  EXT P27_platform45_to_home()
  EXT P28_execute_recipe_right()
  EXT P30_EOATchange_1_to_2()
  EXT P32_EOATchange_2_to_1()
  EXT P43_RFID_to_outletTray1()
  EXT P44_RFID_to_outletTray2()
  EXT P45_RFID_to_outletTray3()
  EXT P46_RFID_to_outletTray4()
  EXT P47_RFID_to_outletTray5()
  EXT P48_home_to_RFIDout()
  EXT P54_Assy_CB()
  EXT P55_Assy_CH()

;ENDFOLD 
  ;FOLD INIT
  DECL CHAR DMY[3]
  DMY[]="---"
  
  INTERRUPT DECL 20 WHEN di_bInitRecoveryfrmPLC == TRUE DO Interrupt_test ( )
  INTERRUPT ON 20 
  ;ENDFOLD (INIT)
  ;FOLD BASISTECH INI
     
  GLOBAL INTERRUPT DECL 3 WHEN $STOPMESS == TRUE DO IR_STOPM ( )
  INTERRUPT ON 3 
  
  BAS (#INITMOV,0 )
  ;ENDFOLD (BASISTECH INI)
  ;FOLD CHECK HOME
  ;$H_POS=XHOME
  ;IF CHECK_HOME==TRUE THEN
    ;P00 (#CHK_HOME,#PGNO_GET,DMY[],0 ) ;Testing Home-Position
  ;ENDIF
  ;ENDFOLD (CHECK HOME)
  ;FOLD PTP HOME  Vel= 100 % DEFAULT;%{PE}%MKUKATPBASIS,%CMOVE,%VPTP,%P 1:PTP, 2:HOME, 3:, 5:100, 7:DEFAULT
  ;PDAT_ACT=PDEFAULT
  ;FDAT_ACT=FHOME
  ;BAS (#PTP_PARAMS,100 )
  ;$H_POS=XHOME
  ;PTP  XHOME
  ;ENDFOLD

Display More

My Interrupt_test

Code

&ACCESS RV1
DEF  Interrupt_test ( )

INTERRUPT OFF 20 
MsgNotify("In Interrupt file",,)

$OV_PRO=5

;PTP to current Pos 
N1pos=$POS_ACT
PTP N1pos c_ptp

PTP interr_pos Vel=100; PDAT1 Tool[1]:GRIPPER Base[1]:assemplate;

INTERRUPT ON 20

END

Display More

**panic mode** · July 1, 2022 at 3:54 PM

Quote from emerald_geni

1)I have commented out the CHECK HOME and PTP HOME in my CELL.SRC. Since when the interrupt is triggered the robot would not be at home. Will this cause any unforseen issues?

"unforeseen" is a relative term. it totally depends on foresight of the programmer. some will know what can happen, others will be oblivious, do crazy things and repent later.

there is a reason for home check in CELL.SRC. that is to be used in EXT mode and in EXT mode there is no BCO (despite message suggesting that you should do a BCO). in other words when robot is started it will run from wherever it is to first programmed point without speed restriction. and high velocity collisions are usually spectacular with lots of carnage. that home check is meant to avoid it by at least making sure robot starts from same known point.

Quote from emerald_geni

2)While in interrupt i get $Advance and $GEAR JERK Variable write-protected in module BAS, Errors. how do i fix these?

take needed KRL programming courses. interrupts are powerful but there are restrictions. most of them are intentional due to architecture and considerations of motion planner. in general (any platform, not just KUKA or robots) anything that is done in an interrupt need to be VERY short and quick to execute (a blink). doing things like waiting, or anything that takes time to process is in general a bad idea. in case of KRL one need to avoid things like motions and certainly more complex things such as inline forms.

Quote from emerald_geni

i believe for $advance i can set a WAITFOR but im not sure whats the best way to do so.

no clue what that means. WAIT commands do not change $ADVANCE but they do cause advance run stop.

take needed programming courses. interrupts are powerful but there are limitations. most of limitations are intentional due to architecture and considerations of motion planner. in general (any platform, not just KUKA or robots) anything that is done in an interrupt need to be VERY short and quick to execute. in case of KRL one need to avoid certain things such as inline forms.

Quote from emerald_geni

i have read the INTERRUPT threads in the manuals page as well.

it's a start... a wrong one but it is a start nevertheless... before tacking advanced topics you should really get to know the fundamentals.

Quote from emerald_geni

I have tried initiating my interrupt_test.src from a .SUB as well and get the same errors as above.

of course... because you skipped the fundamentals.

*.SUB is an extension of a submit program.

submit programs can only run in a submit interpreter.

submit interpreter is a wrong interpreter in this case because it cannot execute robot motions in any shape or form. that ability is strictly reserved for robot interpreter.

inline form instructions are great to start or do some basic things quickly. but they are more complex and rely on code libraries and that makes them unsuitable for use inside an ISR. code in ISR need to be efficient and created by an expert. expert programmers need to account for and program everything themselves - no training wheels here (training wheels = inline forms).

an example of inline form instructions are programs created using standard template ("Module") which contains INI fold and pair of PTP HOME instructions.

all programs are supposed to start and end at HOME so all user code need to be between those two PTP HOME instructions. and this should clarify your first question about check home.

everything is done with certain reasoning and one should be aware of this before attempting to deviate. that includes CELL setup. i would say forget about the interrupts (for now) and try to understanding basic (and reasoning behind). practice and gradually do more challenging things.

for example if you want to do an automated homing, write program for it (not an ISR). make sure to cover all cases (and this will be hard). test it.... and once you are happy with it, use case in CELL to call it like any other program. your button press to home robot should simply be used to call specific case. btw your CELL program is incomplete. switch case block is missing.

emerald_geni · July 2, 2022 at 5:49 AM

Hi Panic mode,

Appreciate your time.

Quote from panic mode

take needed programming courses. interrupts are powerful but there are limitations. most of limitations are intentional due to architecture and considerations of motion planner

I have

Operating and Programming Instructions for System Integrators_KSS 8.5

KUKA Robot Programming 1

KSS_85_System_variables_en

KSS_82_83_CREAD_CWRITE_en

For reference, is there any other material that go in depth regarding the limitations of ISRs?

as for training, i have to travel to another country to get inperson training and its not possible for me at the moment.

Quote from panic mode

WAIT commands do not change $ADVANCE but they do cause advance run stop.
take needed programming courses.

Yes to prevent the Advance pointer from running off. I read it in the interrupt Manual page and had removed INI etc. as suggested from there, in my interrupt file. but i understand now that i cannot have any inline form instructions.

Quote from panic mode

or example if you want to do an automated homing, write program for it (not an ISR). make sure to cover all cases (and this will be hard). test it.... and once you are happy with it, use case in CELL to call it like any other program. your button press to home robot should simply be used to call specific case.

I have tried this method as well and it was the reason why i had to comment off CHECK HOME and PTP HOME in my CELL.SRC, since when homing in initiated my robot won't be at home and thus PGNO would not be executed.

Quote from panic mode

switch case block is missing.

I removed all the excess code not related to my question so its easier for you to read. but i do have a switch Statements below.

**panic mode** · July 2, 2022 at 6:04 PM

yes one can comment out the block that checks for home but this is not really necessary. this already has an IF statement and it is enough to toggle variable used in that IF statement.

advanced training (KUKA programming2 and 3) go over interrupts but ... things like Covid have ruined many opportunities to get the training in person.

so when it comes to alternatives... if you do have to learn on your own...

probably one of the best documents on this (and many other things) is the good old KRL Reference Guide v4.1. it may be old but this document is simply superb, it is still relevant and it is one of the best KUKA resources one can have. anyone using KRL programming will benefit from it.

in general when it comes to programming - some limitations are not necessarily obvious and must be deduced from multiple statements. this is where in-person training shines - one can get the insider knowledge, tricky parts and gotchas mentioned and explained.

an example of interrupt limitation that is probably not very explicitly stated in the documentation - ISR need to be something that is executed quickly. just do what need to be done (as fast as possible) and get out of the way. that should be obvious and many computer programming courses do state so but this is something that may not be written in every manual. one can compare that to a rabbit that patiently waits for the right moment then crosses the road as fast as possible. but things are not always that simple, this rabbit clearly did not get the memo.

for example if the main program runs and there is an interrupt, main program is paused, interrupt is processed, then main program continues. but if one interrupt takes long to process, there may be bunch of other interrupts that may interrupt it. there are several consequences of this. it is even possible that one ISR may never complete if it is interrupted often enough by other interrupts. but also there is a limit to nesting depth (stack). guess what happens when this limit is reached.... yes your program crashes.

so one then naively makes HIS interrupt higher priority one instead of making it snappy. guess what, it does not get interrupted by other interrupts (which get queued) but this also means that important things do not get done. i have seen tons of posts here by people creating their first interrupt programs and they make it the top priority and basically blocking all other interrupts.

Executing movement inside using an interrupt

Advertising from our partners

Anyware Robotics is hiring!

How to see your Job Posting (search or recruit) here in Robot-Forum.com

Tags