This Allen-Bradley ControlLogix fault codes complete list for Studio 5000 covers every Type, Code, and Sub-code combination — the field that distinguishes between a watchdog timeout caused by too much code in a continuous task versus one caused by a stuck network packet in an EtherNet/IP communication block. Every existing reference on the web provides only a flat list: Type number, Code number, text description. None of them includes the Sub-code column. Without the Sub-code, the technician knows there is a watchdog fault but not which of the five different root causes is responsible. This reference includes the complete Type, Code, and Sub-code tables for ControlLogix and CompactLogix Logix5000 controllers, with the probable cause and immediate action for each combination — exactly what the Studio 5000 Fault tab displays but with the diagnostic interpretation that Studio 5000 does not provide.
- How the Logix5000 Fault System Works
- How to Read Fault Codes in Studio 5000
- Type 1 — Non-Recoverable Controller Faults
- Type 2 — I/O Faults (Minor)
- Type 3 — I/O Connection Faults
- Type 4 — Program Execution Faults
- Type 6 — Controller Hardware Faults
- Type 7 — Motion Faults
- How Task Type Affects Fault Behavior: Continuous vs Periodic vs Event
- CompactLogix-Specific Fault Considerations
- How Firmware Version Affects Fault Codes
- Using the Controller Fault Handler Routine
- Technical Validation
- Frequently Asked Questions
How the Logix5000 Fault System Works
Major Faults vs Minor Faults vs I/O Faults
The Logix5000 fault system (used on ControlLogix, CompactLogix, GuardLogix, and SoftLogix platforms) classifies all faults into three operational categories before the Type+Code taxonomy applies:
Major faults halt all task execution and transition the controller to FAULTED state. The RUN LED turns off and the FAULT LED illuminates solid red. A major fault requires explicit clearance — either via Studio 5000, the keyswitch, or a ladder logic SSV instruction — before the controller can return to RUN mode.
Minor faults are logged in the fault table and set a bit in the controller status word, but execution continues. The controller remains in RUN mode. Minor faults that are not cleared accumulate in the fault log (maximum 16 entries); once the log is full, a new minor fault triggers a major fault.
I/O faults indicate that a module connection has failed. The controller may continue executing (using the last known good data for that I/O point) or halt, depending on the connection fault configuration in the I/O module properties.
The fault table in Studio 5000 (Controller Properties → Faults tab) displays the currently active fault with its Type, Code, Sub-code, Fault Description, and the Task Name and Routine Name where the fault occurred. For program execution faults (Type 4), it also displays the Rung Number.
How to Read Fault Codes in Studio 5000
Live fault (controller currently faulted):
Studio 5000 → Controller online → Controller Properties → Faults tab
The Fault tab displays: Type (decimal), Code (decimal), Sub-code (decimal), Fault Description (text), Task Name, Routine Name, and for Type 4 faults: Rung Number.
Fault history (controller cleared or previously faulted):
Studio 5000 → Controller Properties → Fault History tab
Up to 16 historical fault entries with timestamps. Entries are stored in non-volatile memory and persist through power cycles.
Programmatic fault reading with GSV instruction (for automated logging):
GSV(FaultLog, ., MajorFaultRecord, #destination_tag)
The FaultLog.MajorFaultRecord structure includes: Type (DINT), Code (DINT), SubCode (DINT), Info (DINT array with additional context), Time (LINT timestamp). This approach is used to build fault history logs beyond the 16-entry hardware limit. The complete GSV logging implementation is documented in Rslogix 5000 Studio 5000 Controller Fault History Timestamp How To Read.
Type 1 — Non-Recoverable Controller Faults
Type 1 faults indicate a controller hardware or firmware condition that cannot be resolved by software. The controller cannot be returned to RUN without hardware action.
| Code | Sub-code | Description | Probable Cause | Immediate Action |
|---|---|---|---|---|
| 2 | 0 | Controller failed self-test on powerup | Hardware failure | Replace controller |
| 3 | 0 | Controller firmware corrupted | Firmware update interrupted or bad flash | Update firmware via Studio 5000; if unsuccessful, return to factory |
| 4 | 0 | Controller NVS (non-volatile storage) failure | NVRAM hardware fault | Replace controller |
| 7 | 0 | Controller backplane communication failure | Backplane connector or chassis fault | Reseat controller; test in known-good chassis slot |
| 16 | 0 | Controller security authentication failure | Security policy mismatch between project and controller | Download project with matching security configuration |
Recovery note: Type 1 faults do not clear with the standard “Clear Major Fault” operation. Power cycling the controller does not clear a Type 1 fault if the hardware condition persists.
Type 2 — I/O Faults (Minor)
Type 2 faults are minor faults generated by I/O conditions. By default, Type 2 faults do not halt execution.
| Code | Description | Probable Cause | Immediate Action |
|---|---|---|---|
| 1 | Excess data from module | Module sent more data than the input tag structure can receive | Update module properties or tag data type |
| 4 | Insufficient data from module | Module sent fewer data bytes than expected | Verify module catalog number matches project configuration |
| 8 | Module not responding in time | Module connection timeout (non-fatal) | Check module power; verify RPI setting |
Type 3 — I/O Connection Faults
Type 3 faults indicate that an I/O module connection has failed. These can be major or minor faults depending on the module’s “Major Fault on Controller if Connection Fails While in Run Mode” property setting.
| Code | Sub-code | Description | Probable Cause | Immediate Action |
|---|---|---|---|---|
| 16 | Slot number | Module in specified slot: connection lost | Module removed, powered off, or backplane fault | Verify module is seated; check 24V supply; verify end cap on CompactLogix |
| 17 | 0 | Cannot open connection to module | Module not found at configured address | Verify IP address or slot number; check network connectivity |
| 18 | 0 | Module connection rejected | Configuration mismatch between project and module | Verify module firmware version and catalog number |
| 20 | 0 | Module inhibited | Module is inhibited in the project | De-inhibit module in I/O configuration or update project |
Type 3, Code 16 with slot Sub-code is the most common I/O connection fault on CompactLogix systems. The Sub-code is the slot number of the failing module. Common causes specific to CompactLogix 1769: exceeding the left-side bus limit (maximum 3 modules to the left of the power supply) or exceeding the right-side bus limit (maximum 8 modules to the right). The complete decision tree for Type 3 Code 16 including 1769 bus limitations is documented in Allen-Bradley I/O Fault Type 3 Code 16 Module Connection Failed Fix.
Type 4 — Program Execution Faults
Type 4 faults are the most diagnostically complex category because they occur within the user program and their Sub-code identifies the specific execution violation. The Task Name and Routine Name in the fault table are critical for locating the root cause instruction.
| Code | Sub-code | Description | Probable Cause | Immediate Action |
|---|---|---|---|---|
| 4 | 0 | Stack overflow | Excessive nested subroutine calls; recursive JSR | Audit JSR call depth; check for unintentional recursion |
| 20 | Instruction type | Illegal instruction executed | Unsupported instruction for this firmware version; instruction with invalid operand | Locate instruction at reported Rung Number; verify operand tag type and value |
| 34 | 0 | Invalid array subscription | Array index tag contains a value outside the array bounds | Add bounds checking before array access instruction |
| 36 | 0 | Invalid indirect address | Indirect addressing resolved to an address outside valid memory | Verify indirect address tag value is within valid range |
| 42 | 0 | Task watchdog timeout (continuous task) | Continuous task scan time exceeded Period setting | Identify scan time with GSV; check for infinite loops |
| 42 | 1 | Task watchdog timeout (periodic task) | Periodic task took longer than its Period setting | Reduce task content; increase Period; split task |
| 42 | 2 | Task watchdog timeout (event task) | Event task took longer than Period setting | Reduce event task execution time |
| 48 | 0 | Division by zero | Divide instruction executed with zero divisor | Add pre-check: compare divisor to zero before DIV instruction |
| 56 | 0 | Illegal position for instruction | Instruction placed in a context where it is not permitted | Review instruction placement restrictions in Studio 5000 help |
Type 4, Code 20 (Illegal Instruction): the Sub-code identifies the instruction type that caused the fault. The complete procedure to locate the offending instruction using the Cross Reference tool in Studio 5000 is documented in Compactlogix Major Fault Type 4 Code 20 Illegal Instruction Fix.
Type 4, Code 42 (Watchdog Timeout): Sub-code 0 (continuous task) requires a different fix than Sub-code 1 (periodic task). The scan time measurement procedure using GSV instruction and the task splitting approach are documented in Controllogix Watchdog Timeout Fault Type 4 Code 42 Fix Studio 5000.
Type 6 — Controller Hardware Faults
| Code | Description | Probable Cause | Immediate Action |
|---|---|---|---|
| 1 | Controller memory error | RAM hardware fault or corrupted project download | Power cycle; re-download project from Studio 5000 |
| 2 | Battery failure | 3V lithium battery depleted | Replace battery; retain memory data may be lost |
| 4 | Controller temperature exceeded | Cabinet ambient temperature too high; fan failure | Check cabinet ventilation; verify fan operation |
| 8 | Backplane power fault | 1756 chassis backplane power supply failure | Test with known-good power supply module |
| 16 | Flash memory failure | NVS write error during project download | Re-download project; if persistent, replace controller |
Type 6, Code 2 (Battery Failure): on ControlLogix 1756 CPUs, the battery backs the SRAM that holds the user program and retain tags when power is removed. A depleted battery means the program is lost on power cycle. The controller will still run from the flash (stored copy) if a flash backup exists, but retain tag values are lost. Replace with a 1756-BA2 battery and perform a program download to restore the flash copy.
Type 7 — Motion Faults
Type 7 faults are specific to controllers with motion control (Kinetix drives, servo axes). They are reported by the motion control task and the Sub-code identifies the specific axis and motion error.
| Code | Description | Probable Cause |
|---|---|---|
| 1 | Motion task error | Axis configuration mismatch between project and drive |
| 2 | Drive communication fault | EtherNet/IP connection to Kinetix drive lost |
| 4 | Axis position error | Following error exceeded configured limit |
| 8 | Motion planner stack overflow | Excessive move commands queued in motion buffer |
How Task Type Affects Fault Behavior: Continuous vs Periodic vs Event
The same fault code (e.g., Type 4 Code 42 — watchdog timeout) has different Sub-codes and different diagnostic implications depending on the task type where it occurs:
| Task Type | Watchdog Timeout Sub-code | Default Period Setting | Typical Cause |
|---|---|---|---|
| Continuous | 0 | Configured max scan time (default: 500 ms) | Runaway loop, excessive instruction count, communication blocking |
| Periodic | 1 | Defined period in task properties | Task takes longer than period; consider increasing period or splitting |
| Event | 2 | Configured event task timeout | Event task too complex for event-driven execution; move code to periodic task |
For a ControlLogix or CompactLogix system experiencing Type 4 Code 42 faults, the first diagnostic step is to identify the task name from the fault record — this immediately tells you which of the three categories applies and which fix path to follow.
For communication-layer faults (EtherNet/IP, RSLinx connection issues) that appear as Type 3 I/O faults, see Allen-Bradley Ethernet/Ip Connection Timeout Fault Controllogix Fix and Rslinx Classic Communication Path Not Found Error Fix Studio 5000.
For a functional comparison of this Type+Code+Sub-code system against the Siemens 16#EE:NNNN event class system, see Siemens Vs Allen-Bradley Plc Error Code System Comparison Guide.
CompactLogix-Specific Fault Considerations
CompactLogix 1769 systems share the same Logix5000 fault Type+Code taxonomy as ControlLogix 1756 but have hardware characteristics that generate specific fault patterns not common on 1756 chassis systems:
1769 Expansion Bus Limitations and Type 3 Code 16 Patterns
The CompactLogix 1769 expansion bus has explicit module count limits: – Left-side bus (between power supply and CPU): maximum 3 modules – Right-side bus (to the right of the CPU): maximum 8 modules on 1769-L3x; maximum 16 on 1769-L4x and L5x
Exceeding these limits generates Type 3, Code 16 faults on all modules past the limit position. These faults are not caused by module failure — they are caused by bus voltage droop when the current demand exceeds the bus specification. The Sub-code (slot number of the faulting module) appears as the highest-numbered slot in the bus, which is often not the problematic module but rather the last slot to receive adequate bus voltage.
Verification: add up the current draw ratings (printed on the module labels or in the selection guide) for all modules on the bus. Compare to the power supply’s 1769 bus rating. If the total draw is within specification, the bus limitation is not the cause — investigate module-level connection issues instead.
End cap requirement: all CompactLogix 1769 systems require a 1769-ECR (right end cap) or 1769-ECL (left end cap) at each physical end of the expansion bus. A missing end cap causes intermittent Type 3 Code 16 faults on all modules, typically appearing after thermal cycling as the bus connector contracts.
CompactLogix EtherNet/IP Adapter vs Controller Fault Classification
CompactLogix 5380 and 5480 controllers with dual Ethernet ports support a DLR (Device Level Ring) topology. A ring break generates Type 3 faults on all downstream nodes from the break point, which can appear as a cascade of simultaneous Type 3 Code 16 faults. The distinguishing pattern from true module failure: all faults appear in the same Studio 5000 download cycle and correspond to modules physically located after a single point in the ring topology.
For the complete Type 3 Code 16 diagnosis decision tree including CompactLogix bus limitation checks, see Allen-Bradley I/O Fault Type 3 Code 16 Module Connection Failed Fix.
How Firmware Version Affects Fault Code Behavior
Logix5000 firmware updates occasionally change fault code behavior, add new fault types, or modify how existing codes are reported. The most operationally significant firmware-related fault changes in recent releases:
| Firmware Version | Change | Impact on Fault Codes |
|---|---|---|
| V20 (L6x, L7x) | Added Type 4 Code 42 Sub-code differentiation for task type | Sub-code now identifies Continuous (0) vs Periodic (1) vs Event (2) watchdog source |
| V21 | Added Port Object (CIP Class 0xF4) support | MSG instructions targeting 0xF4 now work; previously generated Type 3 Code 17 or 18 |
| V24 | Enhanced minor fault log capacity from 8 to 16 entries | Systems on V20 and below can accumulate only 8 minor faults before escalation |
| V28 | Added enhanced motion fault sub-codes for Kinetix 5700 | Type 7 sub-codes expanded for new axis error categories |
| V32+ | CIP Security implementation | Type 1 Code 16 (security fault) now active for non-compliant connection attempts |
Practical implication: when reading a fault code from a controller running older firmware, verify the firmware version before applying the current documentation. A Type 4 Code 42 on firmware V18 does not include Sub-code task differentiation — all watchdog timeouts report as Sub-code 0 regardless of whether they are continuous or periodic task events.
Firmware version is visible on the controller faceplate status display (scrolls between fault code and firmware version) or in Studio 5000 → Controller Properties → General → Firmware Revision. For the firmware compatibility verification procedure between project firmware and installed firmware, see Plc Firmware Mismatch Error Fix Tia Portal Studio 5000 Guide.
Using the Controller Fault Handler Routine
The Controller Fault Handler (CFH) is a special program routine available in Studio 5000 that executes once when a major fault occurs, before the controller enters the FAULTED state. The CFH gives the program an opportunity to save data, activate safety outputs, or attempt programmatic fault recovery before production halts.
CFH setup:
Program block tree → Add Routine → Name: "FaultHandler" → Type: Ladder Diagram
Controller Properties → Advanced → Major Fault Handler → Select: FaultHandler routine
What the CFH can access: within the CFH, the $FAULTINFO built-in variable provides: Type (DINT), Code (DINT), SubCode (DINT), Program (STRING), Routine (STRING). This allows the CFH to make conditional decisions based on the specific fault type before taking action.
What the CFH can do:
– Write fault data to a retain tag array (persistent across power cycle and fault)
– Activate specific output tags to move equipment to a safe state (e.g., stop drives, close valves)
– Attempt programmatic fault recovery by clearing the fault with the SFC instruction (works for specific recoverable minor faults only)
– Communicate fault data via an MSG instruction to an HMI or historian (if network connection is established)
What the CFH cannot do: the CFH cannot prevent the controller from entering FAULTED state for major faults. After the CFH routine completes, the controller always transitions to FAULTED regardless of CFH actions.
CFH vs GSV logging: the CFH provides real-time fault response capability but executes only once per fault event. GSV logging in the main scan program builds a historical trend but does not execute during a fault event. Both should be implemented for production systems: CFH for immediate response and safety actions, GSV for trend analysis and recurrence prevention.
For the ControlLogix watchdog timeout diagnosis that is the most common Type 4 fault type on high-complexity programs, see Controllogix Watchdog Timeout Fault Type 4 Code 42 Fix Studio 5000.
Technical Validation
The complete Type, Code, and Sub-code table for Logix5000 controllers is formally specified in the Rockwell Automation Publication 1756-PM014 — Logix5000 Controllers Major, Minor, and I/O Faults Reference Manual. This is the authoritative source for all Type and Code values and the primary reference document for any ControlLogix or CompactLogix fault resolution. Sub-code values for Type 4 faults are additionally documented in the archived 1756-PM014 version preserved at PUCRS Polytechnic. The 1769 CompactLogix expansion bus current limitations referenced in the CompactLogix-specific section are validated against the 1769 Power Supply Selection Guide, which documents the per-bus current budget for each 1769 power supply model. Industrial PLC training context from Cincinnati State Workforce Development Center PLC training programs.
Frequently Asked Questions
Studio 5000 shows a fault Type and Code but no Sub-code and no Task Name. Why?
Some fault types (primarily Type 1 and Type 6 — hardware faults) do not generate task context information because they originate from the controller OS level, not from the execution of a user task. There is no program instruction to point to and therefore no Task Name, Routine Name, or Sub-code. For these faults, the Type and Code alone are sufficient for diagnosis — refer to the Type 1 and Type 6 tables in this reference to identify the hardware condition and corrective action. One exception: if Studio 5000 shows a Type 4 fault but no Task Name is visible, this typically indicates the fault occurred during controller initialization before any task began executing. This can happen when a Type 4 fault condition (such as an invalid array index) exists in an OnController event task that fires at startup — the fault occurs before the task name context is fully established in the fault display. Check all event tasks configured to fire on Controller events (power-up, run mode entry) for instruction-level errors.
The same Type 4 Code 42 fault appears every day at the same time. What causes regularly scheduled watchdog faults?
A Type 4 Code 42 fault that recurs at the same time each day almost always correlates with a scheduled operation that adds temporary load to the controller scan — SCADA polling cycles, HMI screen refresh events, historian data collection bursts, or scheduled database queries from FactoryTalk. If the fault timestamp consistently matches a scheduled operation, the fix is either to reschedule that operation to a less production-critical time window or to increase the task Period setting to accommodate the temporary scan time peak. Programmatic scan time monitoring using the GSV instruction to log maximum scan time per period will confirm the correlation before any changes are made.
What is the maximum number of Type 3 I/O faults a ControlLogix controller can accumulate before they cause a major fault?
On Logix5000 controllers running firmware V24 and later, the minor fault log holds 16 entries (8 entries on V20 and below). Once all entries are filled, the next incoming minor fault triggers a major fault regardless of its Type and Code. In systems with many I/O modules, a cascade of Type 3 faults from multiple modules (e.g., a backplane power event or DLR ring break) can fill the minor fault log and escalate to a major fault within milliseconds. To prevent this escalation: use the SSV instruction in the ladder program to periodically read and clear the minor fault log if your application produces known, non-critical Type 3 faults from optional modules. The SSV instruction to clear the minor fault log: SSV(FaultLog, MinorFaultRecord, 0, placeholder_tag) — setting the minor fault record to zero clears all logged minor fault entries. Implement this in a periodic task with a period longer than the main scan but short enough to prevent 16 entries from accumulating under worst-case module fault conditions. Log the minor fault data to a retain tag array before clearing so the fault history is not permanently lost — this allows review during the next scheduled maintenance window without interrupting the running controller.
