Allen-Bradley Major Fault Codes: How to Read, Clear, and Prevent Them

Key Takeaways: On Allen-Bradley Logix controllers (ControlLogix, CompactLogix), a major fault stops the program and puts the controller's OK/FAULT indication into a fault state. Every major fault has a Type and a Code (for example Type 4 = program fault, with codes for errors like an array subscript out of range). Studio 5000's Controller Properties, Major Faults tab shows the record; recoverable faults can be cleared there or handled automatically by a fault routine, so a single bad array index does not have to stop the whole line.

Fault types you will actually meet

• Type 1: power-up faults, the controller faulted while powering up (often the powerup handler is configured to fault deliberately so the process does not restart unattended).
• Type 3: I/O faults, a required I/O connection failed while the fault was configured as major (a missing module, a dead network node).
• Type 4: program execution faults, the workhorse category: array subscript out of range, arithmetic overflow, JSR to a missing routine, invalid instruction data.
• Type 6: watchdog, a task overran its watchdog time, commonly after adding heavy logic or loops to a fast periodic task.
• Type 7: nonvolatile memory faults, a store or load to the memory card failed.

The exact list is in Rockwell's fault-code documentation; the point is to read the pair (Type, Code) rather than treating "faulted" as one undifferentiated event.

Reading and clearing the fault

• 1. Go online in Studio 5000 and open Controller Properties, Major Faults. Record the type, code, and the fault text, including which program and routine faulted.
• 2. Fix the cause: correct the logic (bounds-check the index, guard the math), restore the I/O connection, extend the watchdog only if the task genuinely needs it.
• 3. Clear the fault from the Major Faults tab (or cycle the mode switch per site procedure) and return the controller to Run following your site's restart and safety rules.

Fault routines: handle it without stopping the line

For recoverable Type 4 faults, Logix lets each program have a fault routine: when the fault occurs, the routine runs, can log the event and clear the fault record, and execution continues. Used well, this converts a line-stopping crash into a logged event with an alarm. Used badly, it silently swallows real problems, so ALWAYS log what was caught (the fault record data) somewhere a human reviews, and alarm on repeats. A controller-level fault handler program plays the same role for controller-scope faults.

From fault log to reliability data

Each major fault is a downtime event with a precise, machine-readable cause, which makes it premium input for reliability work if it leaves the PLC. Record faults with their Type and Code in your CMMS work orders, review them in downtime analysis, and design your fault codes to name real causes rather than generic buckets. Fabrico ties this together on the floor: computer-vision-verified OEE captures the stop and its duration even when nobody logs it, and the closed-loop CMMS connects the fault to the fix, feeding honest MTTR and MTBF numbers. For the PLC-side design discipline, see our guide to PLCs in manufacturing.

FAQ

What is the difference between a major and a minor fault?
A major fault stops program execution; a minor fault logs the condition and execution continues. The same root cause can be either, depending on configuration.

The fault clears but keeps coming back. Now what?
The cause is still live. Read the fault record's program and routine reference and fix the logic or connection it names; do not script automatic clears around an undiagnosed fault.

Should every program have a fault routine?
Programs where a recoverable data error should not stop the machine, yes, with logging and alarming. Safety-relevant logic follows its own standards and is never "cleared and continued" casually.

To see how verified stop capture and closed-loop work orders turn PLC fault logs into reliability improvements, book a demo.