ControlLogix major fault codes: Type 4 Code 20 and the rest

A Logix controller with its OK LED flashing red has a major fault. The display, or the Major Faults tab in Logix Designer, gives you two numbers: a type and a code, shown as T04:C20 or 'Type 4, Code 20'. This page is the reference for those numbers and the procedure that follows them.

Every type, code and corrective action below comes from Rockwell. The current Major, Minor, and I/O Faults manual (1756-PM014) no longer prints the code table; it refers to a spreadsheet, Logix 5000 Controller and I/O Fault Codes (1756-RD001, September 2025), which can be downloaded from Rockwell's literature library. Instruction-specific faults are in the general instructions reference, served at the 1756-RM003 address as 1756-RM018A.

What a major fault is

Rockwell's definition, from 1756-PM014: if a fault condition prevents an instruction from running, the instruction aborts and the controller reports a major fault. Logic execution halts and the controller switches to faulted mode. Outputs go to their configured state or value for faulted mode.

A fault routine can clear the fault and let the program continue, which Rockwell calls fault recovery. If it does, the faulted instruction does not run and execution resumes with the next instruction. That last detail matters: if the instruction was a JSR, the whole subroutine is skipped (more on how JSR and subroutines behave).

You can read the fault in three places: the Major Faults tab of Controller Properties, which shows the last three major faults and a count since the log was cleared; the controller's status display, as 'Major Fault TXX:CXX' followed by a message; and in logic, through the MajorFaultRecord attribute of the Program object.

The fault types

The placements for types 1, 3, 4, 6 and 11 are from the fault routine table in 1756-PM014, which covers only those five; the categories are from 1756-RD001.

Common major fault codes and what to do

Motion faults (Type 11) cover overtravel, position error tolerance, encoder loss and drive faults; Type 18 covers CIP Motion drive faults. 1756-RD001 lists each with its reset procedure.

Type 4 Code 20 in detail

This is the one most people search for. Rockwell's description in 1756-RD001 is 'Array subscript too large, or CONTROL data type POS or LEN invalid'. The Index through arrays section of 1756-RM003 puts it plainly: instructions that view arrays as a collection of elements generate a major fault (type 4, code 20) if a subscript exceeds its corresponding dimension.

So it comes from two places. A tag used as an index, Recipe[Recipe_No], holding a value past the end of the array, or negative. Or a file instruction whose CONTROL structure points past the end: 1756-RM003 lists Code 20 for FFL and FFU, LFL and LFU, BSL and BSR, SQL, SRT, STD, DDT and FBC, among others, and Code 21 when POS or LEN is negative. On a BOOL array or a bit number, the same mistake is Code 83 instead.

Prescan has its own rules. If a controller faults immediately after switching to Run, look at prescan. From revision 13.0 the controller clears out-of-range subscript faults during prescan automatically; at 11.x and earlier they fault, and for 12.x Rockwell refers you to the release notes. Logix Designer's internal handler that does this runs only during prescan and only clears array faults, type 4 codes 20 and 83. Array faults are not ignored in postscan.

The fix is a guard before the index is used. In neutral text:

GEQ(Recipe_No,0)LEQ(Recipe_No,19)OTE(Recipe_Valid);
XIC(Recipe_Valid)MOV(Recipe[Recipe_No],Active_Recipe);
XIO(Recipe_Valid)OTE(Recipe_Error);

Here Recipe is a DINT[20]. Every instruction that uses the index is conditioned on Recipe_Valid, and an out-of-range number raises an alarm instead of stopping the controller. The guard itself can be built and tested in the LADX ladder simulator with an integer tag. Why an index faults at all is covered in indirect addressing and arrays.

Add-On Instructions and faults

A fault inside an Add-On Instruction does not behave like one inside a subroutine. 1756-PM014 is explicit: the AOI is an instruction, so a fault inside it aborts the rest of it, and if the fault is cleared, execution resumes after the top-level AOI call. If myAoi calls myNested, which calls inner, and inner faults, none of the remainder of inner, myNested or myAoi runs. Design AOIs to check their own indexes; see Add-On Instructions.

Type 6: the task watchdog

Each task has a watchdog: 1 to 2,000,000 ms, 500 ms by default (1756-PM005). It starts when the task starts and stops when every program in the task has run, including time spent interrupted by other tasks. If the task overruns, the controller raises T06:C01.

The causes Rockwell lists are an infinite loop, a program too complex to run as quickly as specified, and a higher priority task keeping this one from finishing. In Structured Text, a FOR, WHILE or REPEAT loop that runs too long raises the same fault (1756-RM003). The controller fault handler can clear a watchdog fault, but if the same watchdog fault happens again in the same scan the controller faults regardless (1756-PM005). Raising the watchdog only hides the symptom; scan time optimisation addresses the cause.

Clearing a major fault

Fix the cause first. Then either:

• From the software: Controller Properties, Major Faults tab, Clear Majors. If the keyswitch is in Run, the controller starts running again immediately, which is worth knowing before you click.
• From the keyswitch: turn from RUN or REM to PROG, then to REM, then to RUN to restart, or back to PROG to stay stopped. This clears the fault but not the major fault log.

A Type 1 Code 1 at power-up is not an error in the usual sense. If the controller powers up in Run or Remote Run, the Power-Up Handler runs: leave it empty and the controller stays faulted, which is the safe default for many machines; clear the fault in it and the controller resumes.

Fault routines: clear one thing, on purpose

1756-PM014 describes the pattern. Create a user-defined type FAULTRECORD with Time_Low and Time_High (DINT), Type and Code (INT) and Info (DINT[8]). In the program's fault routine, a GSV reads the Program object's MajorFaultRecord into a tag of that type (naming the first member of the tag), EQU instructions test for the one type and code you expect, CLR zeroes Type and Code, and an SSV writes the record back, which clears the fault. In neutral text, for an out-of-range recipe index:

GSV(Program,THIS,MajorFaultRecord,Fault_Rec.Time_Low)EQU(Fault_Rec.Type,4)EQU(Fault_Rec.Code,20)CLR(Fault_Rec.Type)CLR(Fault_Rec.Code)MOV(0,Recipe_No)SSV(Program,THIS,MajorFaultRecord,Fault_Rec.Time_Low);

The MOV puts the index back in range so the fault does not repeat on the next scan. Rockwell's prescan example adds a CPU_scanning bit, written by an unconditional OTE in the main routine, so that the routine can tell a prescan fault from one in normal running: the bit is off during prescan, because the controller resets OTE bits then, and always on once logic runs.

Rockwell is emphatic about the limits: do not use fault routines to continually clear all faults, and be selective in the types and number of faults cleared; the online help adds that you should log each occurrence. A routine that clears everything turns a stopped machine into one running with a skipped instruction nobody knows about.

Where to put it follows the type: Type 4 in the program's fault routine; Types 3, 6 and 11 in the Controller Fault Handler; Type 1 Code 1 in the Power-Up Handler. If a program's fault routine does not clear the fault, the controller runs the Controller Fault Handler; if that does not clear it either, the controller faults.

To test one without waiting for a real fault, use a JSR to the fault routine: 1756-RM003 lists a JSR into a fault routine as Type 4, code 990 or a code you supply, and 1756-PM014 reserves 990 to 999 for user-defined faults. Add the test to your commissioning checklist, and work through real faults with the troubleshooting method rather than by clearing and hoping.