An abnormal exit is something that causes a system program to unceremoniously come to a halt. The system’s mechanical response will also be dependent on the fail-safe strategy that was incorporated into the mechanical and/or process design.
Power failure
One of the more obvious and most frequent causes of abnormal exits is the proverbial power failure. When recovering from a power failure, it’s important to know whether you had a graceful shutdown. This can be accomplished by setting flags within the program. Were you running and, if so, what were you doing? Then, based on what you were doing when the power failure occurred, you need to determine how to most gracefully recover.
For example, you might have been scaling up an expensive batch of raw ingredients and were only part way through the batch. It’s important to know what you were doing, what step you were in, and what your previous actual weights were for the respective ingredients in this interrupted batch. If you know what step you were in, you can check current weight and know what ingredient you were weighing and how much had already been transferred into the scale hopper—then, with all that knowledge, simply resume the batch and continue on with the process.
At Bachelor Controls, we like to use a methodology we call “finite state” programming. This finite state methodology allows us to more gracefully keep track of where we are at any given moment in a programming scheme.
In machine control, it will be important to determine the state you were in when the abnormal exit occurred, and most likely operator interaction will be required in order to know whether or not any in-process material needs to be cleared from the machine before resetting various actuators.
It’s important to say that not every recovery needs to be handled automatically. There can be some operator/administrative interaction, but the system must provide for that operator interaction in order to handle it gracefully from the human-machine interface (HMI). That just needs to be spelled out as a deliberate strategy so that the user knows the action(s) to take.
Also, don’t forget about the data collection. How do you account for scrap that might result from an abnormal exit? Can you make that determination from within the program? Or do you need an operator or supervisor to make that entry/adjustment prior to resuming production?
Faulted processor
If an abnormal exit is caused by a faulted processor, then you obviously won’t know what state you were in when you replace the processor, but you can know through status bits whether your program has run on this processor before. If not, then the program should allow the operator to single step through an appropriate reset so that expensive materials aren’t wasted and so that neither machine damage nor personnel injury occurs. If data logging is part of the application, then perhaps some history can be obtained from the logged data to help an operator manually resume.
A loss of network communication can also cause an abnormal exit. Have you not only planned on how to react to a network failure, but have you also considered how to recover? Can you resolve any data logging that might have been missed and/or can you resolve any lost material and reconcile the data logging to account for such a loss?
The subject of abnormal exits is not a simple subject. Some of it is driven by value of the material being handled, but some of it is also driven by concern for machine damage and concern for personnel.
When performing a factory acceptance test (FAT), it is important to have included the abnormal exits anticipated as part of the testing protocol. There is no finite list of occurrences that could qualify. You will have to use your judgment as to when “enough is enough” (safety is a separate topic from this).
Ray Bachelor is chairman of the board at Bachelor Controls Inc., a certified member of the Control System Integrators Association (CSIA). For more information about Bachelor Controls, visit its profile on the Industrial Automation Exchange.
