A PLC fault routine is special code that runs when the controller detects an error, giving you a chance to react before the CPU decides what to do. PLCs classify errors by severity: minor faults are recoverable and let the program keep running, while major faults are serious enough to halt the controller unless something intervenes. A user fault routine is that intervention - a block of logic that traps a fault, inspects what went wrong, and can optionally clear it so the CPU keeps running instead of shutting down. For an unattended remote site, that difference is the difference between a hiccup and a truck roll.
PLC Fault Routine in one line: A PLC fault routine is user logic the controller executes when it detects a fault, allowing the program to identify the fault and decide whether to clear it or let the CPU fault out. Minor faults are recoverable and logged without stopping the program, while major faults halt the controller unless a fault routine traps and clears them first.
Controllers separate faults by how much they threaten safe operation. A minor fault is a problem the CPU can note and keep going: a battery warning, a value slightly out of an expected range, a non-fatal instruction condition. These are recorded in status so a program or an engineer can see them, but they do not stop the scan. The program continues, and it is up to the application to decide whether a given minor fault deserves any action at all.
A major fault is a different matter. It is an error serious enough that the controller cannot safely continue with the program as written - the classic examples are a divide-by-zero, an array index that points outside the array's bounds, a watchdog timeout where a scan ran far too long, or a hardware fault in a module. Left untrapped, a major fault sends the CPU into a faulted state: it stops executing the program, typically drops its outputs to a safe condition, and waits for a human to clear the fault and restart it.
The reason the distinction matters is that a single line of bad arithmetic can, without any special handling, take the whole controller down. A sensor that momentarily reads zero and then gets used as a divisor, or a calculated index that briefly exceeds its bounds, is enough to trigger a major fault. On a machine with an operator standing next to it, that is an inconvenience. On something running unattended, it is an outage that persists until someone notices and physically intervenes, which is precisely the scenario fault routines exist to prevent.
When a major fault occurs, many controllers will, before shutting down, jump to a designated user fault routine if one is configured. That routine runs with information about what faulted - a fault type and code, and often which program and instruction were involved - available for the logic to read. Inside the routine you can inspect that information and make a decision: some faults are genuinely unrecoverable and should be allowed to stop the CPU, while others are transient or benign enough that continuing is far better than halting.
For the recoverable cases, the fault routine can clear the fault and return control to the program, so the scan resumes instead of the controller faulting out. The pattern is to identify the specific fault, take any corrective action - substitute a safe value, flag the condition, increment a diagnostic counter - and then clear it, so that a known, survivable error becomes a logged event rather than a shutdown. Faults you do not recognize or that indicate a real hardware problem are deliberately not cleared, so the controller still protects itself when the situation truly warrants stopping.
This trap-and-decide behavior is what turns a fault routine into a safety net rather than a blunt override. Blindly clearing every fault would be reckless, because a major fault sometimes reflects a condition where continuing really is unsafe. A good fault routine is selective: it catches the specific, anticipated, recoverable faults that a robust process should shrug off, records enough detail to diagnose them later, and leaves the genuinely dangerous faults to do their job of stopping the machine. Getting that balance right is the craft of writing one.
An unattended RTU at a wellsite has no operator to notice a faulted CPU and press a button. If a controller there faults out on a divide-by-zero or a bad array index, the site simply stops doing its job - control, measurement, safety monitoring, and telemetry all go quiet - and stays that way until someone realizes it and drives out to investigate. In remote basins that can be hours of travel for what began as a single arithmetic edge case, so the economics strongly favor building logic that never lets a trivial fault escalate into an outage.
The defensive work is partly in the fault routine and partly in the code that precedes it. Guarding divisions against a zero divisor, bounding array indices before they are used, and validating inputs before they feed math prevents most avoidable major faults from ever arising. The fault routine then backstops the cases you did not anticipate, catching a surprise fault, logging its details, and, where safe, clearing it so the site keeps running rather than going dark. Together they make a remote controller resilient to the messy, real-world data that a bench test never produces.
Cloud SCADA closes the remaining gap by making faults visible even when nobody is on site. Reporting the controller's fault status, fault codes, and any diagnostic counters the fault routine keeps up to a platform like Merobix means an engineer sees that a site has faulted, or has been catching and clearing recoverable faults, from a dashboard rather than discovering it on a routine visit. That visibility lets a real major fault be dispatched to promptly while a handled minor fault is simply noted, and it turns the fault routine's quiet work into an auditable record of how robustly the remote site is actually running.
A minor fault is a recoverable condition the controller logs while the program keeps running, such as a battery warning or a non-fatal instruction condition. A major fault is serious enough that the CPU cannot safely continue, such as a divide-by-zero, an out-of-bounds array index, or a watchdog timeout, and it halts the controller unless a fault routine traps and clears it. In short, minor faults are survivable and major faults stop the CPU by default.
Yes, if a user fault routine is configured to trap the fault before the CPU shuts down. The routine reads the fault type and code, decides whether the fault is safe to recover from, and can clear it so the program resumes instead of faulting out. Faults that indicate a genuine hardware problem or an unsafe condition should be left uncleared so the controller still protects itself by stopping.
Because a remote RTU has no operator on site to notice a faulted controller and restart it, so a single untrapped major fault can take the whole location offline until someone drives out, which may be hours away. Deliberate fault handling, combined with guarding divisions and array indices in the code, lets a recoverable error be logged and cleared instead of causing an outage. Reporting fault status to a cloud SCADA platform then makes any real fault visible without a site visit.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.