How to design emergency stops for machine uptime and operator safety
Some time ago, my mum gave me a small bottle or Armagnac brandy in a glass case which read, “In case of emergency, break glass.”
If I was in need of a drink, would that constitute an emergency? Depending on the day, it could.
In industrial manufacturing and machinery, an emergency can take various forms, but the common thread with it all is that either the control system—safety programmable logic controller (PLC) or relay—or human imust intervene to prevent or stop a process action.
What constitutes an emergency? In this case, there is no reality, only perception. What I think requires immediate action vs. what the operator thinks may be different. Let’s say there are three moments of an emergency: preemptive, in the moment and post event. Regardless of the emergency, the required action must not fail.
A preemptive situation could be a person walking into a robot cell. An in-the-moment event could be a runaway automated guided vehicle (AGV) about to hit an impediment. A post event would be after the AGV hit the impediment, when the system needs to stop what it’s doing at all costs.
The beginning of the emergency-stop (e-stop) system started with a master control relay (MCR). While fraught with issues, the MCR removed power from the control system’s outputs stopping all devices immediately. The main issue was relay failure and troubleshooting the resulting problem to determine which device caused the stoppage.
It could be caused by wiring or an event triggered by an external action. Keeping downtime to a minimum made for some creative methods to determine what caused the stoppage.
E-stop actions are not stop actions. An e-stop action cannot fail in its responsibility of terminating all movement on the leading edge of the event. Because of the potential failure of the MCR implementation, innovation created safety-rated devices and control systems.
A safety PLC or relay provides the ability to interface with various devices that can be used for those situations that require emergency actions.
Safety devices connected to a safety system can utilize a test pulse which continuously monitors the device to be sure that when the device is to be actuated, it will serve its purpose.
Modern e-stop buttons, whether they are interfaced with a safety subsystem or not, stay activated once activated. They typically have redundant contact blocks, which are supposed to open under any circumstances. Once the button is pressed, the user must rotate the button to release it and allow the system to recover.
This brings us to a software component of the e-stop question. Once power is removed from the machine or process and the operation is stopped, recovering from this event becomes paramount.
Get your subscription to Control Design’s daily newsletter.
In most cases, when the safety system or devices physically remove power, the control system receives that status via an input or inputs, and then the system logically puts the machine or system into a mode to allow for manual or automatic recovery once the e-stop event has been dealt with. Since power is removed, the control system cannot put the system into any state since it is stopped where it sits.
Once power comes back and the e-stop condition is absent from the equation, the process or machine needs to get back into a state to continue operation.
An application that I was involved in was programmed by an outside contractor. I was called in to evaluate the system since there was a major problem when recovering from an e-stop event. The machine was an underground drilling machine with a large hydraulic motor. The contractor used sequential function chart (SFC) to program the sequence.
The reason I was called in was that, upon recovery from the e-stop event, the hydraulic motor came on without operator intervention. This resulted in a hydraulic hose flex which took out the operator since he was not supposed to be there when the pump was on.
The contractor used a retentive, or latched, output to control the motor and didn’t use proper recovery methods to reset it.
Regardless of the application, the control system must start up in a mode that allows for recovery and should not present any unexpected situation to the operator so that the operator is in charge of what happens.
An emergency is defined by both the process and the design team. Implementation of e-stop devices must be fail-safe and reported to reduce downtime.
