1756 ControlLogix Fault Major Fault Type 4 — Array Subscript Out of Range

Overview

An Allen-Bradley 1756 ControlLogix Major Fault Type 04 (Program Fault) Code 20 occurs when the controller attempts to access an array element using an index pointer that falls outside the defined limits of the array. Because a ControlLogix processor cannot resolve a memory reference that is less than zero or greater than the maximum index of the array (N-1, where N is the array size), it halts execution immediately to prevent data corruption, unpredictable machine motion, or unsafe system operations. This results in the processor dropping into Faulted mode, disabling all outputs, and stopping the production line.

Symptoms

When a Major Fault Type 4 Code 20 is triggered, maintenance engineers and plant floor technicians will typically observe the following symptoms:

• Processor State LED Indicators: The "OK" indicator on the front bezel of the 1756 ControlLogix controller (such as a 1756-L73 or 1756-L81E) turns solid red, indicating a non-recoverable major fault has halted program execution.
• Software Status in Studio 5000: The Controller Status box in the upper-left corner of the Logix Designer window displays "Faulted" in red text.
• System Halt: All execution tasks (Continuous, Periodic, and Event) stop instantly. Outputs controlled by output modules or network drives drop to their configured sleep/fail-safe states.
• HMI Failures: Connected Human-Machine Interfaces (HMIs) or SCADA platforms may display communications loss icons or show stale data because the PLC's runtime engine has stopped updating tag values.
• Fault Log Diagnostics: Opening the Controller Properties dialog box and navigating to the "Faults" tab reveals the diagnostic message: "(Type 04) Program Fault (Code 20) Array subscript out of range."

Possible Causes

This fault is almost always a logical software issue rather than hardware physical wear. The primary root causes include:

• Dynamic Index Pointer Overflow: An index pointer tag is incremented using math instructions (such as ADD or INC) without a boundary ceiling check, allowing the pointer to exceed the array's absolute size limit.
• Unrestricted Loop Counter Execution: A nested FOR loop in Structured Text (ST) or Sequential Function Chart (SFC) routines executes one loop too many (off-by-one errors), usually due to incorrect termination parameters (e.g., executing up to index size N instead of N-1).
• Malformed HMI or SCADA Tag Writes: An operator inputs a recipe value or position index via an HMI input panel that exceeds the database limit of the corresponding controller array, and the PLC immediately tries to parse it without vetting.
• Improper Pointer Manipulation with COP/FAL Instructions: Array manipulation instructions such as File Arithmetic and Logic (FAL), File Copy (COP), or FIFO Write (FFW) are configured with incorrect length attributes or source/destination offset values that overrun destination indices.
• Legacy Code Migration Mapping Errors: During conversion of older PLC platforms (like PLC-5 or SLC 500) to ControlLogix, structured files (like standard integer files N7) are dynamically mapped to array objects of different boundaries, leading to legacy pointer offsets targeting newly nonexistent indices.
• Dynamic Indirect Addressing Fields: Indirect variables configured within complex User-Defined Data Types (UDTs) or Add-On Instructions (AOIs) are dynamically modified in code without localized validation checks.

Step-by-Step Troubleshooting

Follow this technical procedure to get offline, isolate the bad logic, restore the controller to Run mode, and implement programmatic safety blocks.

Step 1: Connect to the Controller and Capture Fault Details

1. Open your Studio 5000 Logix Designer project and go Online with the faulted controller using the appropriate communication pathway (Ethernet/IP or USB connection).
2. When prompted, view the fault path details in the popup window, or right-click the Controller icon at the top of the Controller Organizer tree and select Properties.
3. Navigate to the Faults tab.
4. Document the exact details listed under the "Major Fault" category. The fault details will explicitly state which Program, Routine, and Rung Number caused the processor execution to crash.

Step 2: Navigate to and Examine the Offending Rung

1. Locate the program and routine identified in the fault log, and double-click to open it.
2. Go to the exact rung number indicated. If the program crashed in a Structured Text routine, locate the precise line of code.
3. Look for dynamic array calls within instructions on that run. This looks like MyArray[MyPointer], where MyPointer is the variable index tag.
4. Hover your mouse cursor over the dynamic index tag (e.g., MyPointer) to confirm its current value in the database. Cross-reference this value with the dimensions of MyArray (found by opening the Controller Tags list, locating the array tag, and checking the Data Type column, e.g., DINT[100] which allows indices 0 to 99).

Step 3: Analyze the Upstream Logic Modifying the Subscript

