Everything in this book condenses into a single procedure you can run
on almost any PLC-controlled fault. Its value is not that each step is
clever — it is that following it in order stops you from skipping the
check that would have saved an hour. Under pressure, the procedure is
what keeps you rational.
bottom; each step narrows the search before the next.
The steps, expanded
Ensure safety. Identify energy sources and apply LOTO or safe
live-work practices before touching anything.Observe and define the symptom precisely. ‘It’s broken’ is not a
symptom; ‘the infeed will not start and shows no HMI alarm’ is.Check the obvious. Power present, air supply on, E-stops
released, main indicators sensible. A startling share of faults end
here.Read the faults. HMI alarm history, controller fault log or
diagnostic buffer. Let the machine tell you what it saw.Go online. Determine whether the problem is an input not
arriving, logic waiting on a condition, or an output not
acting.Split the signal path. Pick a midpoint and test there to halve
the search — field device, wiring, card, image, logic, output,
actuator.Compare field versus tag. Measure the real device at the terminal
and compare it against the value the controller holds. A disagreement
localizes the fault instantly.Isolate the cause. Swap a suspect module for a known-good one,
force carefully to test a path, or bypass-test a device — always
safely.Repair and verify. Fix the confirmed cause, then run the machine
under real conditions to prove the fix, not just at idle.Document. Record the cause, the fix, and anything that would
prevent recurrence. Close the loop.
tells you whether the fault is upstream or downstream, halving the
search with each measurement.
THE CORE MOVESteps 6 and 7 are the heart of PLC troubleshooting: the signal either |
Why the order is the point
The steps in this procedure are individually obvious; their power is
entirely in the order. Safety comes first because nothing else matters
if someone is hurt. Defining the symptom precisely comes before any
testing because a vague symptom sends you nowhere. Checking the obvious
comes before reading faults because it is fast and catches a surprising
share of problems. Reading faults comes before
theorizing because the machine may simply tell you, and ignoring its
report to guess is prideful waste. Going online, splitting the path, and
comparing field to tag form the core narrowing, each halving the search.
Repairing and verifying comes with verification attached because a fix
unproven under real conditions is not yet a fix. Documenting closes the
loop because an undocumented repair helps no one next time. Every step
prevents a specific, common failure, and seeing which failure each step
guards against is what convinces a technician to keep following the
whole sequence even when a particular step feels skippable, since the
skippable-feeling steps are often exactly the ones that would have
caught the fault fastest.
Beyond the ten steps: growing as a
troubleshooter
The procedure is a foundation, not a ceiling, and the technicians who
grow beyond it do so by deepening the understanding that makes each step
faster and surer, not by abandoning it. With experience, the steps run
more quickly — the obvious checks become instinctive, the fault log is
read fluently, the split points are chosen shrewdly — but the sequence
remains, because its value never expires. Growth comes in the judgment
layered on top: knowing from experience which faults tend to afflict
which machines, recognizing a familiar pattern quickly while still
verifying rather than assuming, choosing the most informative
measurement first, sensing when a fault is beyond one’s scope and
escalating cleanly. This judgment does not replace the method; it
accelerates it, letting an experienced technician run the same
disciplined sequence in a fraction of the time while remaining just as
rigorous. The aspiration is not to outgrow the procedure but to execute
it so fluently and with such accumulated judgment that it looks, to an
observer, like the sixth sense that the first chapter warned was a myth
— which it is, being in truth a deeply internalized method carried out
with the speed and shrewdness that only experience brings.
A case file: the procedure on a communication
fault
To see the procedure handle a different kind of fault, follow it on a
communication problem. A machine stops, and step one is safety — the
technician confirms the state of the machine before investigating. Step
two, define the symptom precisely: the machine stopped and the HMI shows
a communication-related alarm naming a section of the machine. Step
three, check the obvious: power and the basic indicators are sound. Step
four, read the fault: the HMI alarm and the controller’s device view
together show that a group of networked devices in one part of the
machine has dropped communication. Step five would be going online to
determine input, logic, or output — but the fault has already declared
itself as communication, so the equivalent narrowing is to scope which
devices are affected, and the controller’s view shows a contiguous group
missing together. Step six, split the path: the missing devices share a
network path, so the technician tests at a midpoint of that shared path
rather than at each device. Step seven, compare expected against actual:
the controller expects those devices present but sees them missing, and
the pattern points at their shared connection. Step eight, isolate:
inspecting the shared network path reveals a failed connection where
that group branches off. Step nine, repair and verify: restoring the
connection revives all the missing devices, and the machine is run to
confirm stable communication. Step ten, document: the technician records
the symptom, the failed shared connection, the fix, and any note on
protecting that connection. The same ten steps that localize an input or
output fault localize a communication fault, adapted to the network’s
diagnostics — scoping by which devices are missing, splitting along the
shared network path, comparing the controller’s expectation against what
it sees — proving that the procedure is a general method that
accommodates the specific character of whatever fault it is applied to
while keeping the disciplined sequence that carries the investigation
from a stopped machine to a verified, documented fix.