How do I program an e-stop into a state machine?

[RavensFan]

---

@ajsdwilson wrote:

Sorry, should have explained this part...it is a machine that has a robot in it...so one cycle of all it's tasks takes 5 seconds...I'll look at putting E-Stop Checks between each function.

---

Yes.  With that description, that should not be 1 state, but different states for each of the tasks.  Each task would execute then check the e-stop before moving onto the next task.  If any given task takes longer than you want, then follow the advice given above and have the same task keep repeating (since it is a robot, it might be something like "check if move complete").  If it is not complete, check e-stop and return to same task.  If it is complete, check e-stop and move onto next task.  If in any case e-stop turns out to be true, then the next task is automatically made to be (stop, shutdown, power off, whatever) no matter what the next task was supposed to be.

[Matthew_Kelton]

If you already have a hardwired E-stop to the components, then why is it critical for RT to de-energize the system? You must not have hard e-stops to everything. If your hardware is in a safe state, then it should not be critical that the chassis stop immediately. As long as your states are somewhat reasonable in length, a few hundred ms shouldn't matter if everything is in a safe state. The way I typically do it is that I don't depend on the controller to do anything other than detect the e-stop was pressed. All my rails for outputs and inputs are controlled by a hard e-stop. Once pressed, all my outputs automatically go off, regardless of my chassis/PC state. This way, it is not critical the the chassis detect the e-stop quickly, or even at all, because the chassis can continue to run without doing any more damage. Some customers have me kill the chassis on e-stop, some don't if they need the e-stop logged for some reason, or want some series of events to occur when the e-stop occurs. You do inherit some risk in that scenario, but sometimes it is necessary. I try to never depend on the chassis handling the e-stop for the system since the chassis may be the cause of the problem and can't respond to the e-stop. If you blow an output closed, or an input card fails that happens to have your e-stop signal on it, your e-stop could be missed. Turning a chassis output off may not actually fix the problem.

[RTSLVU]

Building on what others have said your E-Stop needs to be hardware based so it stops all the equipment regardless of what the program is doing. 

I have had to work this into my latest test fixture, my E-Stop is based around a self latching relay that once "armed" allows UUT's to be powered up and tested. If the E-Stop is tripped the latching relay unlatches and opens turning off larger relays disconnecting power to the UUT. One contact of the E-Stop relay is monitored by a DIO every 10 mS in a loop that runs parallel to my main program. If the E-Stop is tripped the program is gracefully aborted and stopped. I use a "functinal global" to monitor E-Stop status and have several checks in my program and the most lag between hitting the E-Stop and the program stopping is about a second.

But the timing of the program stopping does not matter so much because the UUT is instantly powered down by hardware disconnect.

[Bob_Schor]

If your State Machine is being driven by a Queue, it's not too difficult to handle getting a rapid response from the 5-second State, which I'll call "Long State".  Split it into two sub-States, Start Long State and Stop Long State.  Start Long State starts asynchronous code to run Long State (using either Start Asynchronous Call, Producer/Consumer, or something like that).  This asynchronous Long State routine called Stop Long State when it is done.

To handle the E-Stop state, enqueue E-Stop, but use the Enqueue at Opposite End so this is at the head, not the tail, of the Queue.

Now your main routine will get to Start Long State, dispatch the Long State code, and be immediately "receptive" to getting more States, including an E-Stop State request coming from hardware, the Long State routine, or whereever.  Since it is just waiting for the next State to be enqueued, it will immediately process the E-Stop.

Bob Schor