PLC Troubleshooting Best Practices

PLC Troubleshooting : PLC Training Best Practices

This is section 4 PLC Troubleshooting of the PLC Training Best practices. Remember when you refer to PLC troubleshooting, you are mostly referring using the PLC to troubleshoot otherwise complex equipment. You do not troubleshoot the PLC itself that often as it is built to industrial standards and is highly reliable.

Additional PLC Troubleshooting support: Review 29 CFR 1910.147 standards, Problem solving training, Root Cause Analysis (RCA) and Ishikawa "Fishbone" diagram for more complex troubleshooting.

To increase one's troubleshooting training skill, in the past the only way was through years of experience. The more years experience one had, the better they got. Now there is real world simulation PLC troubleshooting training software, that allows you to gain years of experience in just days. Below are PLC troubleshooting training tips and best practices of PLC training contained in these 10 sections address. This page is for Section 4 of these 10

The information on this page protected by international copyright laws. You may not copy or distribute any of this page content in anyway without express permission from site owner. You can share this page hyperlink with others though.

PLC Troubleshooting Training Tips:

Remember electrical wiring diagram may not be same as electrical schematic.
Solve a common PLC program loss fault by using an EEPROM configured to load on fault automatically.
Most troubleshooting that involves a PLC, also involves electrical, so it is a great idea to take the electrical troubleshooting course too, before moving on to PLC training.
Before troubleshooting, set your frame of mind to Patience, Perseverance, and Perfection (3Ps).
Troubleshooting by part swapping is costly in both parts and downtime, follow best practice structured approach 4.1 below and make part replacement and guessing a last resort.
For intermittent problems, you can optionally use the "trapping" method of troubleshooting by adding a rung to look for suspected conditions and latch a bit to confirm.
The PLC processor module is the least likely part to fail, always try re-downloading PLC program, before replacing processor module.
The majority of the time, communication problems are caused by cable and/or connection. Second try re-installing the driver. 3rd, re-boot computer.
If you get math overflow fault in processor (value of 37767 in a memory location), the PLC has not been programmed properly.
Failure probability outlined in section 4.2.3 below is multiplied by design complexity. The more simple the design and PLC programming is kept, the less things to fail and mistakes are less likely to occur.
To gain years of troubleshooting experience in just days, see the real world PLC troubleshooting training and evaluation simulation software. A great way to test one's troubleshooting experience too.
More coming soon ...

Section 4: PLC Troubleshooting:

The tips and best practices on this page will be helpful for ...

The maintenance manager, commercial electrician, industrial electrician, instrumentation tech, mechatronics technician, industrial engineer, industrial IT person or the mechanic cross training and others.

Bookmark this page or site; as new best ways for PLC technician, industrial electrician, instrumentation technician and others to perform PLC troubleshooting task are verified, they will be added here.

PLC Training Best Practices:

4.1 Troubleshooting using a PLC:

PLC Troubleshooting requires the most real world experience yet that real world experience and advice is the least documented. Below we begin the long process of documenting that troubleshooting knowledge required.

Troubleshooting a PAC can be much more involved than troubleshooting a PLC.

4.1.1 Symptoms

Indentify and document all symptoms. Start with machine operator report. Include frequency of problem and if it can be repeated. Also review maintenance log to see if any recent changes to machine and/or PLC program have occurred.

4.1.2 Review PLC program

Review PLC program related to symptoms and gain more insight into way machine was programmed to operate.

If PLC program has recently been changed, do a PLC program compare on current copy and a none working copy from past to indentify exactly what changes to the PLC program have been made.

4.1.3 Divide and conquer

Use the problem description and symptoms documented in first section to indentify a narrow part of the machine or system and PLC program the problem and symptoms are related to. As you go through the PLC troubleshooting process, keep dividing into even smaller sub sections as the opportunity presents itself. If possible, test operation in manual mode, to see if problem occurs in manual mode as well as automatic mode. If problem occurs in manual mode too, troubleshooting manual operation is much more simple, than troubleshooting in automatic.

4.1.4 Trace Ladder Logic

Most PLC troubleshooting is the process of converting the symptom to a desired action not occurring, which then is single out to a real world input or output. You then trace backward from real world I/O through internal conditions to be met. Eventually and most commonly trace back through each relevant rung, until you wind up at a different real world input not being made or vise versa for example. This troubleshooting scenario is common because most of the time, the cause of the problem is outside the PLC in the real world. Like a Limit switch not being made or broke.
More coming soon ...

4.1.5 Verify Cause(s)

If while tracing back through the ladder logic, potential causes branch of into 2 or more, pick the one that is most cost effective to verify first. That may be cost effective because it is the quickest, easiest, etc.
Also a key element of verifying I/O (for startups and subsequent certification follow-ups )
More coming soon ...

4.1.6 Advanced PLC troubleshooting

If you have an intermittent problem or can not troubleshoot it efficiently, if possible go online with PLC and save a copy of program while problem is occurring. This will allow you to study the program, timers, I/O states etc. in a more productive environment. This way if possible, the machine can be reset and/or ran manually while PLC program is being studied. If troubleshooting requires understanding of more advanced areas of PLC program, a copy can be sent to OEM for support.

4.2 Troubleshooting the PLC its self:

Inventory all PLCs in your facility

4.2.1 Working with PLCs Safely

Anything to do with PLC forces is a safety issue and should be handles with standard safety protocols.

Follow 29 CFR 1910.147, The control of hazardous energy (lockout/tagout)

4.2.2 Working with PLCs Reliably

Have EEPROM configured to load .automatically on memory error.

As soon as you go online with the PLC, save a temporary extra copy and append to the end of original PLC program name, 'current' or 'faulted' so you have a backup copy to put PLC program back to original state when you first accessed PLC. More about backing up your automation control programs.

Have all employees who will be troubleshooting machine/systems receive PLC foundational training so they can be trained in all reliability best practices like the few examples above.

4.2.3 Failure probability

Standard Failure probability (physics) should be applied to troubleshooting PLC too. In order of most likely to least likely; Mechanical (external to PLC), electro-mechanical (external to PLC first, then PLC modules), Real world I/O, PLC modules(High current then Low current)
More coming soon ...

4.3 PLC communications:

Never use default node and IP address

Disconnect 3rd party outside sources (like OEM vendor support communication), unless you have contacted OEM. then after support instance is done, disconnect outside communication again.

To save communication troubleshooting time after 2 or more devices are added to the network, add each device one at a time, verifying communication if possible before adding next device to network.

Failure probability (physical) apply to PLC communication troubleshooting too. 90% of established communication network failures are due to physical attributes like connection, cable, power supply or communication card. Second most likely cause is communication drivers.

For troubleshooting networks while commissioning or if failure probability method above does not yield desired results, next you should use the Open Systems Interconnect Model. IE: Start with physical layer (mentioned above), then data link layer, network layer, transport layer, session layer, presentation layer, application layer.

Next ... Section 5: Hands-on PLC Training Best Practices. To learn more best practices seek out this Instructor Based PLC training.

PLC Training Org.

PLC Troubleshooting : PLC Training Best Practices

PLC Troubleshooting Training Tips:

Section 4: PLC Troubleshooting:

PLC Training Best Practices:

Recommended PLC training path by occupation...