How to handle E-Stop conditions in PLC program ?

[Luc Morin 1]

Hi all, I usually write small(ish) PLC programs, so the issue was "easy" to deal with so far. Basically, I always design my PLC program on paper using SFC(Grafcet) first. Then I translate it to ladder using the activator/killer pattern. I'd like to know how people writing larger programs, and also using SFC -> ladder, usually handle E-Stop conditions. For example, if you have a complex SFC with AND/OR branches, how do you bring the active step back to a know step ? Do you place killer bits at each step ? Do you use SET and RESET ? MCR instructions ? Please share your experiences/knowledge on this subject. Thank you. Luc

[paulengr 44]

First off, I have never even heard of "killer/activator" patterns whatever that is. The whole idea of patterns as a paradigm is some sort of fad among SOME PC programmers, but that's about it. A long time ago, we called these "algorithms". In fact one of the most famous programming authors, Donald Knuth, sells a complete series considered almost a bible for programmers in general that speaks to nothing but algorithms. As to using SFC's although they are great for sequential programs and process engineers love them, their implementations are often utterly confusing for electricians because it is not intuitively obvious which code is "live" and which is not. And their implementations at least in the most popular PLC's in the US (Allen Bradley) are so bad that they are better left avoided if possible. If you want/need to use them, then carefully read the manuals for your PLC to see just how much processor time is wasted executing these things (they have tons of overhead) and also recognize that you will be involved in doing a LOT of training because your electricians are going to be struggling with trying to understand how your programs work a lot. If you have lots of things happening in parallel with lots of interaction or you have to implement complex interlocks, SFC's can be a great organizational tool with or without paper. The better tool is usually function block programming (which electricians usually have a much easier time understanding), but not all PLC's implement it. Otherwise, they are mostly a lot of overhead. On top of that usually your entire SFC is limited to either executing blocks of structured text in some PLC's (again, confusing for electricians) or else executing JSR's. It might be clearer even if you use SFC's to implement it as ladder code with JSR's. However I also discourage this type of programming. If you have two different ladders which drive the exact same set of outputs, then from a troubleshooting point of view you can be monitoring a ladder, watching it execute, and make completely incorrect assumptions about what is happening simply because you are looking at the WRONG ladder (one that is not executing). Since most of the time it is inconvenient to view more than one section of code at a time, this makes it difficult to keep track of which particular ladder is actually executing and which one is not. In addition from a memory/programming perspective, you end up with lots of duplicated rungs in all your ladders because of the property that with an SFC some ladders might be executing while others are not. It is possible to split your program into a "high level" and "low level" code to alleviate this problem somewhat but rearranging it around a different paradigm solves the issue completely. As to using MCR's, they can be extremely useful. HOWEVER, remember what they do...they simply take all of your non-retentive outputs (OTE's, non-retentive timers) and force them into their false states. The remaining "retentive" (basically all of them) instructions continue to operate as if nothing ever happened. Again, this leads to utter confusion because contrary to popular belief, the PLC doesn't actually simply "skip" the code in between the MCR's. It all still executes. It's just that the MCR acts something like a mass "force" operation. The most confusing rungs are timer-off delays because a false transition with these normally starts them running but with an MCR this is suppressed (actually it leads to effectively an illegal state). All the other non-retentive instructions such as moves, arithmetic operations, latching/unlatching instructions, and so forth are still operating normally. If your code is defined completely by non-retentive outputs and timer-on delays exclusively then you MIGHT be a candidate for using MCR's. It might be more typing but the much safer alternative is to either outright skip the code using a JSR or JMP, or else using explicit checks on every actuator output rung (XIC stop) to specifically identify a stop command. Code execution is slightly slower than using the MCR method but it is more intuitive to troubleshoot, and PLC's are heavily optimized towards executing bit-oriented instructions as quickly as possible. As I've recommended before unless you actually have multiple concurrent operations where a full Petri net is necessary (and then SFC's come into their own with the parallel branching capabiilities) and you can't cut your parallel branches up into a few state machines with a minimal number of points where they interact, I'd stay away from them. Regardless, first and foremost, an E-Stop is pretty much useless across the board. In the US on presses only, OSHA has mandated their use. Everywhere else, any company using them is playing with fire. An E-Stop is a clear indication that a documented risk assessment has not been done because someone essentially said "no matter what the risk, we'll just put in E-Stops as a catch-all and let the operator deal with it". That opens up nothing but legal liability beyond imagination, especially the imagination it takes to do a proper risk assessment. Best thing to do with people who don't understand risk assessments is to explain the liability issue and change the name to "process stop" or just "stop" and insist on NEVER calling it an E-Stop. Then it doesn't invoke any of the safety codes around these things. If you do use an E-Stop, then the risk assessment will also define the design parameters for implementation (for example, is it SIL 1, 2, 3, more?). So you may or may not even be capable of implementing it in a PLC vs. hardware. With a standard PLC (no safety capabilities), the best you will probably be able to achieve is SIL 1. That aside, assuming that the E-Stop stuff is taken care of elsewhere, the PLC really has a simple role. You have to force everything back into a base, "idle" state until a reset happens. Then after a reset, it should NOT start up until you get a "start" command. So you have to have two states in your system somewhere, a "stop/fault" state (since it usually gets dual purpose use), and an "idle" state. An E-Stop should disable all actuator outputs (in other words, stop commanding anything to move), and drive the PLC into the stop/idle state. Then it exits that state to the "idle" state when a reset command is received. This is all very well laid out in NFPA 79 which is available free for viewing on www.nfpa.org. This is very easy code to write in a state machine because you just check for the E-Stop or reset command and force the appropriate state. Everything else hinges off the state machine actions. In an SFC it is very messy because EVERY step must detect an E-Stop and do the right thing (fall through until you reach the end/stop state). In an SFC if you insist on everything being done in an SFC perhaps the easiest practical way to do this is to add a dummy "stop" branch in a selection branching step that evaluates to true only on an E-Stop and where the rest of your code sits in the other selection branch. Then it will keep executing your normal program until an E-Stop occurs and then falls through, bypassing your normal program. However in practice most programmers simply implement a supervisory ladder that simply resets the entire SFC whenever an E-Stop occurs and put a single "reset" transition at the top of the program so that the very first step serves as your fault/stop state, the next one serves as idle, and then the remaining SFC steps are your "running" code.

[Crossbow 295]

I don't write alot in SFC, but when I do, there are also constant scan ladder programs running, and I can monitor the status of the SFC in the ladder. All my I/O is in the ladder, and so I can easily monitor the SFC bits and determine what step the SFC is at. I use the SFC to set up the actual sequence, and then use ladder to monitor overloads, E-stops, etc. to determine when outputs should be on or off.