PLC Troubleshooting: How to Find the Fault
The line is down and people are watching
That is the situation this skill exists for, and the pressure is the hard part. The engineer who finds the fault is rarely the one who knows the most. It is the one who stays methodical while everyone wants a guess.
A method that works
Find out what changed. Almost every fault follows a change: a new batch, a part swapped, maintenance last night, a setting adjusted, a program downloaded. Ask before you touch anything. "It was fine yesterday" is data.
Establish what is actually true. Not what the operator thinks, not what the HMI says, what the controller sees. Go online and look at the inputs. A surprising proportion of faults end here, when the signal you assumed was present is not.
Work outward from the symptom. If a cylinder will not extend, the chain is: PLC output bit, output card LED, solenoid coil, air supply, the cylinder itself. Check the bit first, because it is free and instant. If the bit is on and the card LED is off, you have narrowed it to a card or wiring in one step.
Split the problem in half. Do not walk the chain end to end. Test the middle. If the signal is good at the terminal strip, the fault is downstream and you have eliminated half the system.
Change one thing at a time. Two changes and a fix tells you nothing about the cause, which means it will happen again.
What actually goes wrong
In rough order of how often it recurs.
Sensors. Misaligned, dirty, or drifted. Photo-eyes fill with dust, proximity sensors get knocked, and reflective sensors fail when the target changes colour. The sensor that works when you look at it and fails during production is usually marginal rather than broken.
Wiring and terminations. Vibration loosens screw terminals. Cables chafe where they flex. Intermittent faults that follow machine movement are almost always mechanical damage to a cable, and they are the most time-consuming to find because they refuse to reproduce while you are standing there.
Power supplies. A 24 V supply drooping under load causes behaviour that looks like a logic fault: outputs that will not hold, controllers that reset. Measure under load, not at rest.
Drives. Overcurrent trips on acceleration, usually because the ramp is too aggressive for the load or because something is mechanically stiff. Read the fault code and its history rather than resetting it repeatedly.
Program state. A sequence stuck in a step because a transition condition is never satisfied. This is not a broken PLC; it is logic meeting a situation nobody anticipated, usually a stop at an unusual point in the cycle.
Communications. A dropped node on Profinet or EtherNet/IP, often a switch, a bad patch lead or a duplicate address.
Genuinely failed CPUs are rare. Replacing one should be near the end of your list, not the beginning.
Reading a stuck sequence
The most common software-shaped fault. Something happened, the machine stopped mid-cycle, and now it will not restart.
Find which step it is in. Any sequence worth the name exposes the step number somewhere. Then look at the transition out of that step and read every condition. One of them is false. Go and find out why in the field rather than assuming the logic is wrong.
Nine times out of ten the logic is correct and a condition genuinely is not met: a cylinder not fully home, a guard not closed, a part still present at a sensor that expected to be clear.
The tools
Online monitoring in the programming software, which shows you live values and which rungs are true. This is the single most useful thing you have.
A multimeter, and the habit of measuring rather than assuming.
The trend or historian, if there is one. Lining up several tags on the same time base and reading the order events happened in settles most arguments about cause.
The drawings, marked up honestly. A drawing that no longer matches the panel is worse than no drawing, and keeping them accurate is part of the job.
Habits worth building
Write down what you did. The next person, who may be you in six months, needs to know that the sensor was replaced in March.
Do not clear a fault before reading it. The fault history on a drive or controller is evidence.
Distinguish the fix from the cause. Resetting a tripped drive restores production; it does not tell you why it tripped, and it will trip again.
Say what you do not know. "I have eliminated the output card and the wiring, I am now checking the solenoid" is a far better answer to a production manager than a confident guess that turns out wrong.
What this is worth
Fault-finding is the skill employers test for and the hardest to fake in an interview. Anybody can describe a PLC. Being asked how you would approach a cylinder that will not extend, and answering with a method rather than a list of parts, is what separates candidates.
It is also the reason training on real hardware matters. Simulated faults are clean. Real ones involve a loose terminal you can only find by pulling on wires.
