I have been teaching professionals how to troubleshoot with a PLC for 20+ years. Most of the time I’ve found that if someone says they are using PLC software and asking about troubleshooting PLC, they are referring to how to troubleshoot equipment and processes using that software, not how to troubleshoot the PLC Allen Bradley or Rockwell software itself. As the controllers are very reliable, and the problems encountered exist external to the PLC most of the time (See PLC controller failure rate). So here, I’ll focus mostly on how to troubleshoot equipment using PLC in this article.
First before moving on to PACs (RSLogix 5000, Controllogix, CompactLogix, etc.), learn the PLC (RSLogix 500, PLC5, SLC 500, Micrologix, etc.) first.
Although PLC training software and books covers basic fundamentals of troubleshooting the PLC its self, you need instructor based classes where instructors have years of experience in plants facing the same issues you will face out in the real world. Then they can pass on that knowledge and know best what you are most likely to run into.
It is important to pick a company specializing in PLC training (not PLC vendor or scholastic educators). As only instructors who have been out in facilities troubleshooting for a decade or more, can cover what are the most common problems you will face, prioritize what is most likely to occur, so you can get the most valuable information and techniques out of the automation control training. They’ll teach you things the OEM doesn’t even know, or say.
All that being said, on to the meat and potatoes. Best practice advice is to master PLC (RSLogix 500) before moving on to PAC (RSlogix 5000), because of the difference between PLC and PAC. A PLC is much easier to troubleshoot equipment with than a PAC. First, the PLC is much simpler. Electricians are usually the ones doing troubleshooting, so they relate to ladder logic, plus, the RSLogix 500 software has a whole array of troubleshooting tools that are only being piecemealed back into the RSlogix 5000 PAC over versions and time. This will make RSLogix 5000 troubleshooting a little less of a challenge in the future.
If you are taught PLC troubleshooting properly, utilizing the RSlogix 500 software and its tools, you will find most equipment problems can be troubleshot in 15 minutes, even if you are not familiar with the equipment or PLC program. (PAC/RSLogix 5000 maintenance and troubleshooting is much more complex, especially if the programmer used one of the 4 other programming languages like Structured Text.) Plus, the PAC’s complexity makes it more likely you will have issues with the PAC, software or program itself, as opposed to simple PLC troubleshooting and maintenance. So when troubleshooting equipment with RSLogix 5000 (or other PAC software like Siemens), you have to additionally consider whether the problem is with PAC itself, and not some sensor or other external problem.
So, with a PLC (RSLogix 500) most troubleshooting can be done in about 15 minutes, tracing back through the logic using ‘Find All’. This is to find out which sensor, limit switch or other device out in the real world is causing the problem with a machine or process. For more cumbersome troubleshooting like intermittent problems, RSLogix 500 has great tools like the Histogram, Custom Data Monitors, trend charts, writing your own diagnostics rungs using Latch bit, etc.
One example of real world troubleshooting we teach, which is not in books or software, is using RSLogix 500 program “Compare Tool” (Compare Tool may be in your version of RSLogix 5000, or as a separate software for PACs. Or you might not have the tool if you are using PACs, instead of PLCs to control your machinery.) Those not spending years maintaining a PLC/PAC controlled facility may not be aware of the common scenario of one employee on one shift changing the program, and the rest don’t know it. If the troubleshooter suspects that, they can use the program compare and once again within about 15 minutes, find the problem. (With PAC/RSLogix 5000, machines have been down for hours, even days, not knowing someone changed the program, because there are just so many other possibilities and complexities with a PAC.)
Software Tools to Speed PLC Troubleshooting
RSLogix PAC/PLC program compare tool
Side Note: We also teach maintenance to do a program compare after a machine OEM or PLC OEM has worked on your equipment. That way, they can learn what exactly the OEM changed in the program, learn from it, be prepared for it, and possibly be less OEM dependent in the future! The program compare tool and usage is even more important to downtime reduction since there is an ever-increasing number of OEMs accessing PLC/PAC programs remotely.
System Data Tables and other data tables found in a PLC (like RSLogix 500) are great troubleshooting tools too, but are not in PACs (like RSLogix 5000). This is another major factor contributing to the use of PACs resulting in increased troubleshooting and downtime. In BIN95’s instructor based PLC training, we also teach best practices in writing PLC programs, so attendees can identify if they are being used before purchasing new machines or systems controlled by PLCs. (Like RSLogix 5000 programmer compensating for missing data table files in their tag naming conventions, for example.) Having a program that was written using PLC programming best practices, with the end user in mind (customer who has to maintain equipment for the next 10-20 years), greatly reduces troubleshooting time.
That leads to another area of PAC/PLC troubleshooting training that greatly decreases downtime, by both the reduction PLC troubleshooting time and the number of times troubleshooting is even necessary. Another very important area not covered in books, OEM courses, College or training software is “Best Practices” in Control Automation management. Procedures and Policies developed from decades of experience that increases reliability and safety while reducing downtime and the need to troubleshoot in the first place. When it comes to PACs like RSLogix 5000, sound management policy and procedures are even more critical due to incompatibility issues with the various software version number and firmware numbers. (Something that is hardly ever a concern when working with PLCs.)
So, in summary, in order…
1. Master PLC troubleshooting before moving on to PACs.
2. Learn PAC/PLC Best practices.
3. Learn to trace back through PAC/PLC program using Find All or Cross Reference.
4. Learn troubleshooting tools provided in RSLogix 500 and RSLogix 5000
IE: Find all, Histogram, Data Tables, Trend chart, custom data monitors, program compare, etc.
5. Learn to write diagnostic rungs using Latch bit, Move and Copy instructions.
6. Learn BIN95’s best practices in working with and managing your facility’s control automation.
7. If unavoidable to use a Force for troubleshooting, know the safety steps first.
Hope this article gave you a heads up. Sign up for one of our seminars today, or request a free quote for onsite PAC – PLC training so you and your company can greatly reduce downtime.
About the author:
Don Fitchett is a Industrial Automation Trainer who specializes in Allen Bradley PLCs. He is the president and PLC Training Instructor of Business Industrial Network and is experienced in all aspects of manufacturing. Read more about Don
© Business Industrial Network and https://bin95.com, 2017 -. Unauthorized use and/or duplication of this material without express and written permission from this site’s author and/or owner is strictly prohibited. Excerpts and links may be used, provided that full and clear credit is given to Business Industrial Network and https://bin95.com with appropriate and specific direction to the original content. All trademarks and trade names are property of their respective owners.