One of the more obvious causes of abnormal exits is the proverbial power failure.  With a power failure, the programming logic has no vote in how the system handles itself.  When a power failure happens, the system behavior is dependent on the failsafe strategy of the mechanical designer.  The failsafe strategy is not usually as critical in machine control as it is in process control.

When recovering from a power failure it’s important to know whether you had a graceful shutdown which can be accomplished by setting flags within the program to keep track of whether or not you were running and what you were doing.  Then based on what you were doing when the power failure occurred, you need to determine how to recover (if possible) from that interrupted condition.

For example, you might have been scaling up an expensive batch of raw ingredients and were only part way through the batch.  If you have kept track of what you were doing and if in a sequence what step you were in and if batching what your previous actual weights were for the respective ingredients in this interrupted batch, you can check current weight and know what ingredient you were weighing when so rudely interrupted and simply resume the batch and continue on with the process.

At BCI 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 system programming scheme.  This finite state style works equally well on machine control as well as process control.

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 including servos, etc.

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 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?

If the cause of the abnormal failure is due to 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 you have been on line with this processor before.  If it knows that it is waking up “cold” 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.

This 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, 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 judgement as to when “enough is enough” (safety is a separate topic from this).

Ray Bachelor
Chairman of the Board