Interrupt not working when triggering condition is satisfied at activation time?

    Hello,

    KSS5.6, KRC2, KR5002MT

    I'm having a hard time to understand why one of my interrupt is not triggered.
    It seams to me that when I activate my interrupt, if the triggering condition is already satisfied then the interrupt will never get triggered.

    Just a word about the context :


      • I am launching "actions" from the KCP through a set of softkeys (UserTech / KFD).

      • An action is launched by the SPS through CWRITE($CMD, state, mode, "RUN R1\mdi()").

      • Each action as an ID (eg. action.ID = 101), used to run the corresponding code through a switch condition.

      • Each action is valid for a given set of modes (eg. action.ValidModeOP = 'B0011' = EX|AUT|T2|T1 means the action can execute only in T1, T2 modes)

    I want to listen to $MODE_OP changes in the program to ensure that when an action is launched, it won't be executed in a non valid mode. If the user changes the mode to an unauthorized mode for the running action, the interrupt must be triggered, inform the user he must change back the mode to a valid mode or the program will be automatically canceled by the SPS through CWRITE($CMD, state, mode, "CANCEL 1").

    The SPS is responsible for cyclically checking if $MODE_OP is valid for the running action. $FLAG[99] is set to true if the mode is invalid, and false otherwise.
    Then, In my program, I must respond to $FLAG[99]==true with an interrupt.

    My problem arises when I launch an action with a yet invalid $MODE_OP, that is $FLAG[99] is true at the very beginning of the program. I have set up the following MWE to test and understand my problem :

    In the SPS loop, set $FLAG[99] = true when any program is launched :

    Code
    SWITCH $PRO_STATE1
  CASE #P_RESET, #P_ACTIVE, #P_STOP, #P_END
    $FLAG[99] = true
  DEFAULT
    $FLAG[99] = false
ENDSWITCH

    Then start this test src program :

    The interruption is working properly if I reverse $FLAG[99] just after activating the interrupt (ON 9). If I comment this line, the interrupt never gets triggered.

    Code
    $FLAG[99] = false                  ; comment this line > interrupt does not occur

    How would you explain that ? What I do not understand ?

    Thanks for your kind help,
    Lionel

    That is exactly how interrupts work. They are "edge triggered."

    If you set an Interrupt to trigger on a condition being True, it will only trigger on a transition from False to True. If the condition is already True before you use INTERRUPT ON, the Interrupt will not trigger until after the condition has gone False, and then goes True again.

    This is a deliberate design feature, and goes back to classical electronics and circuits like flip-flops: https://electronics.stackexchange.com/questions/2188…-triggered-mean

    I'm trying to understand the following statements (see code below). I believe this is related to the fact that interrupts are edge triggered as you told me but I might be wrong.
    What is the purpose of those PULSE statements ? I suppose it is, somehow, a way to arm/rearm the triggering.

    Why in the INIT section O_Flag_MoveEnable=FALSE is followed immediately by a PULSE (O_Flag_MoveEnable,FALSE,0.2 ) ? It is yet set to FALSE no ?
    Why in the MoveEnable_Management(1) subroutine the PULSE is not LOW to "rearm" the interrupt trigger after returning to the main program ?

    [list type=decimal]

    • O_Flag_MoveEnable = false at INIT

    • if O_Flag_MoveEnable goes to true at some point interrupt 97 gets triggered and throws MoveEnable_Management (1)

    • Then MoveEnable_Management (1) issues a PULSE (O_Flag_MoveEnable,TRUE,0.05 ) (case 1)

    [/list]

    Init function of systemcellmanagesps.sub (WOP 6) :

    Code
    CASE #INIT_SPS
  ;FOLD Init + Interruptions for management MOVE ENABLE
  O_Flag_MoveEnable=FALSE
  PULSE (O_Flag_MoveEnable,FALSE,0.2 )
  GLOBAL INTERRUPT DECL 97 WHEN O_Flag_MoveEnable DO MoveEnable_Management (1 )
  GLOBAL INTERRUPT DECL 98 WHEN NOT O_Flag_MoveEnable DO MoveEnable_Management (2 )
  INTERRUPT ON 97
  INTERRUPT ON 98
  ...

    And the subroutine :

    Edited once, last by lionpeloux (November 14, 2018 at 10:55 AM).

    ...who wrote this? It seems unnecessarily over-complicated. Although without a larger context, it's hard to say for certain.

    The initial 0.2sec pulse appears to be to guarantee the starting condition of the signal before the Interrupts are declared, but it's redundant with the preceding explicit False setting. Also, DECLing the Interrupts immediately after the Pulse command... will probably work, but I would have added a WAIT FOR state before the DECLs to ensure no edge-condition timing issues could happen.

    After that, the entire use of Pulse commands in the ISR appears to be an attempt at creating a "heartbeat" timer of some kind. If the ISR is called by a False->True transition, the Pulse True command will "extend" the True time of the signal for another 0.05sec, after which it will turn False. This will call the ISR with an argument of True, which will cause the Pulse False command to extend the False time for 0.05sec, and so on forever.

    The trick to the Pulse command is that, if you use it on a signal that is already in the commanded state, the signal will "invert" at the end of the Pulse duration time. So you can set a "timer" on the signal that will "go off" at some moment in the future, regardless of what else the program is doing at that moment.

    This code is from WOP 6.0 (Way of Programming by Kuka France).
    I have to dig more into this "heartbeat" sort of timer that I don't yet fully understand.

    I was not aware of this point :

    Quote

    The trick to the Pulse command is that, if you use it on a signal that is already in the commanded state, the signal will "invert" at the end of the Pulse duration time



    Could you confirm this behavior ? Is there any documentation where this is explained ? I couldn't find anything about this point in the expert programming manual ... but the documentation is often rather obscure !

    Thanks again for your kind help

    I've used it quite a bit for "delayed actions."

    Example: At a particular line in the program, $OUT[1] is already true. I want $OUT to become FALSE in exactly 1.5 seconds, but I can't guarantee what line of the program will be executing in that time frame. So, I use PULSE($OUT[1], TRUE, 1.5). The effect here is that $OUT[1] will stay TRUE for exactly 1.5 seconds longer, then turn FALSE, regardless of what my program may be doing at that time.

    There are other ways to do this, of course ($TIMERs, SPS code, etc), but there were times when this particular trick was the cleanest solution to what I was trying to accomplish.

Advertising from our partners