When a PLC drops to FAULT or STOP, its outputs go to their safe state and the process it was controlling halts, which is exactly what a fault is supposed to do. The wrong instinct is to cycle power and hope it comes back, because that clears the evidence of why it faulted and can drop you straight back into the same fault or, worse, restart a process into an unsafe condition. The right approach is to read what the controller is telling you, decide what kind of fault it is, clear it deliberately, and only then return to RUN. This guide is that recovery runbook.
Fix a PLC in fault mode in one line: A PLC in FAULT or STOP has detected a condition serious enough to halt and safe-state its outputs, so recovery means diagnosing before clearing, not blindly cycling power. Read the fault code and whether it is a major or minor fault, determine whether it is an I/O fault, a scan-overrun or watchdog timeout, or a program fault, correct the underlying cause, then clear the fault and return to RUN under controlled conditions. Cycling power without reading the fault clears the evidence and risks faulting again or restarting into an unsafe state.
The symptom is clear at the panel: the controller status shows FAULT or STOP instead of RUN, a fault indicator is lit, outputs have dropped to their configured safe state, and the process has stopped. What you must resist is treating this as a nuisance to be cleared. The controller went to fault because it detected something it is designed to treat as serious, and the fault status is holding a record of what that was. The first job is to read that record, not to erase it, because the fault information is the fastest path to the cause and, on many controllers, is lost the moment you power-cycle.
Faults are generally split into major and minor. A major fault is a condition the controller treats as severe enough to stop execution and go to fault, safe-stating outputs, because continuing could be unsafe or the program can no longer run correctly. A minor fault flags a problem the controller can note without necessarily stopping, and it may or may not escalate. Knowing which you have frames the urgency and the response: a major fault demands you understand and correct the cause before returning to RUN, while a minor fault may let the process continue but still points at something to fix. Reading the fault type is the first branch in the runbook.
Alongside the major or minor classification, the controller reports a fault code or fault type that names the category of problem, and this is what turns a generic fault into a specific one to solve. Read the code and its description from the controller or programming software before doing anything else, and note any additional context it captures, such as which module, slot, or program element was involved. This is exactly what the fault-routine and controller diagnostics are for, and the fault-routine concept page covers how a program can capture and even respond to these conditions. With the code in hand you can move from the fact of a fault to its category.
The fault code usually places the cause into one of a few families, and telling them apart directs the fix. An I/O fault means the controller lost or could not verify communication with a module or a remote I/O device: a card failed, a rack or network connection dropped, or a device the program expects is not present or not responding. The tell is a fault that names a specific module or I/O connection, and it commonly follows a wiring problem, a failed module, a lost network link to remote I/O, or a device powered down. Recovery here is physical and configuration-based: restore the missing module or connection, replace a failed card, or reconcile the I/O configuration with what is actually installed, because the controller will fault again on RUN if the I/O it expects is still missing.
A scan-overrun or watchdog timeout is a different animal. The controller runs its program on a cycle and enforces a watchdog: if a single scan takes longer than the allowed time, the watchdog fires and faults the controller to prevent it from running unpredictably. A watchdog fault points not at hardware but at the program taking too long, often from an unbounded loop, an unusually heavy scan, a communication instruction that stalls the scan, or a watchdog time set too tight for the actual workload. The watchdog-timer concept page explains the mechanism; recovery means finding why the scan overran and correcting the program or the watchdog setting, since simply clearing it leaves the same slow scan to trip again.
A program fault covers conditions the running logic itself hit that the controller treats as fatal, such as an instruction indexing outside a valid array, a bad or out-of-range pointer or subscript, a division problem, or a jump to a nonexistent routine. These name a location in the program rather than a module, and they usually mean a specific rung or instruction encountered data it could not handle. Recovery is to go to the indicated instruction, understand what data or condition caused it, and fix the logic or add the bounds checking that prevents it, because the fault will recur the moment the program reaches that state again. Distinguishing an I/O fault, a watchdog fault, and a program fault from the fault code is what tells you whether to reach for a screwdriver, a scan-time analysis, or the program editor.
Only once you understand and have addressed the cause should you clear the fault, and how you clear it matters. Clear the fault through the controller or programming software in a controlled way rather than by yanking power, so you keep any captured diagnostics and stay in command of what happens next. Before returning to RUN, think about the state the process will restart into: outputs were safe-stated, actuators and equipment may be in known or unknown positions, and putting the controller back to RUN can re-energise outputs. Confirm the field is safe to restart, follow the plant's start-up procedure, and return to RUN deliberately rather than reflexively, because an unexamined restart of a stopped process is where a controller fault turns into an incident.
Resist the power-cycle reflex specifically because of what it costs. Cycling power may clear a fault, but it discards the fault information that tells you why, and if the underlying cause is still present, an I/O device still missing, a scan still overrunning, a program still hitting bad data, the controller will simply fault again, and you will have learned nothing and possibly restarted into an unsafe condition in between. Blind power cycling also risks masking an intermittent fault that will strike again at a worse time. Reading, diagnosing, and correcting first is slower by minutes and saves hours or an incident.
This is where SCADA and remote monitoring change the calculus, because a faulted PLC at an unmanned site is invisible until someone looks. A cloud SCADA platform such as Merobix that monitors controller status and comms can raise an immediate alarm when a PLC goes to FAULT or STOP or when its communications drop, so operators learn a remote site has stopped in minutes rather than on the next visit. Just as importantly, surfacing the controller's fault status and, where accessible, the fault code lets staff begin diagnosing the category of fault before they travel, so they arrive with the right parts and plan. Remote monitoring does not clear the fault, that must be done safely and deliberately at the controller, but it turns a silent stoppage into a known, triaged event, which is the whole point of watching a site you cannot see.
No, not as a first move. Cycling power may clear the fault but it discards the fault information that tells you why the controller stopped, and if the underlying cause is still present the PLC will simply fault again. Worse, an unexamined restart can re-energise outputs and restart a stopped process into an unsafe state. Read the fault code, diagnose and correct the cause, then clear the fault in a controlled way and return to RUN deliberately.
The fault code and its description point you at the family. An I/O fault names a specific module or I/O connection and follows a failed card, lost rack or network link, or a missing device. A watchdog fault means a scan took longer than allowed, pointing at the program taking too long rather than hardware. A program fault names a location in the logic, such as indexing outside an array, meaning the running code hit data it could not handle.
If it faults again the moment you try to run, the underlying cause is still present. An I/O device the program expects is still missing or offline, the scan is still overrunning the watchdog, or the program still reaches the instruction and data that faulted it. Clearing the fault does not fix the cause, so correct the missing I/O, the slow scan, or the faulting logic first, and only then will the controller stay in RUN.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.