Does a Type 4 Code 20 fault always mean there is bad logic in the program, or can it appear after a firmware update without any program changes? Both scenarios are real, and the fix path is completely different for each. Code 20 (Illegal Instruction) fires when the Logix5000 controller encounters an instruction it cannot execute — but “cannot execute” has three distinct causes: the instruction is not supported by the firmware version, the instruction received an operand with an invalid data type, or the instruction was placed in a context (routine type, task type, or execution mode) where it is not permitted. This guide walks through the GSV-based fault location procedure to identify the exact instruction and rung, and the Sub-code table that separates the three root causes.
- What Type 4 Code 20 Means and What It Does Not Mean
- Sub-Code Table for Code 20: Three Root Cause Categories
- Step 1: Locate the Offending Instruction in Studio 5000
- Step 2: Use GSV to Read Fault Location Programmatically
- Cause A: Instruction Not Supported by Firmware Version
- Cause B: Invalid Operand Data Type or Value
- Cause C: Instruction in Invalid Execution Context
- Prevention: Compile-Time Checks Before Download
- Technical Validation
- Frequently Asked Questions
What Type 4 Code 20 Means and What It Does Not Mean
In the Logix5000 fault taxonomy documented in Rockwell Publication 1756-PM014, Type 4 identifies a program execution fault — the fault originated in the user program during task execution. Code 20 specifically means the controller encountered an instruction it could not execute.
What it does not mean: Code 20 does not indicate a hardware failure, a communication problem, or an I/O module issue. It is always a software-layer fault — something in the user program or in the relationship between the program and the firmware version.
The Studio 5000 Fault tab displays: – Type: 4 – Code: 20 – Sub-code: (varies — see table below) – Task: (name of the task where the fault occurred) – Routine: (name of the routine where the fault occurred) – Rung: (rung number within the routine)
The Task, Routine, and Rung fields are the most immediately actionable data — they tell you exactly where in the program to look. Navigate to that routine and rung as the first step.
Sub-Code Table for Code 20: Three Root Cause Categories
| Sub-code | Root Cause Category | Description | Typical Scenario |
|---|---|---|---|
| 0 | Instruction not supported | The instruction exists in Studio 5000 but is not supported by the controller firmware version | Newer instruction added to project, downloaded to older firmware controller |
| 1 | Invalid operand data type | The instruction received a tag with an incorrect data type for that parameter | Passing a REAL tag to a parameter that requires DINT; INT overflow in arithmetic |
| 2 | Invalid instruction context | The instruction is valid but placed in a routine type or mode where it cannot execute | Motion instruction in a non-motion task; event-only instruction in periodic routine |
| 3 | License required | The instruction requires an optional license not installed on the controller | Add-On Instructions for Safety, Motion, or Process that require separate licensing |
Step 1: Locate the Offending Instruction in Studio 5000
From the Studio 5000 Fault tab: 1. Note the Task Name, Routine Name, and Rung Number from the fault record 2. Project tree → [Controller Name] → Tasks → [Task Name] → [Program Name] → [Routine Name] 3. In the routine, scroll to Rung [Rung Number] 4. The offending instruction is on that rung — it typically displays with a red error indicator
If the controller was cleared and returned to RUN before the fault was read from Studio 5000, the Fault History tab (Controller Properties → Fault History) contains the same Task/Routine/Rung information from the last 16 fault events, each with a timestamp.
Cross Reference for Sub-code 0 (unsupported instruction): Right-click the identified instruction → Properties → verify the firmware version requirement listed in the instruction’s help text. Compare with: Controller Properties → General → Current Firmware Revision. If the firmware is older than the instruction’s minimum requirement, the controller cannot execute that instruction.
Step 2: Use GSV to Read Fault Location Programmatically
For controllers where a human is not immediately available to connect Studio 5000 at the moment of the fault, implement a GSV-based fault capture routine in the controller program:
GSV(FaultLog, ., MajorFaultRecord, #FaultCapture)
The #FaultCapture DINT array (minimum 12 elements) receives:
– [0] — Fault Type (4 for program execution fault)
– [1] — Fault Code (20 for illegal instruction)
– [2] — Sub-code
– [3]–[5] — Fault information (task index, routine index, rung number in packed format)
– [6]–[11] — Timestamp (LINT format)
This GSV routine should be in a periodic task that executes every scan, triggered by monitoring the controller status bits: #ControllerStatus.bit[1] (Major Fault bit) transitioning from 0 to 1. When the bit goes high, execute the GSV instruction once to capture the fault record, then store to a retain tag so it survives the inevitable CPU stop.
For the complete fault history logging implementation including CSV export, see Rslogix 5000 Studio 5000 Controller Fault History Timestamp How To Read.
Cause A: Instruction Not Supported by Firmware Version (Sub-code 0)
Scenario: the program was developed on a workstation with a newer Studio 5000 version than the firmware installed on the physical controller. Certain Add-On Instructions or new native instructions added in recent Logix5000 firmware versions are available in Studio 5000 but not executable on older firmware.
Identification: at the offending rung, check the instruction mnemonic. If it is an instruction introduced after the controller’s firmware version was released, this is the cause.
Common unsupported instruction scenarios:
– AXI (Axis Instruction variants) on firmware below V30
– MAOC (Motion Arm Output Cam) on firmware below V28
– PCMD (Process Control instructions) on controllers without the Process Control license
– Custom Add-On Instructions downloaded to a controller without the AOI installed in the project on that firmware version
Fix: either update the controller firmware to the minimum version that supports the instruction (via Studio 5000 → Online → Download Firmware to Device), or remove the unsupported instruction and implement the equivalent functionality using instructions supported by the current firmware.
Cause B: Invalid Operand Data Type or Value (Sub-code 1)
Scenario: an arithmetic or comparison instruction receives a tag with an incompatible data type, or an array subscript resolves to a value that cannot be converted to a valid index.
Common patterns: – A REAL tag passed to an instruction parameter that requires an integer type (DINT, INT, SINT) — the conversion overflow generates Code 20 – A SUB instruction result underflows below the minimum value for its output tag’s data type – A MOV instruction moving a REAL value with NaN (Not a Number) or Infinity into a tag that does not support these special float values
Fix: add a type validation rung before the offending instruction that verifies the operand is within the valid range for the receiving data type. For REAL-to-integer conversions, use the TRUNC instruction to explicitly truncate before the type conversion.
Cause C: Instruction in Invalid Execution Context (Sub-code 2)
Scenario: an instruction that is valid in some routines is placed in a routine type where it is not permitted.
Common invalid context scenarios:
– A JSR (Jump to Subroutine) instruction used in an SFC (Sequential Function Chart) action routine where only direct instructions are permitted
– A MSG (Message) instruction in an event task — MSG instructions cannot initiate communication in event tasks (they can only be pre-initiated from a lower-priority task)
– An UID/UIE (User Interrupt Disable/Enable) instruction placed inside an interrupt routine it is not permitted to control
Fix: move the instruction to a valid execution context. For MSG instructions in event tasks, initiate the MSG from the continuous or periodic task and only check completion in the event task.
For the complete Allen-Bradley fault code reference including all Type 4 codes, see Allen-Bradley Controllogix Fault Codes Complete List Studio 5000. For the systematic 8-step diagnostic process that frames fault code interpretation within a broader diagnostic workflow, see Plc Diagnostic Troubleshooting Systematic 8-Step Guide Industrial.
Prevention: Compile-Time Checks Before Download
Studio 5000 Logix Designer performs a Verify before download that catches most Type 4 Code 20 conditions before they reach the controller. Force a verification before every download:
Studio 5000 toolbar → Controller → Verify Controller (Ctrl+Shift+K)
A successful verification eliminates Sub-code 0 (unsupported instruction) and Sub-code 2 (invalid context) faults before download. Sub-code 1 (invalid operand value at runtime) cannot be caught by compile-time verification because the invalid value is a runtime condition, not a static property of the instruction.
Technical Validation
Type 4 Code 20 definition and Sub-code specification from Rockwell Publication 1756-PM014. Fault location and GSV diagnostic techniques from NFM Consulting Allen-Bradley faultfinding diagnostics reference. Industrial PLC training context from NIC.edu PLC certification programs.
Frequently Asked Questions
Type 4 Code 20 appeared after a firmware update with no program changes. Is this expected?
Yes. Firmware updates occasionally deprecate instruction behaviors that were previously tolerated. If a firmware update changes how an instruction validates its operands, an instruction that executed without error on the old firmware may generate Code 20 on the new firmware. Check the firmware release notes for deprecated instructions or changed operand requirements. The fix is either to revert to the previous firmware (if downgrade is supported for your CPU) or to update the instruction usage to conform to the new firmware’s requirements.
The fault record shows Routine: “unknown” and Rung: 0. How do I locate the instruction?
Task: unknown / Routine: unknown / Rung: 0 appears when the fault occurred in a context where the controller OS cannot attribute it to a specific user program location — typically during a transition between execution modes (startup, shutdown, mode change) or in firmware-level code. For Sub-code 0 (unsupported instruction), run Studio 5000 Controller Verify (Ctrl+Shift+K) to identify all unsupported instructions across all routines without needing the fault record location. The Verify results panel lists each unsupported instruction with its location.
Can Type 4 Code 20 be programmatically suppressed to keep the controller running?
No. Type 4 Code 20 is always a major fault that halts execution. It cannot be converted to a minor fault or suppressed programmatically. The only valid response to Code 20 is to fix the offending instruction before resuming production. Attempting to clear the fault and restart without fixing the instruction will result in the fault recurring on the exact same scan cycle, stopping the controller again immediately.