PLC Troubleshooting Guide: Faults, Codes & Fixes

PLC Fault Categories

Allen-Bradley classifies faults into two severity levels: major and minor. Understanding the difference tells you immediately how urgent the problem is and what action to take.

• Major Faults — The controller stops scanning the program entirely. The CPU halts execution and will not respond to any input. The machine cannot operate. Major faults require immediate diagnosis and clearing before the program can run again.
• Minor Faults — The program continues running, but a flag is set in the fault status word. The program can check this flag and take recovery action (like logging the fault or triggering an alarm). Minor faults do not stop the machine immediately.
• Recoverable vs Non-Recoverable — A recoverable fault can be cleared and the program will resume. A non-recoverable fault indicates a hardware or controller-level problem that may require a firmware update or hardware replacement.
• I/O Faults vs Program Faults — I/O faults occur when an I/O module cannot communicate (missing, powered off, network disconnected). Program faults occur when the CPU encounters an invalid instruction or data condition (divide by zero, out-of-range address).

Common Allen-Bradley Fault Codes

Each fault is identified by a two-digit type code and a numeric fault code. The type tells you what category of fault occurred; the code tells you the specific issue. After parsing thousands of PLC program files, we've found these fault types account for over 95% of real-world issues.

• Type 1 Faults — I/O Communication — The PLC cannot communicate with an I/O module. This usually means the module is missing from the chassis, powered off, or has a communication timeout. Check the I/O tree in Studio 5000 and verify the rack address matches the physical setup.
• Type 4 Faults — Program Faults — The CPU encountered an invalid instruction or instruction operand. Examples: divide by zero, out-of-range array index, illegal move instruction. The fault buffer shows which rung faulted.
• Type 7 Faults — Motion Faults — A servo drive or motion module reported an error. This includes axis faults, encoder errors, and over-current conditions. Check the drive documentation and the motion fault code register.
• Interpreting the Fault Code Table— In Studio 5000, open Controller Properties > General > Fault Configuration to see the full list. Each fault code has a description, severity, and recovery action. Write down the Type and Code when a fault occurs — this is your first diagnostic clue.

PLC Not Communicating: Root Causes and Fixes

A PLC that won't connect to Studio 5000 or a network device is almost always caused by one of these five issues. We recommend checking them in this order.

• Wrong IP Address — The computer or network device has a different IP than the PLC. Use ipconfig to verify the computer IP. In Studio 5000, check the target IP in the communication settings. If they don't match, update the IP or use a different network path.
• Wrong Chassis Slot Number — You're telling Studio 5000 to connect to the wrong slot in the PLC rack. The communication module (Ethernet or serial) must be in the correct slot. Check the hardware configuration in Studio 5000 against the physical backplane.
• RSLinx Driver Not Loaded — Studio 5000 relies on RSLinx (Rockwell's communication driver) to reach the PLC. If the driver is not running, Studio 5000 cannot find the PLC even if the IP is correct. In RSLinx, verify the Ethernet driver is active and connected.
• Firewall Blocking EtherNet/IP — Windows Firewall or network firewalls may block port 44818 (EtherNet/IP). If the PLC is on a different network segment, ask IT to open UDP 44818 between the computer and PLC. Use netstat to verify the connection is open.
• Network Cable Disconnected or Bad — Check the Ethernet cable at both the PLC and computer. Swap the cable with a known-good one. If the PLC LED does not show a link light, the network port may be damaged or the cable is bad.

Program Fault Troubleshooting

When a program fault occurs, the CPU stops execution and sets the fault bits. To recover, you must understand which rung faulted and why.

• Find the Faulting Rung — In Studio 5000, go to the Fault buffer. It shows the last 16 faults with routine name, line number, and description. This tells you exactly where in the program the fault occurred. Open that routine and go to that line.
• Read the Fault Message — The fault description gives a specific clue: "Array index out of bounds," "Divide by zero," "Illegal instruction," etc. Match the description to the instruction on that rung.
• Check Rung Conditions — Look at the conditions that guard the faulting instruction. Is the instruction supposed to execute every scan, or only when a condition is true? If a condition should prevent the instruction from running, add it to the rung or fix the logic.
• Verify Input Data — Check what values the faulting instruction was trying to process. If it was a divide instruction, was the denominator zero? If it was an array access, was the index out of bounds? Add guards to prevent invalid data from reaching the instruction.

Using Your PLC Program File to Troubleshoot Faster

Before going to the machine floor, load your program file into plc.company. Cross-reference the faulting tag to see every place it's used. This saves hours by letting you understand signal flow without needing to connect to the live PLC.

• Cross-Reference the Faulting Tag — If the fault involves a tag called "PumpMotor_Speed", search for that tag in your program. plc.company and Studio 5000 both show every rung that reads or writes that tag. This reveals the complete signal path: what controls the tag, what the tag controls, and where errors might happen.
• Trace Signal Flow — Start with a known input (like a sensor or button press). Follow rungs that reference that input. See what outputs those rungs produce. Trace those outputs forward to any rungs that use them as inputs. Build a mental map of the logic before touching the machine.
• Understand What a Rung Is Supposed to Do — Read the comments in the code or talk to the original programmer. If a rung is supposed to energize a solenoid when three conditions are met (e.g., door closed AND button pressed AND safety relay OK), look for those three conditions in the rung. If one is missing, the rung may execute at the wrong time, causing unexpected behavior.

I/O Module Faults

I/O module faults are the most common type we see in the field. A module goes offline and the PLC halts. Here's how to diagnose and fix it.

• Module Not Found — The I/O tree shows a module is missing. Check that the module is physically installed in the correct slot. Verify the slot number in Studio 5000 matches the physical position (slot 0 = leftmost after CPU). If the slot number is wrong, edit the configuration and download to the PLC.
• Connection Timeout — The module is in the rack but not responding. Check the module power LED. If it's off, verify 24V power is reaching the backplane. If it's on, the module may be hung; try a power cycle (turn off the PLC, wait 30 seconds, turn it back on).
• Verify Rack Address and Catalog Number — In Studio 5000 I/O tree, right-click the module and check Properties. Verify the catalog number matches the physical label on the module. If you've replaced the module, the new one must have the same catalog number and configuration (number of I/O points, voltage, etc.).

When to Escalate vs. Fix Yourself

Not every fault should be cleared immediately. Some require specialized expertise or spare parts. Know your limits.

• Fix Yourself — Wrong IP address, missing I/O module configuration, invalid tag reference in code, disabled input card. These are logic or configuration issues you can troubleshoot with Studio 5000 and your program file.
• Escalate to Controls Engineer — Program fault that repeats after clearing (suggests a logic error), motion faults (require drive expertise), or unusual fault codes not documented in the manual.
• Escalate to Rockwell/Integrator — Hardware failures (dead module LED, backplane power failure), firmware version mismatch, or controller-level faults that persist after power cycle.
• Safety-Related Faults — If a fault involves safety I/O or safety interlocks, do not clear it yourself. A safety fault means a condition that should prevent machine operation has been violated. Escalate to a safety engineer.