Ladder Logic: Fault detection and messages
In ladder logic, faults are used to capture abnormal circumstances such as an actuator not completing its motion within a prescribed period of time. Each cell or station in a program will usually have its own fault routine. There is usually one fault for every motion (extend, retract, raise, lower and so on). Other faults may include lack of air pressure, emergency stop actuation, guard door switches and drive or overload alarms. Note that any system fault disables the timer on the fault rung. This serves two purposes:
1. Only the fault that happens first is enabled. This prevents subsequent faults that may have been caused by the initial fault from occurring. If air is removed from the system several pneumatic actuators may fault within the same event.
2. After the fault occurs the timer resets allowing a new countdown. This allows physical correction of the cause of the fault by maintenance or an operator.
There are a couple of methods of resetting the fault. One is to clear the register word that contains the faults, in this case word 10. This fault word may be for only this cell allowing the system reset signal to reset faults in sections if desired; word 10 for cell 1, word 11 for cell 2, etc. Another method is to reset or unlatch faults individually.
These reset signals can also be individually conditioned this way on each rung.Faults can also be used in a permissive rung to prevent actuation of an axis. Fault bits are also used to activate messages on a touchscreen or human-machine interface (HMI), for instance, bit 10.0 might bring up a message that says, "Axis SV1.0 Failed to Extend; Correct Fault and Press Reset." The message would be cleared when the fault is corrected and the fault reset button pressed.
There are several ways to display fault messages on an HMI. Most HMI software allows the user to make a list of faults and then call them by number to display in a banner or other type of text display.
Another option is to configure the trigger to display the message by bit number. This also allows multiple messages to be displayed on a timed cycle, unlike if the message were to be displayed by value or placing a number into the message register.
The background color of the message can also be configured so that fault messages and warnings or other informational text can be displayed in the same banner. This is especially helpful if the HMI is small and doesn’t have room for more than one message display.
Besides faults and messages, these displays can be used as multi-state indicators to show the mode of a machine or station status. Other properties of the message display can also be configured such as its visibility.
There are advantages and disadvantages to using bits versus values. Using bits allows several "states" or messages to exist at the same time, whereas a value allows only one message to be called. If the HMI does not have the ability to cycle through messages with several bit triggers active at the same time, it will be necessary to write code in the programmable logic controller (PLC) that cycles through the messages.
Another method that is sometime used for message displays is to simply place a string display on the screen. While this is simple on the HMI end, it requires the PLC program to cycle through the strings and place them into the message register, which of course must be of the STRING data type.
This technique has advantages and disadvantages.
On the plus side, string messages can be changed dynamically by the PLC programmer. As a matter of fact, the programmer can give access to the user of the touchscreen by placing links to the locations of the string registers on a screen. This allows the messages to be configured without using the HMI software.
On the minus side, it is difficult to manage background or text colors using strings. The background would have to have a color register assigned to it which would be managed separately.
Frank Lamb is the founder of Automation Consulting LLC, and is a member of the Control Engineering Editorial Advisory Board. This article originally appeared on Automation Primer’s blog in two parts. Automation Primer is a CFE Media content partner. Edited by Chris Vavra, production editor, Control Engineering, firstname.lastname@example.org.