Setting a boolean variable in an interrupt that is monitored in a submit interpreter.

    Hi,


    I'm having the following issue that I do not understand.


    I have the following interrupt declaration:


    INTERRUPT DECL 1 WHEN NOT SignalToMonitor DO ISR_1()


    I activate the Interrupt when some preconditions are met.


    When SignalToMonitor is false, ISR_1() is called which is defined as follows:



    DEF DO ISR_1()

    BRAKE


    ABORT_PROGRAM = TRUE


    END


    In my sub file I have the following code:

    LOOP


    IF ABORT_PROGRAM THEN

    MODE=#SYNC

    CWRITE($CMD, STAT, MODE, "CANCEL 1")

    CWRITE($CMD, STAT, MODE, "STOP 1")

    ABORT_PROGRAM = FALSE

    ENDIF

    ENDLOOP


    The whole purpose is to stop the robot interpreter so that the program that was running is stopped. But my issue is the robot interpreter is never stopped. I have similar code in other programs which are not in the interrupt routine that set the ABORT_PROGRAM variable to TRUE and the interpreter gets stopped.


    My KSS version is 8.6.10.


    Thank you in advance.

    that should work as long as scope is correct. how do you know that ISR is called?


    btw. the whole point of interrupt is to do something else WHILE program is running. if interrupt was to stop own interpreter, there is nothing to return to. (notice part "WHILE program is running"). in other words interpreter cannot start itself and also cannot stop itself. both actions need EXTERNAL influence, such as from another interpreter.

    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

    Hi,


    I know that the ISR is called because I send the signal from the plc and I can see the ISR being called.


    The idea was that from the submit interpreter I cancel the robot interpreter. Funny thing is that if I execute the program in step by step mode (in T1) the robot interpreter is stopped, that is what I dont understand.


    And the ABORT_PROGRAM variable is also global.

    so the issue is the timing... CWRITE commands take really long time to execute so they run asynchronously (this is passed on to vxworks and processed there).


    think of it as if loop in submit need to run 10x to complete single CWRITE command.

    you have no checks if that is the case and if command is finished. in fact before one is finished you already start the next one. and then you stop long before either of them had a chance to finish because your code turn off the ABORT_FLAG in the first pass of the loop.


    you should not run CWRITE to cancel program until CWRITE to stop program is done

    and you should not turn off the flag until the the second CWRITE is finished.

    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

    Hi once again,


    Thank you for the response. I will try to search how can I verify the result of CWRITE so that I call the second one only when the first finishes and set the ABORT_PROGRAM to false only when the second finishes.

    Very strange behaviour.


    I changed my sps to:


    IF ABORT_PROGRAM THEN


    MODE=#SYNC


        CWRITE($CMD, STAT, MODE, "CANCEL 1")


        CWRITE($CMD, STAT, MODE, "STOP 1")


        WAIT FOR $PROG_INFO[1].P_STATE == #P_FREE


    ABORT_PROGRAM = FALSE


    ENDIF


    Even in this case this is not working. If I set the variable in the smart pad to TRUE it works even without the WAIT FOR.

    Hello, first send the STOP command, when the program has stopped only then send CANCEL command like Panic mode has posted.

    Quote from DannyDJ

    Hello, first send the STOP command, when the program has stopped only then send CANCEL command like Panic mode has posted.

    I appreciate the effort but I also tried to invert the order 1st stopping and then cancelling but neither way it works. If I just let it with cancel it also works from the smart pad but not from the interrupt.

    oh no.... please stop putting wait commands in the submit code... they block execution of everything in the submit.


    it you really must, try using fixed short delay inside IF block. do not use indefinite WAIT FOR command.


    check system integrator manual and CWRITE manual for more info on this.


    this is one CRUDE thing (it does not VERIFY program state)


    Code
    IF ABORT_PROGRAM THEN
  MODE=#SYNC
  CWRITE($CMD, STAT, MODE, "STOP 1")
  WAIT SEC 0.5
  CWRITE($CMD, STAT, MODE, "CANCEL 1")
  WAIT SEC 0.5
  ABORT_PROGRAM = FALSE
ENDIF


    it does cause slowing down of submit of the ABORT_PROGRAM was active but at least it does not permanently block it, the delay is observed only while ABOT_PROGRAM is active and the commands are called in CORRECT order (first stop, then cancel)


    then better way is to not block at all... let each instruction take the time it needs and look at the program state for verification and sequential activating of the commands.

    maybe something like this



    this version not only checks program state but only executes commands that may be needed. if program is not running, there is no need to issue STOP command, if program is already deselected there is no need for CANCEL either.

    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

    Like 1
    Quote from panic mode

    then better way is to not block at all... let each instruction take the time it needs and look at the program state for verification and sequential activating of the commands.

    maybe something like this



    this version not only checks program state but only executes commands that may be needed. if program is not running, there is no need to issue STOP command, if program is already deselected there is no need for CANCEL either.


    Would this not call CWRITE continuously until the checked flags are false? I have not looked at the documentation to know enough about whats going on behind the scenes, but have found that in my experience it is always best to ensure that all calls to functions are explicit. Wouldn't it be better to implement falling edge triggers on $PRO_ACTIVE and $PRO_STATE1 or does it not matter in this case?

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account
Sign up for a new account in our community. It's easy!
Register a new account
Sign in
Already have an account? Sign in here.
Sign in Now