Injected-fault diagnosis practice
PLC troubleshooting simulator: diagnose injected faults from symptom to fix
Direct answer
A PLC troubleshooting simulator loads a machine program with one known fault already injected, such as a stuck sensor, a missing seal-in branch or a counter that never resets. You restate the symptom, read the rung that owns the failing output, compare input, tag and rung state, confirm the cause with a simulated test and verify the repair.
This guide is written for electricians moving into controls, maintenance apprentices, students without plant access and technicians preparing for a spoken fault walkthrough in an interview. The intended result is specific: the learner can place a fault in the right category (field device, program, runtime value or scan order) and justify it with one observation that rules out the competing explanations.
Symptom before hypothesis
Write down what the machine fails to do in observable terms: “fill pump never starts with the tank empty”, not “the level switch is bad”. The symptom fixes which output is under suspicion and the conditions needed to reproduce it. A suspected cause belongs later, once the rung and the input values point somewhere specific.
The owning rung
Every misbehaving output is decided by one rung, or by a pair of latch and unlatch rungs. Find them by searching for the output address, then read each series contact to see which one blocks power flow. A dark contact is only a lead; the real question is whether its input value is wrong or the instruction itself is wrong.
Stuck or failed input
A sensor that fails closed reports true whatever the process is doing, so correct logic produces the wrong result. In the stuck level-switch exercise the fill pump never energizes because the program always believes the tank is full. The giveaway is an input that never changes state while the condition it measures obviously does.
Program defect
Here the field devices are healthy and the ladder is wrong: the wrong examine instruction on a normally closed stop button, a missing seal-in branch that drops the motor when START is released, or a coil written to the wrong output address. Toggling inputs shows the rung responding exactly as written, which is the problem.
Timer and counter state
Timers and counters hide faults inside their accumulated values. A TON clears its elapsed time only when its enable drops, so an enable that is never cleared leaves the done output on permanently. A CTU keeps its count until its reset input is driven, so the next batch cannot begin. Watch the values, not just the outputs.
Forcing and scan order
A simulated input toggle shows whether the logic responds once a field signal is corrected. On real plant a force overrides the field state and can move machinery, so it is an authorized action and never a default step. Scan order is the other trap: a coil written below the rung that reads it arrives one scan late.
- 01
Restate the symptom
Read the one-sentence scenario brief and rewrite it as expected versus observed behavior, including the input conditions that should produce the output.
Evidence: A symptom line that names the output, its expected state and the operating condition.
Avoid: Writing a suspected component as the first line of the fault log.
- 02
Locate the owning logic
Find every rung that writes the affected output, including latch, unlatch and duplicate coils, and list the contacts in series with each one.
Evidence: A short list of the conditions that enable or block that single output.
Avoid: Reading the whole program from the top before narrowing down to the failing device.
- 03
Compare signal states
For each listed condition, compare what the process should be doing with the input value in the I/O panel and the contact highlight on the rung.
Evidence: The specific condition where the tag stops matching the process is identified and recorded.
Avoid: Assuming an input is healthy because its contact happens to be lit at this moment.
- 04
Test one hypothesis
Toggle a single simulated input, or watch one timer or counter value through a full cycle, to separate a field-device fault from a program fault.
Evidence: A prediction written before the test and a result that confirms or eliminates one explanation.
Avoid: Toggling several inputs together and losing track of which change mattered.
- 05
Choose the cause and repair
Select the root cause the evidence supports and make the smallest correction, such as restoring a seal-in branch, correcting a contact type or adding a reset path.
Evidence: The grader accepts both the diagnosis and the fix and explains the injected fault.
Avoid: Adding extra rungs that hide the symptom while the original cause stays in place.
- 06
Verify the whole function
Rerun normal start, stop, restart and the original failure case; on real plant, also prove stops and interlocks as part of the verification step.
Evidence: The original symptom is gone and none of the unaffected cases behaves differently.
Avoid: Declaring success the first time the symptom disappears.
| Observed symptom | Inspect | Interpretation | Next proving action |
|---|---|---|---|
| Motor runs only while START is held | Motor coil rung, the parallel holding branch and the address of the contact used in it | A missing or mis-addressed seal-in branch means nothing keeps the rung true once the button is released. | Add a normally open contact of the motor output in parallel with START and retest stop. |
| Motor will not start at all | Stop button contact type, its input value at rest and the instruction used for it on the rung | A normally closed stop button reads true at rest and needs XIC; examining it with XIO holds the rung false permanently. | Check the rest state of the input, then match the instruction to the physical contact type. |
| Rung true but the field device stays idle | Output address in the coil, the output image, the module indication and the device that address actually drives | A coil written to the wrong address energizes a different output, or a valid command is lost in the output circuit. | Match the coil address to the I/O list, then trace the output wiring. |
| Pump never runs although the tank is empty | Level input value across a full fill cycle compared with the process indication | An input that stays true while the process changes points to a failed or stuck sensor, not to the ladder. | Toggle the simulated input; if the pump responds, the sensor is the fault and the program stays unchanged. |
| Cycle-complete output stays on or never repeats | Timer enable, elapsed time, done output, counter count and counter reset input | Values that never return to zero mean the reset or enable path is missing; the preset is rarely the culprit. | Trace what should drop the timer enable or drive the counter reset, then repair that path. |
| Output glitches or a brief start press is lost | Rung order, duplicate coils and set and reset rungs acting in the same scan | When two rungs write one bit in the same scan the last write wins, and a coil read above where it is written lags one scan. | Give each bit a single owner or reorder the logic, then retest the edge case. |
Product evidence / 05
What the browser practice can actually demonstrate
Each fault scenario opens with a one-sentence symptom, lets the learner toggle simulated inputs while the ladder monitor shows which rungs energize, and grades both the chosen root cause and the applied fix. A no-account guided motor-start diagnostic shows the workflow before signup.
Why practice PLC troubleshooting with injected faults rather than random errors?
An injected fault is known to the scenario, so the grader can check whether your diagnosis matches the actual cause. Random failures reward guessing. A designed fault also produces consistent evidence: a stuck sensor never changes state and a missing seal-in drops on release, which makes each attempt repeatable and comparable.
How do you tell a failed sensor from a logic fault?
Watch the input value while the process changes. If the input never follows the process, the device or its wiring is suspect. If the input changes correctly but the output still misbehaves, read the rung for a wrong instruction type, address or missing branch. A single simulated toggle then confirms which side owns the fault.
What is a broken seal-in and how do I spot it?
A seal-in uses a contact of the output itself in parallel with the start button, so the rung stays true after the button is released. If that branch is missing or reads the wrong address, the motor runs only while START is held. Press, hold, release and watch whether the rung drops.
Why would a PLC output not energize when the rung looks correct?
Check whether another rung writes the same address later in the scan, whether the coil points at the wrong output, and whether the field circuit is actually being driven. A rung that shows true on screen proves only the logic decision; the physical load still depends on the output module, wiring and device.
Is forcing I/O a good way to troubleshoot?
In the simulator a toggle is a safe way to see whether logic responds when an input is corrected. On a running machine a force overrides real field state and can cause unexpected motion, so it needs authorization, warning of affected people and a plan to remove it. When behavior makes no sense, check for forces already active.
Why does my timer or counter work once and then never again?
Timers and counters retain state between scans. A TON resets its elapsed time only when its enable input goes false, and a CTU clears its count only when its reset input is driven. If nothing drops the enable or drives the reset after the first cycle, the done output stays on and the next cycle cannot start.
What are scan-order faults in a PLC?
The controller solves rungs from top to bottom on every scan. If a coil is written on a lower rung than the contact that reads it, the reading rung sees the new value one scan late. Two coils writing one address leave the last write in effect. These faults look intermittent until you apply the rule.
How should I describe my troubleshooting approach in an interview?
Walk through one concrete case: state the symptom, name the output and its rung, compare input, tag and rung state, describe the single test that separated field from logic, then give the repair and how you verified it. Say where you would stop for isolation and permission on real equipment. Structure beats naming a guessed part.