Need Custom Pricing? Request a Quote!
Request a free quote for bulk orders or repairs—response in 24 hours. Or get tailored advice and a quote for your automation needs.
Get Your Free Quote!
When your ControlLogix controller trips a Major Fault, the program stops executing, the outputs go to their configured fault state, and your machine or process comes to a halt. You need answers fast — what caused it, what does the fault code mean, and how do you clear it and get running again?
This quick-reference guide covers the most common ControlLogix Major Fault types and codes, their root causes, and the steps to diagnose and resolve each one.
How ControlLogix fault handling works
ControlLogix organizes faults into three categories:
- Major Faults: Critical errors that halt the controller. The controller enters Faulted mode and stops scanning the program. These are what this guide focuses on.
- Minor Faults: Non-critical issues logged to the fault log but do not stop program execution (e.g., output point fuse blown, instruction overflow).
- I/O Faults: Module-level errors reported through the I/O tree (e.g., module not responding, configuration mismatch).
Every Major Fault has two identifiers:
- Type: The category of the fault (1–14)
- Code: The specific error within that type
You can read these in Studio 5000 under Controller Properties → Major Faults, or programmatically via the GSV (Get System Value) instruction using the FAULTLOG or MAJORFAULTRECORD objects.
Major fault types at a glance
| Type | Name | Description | Severity |
|---|---|---|---|
| 1 | Power-Up | Controller powered up with no program or after firmware update | Low — usually clears by downloading program |
| 3 | I/O | Critical I/O module error or loss of communication | Medium — check module and connections |
| 4 | Program Execution | Errors during ladder/FB/ST execution (divide by zero, array out of bounds, etc.) | High — program bug, must fix logic |
| 5 | Watchdog | Task execution exceeded its configured watchdog timer | High — task taking too long |
| 6 | Stack | Unrecoverable error related to the controller's internal stack | Critical — possible hardware issue |
| 7 | Communications | Error in controller-to-controller communications | Medium — network or MSG instruction error |
| 8 | Diagnostics | Battery failure, memory errors, or firmware corruption | Critical — may need hardware replacement |
| 11 | Motion | Fatal motion group or axis error | High — check servo/drive configuration |
| 14 | Safety | Safety task fault (GuardLogix only) | Critical — safety integrity compromised |
Type 1: power-up faults
| Code | Cause | Fix |
|---|---|---|
| 1 | Power-up after power loss; no program in memory | Download program from Studio 5000 or restore from SD/CF card; switch to RUN |
| 60 | Firmware update completed; controller needs to be put into RUN | Verify firmware version, then switch to RUN mode |
| 61 | Non-recoverable controller fault detected at power-up | Cycle power. If repeats, replace controller |
Type 3: I/O faults
| Code | Cause | Fix |
|---|---|---|
| 16 | I/O module not responding (connection lost) | Check module seating, backplane connection, and power supply. Verify the module is configured in the I/O tree. |
| 20 | I/O module reported a fatal fault | Check the specific module's channel-level fault data. Replace module if hardware failure is confirmed. |
| 23 | I/O connection failed during program execution | Check EtherNet/IP network health, cable connections, and switch status. Reduce network traffic if needed. |
Pro tip: For intermittent Type 3 faults, check the backplane power supply. A marginal 1756-PA72 or 1756-PB72 can cause random I/O drops that look like module failures. Try swapping the power supply first.
Type 4: program execution faults (most common)
Type 4 faults are the ones you will encounter most often. They indicate a bug or unexpected condition in your program logic.
| Code | Cause | Fix |
|---|---|---|
| 4 | Array subscript out of range | Check all indirect addressing (array[variable]). Ensure the index variable cannot exceed the array dimension. |
| 20 | Stack overflow — too many nested JSR (Jump to Subroutine) calls | Reduce nesting depth. Refactor deeply nested JSR chains. Check for recursive JSR calls. |
| 21 | Return (RET) without matching JSR | Verify every RET instruction has a corresponding JSR. Check for conditional logic that could bypass the JSR but still reach RET. |
| 31 | Divide by zero (DIV, MOD, or CPT instruction) | Add a pre-check: if divisor = 0, branch around the divide instruction. |
| 34 | Timer or counter preset value negative or overflowed | Verify .PRE and .ACC values are within valid ranges. Check for uninitialized tags. |
| 42 | User-defined fault (via programmatic Major Fault instruction) | Search your program for GSV/SSV or the "Major Fault" instruction to find where this is triggered intentionally. |
| 82 | Instruction execution error (invalid operand) | Check the operand types and sizes. This often happens when a string instruction gets a null or oversized string. |
| 84 | FOR/NEXT loop exceeded maximum iteration count | Review the FOR instruction's parameters. Ensure the loop counter and limit are set correctly. |
Type 5: watchdog faults
| Code | Cause | Fix |
|---|---|---|
| 1 | Task watchdog timer expired — task execution exceeded the configured time |
|
Quick check: In Studio 5000, go to Controller Properties → Tasks. Compare the "Max Scan Time" to the "Watchdog" value. If they are close, you are one heavy scan away from a fault. Increase the watchdog to 2x the max observed scan time as a minimum.
Type 6: stack faults
| Code | Cause | Fix |
|---|---|---|
| 1 | Internal stack overflow — unrecoverable | Cycle power. If fault repeats, it may indicate a firmware bug or hardware failure. Update firmware to latest version. If the problem persists, replace the controller. |
Type 8: diagnostics faults
| Code | Cause | Fix |
|---|---|---|
| 1 | Non-volatile memory (NVS) fault — memory corruption or write failure | Re-download the program. If fault persists, replace the SD/CF card and retry. If the controller memory itself is corrupted, replace the controller. |
| 9 | Battery low or missing | Replace the 1756-BA1 or 1756-BA2 battery. Clear the fault and verify the battery status in Controller Properties. |
How to clear a Major Fault
- Identify the fault: In Studio 5000, go online and check Controller Properties → Major Faults. Note the Type and Code.
- Fix the root cause: Use the tables above to diagnose and resolve the underlying issue. Simply clearing the fault without fixing the cause will result in an immediate re-fault.
-
Clear the fault:
- From Studio 5000: Click "Clear Major Fault" in Controller Properties, then switch to RUN mode.
- From the keyswitch: Turn the keyswitch from PROG to RUN (if the controller has a keyswitch and is not in Remote mode).
- Programmatically: Use the SSV (Set System Value) instruction to clear the fault from a fault handler routine. This is useful for automated recovery.
Setting up a fault handler (best practice)
Every production ControlLogix program should include a Controller Fault Handler. This is a special program/routine that executes when a Major Fault occurs, giving you a chance to:
- Log the fault details to a buffer for later analysis
- Attempt automated recovery for known fault types (e.g., clear a Type 4 Code 31 divide-by-zero and continue)
- Set outputs to a safe state before the controller stops
Configure it under Controller Properties → General → Controller Fault Handler. Assign it to a dedicated program and routine.
Related resources
- Allen-Bradley PLC Buyer's Guide: ControlLogix vs CompactLogix vs Micro800
- PLC-5 to ControlLogix Migration Guide
- Allen-Bradley Catalog Number Decoder
- PowerFlex VFD Fault Codes: Complete Troubleshooting Reference
Need a replacement ControlLogix processor or module? Browse our 1756 inventory — we stock CPUs from the 1756-L61 through the latest 1756-L85E, all with a 2-year warranty.
Frequently asked questions
What is the most common ControlLogix Major Fault?
Type 4 (Program Execution) faults are the most common in the field. Among those, Code 4 (array subscript out of range) and Code 31 (divide by zero) account for the majority of cases. Both are preventable with defensive programming — bounds checking on array indices and zero-checking before division operations.
Will a Major Fault damage the controller hardware?
No. A Major Fault is a software-level protection mechanism. It stops the program to prevent unpredictable behavior, but it does not damage the processor or modules. The exception is Type 6 and Type 8 faults, which may indicate actual hardware issues — but the fault itself is not the cause of the damage.
Can I prevent Major Faults from stopping the controller?
You cannot prevent the controller from entering Faulted mode on a Major Fault. However, you can create a Controller Fault Handler routine that captures the fault and clears it programmatically, allowing the controller to automatically return to RUN mode. This should only be done for faults you fully understand — blindly clearing faults can lead to unsafe conditions.
How do I check the fault log history?
In Studio 5000, go to Controller Properties → Major Faults tab. This shows the most recent fault. For a complete history, use the GSV instruction to read the FAULTLOG object in your program, or check the controller's diagnostic log via FactoryTalk Diagnostics if available on your network.