PLC Simulator
Fault Diagnosis

PLC Troubleshooting — Trace the Output Back to the Fault

Start at the failed machine output and move backward through command, permissives, PLC state, I/O and field devices. The seven-step method turns random checking into a bounded diagnosis you can practise on live faults.

Start a fault scenarioRun your first PLC program — no signup

Join 15600+ learners practicing PLC programming

First fault scenarios and wiring labs are free. Create a free account to save your progress.

PLC troubleshooting — 7-step method, four fault families, inputs to field

Where faults live

The four fault families

Before any diagnosis, identify the first observed mismatch. A field device, card LED, software tag, rung state and output command form an evidence chain; the first disagreement determines the fault family and next check.

PLC fault families — wiring, config, logic, intermittent, with symptoms, first checks, and tools
The four fault families and the first check for each.
Wiring fault
Symptom
Input never changes state despite field device operating
First check
Supply voltage at device; continuity back to I/O card
Tool
Multimeter
Trained by
Wiring fault labs: fault-01 through fault-08
Configuration fault
Symptom
Input changes but PLC ignores it, or wrong engineering-unit value
First check
Tag address, I/O card slot assignment, scaling block
Tool
Software monitor
Trained by
Fault scenarios: fault-03 (wrong address)
Logic fault
Symptom
Rung stays false even when all inputs appear correct
First check
Contact types (XIC/XIO), interlock conditions, coil address
Tool
Ladder monitor
Trained by
Fault scenarios: fault-01 (NO/NC swap), fault-02 (missing seal-in)
Intermittent fault
Symptom
Fault clears itself; reappears under load, heat, or vibration
First check
Connector seating, shielding, data logging over time
Tool
Multimeter + data log
Trained by
Fault scenarios: fault-08 (intermittent edge-case)

Evidence before replacement

See how each observation narrows the PLC fault window

These examples move from a visible machine symptom to a bounded cause, including input and output splits, scan-order behavior, intermittent evidence and the verification step after the repair.

PLC troubleshooting workflow tracing a stopped conveyor motor through output, ladder logic, input and field overload trip to the root cause
01Start from the failed load and trace the evidence backward. Here the output is correctly withheld because the overload-trip input blocks the run permissive.
PLC input fault comparison using proximity sensor state, input card LED, software tag and ladder rung to separate field, configuration and logic faults
02Comparing the physical event, card LED, tag value and rung state splits one vague “input problem” into three different diagnostic paths.
PLC output troubleshooting matrix comparing output tag, module LED, control voltage and contactor state
03For output faults, each mismatch narrows the boundary: command logic, module path, field wiring or actuator. Do not replace the load before locating the break.
PLC scan-order fault diagram comparing an internal bit read before write with corrected rung order and showing a one-scan output delay
04The same Boolean logic can behave differently when rung order changes. A read-before-write pattern can leave an output one scan behind the intended state.
Intermittent PLC sensor fault trend correlating vibration spikes, input dropouts and motor stops before verifying a loose connector
05Trends reveal repeatable correlations, but correlation is only a lead. Inspect and reproduce the suspected connection fault before declaring root cause.
Post-fix PLC troubleshooting verification checklist with forces cleared, full conveyor cycle passed, no new alarms and maintenance log saved
06A repair is not finished when the symptom disappears. Clear forces, test the full cycle, look for new alarms and record the confirmed cause and corrective action.

The method

The 7-step PLC troubleshooting method

Every step eliminates a portion of the fault window. The direction is always inputs to field: define the symptom, confirm power, read the ladder, check the I/O card, trace the wiring, check the output, verify the fix.

7-step PLC troubleshooting method flowchart — inputs to logic to outputs to field
The seven steps from symptom to verified fix.
1

Define the symptom precisely

Write it down before touching anything. "Motor does not start" is a symptom. "I think the proximity sensor is bad" is a hypothesis. Keep them separate — you need the symptom clear before you form hypotheses.

Inputs → Logic → Outputs → Field is the direction of travel.

2

Confirm power — PLC running, I/O powered, no fault lights

Confirm PLC RUN LED, I/O card power LEDs, and supply voltage at the distribution point. A PLC in fault mode or a card with a blown supply fuse mimics logic and wiring faults.

3

Read the ladder — find the output that should be ON

Open the online ladder monitor and find the output coil for the device that is not operating. Walk the rung from left rail to right. Which contact is false when it should be true? That contact is your target.

