Calling IR_STOPM() from within a program using a standard $IN signal

KRC5
KSS 8.7.6

On one of our welding systems, we have built a fairly robust user stop/start into IR_STOPM, largely to allow for automated recovery from a user initiated E-Stop. This is primarily to allow a user to E-Stop the system at will and to have the system re-establish a weld bead from the point of the stop once the E-Stop has been cleared, all safety requirements are met, and the user initiates recovery. This has been heavily tested and works flawlessly.

However, there are a number of other factors that the welder monitors and reports to the robot controller during the weld that we'd like to have automatically initiate the same process as the user initiated E-Stop, i.e. when the welder reports $IN[2050]==TRUE, run IR_STOPM which stops the weld, locks the welder into a safe mode from which it cannot ignite an arc, stop motion, turn off shielding gas flow, etc. However, as braking only occurs in IR_STOPM when $STOPMESS is true and $STOPMESS is write-protected, I've yet to find a way to call IR_STOPM programmatically and have it perform exactly as a user E-Stop. For example, is there way to use a standard interrupt to call IR_STOPM with full functionality such as:

; ... within weld_program.src

; $IN[2050] input from welder to controller, reports if there is a detected weld error.
; this input is declared within config.dat for global access.
; $IN[2060] input from welder to controller, reports the specific weld error number when 2050 goes TRUE
; not specifically used here, but added for awareness for recovery code
DECL INTERRUPT 5 WHEN $IN[2050]==TRUE DO IR_STOPM()

; ... weld_program.src continues below

To be clear, this is not meant to try and trick or work around safety, as the system is completely locked out any time an E-Stop is called. We're simply trying to use the stop and recovery designed for manual E-stops to help automatically stop the weld if there is an error detected by the welder and reported to the robot controller to prevent the process quality from being diminished by arcs continuing in suboptimal states. Is there a way to do so and call IR_STOPM in such a manner that it will behave exactly as if a user has hit the physical E-Stop, but from an interrupt within a program? If we simply need to write our own ISR and duplicate/move some of the recovery code into this separate ISR that calls BRAKE regardless of the status of $STOPMESS, that's totally fine; we were hoping to avoid code duplication and use the already tested and proven code within IR_STOPM.

Quote from SkyeFire

Hes' approach would work, but would require you to change every IR_STOPM Interrupt declaration. Which could be a problem if you're using the default templates.

An alternative method would be to create your own Interrupt in parallel with the template default Interrupt (INTERRUPT 3, IIRC) that calls IR_STOPM.

So IR_STOPM would be called by either $STOPMESS or by $IN[2050]. Two different Interrupt DECLs can call the same subroutine. You'd want to use a higher Interrupt number to ensure the $STOPMESS had higher priority -- Interrupt 1 is the highest priority, higher numbers are lower priority.

And you'd need to edit IR_STOPM to add INTERRUPT OFF X to disable both Interrupts at the beginning of IR_STOPM, then turn them back on at the end.

Code

  ;FOLD BASISTECH INIT
     INTERRUPT OFF 3
     Add your own Interrupt Off here
     STOPM_FLAG=TRUE ;Reflects state of interrupt 3 to activate/deactivate $Stopmess interrupt
     ID[]="CTL"
     If ($STOPMESS==TRUE) THEN ; add OR NOT $IN[2050] to the IF
       BRAKE
  ;ENDFOLD (BASISTECH INIT) 
 
   ;FOLD BASISTECH REACTIVATE
    Endif 
	INTERRUPT ON 3
    STOPM_FLAG=FALSE ;Reflects state of interrupt 3 to activate/deactivate $Stopmess interrupt
    ; add your own INTERRUPT ON here   
  ;ENDFOLD (BASISTECH REACTIVATE)
END

Display More

Awesome, thank you! That's pretty much what I was thinking, but I wanted to double check before messing with IR_STOPM too much. Any time safety-rated signals are involved, I certainly appreciate a sanity check.

From looking at your logic for calling BRAKE, you have NOT $IN[2050]. Since $IN[2050] goes high when an error is detected, I should think I'd be looking for that to be true, not false. Is there some reason I should be looking for the inverse behavior or is that just a typo?