Troubleshooting automated systems

Why it matters

When an automated line stops, everyone looks at the technician. Guessing and swapping parts wastes hours and money. A systematic method finds the fault quickly, and the PLC gives you tools a relay panel never had: status LEDs on every point, online monitoring and diagnostic buffers. Most faults turn out to be in the field devices and wiring, not the PLC.

A systematic method

1. Gather information. What exactly happened? What does the HMI alarm say? When did it start? What changed recently (a new part, a program change, a cleaning shift)?
2. Observe the machine safely from outside the guards. Which step of the sequence is it stuck on? Which actuators moved?
3. Check the PLC status. Is the CPU in RUN with no fault lights? Are I/O modules healthy? Check the diagnostic buffer or fault log.
4. Go online with the program and find the output that should be on but is not. Trace the rung back to the condition that is false.
5. Half-split the signal path: decide whether the fault is on the input side, in the logic, or on the output side, then keep dividing.
6. Fix the root cause, test, and document it in the work order.

Inputs: is the signal reaching the PLC?

The path for an input runs: field device → wiring → terminal block → input module → input image bit → program.

Checks, from least to most invasive:

• Does the sensor's own LED come on when the target is present? If not, the sensor, its target, its alignment or its power is the problem.
• Does the input module LED for that point come on? If the sensor LED is on but the module LED is off, the fault is in the wiring between them (or a PNP/NPN mismatch).
• Does the bit in the program go true when the module LED is on? If not, check the address or tag mapping, or whether the module is faulted.

Outputs: is the PLC command reaching the device?

The path for an output runs: program → output image bit → output module → fuse → wiring → interposing relay or contactor → field device.

• Is the output bit true in the program? If not, the problem is a missing condition in the logic: trace the rung.
• Is the output module LED on? If the bit is true but the LED is off, suspect a faulted module or a forced-off point.
• Is the output fuse intact and is there field power to the module?
• Does the interposing relay or contactor pull in? Does the device (solenoid, motor) respond? A coil can be open; a valve can be stuck mechanically.

Half-splitting

Rather than checking every point in order, test in the middle of the path. If the signal is good there, the fault is downstream; if not, it is upstream. Each test halves the search. On a long chain of series contacts or a long cable run, this saves a lot of time.

Worked example. A cylinder will not extend. The HMI shows the machine waiting at step 4, "extend pusher". Online, the output bit Pusher_Extend_Sol is true. The output module LED is on. That splits the problem: logic and module are fine, so the fault is in the field side. The valve's solenoid LED connector is dark, so voltage is not arriving at the valve. Under the site's lockout and test procedure, a qualified technician checks the field wiring and finds a cable crushed in a cable track. Fix, test, record. Total time: 15 minutes instead of an hour spent swapping the valve and the output card.

Using the program as a troubleshooting tool

• Cross-reference a tag to see every rung that reads or writes it.
• Trends in the HMI or programming software show when a signal flickers.
• Sequence step numbers tell you where the machine is waiting; the transition condition for the next step tells you what it is waiting for.
• Compare the running program with the backup to see whether anyone changed it.

What not to do

• Do not force I/O to "see what happens" on a real machine. Forcing overrides the logic and safety interlocks in the program, and can move equipment with people nearby. Only authorized people may force, with the area cleared, and all forces must be removed afterwards.
• Do not jumper out sensors or safety devices to get production running.
• Do not download program changes without authorization and a backup.
• Do not replace the PLC first: CPUs and modules are rarely the cause.

Practise safely

You can practise these skills without a live machine: paper exercises with I/O tables like the one in the Do tab, PLC simulators such as OpenPLC Editor's simulation mode (https://autonomylogic.com/), and the ladder logic simulations earlier in this course. Checked on 2026-10-23.

Safety

Voltage testing in control panels is energized electrical work: it needs the right meter, PPE, an energized work justification under NFPA 70E, and employer training and authorization. Control panels contain voltages that can kill, stored energy in drives and capacitors, and machines that can start unexpectedly. Everything in this course is practised on paper or in simulators. Working in real panels requires employer training, supervision by a qualified person, lockout/tagout and the arc-flash practices in NFPA 70E (https://www.nfpa.org/codes-and-standards/nfpa-70e-standard-development/70e), and for electricians a registered apprenticeship and state or local licence. Checked on 2026-10-23.

Recap

• Gather information, observe, check PLC status, go online, half-split, fix the root cause, document.
• Inputs: sensor LED → module LED → program bit.
• Outputs: program bit → module LED → fuse and field power → relay or device.
• Never force or jumper on a live machine without authorization.

Try it

Open the Do tab and isolate an I/O fault on paper.