Allen-Bradley Major and Minor Faults: What They Mean and How to Clear Them Properly
The short answer
A minor fault is logged and the controller keeps running. A major fault puts the controller into faulted mode and it stops executing logic until the fault is cleared. Both carry a type and a code that identify the cause precisely, readable in the controller properties in Studio 5000 or from the FAULTLOG and PROGRAM fault records. The instinct to clear a major fault in a fault routine is often wrong, and understanding when it is right is the difference between a robust machine and one that hides its own defects.
Reading the fault
In Studio 5000, Controller Properties has a Major Faults tab and a Minor Faults tab. Each fault gives a Type and a Code, and the pair is what you look up.
The types you meet most:
| Type | Meaning |
|---|---|
| 1 | Power-loss related |
| 3 | I/O fault, including a module or connection failure |
| 4 | Program execution fault, the largest family |
| 6 | Watchdog, task exceeded its period |
| 11 | Positioning or motion fault |
Within type 4, code 20 is an array subscript outside range, code 16 is a jump to a label that does not exist, code 21 is a control structure length or position invalid, and code 34 is a timer preset or accumulated value invalid, typically negative. Type 4 code 20 is the single most common major fault in the field and it is almost always an index computed from a value that was allowed to go out of range.
Where to intervene
The controller fault handler, a Program in the Controller Fault Handler task, runs when a major fault occurs. Inside it, the GSV on the PROGRAM object retrieves the fault type and code, and SSV clearing the MajorFaultRecord clears the fault and allows execution to resume.
Minor faults need no handler to keep running, but they should still be read, because a minor fault repeating thousands of times a day is telling you something is wrong even though nothing stopped.
When clearing is right, and when it is not
Clearing is right when the fault is expected, recoverable and understood. The clearest case is an arithmetic overflow in a calculation you know can overflow, or a specific I/O connection that is allowed to be absent because the module is optional on that machine build.
Clearing is wrong when it is used as a blanket. A fault routine that clears every major fault regardless of type turns a controller that would have stopped safely into one that continues with corrupted logic. A type 4 code 20 means you indexed outside an array, which means you wrote or read memory you did not intend to. Continuing from that is not recovery, it is proceeding with unknown state.
The discipline: in the fault handler, examine the type and code, clear only the specific ones you have decided are recoverable, log everything with a timestamp, and let anything else stop the controller.
The one that is not a program bug
Type 3, I/O fault, is usually physical: a module removed, an EtherNet/IP connection timing out, a chassis power problem, or a device on a different subnet after a network change. Look at the module status in the I/O tree and the module's own LEDs before touching the code.
Connection timeouts that appear under load rather than at random usually mean the RPI is set faster than the network or the module can sustain, or that the network is carrying broadcast traffic it should not.
Where to learn it
Allen-Bradley Studio 5000 covers the controller organisation, tasks and fault handling, and Allen-Bradley RSLogix 500 covers the older SLC and MicroLogix family where the fault model is different again. Related reading: PLC program structure: OB, FB, FC versus Rockwell tasks and, for the Siemens equivalent, reading the Siemens diagnostic buffer.
Frequently asked questions
Does clearing a major fault lose the record? Clearing the MajorFaultRecord clears the active fault. Log the type, code and time to a data table inside the handler before clearing, or the evidence is gone.
Why did my controller fault only in the field and never in test? Almost always data. Test data stays inside the ranges the code assumes; real production data does not. Type 4 code 20 is the usual result.
Is a watchdog fault fixed by increasing the watchdog? Rarely. It is a symptom of a task that occasionally takes longer than its period, and the cause is usually a loop, a blocking message instruction, or too much work in a periodic task.
