Basics
One of the first concept in programming a PLC, wether it is for HVAC, Process or Packaging, is alarming. With luck, there are built in mechanics that we may use, but most of the time not.
As an OEM, I don’t work with a specific brand as I need to adapt to customers will. Such a requirement implies that all mechanics involved must remain portable between brands.
As of today, there are no uniform way to do OOP(Object Oriented Programming) in many PLC. So wrinting alarms in a specific portion of code feels fine. This also helps the troubleshoot by site maintenance’s.
Ahead of the dive
When planing alarms, it is important to keep in mind some criteria :
- Alarms have to be memorized
- Alarms must be easy to count and acknowledge
- All alarms should trigger an appropriate reaction
Even if those points seem trivial, they are not. A common mistake encountered in beginner’s work, is an acknowledgement after the alarm trigger.
As you may be aware, PLCs (Programmable Logic Controllers) are not running code the way a computer does. After updating communications and I/Os (Inputs and Outputs), the code is executed from the first line to the last one, and then, the cycle restarts another I/Os and communication update.
Back to the issue, the alarm is now in the best cases blinking when you acknowledge, and in the worst, it disappear.
Alarms have to be memorized
This point is important to trace what is hapening on your machine. In some cases, a faulty connection of a wire may trigger annoying alarms, very hard to troubleshoot if not memorized.
Alarms must be easy to count and acknowledge
When a machine produces more than 50 alarms, it is impractical to add every alarm to the alarm summary. Moreover, proceeding this way has a high chance of forgetting some alarms to the summary. Same goes for the acknowledge.
All alarms should trigger an appropriate reaction
A common issue with bad alarm zoning or summing is unnecessary machine stops. The code shall not trigger the same reaction when the electrical cabinet cooler is faulty or when you loose energy (Compressed air, hydraulics, electrical supply …). Thus, we want to zone and group alarms.
Our tools
Almost all industrial PLC brands offer boolean arrays. It is quite easy to work with, provisioning doesn’t hit much the memory allocation and last but not least, it is quick to code them.
The use of arrays come at a price : variable names (or tag names) won’t match the exact purpose. Still, there are some workaround, like using constants for array indices or using aliases. But they are not very elegant to use, and not available with all PLCs.
Anyway, commenting every used bit is mandatory, especially with arrays. Commenting free ones may also be nice to help any further modification of the machine.
Zoning
Almost all machines need alarm zoning. A quick way to do it is using an array for each functional unit. Although it is frequent to have a global zone to deal with signals that are common to every functional unit.
In every functional unit, it is wise to split alarms in different groups. Defining groups, depending on their consequences on the machine’s cycle. This way, alarms can be splitted in 4 groups:
- Requires de-energizing (opened guard door)
- Requires an immediate cycle stop (24V breaker trip)
- Requires an end of cycle stop (low low level in supply tank)
- Requires no stop at all (electrical cabinet cooler faulted)
Depending on the process, it may be convenient to add more groups, especially if there are more kind of stop types.
Some would argue that the last alarm group may fall into what we call warnings, and it is a close one. But warning and no stop alarms are different by nature: warning serves the purpose of preventing a stop (low level in supply tank), while no stop alarms are more to schedule some maintenance on the equipment.
Data storage
As the alarm trigger may be active only when the machine runs and requires a machine stop, there is a requirement for an operator to acknowledge alarms.
A nice feature of arrays, is how you can copy all your values to another array, just in one code line (that may be a little more, depending on the brand).
In order to save a raised alarm, it is as simple as doing an OR between the two arrays. If the brand doesn’t support it, looping through every item is very ineffective but still does the job.
Then, acknowledging is simply done by resetting the second array, while the first one holds the real time value of the alarm.
Another big advantage of using arrays, is new fault detection. It is done just by comparing each array with the previously saved one.
And last but not least, arrays are also the key for alarm occurences and time elapsed tracking.