4

Check inputs at the I/O card

For the blocking contact, check the input LED on the physical card. LED off = field fault (go to Step 6). LED on but tag false = configuration fault (wrong address or card slot). LED matches tag but rung still false = logic fault in the rung itself.

The LED/tag comparison is the fastest field-vs-software split.

5

Half-split the field wiring

Measure voltage at the I/O card terminal. If correct: trace toward the device, measuring at the midpoint of the remaining run. If zero: trace back toward the supply. Each measurement halves the fault window.

6

Check the output card and field actuator

Output LED lit but actuator not responding: break in wiring between card and actuator, or actuator fault. Output LED not lit but tag is true: output card fuse blown or card failure. Measure voltage at the actuator terminals while output is commanded ON.

7

Apply the fix and verify — no new symptoms

Make the minimum change needed. Clear all test forces. Cycle the machine through a full operational sequence. Confirm the original symptom is gone and no new symptoms appear. Document root cause and fix in the maintenance log.

Verify before you close the job.

Half-split: binary search through the fault window

Instead of probing from one end sequentially, measure at the midpoint of the circuit. Voltage present: fault is in the second half. Zero volts: fault is in the first half. Repeat — each measurement halves the remaining window. The PLC I/O boundary (card terminal vs field terminal) is the natural midpoint for most control circuits.

16 components, 4 measurements maximum — versus 16 sequential tests.

The diagnostic toolkit

A visual map of the fault-diagnosis method

Every fault is found in the same direction — symptom, inputs, logic, outputs, field. These diagrams are the mental models the method runs on: the decision flow, the I/O LED comparison, the field terminal, and the scan order that hides scan-order bugs.

