PLC Alarm Programming - Advanced Alarm Capturing in Ladder Logic RSLogix 500 Allen Bradley
In a recent post, we’ve covered the importance of properly defining alarms, faults & warnings within a PLC routine. Although we went over the basics, an advanced practice would require us to go a step above what we’ve defined by implementing ladder logic which would capture the first fault which occurred. The purpose of this logic would be to notify the operator or engineer which fault came first as in many cases, an array of faults would be triggered after the first one.
For example, if the tank reaches a critical level, the system is shut down, valves are opened and you now have alarms for temperature, pressure & level. You’d want to know that the problem was initially caused by the tank overfilling so that you can rectify the issue.
Assigning Unique Fault Codes
A unique fault code should be assigned to every single fault, alarm, and warning. These values are needed to properly troubleshoot the system, describe faults as they occur and keep track of what’s going on. Making sure that this is in place at the very beginning will save a lot of time down the road.
We’ve assigned fault codes to our faults in the previous program, but we do need to store them within a register in order to identify which one is which. It’s possible to do this with a string, but it’s much more difficult to manipulate and isn’t recommended. A common practice is to create a simple spreadsheet which lists all the faults, warnings and alarms of a system along with the identifier assigned to each one. Here’s a screenshot of one of my spreadsheets.
You may note that the spreadsheet above is slightly more complex than what we’ve implemented in the previous tutorial. It’s used for a system which has multiple areas of operation thus required me to track which fault would shut down an area. This is an advanced practice which you’ll get to as you program Programmable Logic Controllers.
Identifying which Fault Occurred First
As mentioned above, we will use the unique identifier to capture the first fault which occurred. By utilizing a simple MOV Instruction, we can transfer the appropriate ID into a register which stores the fault. The example below illustrates the MOV Instruction which is executed once the fault is triggered. The comparison instruction EQU allows us to store the value only when the fault register is set to 0. This is important as once we capture the fault, the register is no longer equal to 0 and thus our logic prevents another fault which contains the same logic to store the ID once it’s triggered.
Resetting the Fault Register
We’ve captured the fault, but we need to reset the register once the system is back into operation. This can be easily achieved through the use of the “system reset” which we’ve configured previously. Here’s the logic which does exactly that:
Knowing how to work with Faults, Alarms and Warnings is an important skill when it comes to Programmable Logic Controllers. Although different situations will require different solutions, it’s always good to have a strong base on how to set these up; they are present in every single application.
In many circumstances, you’d want to know which fault occurred first and triggered all the other ones. This would allow the operator or engineer to troubleshoot the system much easier as the source of the problem is known. To create this logic, you can leverage a fault register paired with a MOV instruction which stores the unique ID of the fault.