1. Right-click the index variable tag (e.g., MyPointer) and select Cross Reference (or press Ctrl + Y).
2. Filter the search results to scan only for destructive writes (where the tag is written to or modified, such as with MOV, ADD, SUB, or HMI write-access).
3. Trace backwards through the scans to understand why the pointer value exceeded the maximum permissible boundary. Check if the value is derived from user entry or sensor data tracking.

Step 4: Reset the CPU and Clear the Major Fault

1. To clear the system's fault so you can perform online edits, you must temporarily switch the controller mode switch to Program Mode to cease task scanning.
2. In the Controller Properties dialog under the Faults tab, click Clear Major Faults.
3. Confirm that the fault clears and the red "OK" LED starts flashing green, indicating the CPU is in Program Mode and waiting for standard startup checks.

Step 5: Implement Defensive Bounds Checking (The Fix)

Before executing code that accesses the array, you must constrain your index pointers using a Limit check.

• In Ladder Logic (LD): Add a Limit block (LIM) ahead of the instruction using the index pointer. Set the Low Limit to 0 and the High Limit to the maximum array index (e.g., 99 for a 100-element array). Only execute the step containing the array subscript if the condition is True.
• Alternative Clamp Logic: Alternatively, program a reset rung to restrict the pointer:

  IF MyPointer < 0 THEN
      MyPointer := 0;
  END_IF;
  IF MyPointer > 99 THEN
      MyPointer := 99;
  END_IF;
  

Step 6: Verify and Return to Run Mode

1. If online edits were executed, complete the online editing progress by verifying the routine and accepting the changes.
2. Switch the physical keyswitch or software status window back to Run Mode.
3. Monitor the database variables to confirm that the index pointer remains nested within safe bounds during routine cycles.

Recommended Actions

To eliminate the risk of recurring Array Subscript faults in your plant, incorporate these architectural programming modifications:

• Add High/Low Clamping Logic globally: Never write an analog index directly to an array pointer instruction. Always buffer raw user-entered numbers through a limit evaluation rung before copying them to array index variables.
• Use the LOGIX Size Instruction (SIZE): For complex dynamic loops (especially inside custom Add-On Instructions), use the SIZE instruction to read the physical array length runtime. Set your comparison variables automatically based on this value so that any future expansion of the array size does not break the bounds-checks.
• Implement a Controller Fault Handler: configure a specific "Fault Routine" for the controller program folder. If a Type 4 Code 20 fault occurs, the handler routine can run briefly to clamp the index back to a safe reset value of 0 and execute the SSV (Set System Value) instruction to clear the major fault automatically, allowing the machinery to stay online or run a controlled system stop instead of hard tripping.

Recommended Replacement Parts

While Major Fault Type 4 is a logical programming error rather than physical breakdown, recurring system lockups, corrupted memory, or failures to hold logical modifications online can point to aging CPU hardware or failing memory chips. Consider these replacements if your chassis system shows signs of instability:

Related Articles

• Structuring Controller Fault Handlers in Studio 5000
• Guide to Replacing 1756-L7x Processors with L8x Series
• Logix Designer Migration Compatibility: Logix5000 v20 to v35

FAQ

Q: Can a Type 4 Code 20 fault damage my 1756 physical output modules?

No. This is a purely logical programming fault. However, because the processor immediately drops out of Run mode, all output modules will immediately go into their configured fail-safe modes (typically turning Off), which could affect physical mechanics downstream if the systems do not have proper mechanical check valves or interlocks.

Q: Why does this fault occur only occasionally during automated plant transitions?

This usually occurs when index pointers are changed relative to variable production factors, such as recipes, tracking queues, or conveyor indexing steps. When a specific uncommon batch size is selected or a queue fills to maximum capacity, it pushes the index tracking scale beyond the array size, causing a crash that doesn't occur during normal shifts.

Q: Does using the COP (File Copy) instruction protect me from indexing faults?

The standard COP instruction in Studio 5000 is blind to the logical termination boundary of the destination array. If the length specified in the instruction is larger than the destination array can handle, the copy function will overrun the array, corrupting adjacent tag memory blocks. Make sure your COP lengths are strictly validated prior to runtime execution.

Q: What is the fastest method to restore physical operations when the site is down?

Clear the major fault through Studio 5000, physically force the out-of-range pointer tag to 0 or another valid index manually in the controller tag database, and toggle the CPU back to Run mode. Correct the underlying boundary logic online once production has safely resumed.