Comparing SIGNAL to variable in interrupt

    Hi all,


    System details:

    KUKA KR 70 R2100

    KR C5 controller

    KSS 8.7.x (don't know specific subversion yet, as I'm currently working offline in KUKA.sim)

    KUKA.sim 4.1 and WV 6.0


    I want to compare a SIGNAL to a REAL as the trigger of an interrupt. I cannot use:


    INTERRUPT DECL 11 WHEN BoxTypeSensor <> BOX_SENSOR_LATCH DO FreeOfNextBox_ISR()


    As I need a tolerance between the two values of 0.1 at least to trigger the interrupt, since the SIGNAL is oscillating a bit.

    I have tried:


    INTERRUPT DECL 11 WHEN ABS(BoxTypeSensor - BOX_SENSOR_LATCH) > 0.1 DO FreeOfNextBox_ISR()


    But I'm prompted that the ABS statement is not allowed in an interrupt.

    Then I tried with a cyclical flag, but my BOX_SENSOR_LATCH value is not initialized before later in the execution, so the interpreter complains that it hasn't been initialized upon creating/declaring the cyclical flag:


    $CYCFLAG[1] = ABS(BoxTypeSensor - BOX_SENSOR_LATCH) > 0.1

    Any suggestions on comparing two values including a tolerance in an interrupt declaration?

    Quote from marlenehj

    Then I tried with a cyclical flag, but my BOX_SENSOR_LATCH value is not initialized before later in the execution, so the interpreter complains that it hasn't been initialized upon creating/declaring the cyclical flag:

    Just set the $CYCFLAG after BOX_SENSOR_LATCH is initialized. $CYCFLAGs can be assigned and redefined at any time in a program.

    exactly, expression used to trigger interrupt must be simple one such as variable or single comparison but not compound expressions. and this is where cyclical lags come in.

    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

    Thumbs Up 1
    Quote from SkyeFire

    Just set the $CYCFLAG after BOX_SENSOR_LATCH is initialized. $CYCFLAGs can be assigned and redefined at any time in a program.

    Thank you! Didn't know I could assign it at any point - I naively thought it needed to be declared at the declaration section.


    I've now assigned it after BOX_SENSOR_LATCH is initialized, and I get the following error:
    "Condition ABS(BoxTypeSensor - BOX_SENSOR_LATCH) > 0.1 is not monitorable."

    But I suspect this is due to the fact that I'm working purely offline in KUKA.sim, and I get no actual input from BoxTypeSensor. I might try with a small Python script to mimic an input.


    Thank you for your quick response. It's greatly appreciated :smiling_face:

    Hm... not sure I've seen that before. OL shouldn't make a different about the $INs, you'll just be dealing with a $IN that never changes state.


    How are BoxTypeSensor and BOX_SENSOR_LATCH declared? And where? I vaguely recall that $CYCFLAGs might have issues working with runtime variables -- that is, variables DECL'd inside a function/subroutine. These variables are temporary and local purely to that subroutine, and as soon as that subroutine is no longer in the call stack, that memory space is recycled. But since $CYCFLAGs are system resources, and thus permanent, connecting them to temporary variables causes conflicts.


    Variables DECL'd in .DAT files, OTOH, have their memory permanently allocated during the compile/link process.


    So, if your DECL BOOL or your SIGNAL are in the subroutine, rather than in the .DAT file of the module (or GLOBAL in another .DAT file), that might cause the issue you're seeing.

    the issue is that cyclical flag can monitor variables and IO but not call functions like ABS. it can evaluate readily available info that is already in variables. but it cannot call programs or functions to get the values.


    just rewrite your expression from

    $CYCFLAG[1] = ABS(BoxTypeSensor - BOX_SENSOR_LATCH) > 0.1 ; error


    to

    $CYCFLAG[1] = ((BoxTypeSensor - BOX_SENSOR_LATCH) > 0.1) OR ((BoxTypeSensor - BOX_SENSOR_LATCH) < -0.1) ; works



    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

    Thanks 1

    Yessss! I wouldn't have guessed that was the issue, but you're perfectly right, it was the ABS function that was causing the error. I've now rewritten the expression as you've stated, and there are no more issues.


    Thank you both SkyeFire and panic mode, I really commend the work that you do on here :smiling_face:


    Have a great day.

Advertising from our partners