Is it the PLC or the field? Reading fault codes and I/O status

Sometimes the PLC itself is the problem, not the machine. Read the processor and module status LEDs, the fault code, and the comms — and you'll know in seconds whether to chase a field device or a piece of the controller.

A faultline101 training module · the skill behind six hands-on scenarios

Sometimes the controller is the problem, not the machine. Read the processor and module status LEDs, the fault code, and comms to know in seconds whether to chase the field or the PLC.

The idea

Most of PLC troubleshooting is chasing field faults through the logic. But sometimes the controller is what failed — a processor major fault, a faulted I/O module, a blown module fuse, or a dropped network. Chase the field on one of those and you'll waste hours on healthy sensors.

The tell is in the hardware status: the processor's run/fault LED, each module's status LED (solid vs flashing), the fault code, and the comms indicators. A whole card reading 0 usually isn't sixteen sensors dying at once — it's the card's field power, its fuse, or the module itself.

So before you disappear into the field, glance at the rack. If the processor is in a major fault it isn't even scanning; if a module LED is flashing, that module faulted; if remote I/O comms dropped, the inputs are frozen at their last state and lying to you. Rule the hardware in or out first.

Six faults you'll work in this module

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

1. Sixteen sensors don't die at once. One fuse, not sixteen dead devices.
2. The processor stopped scanning. Fix the controller fault first; the field was never the issue.
3. Frozen, not fine. The tags were stale, not truthful.
4. One flashing light. The flashing LED named the exact point.
5. Too many coincidences. One common cause, not four bad devices.
6. Cold: hardware or field?. Hardware-vs-field, decided in seconds, then a clean field trace.

The mistakes it kills

• Chasing field devices when a whole card reads 0 because its fuse or field power is gone
• Not noticing the processor is in a major fault and isn't scanning at all
• Trusting frozen inputs after a comms drop as if they were live

Why it matters: Knowing in ten seconds whether it's the controller or the field is what stops you from meloading twenty good sensors while a blown module fuse sits there flashing.

More: Follow the rung backward · Get the comic · All troubleshooting guides.