PLC Troubleshooting - RSLogix 500 SLC MicroLogix Mathematical Overflow Fault Code Finding Techniques
Introduction
Troubleshooting a fault on a production PLC system is often stressful and ambiguous. Knowing how to navigate common issues on legacy systems running RSLogix 500 could save you and your plant precious hours of downtime.
In this tutorial, we will be going over a common error which we’ve observed in systems that run on RSLogix 500. The goal of the tutorial is to illustrate simple, yet effective, troubleshooting steps you can apply to most errors.
If you wish to donwload the program and try the troubleshooting steps on your own, here’s the link to the RSLogix 500 file. Note that you may choose to run this on an emulator or an actual PLC. In our case, it’s the MicroLogix 1100.
RSLogix 500 MicroLogix 1100 Fault Finding Program
The General Approach to PLC Fault Troubleshooting
The ability to effectively troubleshoot control systems comes from practice. By going through the steps, again and again, an experienced electrician, technician or engineer, will develop an eye for how to fix most problems. By practicing this skill, the individual will take less time on future problems they encounter. That being said, what is an effective starting process? Which steps would we typically take?
Step 1 – Resetting the Fault
It’s important to note that in production, every minute of downtime is expensive. Therefore, unless a potential problem of doing so is apparent, the first step is often to reset the PLC and set it back to “Run”. An intermittent fault may have been caused by a deadlock in the software, an electrical malfunction or a glimpse in the system. These aren’t common, but they do occur.
Step 2 – Using the Error Description Functionality
Every Programmable Logic Controller that throws a fault will present the user with a certain description. In RSLogix 500, this description may be accessed through the fault menu in the top left corner.
Once the menu is opened, it’s important to take note of the fault. This description will aid in the following steps of the process and may give the programmer a good idea of what the problem is.
Step 3 – Fault Research
Fault codes may be typed directly into Google. Chances are, someone has already encountered the same fault you’re seeing. The top results within the search engine are very good at resolving the fault of our experience. Note that some of these resources could be from a forum, blog post or another user-created resource. Other times, the fault code along with an extensive troubleshooting guide will be available from an OEM document such as a datasheet. Do not disregard user-generated content as end-users may often encounter faults that aren’t always known by the OEMs.
Step 4 – Technical Support Channels
If none of the above methods worked, it’s time to reach out for professional help. If you have access to paid channels such as Rockwell Tech Connect, it’s time to make a phone call. You’ll be connected with an expert from the company who should be able to guide you toward a resolution of the problem. If this isn’t available to you, it’s often possible to obtain help from a local system integration company. If you’ve purchased equipment from a local distributor, they may be of assistance as well.
Step 5 – New Fault Documentation
If you’re still stuck, it’s advised to post your fault with as many details as possible on an end-user community forum. As mentioned above, it’s highly unlikely that you’ve encountered an issue that has never been seen before. Create a post with as many details as possible on the following forum: SolisPLC Forums
RSLogix 500 Mathematical Overflow Fault Troubleshooting
RSLogix 500 allows the user to define the data types which will be used within the program. This process is different from RSLogix and Studio 5000 in which the user defines every tag instead.
PLC Troubleshooting – RSLogix 500 SLC MicroLogix Mathematical Overflow Fault Code Finding Techniques
By specifying certain data types and performing operations, the user can easily fall into the trap of “mathematical overflow”. This fault is caused by sending a value into a data structure which isn’t able to hold it.
In the program you’ve downloaded above, the counter is used to increment a Long Integer data structure through an ADD Instruction. The value within the Long Integer is then transfered into an Integer (N7:0) through the use of a MOV Instruction.
The program operates without an issue until the Long Integer reaches a value of 32768. At this point, the PLC throws a Fault and stops all operation. Resetting the Fault clears the error, but throwing the PLC back into “Run” mode faults it out immediately. Here are the details of the fault thrown by the PLC.
At this point, you may try to clear the fault and put the PLC back into “Run” mode. The fault reset is issued without a problem since the fault is considered minor. However, since the value is still over the allowed range, the PLC will fault out immediately upon setting it into “Run”.
Avoiding the Overflow Fault
This fault is extremely common in legacy systems. It’s easy to lose track of an integer during such a move or any other instruction which cause it to overflow. To mitigate its occurance, a PLC programmer has several options.
The first one being to create traps which would reset integers to 0 or prevent them from increasing further. This can be achieved by including a comparison condition prior to any mathematical operation. Based on the condition, the mathematical function may or may not be executed.
The second solution would be to use data locations appropriate for the requirements of the system. In other words, if you know that you may need additional memory, use a “Long Integer” instead of the “Integer”. This data structure will give you 32 bits of data and allow you to store larger numbers.
Lastly, each minor fault thrown by the PLC may be detected by the program through system bits. By unlatching the fault prior to the end of the program, it’s possible to ignore any of the faults thrown during a PLC scan. In other words, a OTU instruction used on the fault bit shown above, will allow the PLC to remain in “Run” mode despite the issue it encountered. Do note that the instruction which moves the values between integers will still fail to execute. In other words, the instruction will fail, but the PLC won’t fault out. It would be important to create a way to notify the program about this issue if it occurs.
Conclusion
In the field, most of your time will be spent troubleshooting and figuring out the root cause of different problems. One of the most important tools you can master is a systematic approach to troubleshooting faults. In fact, one of the methods to test PLC programmers during an interview is the analysis of their troubleshooting approach. Are they composed during the execution? Are they able to use all tools at their disposal? Are they concerned about the functionality of the equipment and the downtime it’s incurring?
The approach is simple; start by using the tools within the programming environment. Proceed to researching the faults thrown on Google and appropriate forums, blogs and 3rd party sites. Lastly, reach out to OEMs, local distributors and through technical support programs.
Last, but not least, never dispair!
