Today we will cover the first three steps on how to backup your Allen-Bradley Logix Controller Program to your PC. The detailed steps include: Connecting to a Serial Controller; Establishing a RSLinx Connection; Launching RSLogix 5000; Stay tuned for Part II where we will connect to Ethernet and USB controllers.
FactoryTalk View Site Edition
FactoryTalk® View Site Edition software provides a comprehensive and accurate picture of operations via tight integration to your Logix control platform and FactoryTalk information systems.Learn moreFactoryTalk View Machine Edition
FactoryTalk View Machine Edition allows for a consistent operator interface across multiple platforms, including Microsoft® Windows® CE and Windows desktop solutions.Learn moreFactoryTalk ViewPoint
FactoryTalk ViewPoint extends a FactoryTalk View HMI application to a web-browser interface for access from home, on the road, in the air–wherever you can get an internet connection.Learn moreRSView 32
RSView32® expands your HMI/SCADA with open technologies that provide unprecedented connectivity to other Rockwell Software products, Microsoft products, and third-party applications.Learn more
Rockwell Software eNews
NEW Rockwell Software eNews
Your search is over. Get all the latest news and updates in one place with the Rockwell Software eNews.
Spotlight Webinars!
- Modern HMI Reduces Risk and DowntimeObsolete SCADA systems and security concerns drove this food manufacturer to migrate their unsupported systems to a distributed FactoryTalk View SE application in a secure, virtualized environment. Solution Partner Grantek Systems guides them to the future.
- Data Management and Reporting for Effective Manufacturing IntelligenceManaging your data is not just about collecting data, but looking at the “right” data in your systems and creating reports that provide effective decision making information for productivity improvements. Learn how to create a system that works for your needs and can provide immediate results.
- Modernize Metals Production With MESLearn how modern MES can ease the struggle with data collection, manufacturing intelligence, material tracking, and knowledge, quality, performance and recipe management.
Contact Us
We are eager to help. Make a selection below to get answers to questions on sales, products, services and technical support.
PLC Alarm Programming – Fault Capturing Example in Ladder Logic RSLogix 500 Allen Bradley
Alarms, Faults, and Warning play a critical role within every PLC Program. This logic allows the programmer to capture any abnormalities, alert the operator of a failure, and prevent system damage. Ultimately, this code is needed to make sure that equipment is brought to a safe condition after a critical failure.
These conditions can be detected by sensors, be the result of certain operator errors or be programmed in software. Whatever the source of the error, the system must be able to capture the occurrence and to act accordingly.
A common question and debate between PLC programmers is the distinction between the levels of faults & the proper designation of each one. My approach is quite simple: a fault will cause a stop of a certain process; a warning will only be a visual indication for the operator. In other words, there are two types of errors: one which will cause a stop and the other which will not. However, the programming of these is absolutely the same. The final outcome will be determined by the programmer.
As you work & observe the Alarm structures within PLC applications, you’ll notice that they generally follow a similar structure. The reason for this, of course, is that there are certain principles when it comes to alarms, faults & warnings. Here’s a brief list of some of these best practices which I’ve discovered over the years.
- Alarms must reside in a separate routine.
- It’s easy to be confused by the general logic written by another programmer. However, alarms, faults & warnings are the most critical items as they protect the process from failure. Therefore, it’s important to make them easily accessible & visible to a novice programmer, technician, etc.
- Alarms must remain latched in until they are cleared by manual intervention.
- Remember that an alarm is an unrecoverable event. This means that the system is beyond the point of being able to stabilize itself; it will require intervention. Therefore, it’s crucial to make sure that the operator, as well as other parties at the facility, are aware of what caused the issue. Each alarm which occurred during the incident must remain active until it is addressed.
- Alarms must have a unique identifier.
- A unique ID allows one to easily refer to an alarm. Furthermore, it’s something which programmers often use to troubleshoot the system. A unique identifier displayed on an HMI screen will allow a skilled engineer to immediately trace the logic on the Programmable Logic Controller and find the root cause of the issue.
A basic alarm rung is shown below. It’s composed of a few basic instructions which we’ve covered in other tutorials.
The first XIC instruction is the trigger for the alarm. This instruction may be replaced by any other which will cause the alarm to energize. Since the “System Fault Reset” bit is tied to an XIO, it will allow the final bit to energize should the “TEMP HIGH” fault trigger through the I0:0 input on the MicroLogix 1100. Once the B3:50/0 internal boolean is energized, it’s latched in place by the XIC Instruction which is tied to itself. Doing so satisfies the condition mentioned above. Lastly, the only possible means of de-energizing the fault after it has been triggered is by using the “System Fault Reset” bit. This bit is tied to field buttons as well as an HMI button in the “Main” routine.
Do note that in RSLogix500, it’s not as simple to give tags a meaningful name. Therefore, a description containing a unique ID is given to the fault bit. This is used as a reference to the fault & will be used for the HMI application.
Expanding the Structure to Infinite Alarm Conditions
Now that we have a finished rung, we can copy & paste it as many times as needed until we’ve covered all the alarms. Of course, we need to update the tags we’re using for triggering the alarm as well as the alarms themselves. The reset bit should stay as is. Here’s what a structure of the second alarm looks like.
Do note that the trigger has changed to a GRT Instruction. This is because the simulated signal which will trigger this alarm is an analog value. Therefore, it’s not an internal bit, but rather a limit which was set by the programmer.
Now that we’ve defined multiple rungs which represent unique alarms/faults, we need to make sure that we’re able to stop the process in case of a failure. This can be done by inserting a condition for each alarm into the “Main” routine. However, a much more elegant way would be to utilize area identifiers of failure. These bits will aggregate multiple alarms and can be utilized to stop a single area. This makes the logic much easier to read and allows the programmer to segment the different areas from within the alarm routine.
Here’s an example of the main area (Tank 1) fault status which aggregates 5 different alarms that we’ve defined previously.
Alarms, Faults & Warnings are crucial components of every automated system. They are used to prevent damage, critical failure or injury to an operator. These alarms much are defined in a clear and structured manner in order to be effective, be easy to troubleshoot & provide information to anyone working with them.
The three main principles of each alarm are as follows: keep the alarms latched until the problem has been identified and manually reset, give each alarm a unique ID and make sure to have your alarms within a dedicated routine. Following these principles will make sure that the code you leave behind can be easily understood.
Lastly, make sure to work with a professional if you aren’t comfortable with implementing alarms. A proper risk assessment must be conducted on a process before identifying all the potential failures.