Every CIP device — whether it is an Allen-Bradley PLC, a variable frequency drive, a remote I/O module, or a safety controller — organizes its data using the same object model. Understanding this model is the key to configuring, programming, and troubleshooting any CIP-based device.
CIP (Common Industrial Protocol) does not use register maps like Modbus. Instead, it uses an object-oriented structure where every piece of data belongs to a Class, an Instance of that class, and an Attribute of that instance. You access data by sending a Service request that specifies the Class, Instance, and Attribute.
This guide explains the CIP object model from the ground up: how classes, instances, and attributes work, what the standard CIP objects are, how services and connections function, and what the error codes mean when something goes wrong.
Table of Contents
1. What Is the CIP Object Model
CIP models every device as a collection of objects. An object is a structured container that holds data (attributes) and supports operations (services).
This is fundamentally different from Modbus, where all data lives in flat register tables. In CIP, data is organized hierarchically:
Device → Object Class → Instance → Attribute
Every CIP device, regardless of vendor, uses this same structure. A Rockwell Automation CompactLogix PLC and a third-party VFD both expose their data through CIP objects with the same class codes, service codes, and addressing rules.
2. Classes, Instances, and Attributes
Class
A class is a template that defines a type of object. Each class has a unique Class ID (a numeric code). CIP defines many standard classes, and vendors can add their own.
Examples:
| Class ID (hex) | Name | Purpose |
|---|---|---|
| 0x01 | Identity | Device identification (vendor, product, serial number) |
| 0x02 | Message Router | Routes explicit messages to the correct object |
| 0x04 | Assembly | Groups I/O data into assemblies for implicit messaging |
| 0x05 | Connection | Manages communication connections |
| 0x06 | Connection Manager | Creates, manages, and tears down connections (Forward Open/Close) |
| 0xF5 | TCP/IP Interface | IP address, subnet mask, gateway (EtherNet/IP only) |
| 0xF6 | Ethernet Link | Link speed, duplex, MAC address (EtherNet/IP only) |
Instance
An instance is a specific occurrence of a class. Instance 0 is the class level (class attributes). Instance 1, 2, 3, etc. are individual object instances.
For example, a device with two Ethernet ports has:
- Ethernet Link Object, Instance 1 → port 1
- Ethernet Link Object, Instance 2 → port 2
Attribute
An attribute is a single data element within an instance. Each attribute has an Attribute ID (a numeric code).
For example, the Identity Object (Class 0x01), Instance 1 has:
| Attribute ID | Name | Data Type | Description |
|---|---|---|---|
| 1 | Vendor ID | UINT | ODVA-assigned vendor identifier |
| 2 | Device Type | UINT | Device type code |
| 3 | Product Code | UINT | Vendor-specific product code |
| 4 | Revision | Struct (USINT.USINT) | Major.Minor revision |
| 5 | Status | WORD | Device status bits |
| 6 | Serial Number | UDINT | Unique serial number |
| 7 | Product Name | SHORT_STRING | Human-readable product name |
3. How CIP Addressing Works: The EPATH
Every CIP message includes a path that tells the device where to deliver the request. This path is called an EPATH (Electronic Path) and is encoded as a sequence of segments.
The most common segment types:
| Segment | Format | Example |
|---|---|---|
| Class ID | 8-bit or 16-bit logical | Class 0x01 (Identity) |
| Instance ID | 8-bit or 16-bit logical | Instance 1 |
| Attribute ID | 8-bit or 16-bit logical | Attribute 7 (Product Name) |
| Port / Link | Port segment | Backplane port 1, slot 3 |
| Symbolic | ASCII string | Tag name (Logix-specific) |
A typical EPATH for reading the Product Name from the Identity Object:
Class 0x01 → Instance 1 → Attribute 7For Logix controllers, tags are addressed using symbolic segments — the tag name is sent as an ASCII string in the EPATH.
4. CIP Services: How Devices Exchange Data
A service is an operation you perform on an object. Every CIP message contains a service code that tells the target object what to do.
The general message format:
| Field | Description |
|---|---|
| Service Code | What operation to perform (1 byte) |
| Request Path | EPATH — which Class/Instance/Attribute to target |
| Request Data | Service-specific data (e.g., the value to write) |
The response format:
| Field | Description |
|---|---|
| Reply Service Code | Original service code with bit 7 set (0x80 OR’d) |
| General Status | Success (0x00) or an error code |
| Extended Status | Additional error detail (if any) |
| Response Data | The requested data (for reads) |
5. Common CIP Service Codes
| Code (hex) | Name | Description |
|---|---|---|
| 0x01 | Get_Attributes_All | Read all attributes of an instance |
| 0x02 | Set_Attributes_All | Write all attributes of an instance |
| 0x03 | Get_Attribute_List | Read specific attributes by ID |
| 0x04 | Set_Attribute_List | Write specific attributes by ID |
| 0x05 | Reset | Reset the object or device |
| 0x08 | Create | Create a new object instance |
| 0x09 | Delete | Delete an object instance |
| 0x0D | Apply_Attributes | Apply configuration to a connection |
| 0x0E | Get_Attribute_Single | Read one specific attribute |
| 0x10 | Set_Attribute_Single | Write one specific attribute |
| 0x11 | Find_Next_Object_Instance | Search for instances |
| 0x4B | Read_Tag_Service | Read a tag value (Logix-specific) |
| 0x4C | Read_Tag_Fragmented_Service | Read a large tag in fragments |
| 0x4D | Write_Tag_Service | Write a tag value (Logix-specific) |
| 0x4E | Write_Tag_Fragmented_Service | Write a large tag in fragments |
| 0x52 | Read_Modify_Write_Tag | Atomic read-modify-write (Logix) |
| 0x54 | Forward_Open | Establish a CIP connection |
| 0x4E | Forward_Close | Close a CIP connection |
Services 0x4B–0x4E and 0x52 are Logix-specific — used by Allen-Bradley ControlLogix and CompactLogix controllers for tag-based access.
6. Explicit Messaging vs Implicit Messaging
CIP defines two messaging types:
| Feature | Explicit Messaging | Implicit Messaging |
|---|---|---|
| Purpose | Configuration, diagnostics, tag reads/writes | Cyclic I/O data exchange |
| Transport | TCP (EtherNet/IP port 44818) | UDP (EtherNet/IP port 2222) |
| Message content | Service code + Class/Instance/Attribute path + data | Raw I/O data only (no path) |
| Pattern | Request → Response | Producer → Consumer (continuous) |
| Connection type | Unconnected (UCMM) or connected | Always connected (Forward Open required) |
| Timing | On-demand | Cyclic at the RPI (Requested Packet Interval) |
| Use case | Read device identity, change parameters, read tags | Exchange input/output data between PLC and I/O module |
7. The Connection Manager Object (Class 0x06)
The Connection Manager is the most important CIP object for real-time communication. It creates, manages, and tears down connections between devices.
Class Code: 0x06
Key services:
| Service Code | Name | Purpose |
|---|---|---|
| 0x54 | Forward_Open | Establish a new connection |
| 0x4E | Forward_Close | Close an existing connection |
| 0x52 | Unconnected_Send | Send a message without a connection (routed through intermediary devices) |
| 0x5B | Get_Connection_Data | Read connection status information |
8. Forward Open and Forward Close
Forward Open (Service 0x54)
The Forward_Open service establishes a CIP connection for implicit I/O data exchange. It is the single most important message in EtherNet/IP.
Key parameters in the Forward_Open request:
| Parameter | Description |
|---|---|
| Connection Serial Number | Unique identifier for this connection |
| Originator Vendor ID | Vendor ID of the requesting device |
| Originator Serial Number | Serial number of the requesting device |
| O→T Connection ID | Connection ID for Originator-to-Target data |
| T→O Connection ID | Connection ID for Target-to-Originator data |
| O→T RPI | Requested Packet Interval for O→T direction (µs) |
| T→O RPI | Requested Packet Interval for T→O direction (µs) |
| O→T Network Connection Parameters | Connection size, type (point-to-point or multicast), priority |
| T→O Network Connection Parameters | Connection size, type, priority |
| Transport Class/Trigger | Transport class (0–3) and trigger type (cyclic, change-of-state, application) |
| Connection Path | EPATH specifying the target — typically backplane/slot for I/O, or assembly instances |
Connection Path Examples
I/O connection to a module in slot 3:
Port 1 (backplane), Link Address 3 → Configuration Assembly → O→T Assembly → T→O AssemblyForward Close (Service 0x4E)
The Forward_Close service tears down an existing connection. It uses the Connection Serial Number, Vendor ID, and Originator Serial Number to identify which connection to close.
9. Transport Classes and Triggers
The Transport Class/Trigger byte in the Forward_Open defines how data flows:
| Bit | Field | Values |
|---|---|---|
| 7 | Direction | 0 = Client, 1 = Server |
| 6–4 | Production Trigger | 0 = Cyclic, 1 = Change-of-State, 2 = Application Object |
| 3–0 | Transport Class | 0, 1, 2, or 3 |
Transport Classes
| Class | Behavior |
|---|---|
| 0 | Produce-only or consume-only. No sequence counter. |
| 1 | Produce-only or consume-only. 16-bit sequence counter prepended. Duplicates detected. |
| 2 | Produce and consume. Server responds immediately (auto-reply). Sequence counter included. |
| 3 | Produce and consume. Server responds after application processes data. Sequence counter included. |
Class 0 and 1 are used for I/O connections. Class 3 is used for explicit messaging connections.
Production Triggers
| Trigger | When Data Is Produced |
|---|---|
| Cyclic | At every RPI interval (timer-based) |
| Change-of-State | When the application data changes |
| Application Object | When the application decides to produce |
10. Standard CIP Object Library
CIP defines a large library of standard objects. The most commonly used:
| Class ID (hex) | Name | Required? | Purpose |
|---|---|---|---|
| 0x01 | Identity | Required | Device identification |
| 0x02 | Message Router | Required | Routes explicit messages |
| 0x04 | Assembly | Common | Groups I/O data into assemblies |
| 0x05 | Connection | Required | Manages connection endpoints |
| 0x06 | Connection Manager | Required | Forward Open/Close, Unconnected Send |
| 0x08 | Discrete Input Point | Optional | Single digital input |
| 0x09 | Discrete Output Point | Optional | Single digital output |
| 0x0A | Analog Input Point | Optional | Single analog input |
| 0x0B | Analog Output Point | Optional | Single analog output |
| 0x0F | Parameter | Common | Device parameters (drives, sensors) |
| 0x23 | Acknowledge Handler | Optional | Acknowledges alarm messages |
| 0x29 | Discrete Input Group | Optional | Group of digital inputs |
| 0x2A | Discrete Output Group | Optional | Group of digital outputs |
| 0x2B | Discrete Group | Optional | Mixed I/O group |
| 0xF5 | TCP/IP Interface | EtherNet/IP | IP configuration |
| 0xF6 | Ethernet Link | EtherNet/IP | Link status, speed, duplex |
11. The Identity Object (Class 0x01)
Every CIP device must support the Identity Object. It provides basic identification.
Class Code: 0x01 Required: Yes, on all CIP devices
Instance Attributes
| Attr ID | Name | Data Type | Access |
|---|---|---|---|
| 1 | Vendor ID | UINT | Get |
| 2 | Device Type | UINT | Get |
| 3 | Product Code | UINT | Get |
| 4 | Revision | Struct (Major.Minor) | Get |
| 5 | Status | WORD | Get |
| 6 | Serial Number | UDINT | Get |
| 7 | Product Name | SHORT_STRING | Get |
Services
| Service | Code | Description |
|---|---|---|
| Get_Attributes_All | 0x01 | Returns all attributes in a single response |
| Reset | 0x05 | Resets the device (Type 0 = power cycle equivalent, Type 1 = return to factory defaults) |
| Get_Attribute_Single | 0x0E | Read one attribute |
Practical Use
In Wireshark, a List Identity response (EtherNet/IP encapsulation command 0x0063) returns the Identity Object data for device discovery. This is how engineering tools find devices on the network.
12. The Message Router Object (Class 0x02)
The Message Router receives all incoming explicit messages and routes them to the correct target object based on the EPATH in the request.
Class Code: 0x02 Required: Yes
Every explicit message — whether it arrives via UCMM (unconnected) or over a connected explicit messaging connection — passes through the Message Router first.
Message Router Request Format
| Field | Data Type | Description |
|---|---|---|
| Service | USINT | Service code of the request |
| Request Path Size | USINT | Number of 16-bit words in the path |
| Request Path | Padded EPATH | Class ID, Instance ID, Attribute ID |
| Request Data | Byte array | Service-specific data |
Message Router Response Format
| Field | Data Type | Description |
|---|---|---|
| Reply Service | USINT | Service code with bit 7 set |
| Reserved | Byte | Always 0 |
| General Status | USINT | Status code (0 = success) |
| Size of Additional Status | USINT | Number of 16-bit words in additional status |
| Additional Status | Array of WORD | Extended error information |
| Response Data | Byte array | Requested data |
13. The Connection Object (Class 0x05)
The Connection Object represents one endpoint of a CIP connection. When a Forward_Open succeeds, the Connection Manager creates an instance of the Connection Object.
Class Code: 0x05
Key Instance Attributes
| Attr ID | Name | Data Type | Description |
|---|---|---|---|
| 1 | State | USINT | 0=Non-existent, 1=Configuring, 3=Established, 4=Timed Out |
| 2 | Instance Type | USINT | 0=Explicit Messaging, 1=I/O, 2=CIP Bridged |
| 3 | Transport Class/Trigger | BYTE | Transport class (0–3) and trigger type |
| 7 | Produced Connection Size | UINT | Max bytes transmitted |
| 8 | Consumed Connection Size | UINT | Max bytes received |
| 9 | Expected Packet Rate | UINT | RPI in milliseconds |
| 10 | CIP Produced Connection ID | UDINT | Connection ID for outgoing data |
| 11 | CIP Consumed Connection ID | UDINT | Connection ID for incoming data |
| 12 | Watchdog Timeout Action | USINT | 0=Transition to Timed Out, 1=Auto Delete, 2=Auto Reset |
Connection States
| Value | State | Meaning |
|---|---|---|
| 0 | Non-existent | Not yet created |
| 1 | Configuring | Created, waiting for configuration |
| 3 | Established | Active, exchanging data |
| 4 | Timed Out | Inactivity/watchdog timeout occurred |
14. The Assembly Object (Class 0x04)
The Assembly Object groups multiple data points into a single block for efficient I/O transfer. Instead of reading each point individually, the PLC reads or writes an entire assembly in one implicit message.
Class Code: 0x04
Assemblies are referenced by Instance ID in the Forward_Open connection path:
- Input Assembly — data produced by the I/O device (T→O direction)
- Output Assembly — data consumed by the I/O device (O→T direction)
- Configuration Assembly — parameter data sent during connection setup
Assembly instance numbers are device-specific and documented in the device’s EDS file.
15. CIP General Status Codes
Every CIP response includes a General Status code. 0x00 means success. Anything else is an error.
| Code (hex) | Name | Meaning |
|---|---|---|
| 0x00 | Success | Service completed successfully |
| 0x01 | Connection Failure | Connection-related error (check extended status) |
| 0x02 | Resource Unavailable | Device out of memory or resources |
| 0x03 | Invalid Parameter Value | A parameter in the request is out of range |
| 0x04 | Path Segment Error | Invalid segment in the EPATH |
| 0x05 | Path Destination Unknown | Target object does not exist |
| 0x08 | Service Not Supported | The target object does not support this service |
| 0x09 | Invalid Attribute Value | Attribute value out of range |
| 0x0A | Attribute List Error | One or more attributes in a list request failed |
| 0x0C | Object State Conflict | Object is in the wrong state for this service |
| 0x0E | Attribute Not Settable | Attribute is read-only |
| 0x10 | Device State Conflict | Device is not in the right mode |
| 0x13 | Not Enough Data | Request is too short |
| 0x14 | Attribute Not Supported | Attribute ID does not exist |
| 0x15 | Too Much Data | Request is too long |
| 0x1E | Tag Not Found | Logix tag name does not exist |
| 0x20 | Invalid Parameter | Service-specific parameter error |
| 0x26 | Bridge Request Too Large | Message too large for routing path |
16. CIP Extended Status Codes for Connection Manager
When a Forward_Open fails (General Status = 0x01), the Extended Status field provides the specific reason.
| Extended Status (hex) | Meaning | Common Cause |
|---|---|---|
| 0x0100 | Connection in use or duplicate Forward Open | Connection already exists |
| 0x0103 | Transport class and trigger not supported | Device does not support the requested transport |
| 0x0106 | Ownership conflict | Another scanner already owns this connection |
| 0x0107 | Connection not found at target | Wrong connection path (backplane/slot error) |
| 0x0108 | Invalid connection type | Mismatch in connection parameters |
| 0x0109 | Invalid connection size | O→T or T→O size does not match device |
| 0x0110 | Target does not support requested RPI | RPI too short for the device |
| 0x0111 | RPI out of range | RPI value is out of the supported range |
| 0x0113 | RPI not acceptable | Connection rejected due to RPI constraints |
| 0x0116 | Invalid O→T connection size | Output assembly size mismatch |
| 0x0117 | Invalid T→O connection size | Input assembly size mismatch |
| 0x0203 | Connection timed out | Target did not respond in time |
| 0x0204 | Unconnected send timed out | Intermediate router did not forward the message |
| 0x0311 | Real time format not acceptable | Run/idle header mismatch |
| 0x0312 | No internal resources | Device cannot create more connections |
17. How CIP Maps to EtherNet/IP, DeviceNet, and ControlNet
CIP is the application layer. The network adaptation defines how CIP messages are transported.
| Feature | EtherNet/IP | DeviceNet | ControlNet |
|---|---|---|---|
| Physical layer | Ethernet (100 Mbps / 1 Gbps) | CAN bus (125–500 kbps) | Coaxial cable (5 Mbps) |
| Explicit messaging transport | TCP port 44818 | CAN Group 2 messages | Scheduled/unscheduled slots |
| Implicit I/O transport | UDP port 2222 | CAN Group 1 messages | Scheduled bandwidth |
| Connection setup | Forward_Open via Connection Manager | Predefined connections or Forward_Open | Forward_Open |
| Max nodes | Unlimited (IP-based) | 64 per segment | 99 per segment |
| Connection ID | 32-bit (UDINT) | 11-bit CAN ID | Network-allocated NCI |
CIP is the same on all networks. Only the transport changes.
18. CIP Data Types
CIP uses IEC 61131-3 compatible data types:
| CIP Type | Size | Description | Range |
|---|---|---|---|
| BOOL | 1 bit | Boolean | TRUE/FALSE |
| SINT | 1 byte | Signed 8-bit integer | -128 to +127 |
| USINT | 1 byte | Unsigned 8-bit integer | 0 to 255 |
| INT | 2 bytes | Signed 16-bit integer | -32,768 to +32,767 |
| UINT | 2 bytes | Unsigned 16-bit integer | 0 to 65,535 |
| DINT | 4 bytes | Signed 32-bit integer | -2,147,483,648 to +2,147,483,647 |
| UDINT | 4 bytes | Unsigned 32-bit integer | 0 to 4,294,967,295 |
| REAL | 4 bytes | IEEE 754 single-precision float | ±3.4 × 10³⁸ |
| LREAL | 8 bytes | IEEE 754 double-precision float | ±1.7 × 10³⁰⁸ |
| STRING | Variable | Character string | Up to 65,535 characters |
| SHORT_STRING | Variable | Short string (1-byte length prefix) | Up to 255 characters |
| WORD | 2 bytes | 16-bit bit string | Bit-level access |
| DWORD | 4 bytes | 32-bit bit string | Bit-level access |
All CIP data is encoded in little-endian byte order (least significant byte first). This is the opposite of Modbus (big-endian).
Summary
The CIP object model is the foundation of EtherNet/IP, DeviceNet, and ControlNet communication. Every device exposes its data through classes, instances, and attributes — accessed using standardized service codes.
The key concepts:
- Class → Instance → Attribute is the CIP addressing model (not register numbers)
- Services define what operation to perform (Get, Set, Forward_Open, Read_Tag)
- Explicit messaging (TCP 44818) is for configuration and diagnostics
- Implicit messaging (UDP 2222) is for cyclic I/O data
- Forward_Open (service 0x54) establishes I/O connections — it is the most important CIP message
- General Status 0x00 = success. Anything else means an error — check the code tables.
- CIP data is little-endian — the opposite of Modbus
For CIP port details, see: CIP Protocol Ports: How EtherNet/IP Uses Ports 44818 and 2222
For the full CIP architecture guide, see: What Is the CIP Protocol? Complete Guide
For Wireshark analysis, see: Wireshark for EtherNet/IP: How to Capture and Decode CIP Traffic