Controls work becomes manageable when each fault is reduced to a defined signal path, tested in commissioning order, and closed with an operating proof. Product knowledge still matters, but a repeatable diagnostic method prevents an unfamiliar device, inherited PLC program, or communication failure from turning into uncontrolled trial and error.
Diagnostic Approaches
Two approaches appear repeatedly in controls work: changing items until the symptom moves, or testing the system from prerequisites through outputs. Both can expose a fault, but they carry different risks.
| Approach | Useful when | Main limitation | Decision criterion |
|---|---|---|---|
| Exploratory changes | The process is safe, reversible, and poorly documented | Multiple changes destroy cause-and-effect evidence | Use only after recording the original state and defining a rollback |
| Structured signal-path testing | Commissioning, intermittent faults, inherited logic, and device integration | Requires disciplined observations before editing | Preferred whenever an incorrect change could stop equipment or hide the real cause |
| Mechanical-first inspection | The command and PLC output are correct, but the physical result is wrong | Misses permissives, field wiring, and communication state if applied too early | Use after proving the control command reaches the final device |
| PLC-first inspection | The expected command never appears | Encourages unnecessary code edits when an input or permissive is false | Trace the command backward before modifying logic |
Use structured signal-path testing as the default. Exploratory testing remains valid when it is controlled: change one item, predict the result, observe it, and restore the original state if the prediction fails.
Initial Fault Triage
Before anything else, confirm what the machine was commanded to do, what it actually did, and when the behavior changed. Replace statements such as “the PLC is not working” with an observable mismatch: an input changes but the sequence does not advance, an output command turns on but the actuator does not move, or a device is powered but does not exchange data.
- Define the symptom. Record the operating mode, active step, operator command, device indication, and physical response. Do not move on until another engineer could reproduce the observation.
- Establish the boundary. Decide whether the first failed condition lies in the process, sensor, field wiring, I/O, PLC logic, network path, device configuration, or actuator.
- Check prerequisites. Confirm power, operating mode, interlocks, permissives, communications state, and mechanical freedom before editing code.
- Review recent changes. Compare the current program, configuration, wiring, and device installation with the last known working state. A change is a lead, not proof.
- Choose one test. Select the measurement that separates two plausible causes. State the expected result before performing it.
Control-Path Mechanism
A control action normally crosses several boundaries: a physical condition becomes an electrical signal, the input module presents that state to the controller, logic evaluates permissives and sequence conditions, an output or communication command is produced, and a field device converts that command into motion or process action. The useful question is not whether the system “looks right,” but where the expected state stops propagating.
| Observed boundary | Next check | Likely fault class |
|---|---|---|
| Sensor changes physically, but the input state does not | Measure the field signal and inspect wiring and channel indication | Sensor, power, wiring, or input channel |
| Input state is correct, but no command is generated | Trace permissives, modes, sequence state, latches, and inhibit conditions | Logic state or unmet process condition |
| Command exists, but the output state does not | Check output ownership, module state, and channel condition | I/O configuration or module fault |
| Output state is correct, but no field voltage or motion appears | Measure at the terminal and then at the load | Wiring, protection device, actuator, or mechanical fault |
| Device has power, but data does not update | Check physical link, addressing, configuration match, connection state, and data mapping | Network or device-integration fault |
This boundary method also controls the scope of code review. Start at the tag representing the failed physical result and trace backward through every writer, permissive, mode selector, and sequence transition. Search for duplicated commands and indirect dependencies before concluding that the visible rung or block owns the final state.
Commissioning-Order Procedure
- Capture the baseline. Save or document the active program and device configuration, note the current operating state, and record fault indicators. Confirm that a rollback path exists before making a change.
- Prove the physical layer. Verify power, connections, terminal condition, sensor operation, actuator freedom, and network link indication. Do not move on until the field condition matches the electrical observation.
- Prove the controller view. Monitor the relevant input, output, status, and diagnostic data. Change the physical input through a safe test and confirm that the controller sees the transition.
- Trace the logic path. Follow the requested action through mode selection, interlocks, permissives, sequence conditions, and the final command. Record the first condition that differs from the expected state.
- Check device integration. Compare the controller configuration with the device configuration and manual. Confirm that addressing, connection state, exchanged data, and command interpretation agree on both sides.
- Correct one cause. Change only the item proven wrong. Avoid simultaneous edits to logic, wiring, and device settings because the successful change will become unknowable.
- Retest from the initiating condition. Return the system to a known state and repeat the original command. Confirm each boundary in sequence rather than accepting only the final motion.
Program and Configuration Practices
Inherited logic is slower to diagnose when every programmer invents a new structure. Preserve established project patterns unless a functional requirement demands a departure. Group related mode handling, permissives, commands, feedback, alarms, and sequence transitions so that the path from request to physical result remains visible.
Use comments to explain why a condition exists, what field state it represents, and what clears it. A comment that merely repeats an instruction adds little diagnostic value. When several programming methods can produce the same result, prefer the method already used consistently in the project and verify its scan-to-scan behavior.
Manuals are part of the diagnostic path, particularly for unfamiliar devices. Read the sections covering wiring, configuration, exchanged data, status indications, and troubleshooting. Translate each requirement into a checkable condition; do not treat a successful download or lack of an obvious fault light as proof that the device is correctly integrated.
Change Verification and Recurring Pitfalls
A fix is incomplete if it removes the immediate symptom but creates an unsafe transition, masks an interlock, or fails after a mode change. Verification must exercise the control path under the states that can alter it.
- Repeat the original failing action and confirm that the expected input, logic condition, command, feedback, and physical response occur in order.
- Test relevant operating modes and sequence transitions, including stopping and restarting from a defined state.
- Remove and restore the initiating condition to confirm that the command clears and reasserts correctly.
- Check diagnostics after the test for new device, I/O, or communication faults.
- Record the proven cause, the single correction, the observations that confirmed it, and the retained rollback information.
Recurring failures come from skipping prerequisites, treating every symptom as a PLC-code problem, accepting an internal output state as proof of field voltage, and editing unfamiliar logic before identifying all writers. Workload is another technical risk: rushed troubleshooting encourages undocumented changes and incomplete testing. Define the test boundary, preserve recovery information, and escalate when safe access, documentation, or adequate test time is missing.
Frequently Asked Questions
How do I troubleshoot an unfamiliar PLC-controlled machine?
Define one observable failure, establish the signal path from field input to physical output, and test each boundary in commissioning order. Record the first point where the expected state disappears.
How do I decide whether a fault is mechanical or in the PLC?
Confirm the PLC command and measure the corresponding field output. A correct command with the expected field signal shifts the investigation toward the actuator or mechanism; a missing command requires tracing inputs and permissives backward.
How do I debug PLC logic written by someone else?
Start at the failed output or command, identify every instruction that can write it, and trace backward through modes, permissives, interlocks, and sequence state. Preserve the existing structure until one condition has been proven wrong.
How do I commission a new device that will not communicate?
Prove power and the physical link first, then compare addressing, controller configuration, connection state, exchanged data, and command interpretation with the device manual. Do not change multiple network and program settings in one test.
How do I verify that a controls change fixed the root cause?
Restore a known initial state, repeat the original command, and confirm the input, logic decision, output or communication command, device feedback, and physical response at every boundary. Then repeat the relevant stop, restart, and mode transitions while checking diagnostics for new faults.