Follow the Rung Backward: Using the PLC to Find the Fault

A machine is down and the crew is already guessing. But the PLC isn’t guessing — it knows exactly which condition is false and it’s showing you, right now, if you go online and read it. A dead output is a trail of breadcrumbs. The code doesn’t lie.

PLC troubleshooting module · the skill behind six hands-on scenarios

The output is off. The PLC already told you which contact broke the chain — you just have to read it backward.

The move: a dead output is a trail of breadcrumbs

An output that won’t turn on is not a mystery to the PLC. Every output is the end of a chain of conditions the original designer wired in ladder logic. If the output is off, at least one condition in that chain is false — and the controller is showing you which one, live, the instant you go online. The method is always the same four steps:

• 1. Find the rung. Search the program for the output that isn’t coming on (CONV_RUN). Go to where it’s written.
• 2. Read which condition is false. In monitor mode the true conditions light up and the false ones don’t. Don’t assume the obvious one — read which is actually open.
• 3. Cross-reference it back. That false bit is written somewhere — a physical input, or another rung. Jump to its source.
• 4. Keep going until you hit the real world. Trace backward, rung by rung, until the trail ends at a physical input: a switch, a sensor, a field device. That’s your fault.

Why this beats the parts cannon

The guesser sees “conveyor won’t start” and starts swapping: new start button, new relay, new drive. Hours and parts, chasing everything the fault could be. The troubleshooter goes online, follows the dead output back to a single open contact, walks to that photo-eye, and wipes the lens. Thirty seconds. The difference isn’t talent — it’s reading the evidence the machine is already handing you.

Backward tracing doesn’t just find the fault — it tells you where to stop looking. If the trail ends at an input the PLC reads as true but the field device is dead, the code is fine and the problem is downstream. The rung just saved you from tearing into a program that was never wrong.

Six scenarios in this module

You don’t learn this by reading it — you learn it by doing it on six different faults, each one drilling the same move until it’s instinct:

1. The blocked eye. Conveyor won’t start; the crew blames the start button. You trace the dead output to one open photo-eye input — caked lens.The output named the exact input to check.
2. The interlock holding it off. Pump output false; everyone assumes a dead pump. The trace lands on a normally-closed high-level bit doing its job.An interlock working looks just like a dead machine.
3. Stop looking in the code. Output bit reads TRUE, device is dead. The trace proves the logic is fine — the fault is downstream.Tracing tells you when to quit the code and go to the field.
4. Which condition is false? A rung with five conditions. You find the one that’s actually open — a quiet NC contact set in another routine — instead of assuming.Never assume the obvious condition. Read it.
5. Curveball — the code didn’t lie, the wire did. The output won’t seal in. The trace shows a seal-in broken by a momentary input dropping out — a loose field wire, faithfully reflected in the logic.The PLC showed the truth: a flickering input. You just had to watch it.
6. Cold capstone — you’re the one they called. Unfamiliar machine, line down, on the clock. Nested permissives across routines lead you back to a single missing “ready” bit from an upstream station.An unfamiliar program is still just rungs. Follow it back — it always ends at a real cause.

Related: The crew swore they checked the jumpers · The breaker was screaming, not nagging · Get the comic · All troubleshooting guides.