PLC troubleshooting decision flow — symptom to inputs to logic to outputs to field, the systematic fault-diagnosis path that narrows the fault window at each stepA PLC fault-diagnosis flow from top to bottom: observe the symptom, check the inputs, check the logic, check the outputs, then apply the fix.SymptomCheck inputsCheck logicCheck outputsFix
The decision flow — symptom to inputs to logic to outputs to field.
PLC input I/O card LED versus tag comparison — the fastest split between a field wiring fault and a software configuration fault during troubleshootingA digital input pushbutton wired to a PLC input card, and a PLC output card driving a lamp, with a sinking versus sourcing hint.I/O CARDINPUTOUTPUTPushbuttonI:0/0LampO:0/0sinking (NPN) vs sourcing (PNP)
Input I/O — the LED-vs-tag comparison that splits field faults from software faults.
PLC field wiring terminal block — where you half-split a control circuit with a multimeter to trace a broken supply, open return, or transposed terminalA PLC terminal strip wiring view: a switch wired to an input terminal and a lamp wired to an output terminal, with numbered terminals.TERMINAL STRIP0VI0I124VO0O1switchlampfield wiring to numbered terminals
The field terminal — where you half-split the circuit to trace a wiring fault.
A PLC ladder rung under diagnosis — walking left to right to find the false contact that should be true when an output stays offA basic ladder logic rung between two power rails: an examine-if-closed contact (XIC) in series driving an output coil (OTE).L1L2] [StartXIC I:0/0LampOTE O:0/0
Reading the rung — find the false contact that should be true.
The PLC scan cycle in troubleshooting — understanding read-inputs, execute, update-outputs order to catch scan-order faults and one-scan delaysThe repeating PLC scan cycle: read inputs, execute the ladder logic, update outputs, then housekeeping, looping continuously.1Read Inputs2Execute Logic3Update Outputs4HousekeepingSCANCYCLE
The scan cycle — the rule behind one-scan delays and scan-order faults.
Motor starter troubleshooting — the contactor coil, overload relay, and PLC output zones where a motor-won't-start fault is isolated zone by zoneA 3-wire motor control circuit: Stop and Start pushbuttons, a contactor coil with a seal-in auxiliary contact and an overload contact, driving a motor.StopStartM (seal-in)OLMMmotor
Motor starter zones — coil, overload, PLC output: isolate a no-start zone by zone.

Honest scope

What needs a real meter

The fault scenarios and wiring labs build diagnostic reasoning — the method, the mental model of the circuit, and pattern recognition of fault types. That transfers directly to real hardware. What a browser cannot replicate:

  • →Developing safe probe placement habits on live 24 VDC and 230 V AC terminals
  • →Recognizing the physical signs of a burnt contact, corroded terminal, or cracked insulation
  • →The physical feel of a loose connector versus a tight one — caught before it causes a fault
  • →Correctly identifying polarity, phase, and common returns by sight in a real wiring arrangement
  • →Responding safely when something unexpected happens during live probing

Use the simulator to build the reasoning. Arrive at a real panel having already diagnosed sixteen simulated faults and you will be measurably faster than someone coming in cold.

Intermittent faults

Capture the first disagreement before resetting

A reset often removes the evidence that distinguishes a field dropout from a sequence or communication fault. Before cycling power, record controller status, active and first-out alarms, sequence state, raw input, conditioned input, final output command, physical feedback and relevant network quality. If production risk requires an immediate safe stop, make the process safe first; evidence collection never overrides the site procedure.

Build a short trigger window around the symptom. A useful trend includes several seconds before and after the event, uses timestamps from one understood clock domain, and records Boolean transitions without smoothing them away. Compare the first unexpected transition with the control requirement. A feedback that drops while its command remains on points toward the actuator, field circuit or feedback device. A command that drops first directs the investigation toward logic, mode, interlocks or task execution.

Correlation creates a testable hypothesis, not a root cause. If vibration coincides with sensor dropouts, inspect and reproduce the suspected connector under an approved test. If network loss coincides with a drive stop, verify switch diagnostics and the drive’s configured loss response. After correction, replay the operating condition long enough to challenge the repair, clear every temporary force or bypass, and attach before-and-after evidence to the maintenance record.

Minimum fault capture
SignalDiagnostic question
Raw inputDid the field state reach the input image?
Conditioned inputDid filtering or validation reject it?
Sequence stateWhich state owned the transition?
Final commandDid logic request the actuator?
Physical feedbackDid the field device obey?
Quality and alarmWas data stale, invalid or disconnected?

What is inside

Logic-fault scenarios plus practical wiring fault labs

Each scenario injects a specific fault into a running machine simulation. Each wiring lab puts a fault in a field circuit and asks you to trace it with the virtual multimeter. Every one is auto-graded.

PLC troubleshooting training catalog with logic, runtime, scan-order and practical wiring fault exercises
The full training catalog — fault injection scenarios and wiring labs mapped to fault families.

Go deeper

Detailed guides

Guide

PLC Fault Finding: 7 Steps from Symptom to Root Cause

Complete coverage of the 7-step method, multimeter discipline sequence, half-split technique, and how to approach all four fault families including intermittent faults.

Read the guide →

Guide

Motor Starter Troubleshooting: Contactor, Overload, and Control Circuit Faults

The three fault zones in a DOL motor starter — coil circuit, overload relay, and PLC output side — with the correct measurement sequence and overload trip diagnosis checklist.

Read the guide →

Keep exploring

Related practice

Questions

PLC troubleshooting FAQ

A systematic PLC troubleshooting method works from symptom to root cause using a fixed sequence of steps: define the symptom, confirm power, read the ladder, check inputs at the I/O card, trace field wiring, check output card and actuator, apply and verify fix. Each step eliminates a portion of the fault window. The alternative — random probing — takes longer and sometimes misses the root cause entirely.

Diagnose your first PLC fault in the next two minutes.

Free browser simulator. Auto-graded. No hardware panel, no $500 course, no install.

Start a fault scenarioRun your first PLC program — no signup

Technical reference and worked-example guide

PLC troubleshooting: field reference

Direct answer

The technician can preserve a symptom, find the first signal disagreement and prove recovery without uncontrolled changes.

Written for maintenance technicians and controls engineers diagnosing field, I/O, program, actuator and process faults.

System map / 02

NODE 01observable

Definition

A precise symptom, safe state and last known good condition.

NODE 02observable

Signal path

Field condition through I/O, logic, output, actuator and feedback.

NODE 03observable

Worked example

Normal command and response timing.

NODE 04observable

Limits

Intermittent, stale, retained and restart conditions.

NODE 05observable

Common mistake

The first disagreeing signal in a controlled fault path.

NODE 06observable

Verification

Repair evidence, regression tests and documented handover.

Continue the signal path / 08

Troubleshooting learning path

Diagnose from evidence instead of replacing parts

Establish the expected state, isolate the failed signal path, test one hypothesis and prove the repair under the original conditions.