Most "PLC is down" calls are not PLC faults. They are a sensor, a safety circuit, a network drop or a mode selector. This is the order that finds them fastest without skipping safety.
Before you touch anything
Confirm what the machine is supposed to do and who is allowed to intervene. Lock out energy sources that are not required for diagnosis, and never bypass a safety device to "test" a theory. If a guard interlock is the fault, the correct action is to fix the interlock, not to jumper it.
Write down the exact fault text, the indicator states and what the operator did immediately before the stop. That log is worth more than an hour of guessing.
The sequence
1. Confirm the scope
One station, one machine or the whole line? Whole-line stops point at shared services: main air, incoming power, a line controller, or a network segment. One station points at that station's field devices.
2. Power and the E-stop chain
Check control power first, including any 24 V supply droop under load. Then walk the E-stop and guard chain: every device in series must be closed. A single partially actuated E-stop, a bent actuator or a loose terminal will hold the whole string out. Measure at the terminals rather than trusting the indicator lamp.
3. Safety relay and reset state
Safety relays latch. Confirm the relay is energised after reset and that its feedback contact back to the PLC matches reality. A safety circuit that resets but does not report back gives you a machine that looks ready and refuses to run.
4. Controller state
Is the processor in RUN, or has it dropped to PROGRAM or FAULT? Read the fault code before clearing it. Battery low, I/O module fault, watchdog and communication errors all present differently and clearing without reading throws away the evidence.
5. Inputs, physically
Force-screen nothing yet. Look at the input LEDs and compare against the field device state. The classic failure is a sensor that is powered and sensing but positioned 3 mm out of range, so the input never changes. Check the mechanical target, not just the electrical signal.
6. Communications
If the controller talks to drives, remote I/O or a SCADA layer, check the link counters and node status. A single dropped node can hold a permissive false indefinitely. On Ethernet, confirm link lights and switch port state before assuming the program is wrong.
7. Interlocks and permissives
Walk the start conditions one at a time. Most sequence faults are a missing permissive: guard closed, clamp confirmed, pressure switch made, upstream machine ready. If the HMI shows a start-permissive screen, use it; if it does not, that screen is a worthwhile improvement.
8. Outputs and drives
Confirm the output module indicator matches the commanded state, then confirm the field device actually moves. A contactor coil that reads 24 V but does not pull in is a coil, not a program bug. On drives, read the drive's own fault code from its keypad or parameter - it usually names the problem the PLC can only report as "drive not ready".
9. Record and restore
Before clearing anything, capture: fault text, controller fault code, drive code, the input states at fault, and a photo of the panel. Then fix the cause and verify by running the sequence, not by jogging one output.
Common causes, ranked by how often they are the answer
- Safety circuit open - E-stop, guard, gate, rope pull, or a loose terminal in the chain.
- Missing permissive from an upstream machine or utility (air pressure, coolant, hydraulics).
- Sensor position or contamination, especially optical and inductive sensors near metal chips.
- Loose field wiring at a terminal strip that passes a meter check but fails under vibration.
- Network node dropped, duplicate IP address, or a switch port negotiated down.
- Program in the wrong mode, or a recipe/parameter out of range after a changeover.
What to capture before calling an integrator
Controller model and firmware, the exact fault text, the fault code if there is one, a photo of the panel interior, the last known good behaviour, and what changed. If the machine has a program backup, note its date. Nine times out of ten that package lets a controls engineer tell you whether it is a field fault or a code fault before anyone drives out.
Preventing the repeat
- Keep a current program backup and a printed I/O list in the panel.
- Label the safety chain device by device, not as one string.
- Trend the faults you actually get, so the third occurrence is a planned fix instead of an emergency.
- Replace obsolete controllers before the spares run out, not after.
A line that stops for the same reason three times is a design problem. That is when the fix is a small controls change, not another breakdown call.