There are many new and old-school ways to handle alarm management. Several national and international standards exist and are built into many controllers and human-machine interfaces (HMIs). The bottom line is alarms are used to detect unsafe or unexpected machine conditions, and they must notify the operator clearly that a machine needs attention, immediately.
So, what is a good starting point for good alarm management in a PLC? Consider ease of understanding, priorities, standard programming logic and reusable code. The alarm messages must be presented to an operator in a limited number, or it's likely they will be ignored or disabled. The methods to present and acknowledge or ignore the alarm must also be defined.
Don't overload the operator with information. Alarms can be broken down into priorities and areas, which allows only high-priority alarms to be displayed. While some systems may benefit from 10 levels of alarm priorities, to keep it simple, many machines have just two levels. Those are alarms, often called faults, and warnings. Other informational messages may also be included.
What is an alarm, and what is a warning? An alarm is a detectable condition that keeps a machine from cycling, and it requires immediate operator intervention or the machine stops. Warnings are similar to alarms but don't always require operator intervention. An alarm stops cycles in progress, such as when a gripper did not advance. A warning may stop a cycle from starting, such as when the infeed is waiting for parts.
Simplified, an alarm can be thought of as a major fault, and a warning as a minor fault or, at least, very important information.
Defining alarm areas is also important. An alarm at a station within a work cell is often the roadblock to product flow through the cell. However, that alarm should not stop the auto sequencing of the other stations. The result should be more like a cycle stop, where possible.
The stations that can finish their cycles do, and other stations may continue to operate until operator intervention stops the cycle and removes power as needed to access and clear the alarm.
Once the alarms are defined and prioritized, they must be programmed. Some methods include use or face plates, templates or dialog boxes to create alarms in a controller or human-machine interface. These methods provide a fill-in-the-blank user experience. Another popular and common method uses PLC ladder logic to detect alarms. Proper use of standard programming logic, add-on instructions and user-defined data types can make the resulting program easy to edit and reusable.
Using simple relay logic, if a raised gripper output solenoid is energized and the corresponding gripper-raised sensor is not activated after a preset period of time, a “gripper did not raise” fault is latched on and displayed via an HMI as a fault indicator and message text. Something was turned on, but it didn't cause an expected result, so an alarm is generated.
Unfortunately, this simple logic often creates many alarms that don't exist, meaning it's not an alarm if the underlying control is not ready to run. For example, the machine power is off, the air pressure is low, and the emergency stop is pressed. All are valid alarms to display. However, the other alarms, such as “gripper failed to open” and “gripper failed to raise” are not alarm conditions until the machine is turned on and air pressure is present. These are preconditions that should be included to inhibit most alarms.
With priorities set and well-documented alarms, consider creating standard alarm logic with add-on instructions (AOIs). For example, if an AOI is created for the control of a solenoid-operated cylinder, providing advance and retract output functions, it includes the end-of-travel sensors as inputs to the AOI, as well, so all the data that is needed to create the alarm logic is available. Based on the state of the AOI's output, the sensors can be monitored for alarm conditions. Time is well-spent up front, including the alarm management when creating universal AOI for discrete control. The addition of the fault logic in the AOI can save significant development time. This is especially true in systems with many discrete devices.
In addition to the development of custom add-on instructions, pre-defined data tables and user-defined data types (UDTs) can help to configure and reuse the program bits, integers, timers and strings. A simplified example of a UDT would include several data types such as Station[5].Alarm[2].Timer.DN (alarm timer done bit), Station[5].Alarm[2].Present (alarm bit), Station[5].Alarm[2].PresentS (alarm description text string, for example, Station 5 gripper did not open).
These well-defined data tables and user-defined data types make it easy to copy and reuse code. Although sensors and outputs monitored will change, copying and pasting a well-thought-out rung of alarm logic usually requires editing only a single number in each instruction, such as changing Alarm[2] to Alarm[3].
Keep those alarm priorities, messages and logic simple and reusable.
