Estop is a manual function and it requires manual reset. In EXT mode you can use IO signals to restore drives power, acknowledge messages and start program.
In all of my RSI applications to date, I killed the RSI container on an E-Stop, and used IR_STOPM or a similar interrupt to move the robot back to the "starting point" of the RSI activity in the regular KRL program, before attempting to re-start the RSI activity from scratch.
In EXT mode you can use IO signals to restore drives power, acknowledge messages and start program.
I've been trying to do this also in EXT mode. According to the manual the signals and their order on going high and low is exactly the same at when switching to EXT from , for example, T1.
But even after the signals had gone in, the STOPMESS is still active and the robot does not restart the program or anything at all.
Is there anything extra I need adding to IR_STOPM or somewhere else to recover?
But even after the signals had gone in, the STOPMESS is still active and the robot does not restart the program or anything at all.
Is there anything extra I need adding to IR_STOPM or somewhere else to recover?
That has nothing to do with IR_STOPM. If $STOPMESS is still active, then you haven't cleared the fault. $CONF_MESS has to be a pulse, and if that doesn't reset $STOPMESS, then you have to track down whatever the root cause of the error is.
I ended up commenting out 'BRAKE' command in IR_STOPM just after 'If ($STOPMESS==TRUE)' and that seemed to do the job. The robot stops on any of my e-stops and then restarts the program again.
