Fault-finding is the most valuable skill a PLC technician can have. Every plant manager knows it; every recruiter mentions it in job descriptions. But it is almost impossible to teach from a textbook. You learn to find faults by finding faults — and on a real machine, that means production is stopped while you figure it out.
Fault injection simulation solves this by inserting a hidden fault into a running machine model and challenging you to find it before time runs out. This is how the fault diagnosis module in the simulator works.
What Is a Fault, in Practice?
In PLC automation, a "fault" is any condition that causes the machine to behave differently from its intended design. In practice, the most common faults are:
- Wiring faults — broken wire, loose terminal, short circuit to ground or +24V
- Sensor faults — failed sensor, incorrect output type (PNP vs NPN swap), sensing range exceeded
- Contact type errors — a normally-open contact wired where normally-closed is required (or vice versa)
- Field device failures — contactor coil burned out, valve stuck open or closed, motor overload tripped
- Program logic errors — wrong rung order, duplicate output, latch coil that cannot be reset
The first four categories are hardware faults. The fifth is a software fault. Both types appear in the fault injection module because real fault-finding requires knowing how to distinguish between "the machine is wired wrong" and "the program has a bug."
A fault can be injected at any point in the I/O loop — at the sensor, the input or output wiring, the program logic, or the actuator.
How the Fault Injection Module Works
When you start a fault session:
- The simulator selects a random fault type from the configured difficulty pool
- The fault is applied silently — you are not told what the fault is or where it is
- The machine simulation starts running with the fault active
- You observe the machine's abnormal behavior and use the available tools to diagnose the cause
Available diagnostic tools:
- Scan-cycle highlight — watch each rung execute and observe contact/coil states
- Variable table — monitor any memory bit, register, or I/O point in real time
- Cross-reference — see every rung that reads or writes a specific tag or device
- I/O status panel — shows the raw state of each physical I/O channel
You must identify: (a) what is wrong, (b) where the fault is (which rung, which device, which wire), and (c) how to fix it.
Example: Diagnosing a Contact Polarity Swap
Setup: A motor start/stop circuit. The motor should stop when the stop button is pressed.
Injected fault: The Stop_PB contact in the program has been changed from XIO (normally-closed, examine if open) to XIC (normally-open, examine if closed).
What you observe: The motor runs normally when started, but pressing the stop button has no effect.
Diagnostic process:
- Open the scan-cycle highlight, run the program, try pressing stop
- Find the motor control rung:
XIC Start_PB → XIC Stop_PB → OTE Motor_Run - Wait —
XIC Stop_PB? This should beXIO Stop_PBfor a normally-closed stop button - Observe in the scan highlight: Stop_PB shows as FALSE when not pressed (no 24V — correct, the NC button is not pressed, so the circuit is closed, 24V is present... but XIC is reading it as TRUE)
- Actually, XIC sees 24V (TRUE) and passes — the rung stays energised even when you press stop, because XIC passes when the signal is TRUE, and the NC stop button only opens (drops to FALSE) when pressed
You have found the fault: the contact type is wrong. The fix is changing XIC to XIO for the Stop_PB contact.
Scoring: You are scored on how quickly you identified and corrected the fault. Faster diagnosis = higher score.
Why This Is More Effective Than Reading About Fault-Finding
Passive learning problem: Reading a description of a NO/NC swap does not build the diagnostic instinct. You can read the same passage ten times and still fail to identify the problem when you encounter it in the field, because the real skill is in observation — noticing that the motor runs fine but stop has no effect, inferring that the issue is in the stop logic path, checking the rung, and recognizing the wrong contact type.
Active practice solution: Fault injection forces you to start from the abnormal behavior and trace backward to the root cause. Each solved fault session reinforces the diagnostic habit. After 10–15 fault sessions, the process becomes automatic — and that automaticity transfers to real hardware.
Across those sessions you build a stack of transferable diagnostic skills.
Fault Types in the Module
Different fault types produce different symptoms — and each points you toward a different diagnostic tool.
The fault injection module includes graduated difficulty:
| Level | Fault types |
|---|---|
| Beginner | Contact polarity swap (XIC vs XIO), single open wire, sensor stuck ON/OFF |
| Intermediate | Latch coil that cannot reset, timer preset error, duplicate output conflict |
| Advanced | Multiple simultaneous faults, intermittent fault (activates only under specific conditions), PID loop off-setpoint due to wrong engineering-unit scaling |
Start at Beginner and progress. The diagnostic tools are identical across all levels; the faults become subtler and require more systematic investigation.
Connection to the Curriculum
Fault-finding is covered in Lesson 11 of the curriculum. The lesson introduces the diagnostic methodology and then directs you to the fault injection module for the actual practice exercises. Completing at least Lessons 1–8 first is recommended — the faults in the advanced exercises involve timers, sequencers, and analog I/O that you need to understand before you can diagnose them efficiently.
Start finding faults in the simulator. The fault injection module includes beginner, intermediate, and advanced scenarios. Fault-injection scenarios are part of Pro (USD 29/month or USD 249/year); the Free tier includes starter fault-finding practice.
