Does CIP Extended Status 16#0005 “Bad Class” always indicate a firmware problem with the target device, or can Studio 5000 generate this error for a device that is functioning correctly? The error is almost never a device fault — it is generated by the controller or by FactoryTalk when the EtherNet/IP connection request targets a CIP Object Class that does not exist in the firmware of the device being addressed. The most common scenario is a MSG instruction whose CIP path was copied from one device type to another: the path contains a Class ID that existed in the source device but is not present in the target device. This guide covers the EtherNet/IP connection error 16#0005 bad class for FactoryTalk and Studio 5000, comparing the four root causes against the related 16#0001 error so you can direct the fix without trial-and-error.
- What CIP Error 16#0005 “Bad Class” Means in the CIP Object Model
- Four Scenarios That Generate 16#0005 with Root Cause
- Scenario 1: MSG Instruction with Incorrect CIP Class ID
- Scenario 2: FactoryTalk View Tag Targeting a Non-Existent CIP Object
- Scenario 3: Device Firmware Too Old to Support the Requested Class
- Cause 4: HSP / Add-On Profile Version Mismatch
- Common CIP Class IDs for Rockwell Devices
- Technical Validation
- Frequently Asked Questions
What CIP Error 16#0005 “Bad Class” Means in the CIP Object Model
The Common Industrial Protocol (CIP) uses an object model where each device is composed of objects identified by a Class ID. When a connection request or explicit message targets a specific Class ID, the device looks up that Class ID in its internal object dictionary. If the Class ID does not exist in the device’s firmware, the device returns CIP General Status code 16#0005 “Path Segment Error — Bad Class.”
The error code 16#0005 is a CIP response code, not a controller fault code. It appears in Studio 5000 when a MSG instruction returns an error, and in FactoryTalk communication diagnostics when an I/O connection is rejected.
The full error path in Studio 5000 when a MSG instruction fails with 16#0005: – MSG instruction Err bit = 1 – Message Error Code (in the MSG configuration’s .ERR attribute): 16#0005 – Extended Error: sometimes provided, specifying which path segment failed
Four Scenarios That Generate 16#0005 with Root Cause
| Scenario | Where the Error Appears | Root Cause | Fix |
|---|---|---|---|
| MSG instruction with wrong Class ID | MSG .ERR = 16#0005 | CIP path copied from different device type | Correct Class ID in MSG path |
| FactoryTalk View tag pointing to wrong device type | FactoryTalk communication error log | Tag was configured for a different controller model | Update tag path to match device type |
| Device firmware too old | MSG .ERR = 16#0005 | Class added in newer firmware not present in installed firmware | Upgrade device firmware |
| HSP / AOP version mismatch | 16#0005 on I/O connection paths to AOP-installed devices; Fault History Type 3, Code 16 | AOP version in Studio 5000 differs from device firmware; forward-open requests wrong Class ID | Match AOP version to device firmware via PCDC |
Scenario 1: MSG Instruction with Incorrect CIP Class ID
MSG instructions in Studio 5000 can be configured to send explicit CIP messages to any device on the EtherNet/IP network. A MSG instruction’s CIP path specifies: Service Code (the operation to perform), Class ID (the object class to target), Instance (the specific object instance), and Attribute (the specific attribute within the instance).
If the Class ID in the MSG path does not exist in the target device, the device returns 16#0005.
Common cause: a MSG instruction template was copied from a project that used a different device (e.g., a 1756-L71 ControlLogix controller) and applied to a different target device (e.g., a PowerFlex drive). The Class IDs for reading identity information from a ControlLogix backplane differ from the Class IDs for PowerFlex drive parameter objects.
Fix: access the MSG instruction in Studio 5000 → MSG Properties → Communication tab → verify the CIP path matches the target device type. Consult the target device’s EtherNet/IP manual for the correct Class ID for the desired service.
For context on how controller faults correlate with failed MSG instructions, see Allen-Bradley Controllogix Fault Codes Complete List Studio 5000.
Scenario 2: FactoryTalk View Tag Targeting a Non-Existent CIP Object
FactoryTalk View (SE or ME) reads tag values from controllers and devices via RSLinx Classic using CIP explicit messaging. If a FactoryTalk tag is configured to read a specific parameter from a device using a CIP path, and that path targets an object Class that does not exist in the device’s current firmware, FactoryTalk logs a 16#0005 error for that tag.
Common cause: a FactoryTalk application was upgraded from an older version that communicated with a previous device model. The new device model has different Class IDs for the same parameters.
Fix: in FactoryTalk View Studio → Communication Setup → RSLinx Classic OPC Server → identify the tag returning the 16#0005 error. Update the tag’s device path to use the Class ID documented in the current device firmware’s EtherNet/IP object mapping.
Scenario 3: Device Firmware Too Old to Support the Requested Class
Rockwell Automation adds new CIP object classes to device firmware over time. A connection or MSG instruction targeting a Class ID that was added in firmware version 2.x will fail with 16#0005 on a device running firmware version 1.x.
Diagnostic: check the device’s current firmware version (Studio 5000 → Module Properties → General → Firmware Revision for I/O modules; or controller faceplate for processors). Compare to the device documentation for the required minimum firmware version for the CIP Class being accessed.
Fix: update the device’s firmware using ControlFLASH or ControlFLASH Plus (Rockwell Automation’s firmware update tools). Firmware updates require downloading the firmware file from the Rockwell Product Compatibility and Download Center (PCDC) and applying it with the controller in PROG mode.
Cause 4: HSP / Add-On Profile Version Mismatch
When Studio 5000 generates implicit I/O connections to a device using an Add-On Profile (AOP) or Hardware Support Package (HSP), it embeds the expected CIP Object Class in the forward-open request based on the AOP version installed. If the HSP/AOP version on the engineering workstation is newer or older than the firmware in the physical device, the Class ID in the forward-open request will not match what the device accepts — generating 16#0005 “Bad Class.”
Diagnostic signature: 16#0005 appears only on I/O connection paths to devices installed via AOP/HSP (drives, remote I/O adapters, safety modules), not on MSG-instruction paths. The device firmware version and the AOP version installed in Studio 5000 differ.
Verify AOP version: 1. In Studio 5000, right-click the device in the I/O tree → Properties → General tab → note the AOP version shown. 2. Compare to the device firmware version (read from the module’s STATUS/REV attribute via a MSG instruction, or from the device’s front display if it has one). 3. Download the matching AOP from the Rockwell Automation Product Compatibility and Download Center (PCDC): search for the device catalog number, then select the AOP version that matches the installed firmware.
Fix: – If the AOP is newer than the device firmware: update the device firmware to match the AOP, or download an older AOP version that matches the current firmware. – If the AOP is older than the device firmware: update the AOP in Studio 5000. After installing the new AOP, right-click the device in the I/O tree → Change Module Definition → apply the new revision.
After AOP correction, download the project and verify the forward-open completes without 16#0005.
Common CIP Class IDs for Rockwell Devices
| CIP Class ID | Class Name | Available In |
|---|---|---|
| 0x01 | Identity Object | All CIP devices |
| 0x06 | Connection Manager | All CIP devices |
| 0xF4 | Port Object | Logix5000 V21+ |
| 0x6B | ControlLogix CPU Time Sync Object | 1756-L7x, 1756-L8x |
| 0x64 | Parameter Object | PowerFlex drives with CIP |
| 0x93 | PCCC Object | Logix5000 (for legacy PCCC communication) |
| 0x67 | Acknowledge Handler | Motion devices |
Class IDs not listed in the target device’s EtherNet/IP Implementation documentation will generate 16#0005. For EtherNet/IP connection timeout troubleshooting that may accompany 16#0005 errors during connection establishment, see Allen-Bradley Ethernet/Ip Connection Timeout Fault Controllogix Fix.
16#0005 vs 16#0001 — How to tell them apart:
Both CIP errors appear in the MSG .ERR field and both indicate a path problem, but the distinction directs the fix differently:
| Attribute | 16#0005 “Bad Class” | 16#0001 “Path Segment Error — Connection Failure” |
|---|---|---|
| Meaning | The Class ID in the CIP path exists as a valid CIP format but the target device does not implement that class | The path segment itself is malformed or the device at that path address is unreachable |
| Typical cause | Correct device, wrong CIP class for that device type | Device not responding at the specified IP/slot address |
| Device reachable? | Yes — device responds with 16#0005 (it processed the request and rejected it) | No (or maybe) — device either not at that address or rejects connection at transport level |
| MSG .DN bit | Never set | Never set |
| Fix direction | Correct the Class ID in the MSG path | Fix the physical address (IP, slot) or network path |
| HSP/AOP mismatch | Generates 16#0005 — AOP version mismatch causes wrong Class ID in forward-open; device is reachable but rejects the class | Does NOT generate 16#0001 — mismatch is a class content error, not a path addressing error |
If you see 16#0005, the device is physically reachable and processing CIP — the error is entirely in the content of the request. If you see 16#0001, start with physical connectivity: ping the device, verify the IP address, verify the slot number in the ControlLogix chassis.
Technical Validation
CIP error code specification and MSG instruction error handling from Rockwell Publication 1756-PM014. EtherNet/IP CIP object class implementation and connection management specifications from the Rockwell Automation EtherNet/IP Communication Modules User Manual. Industrial EtherNet/IP and CIP protocol training from Cincinnati State Workforce Development Center PLC programs.
Frequently Asked Questions
CIP error 16#0005 appears on a MSG instruction that worked correctly last month but now returns the error after a controller firmware update. What in a firmware update causes 16#0005 to suddenly appear on a previously working MSG?
A firmware update can change the Class ID assignments for certain CIP objects, or can remove deprecated classes that were present in older firmware. If a MSG instruction targeted a Class ID that was removed or renumbered in the new firmware, the instruction that worked in the old firmware returns 16#0005 in the new firmware. Check the device’s firmware release notes (available in the Rockwell Knowledgebase) for any CIP object changes between the previous and current firmware version. Update the MSG Class ID to the value documented in the new firmware’s EtherNet/IP implementation guide.
Is 16#0005 a recoverable error for the MSG instruction, or does it require the controller to go offline to fix?
CIP error 16#0005 on a MSG instruction is fully recoverable without taking the controller offline. The MSG .ERR bit stays set until the error condition is resolved, but the controller continues running. Fix the CIP path in the MSG instruction while the controller is online (Studio 5000 supports online editing of MSG instruction parameters), then toggle the MSG enable bit (EN) to reset the instruction and retry the message with the corrected path. No fault clearance, mode change, or download is required.
Can 16#0005 appear on an implicit I/O connection rather than a MSG instruction? The Fault History shows Type 3, Code 16 at the same time as 16#0005.
Yes. Implicit I/O connections (standard I/O modules on EtherNet/IP) can generate 16#0005 if the I/O module’s HSP (Hardware Support Package or Add-On Profile) installed in Studio 5000 does not match the module’s actual firmware. The Type 3, Code 16 in the Fault History is the I/O connection failure; the 16#0005 is the CIP extended status returned by the I/O module when Studio 5000 attempts to connect using a connection class that the module firmware does not support. Fix: verify the I/O module’s installed firmware matches the HSP/AOP version in Studio 5000 (Tools → Product Compatibility and Download Center). Update either the module firmware or the HSP to achieve matching versions before the next connection attempt.