From my experience, I know that controls engineers performing equipment startups are often facing an issue of quickly finding the reason why this or that equipment stopped all of a sudden. When the control system is set-up, and alarms are correctly configured, this is usually not an issue.

But wouldn't you agree that there are plants that have this issue even years after the startup? Going through hundreds of alarms and identifying what happened first is painstaking, and mistakes are easily made, not to mention the cost.

I know that experienced programmers have ways to avoid or minimize this type of issue. But for those who still "suffer from poor alarm-management", I want to show our approach.

So here is a hypothetical setup:

• A motor that is getting run/stop signals from SCADA/control sequence.
• The motor is interlocked with several signals.
• While all interlocks are "true," - motor can run.
• When any of the interlocks is "false," - motor has to stop. These can be lubrication pump running, bearing temperatures, vibration sensors, other equipment states, etc.

Here is how it can be programmed:

As seen in rung 1, Interlocks 1 to 5 are in series.

When something bad happens, there is a chain of events:

• The root cause (one of the interlocks) trips the motor.
• The change of motor state trips other equipment that can be back-interlocked with our motor.

So within a very short period of time there may be several interlock signals that fall from "true" to "false". Our goal is to identify the root cause - the first event that stopped our motor.

We've written a simple AOI (Add on Instruction) for Rockwell PLCs that is:

• Capturing the first input that falls from "true" to "false."
• Resetting the output from "true" to "false".
• Providing a report with information of which interlock caused the trip, including the event's timestamp.

Here is how we would program the same motor:

You can see that there is now an additional "Condition_List" block. All interlocks are wired to the block-inputs, and the "Condition_List" output [_CL.OUT] is connected to the Motor Control Protective Interlock bit [UMOTOR.PIL1].

Now let's see this block in action.