May 16, 2026 · Guide

EtherNet/IP and CIP Protocol Explained: Complete Guide

If you work with Allen-Bradley PLCs, you are already using EtherNet/IP whether you think about it or not. Every ControlLogix and CompactLogix controller on your network speaks it. Every PanelView HMI, every PowerFlex drive, every Point I/O module. It is the backbone of Rockwell Automation's ecosystem and one of the most widely deployed industrial protocols in the world.

But EtherNet/IP is poorly understood outside the Rockwell ecosystem. The name causes confusion ("is this about assigning an Ethernet IP address?"). The relationship between EtherNet/IP and CIP is unclear to many engineers. And the protocol internals are buried in ODVA specification documents that cost money and read like legal contracts.

This guide explains EtherNet/IP and CIP from the ground up: what each layer does, how messaging works, how to read and write tags, and how it compares to Modbus TCP and OPC UA. For a practical walkthrough of connecting to Allen-Bradley PLCs on macOS, see our guide to EtherNet/IP Explorer for macOS.

What EtherNet/IP Is (and Is Not)

First, the naming. EtherNet/IP stands for Ethernet Industrial Protocol. The "IP" does not refer to Internet Protocol or an IP address. It is an acronym within an acronym, which is part of why the protocol is so frequently misunderstood.

EtherNet/IP is an industrial application-layer protocol that runs on top of standard Ethernet and TCP/IP. It uses the same cables, switches, and network interface cards as your office network. What it adds is a structured way for industrial devices to exchange control data, configuration, and diagnostics in real time.

The protocol is managed by ODVA (Open DeviceNet Vendors Association) and is an open standard. Any manufacturer can implement it. In practice, the Rockwell Automation / Allen-Bradley ecosystem is where you will encounter it most often.

What Is CIP (Common Industrial Protocol)

CIP is the application-layer protocol that sits on top of EtherNet/IP. It defines how industrial devices represent data, how they exchange messages, and how they describe their capabilities. CIP was originally developed by Rockwell Automation and is now maintained by ODVA as an open standard.

CIP is transport-independent. The same CIP application layer runs over multiple networks:

• EtherNet/IP — CIP over TCP (port 44818) and UDP (port 2222) on standard Ethernet
• DeviceNet — CIP over CAN bus (used for sensor-level device networks)
• ControlNet — CIP over a deterministic token-passing network (largely legacy)
• CompoNet — CIP over a high-speed sensor/actuator network

This means that a CIP-compatible tool can talk to devices on any of these networks, provided it has the right transport adapter. For a broader look at how these fit into the industrial networking landscape, see our industrial protocol comparison guide.

CIP Architecture: Object Model

CIP organizes device functionality into objects. Each object represents a specific aspect of a device, and objects contain attributes (data), services (methods you can call), and behaviors (how the object responds to events).

Every CIP device implements a set of mandatory and optional objects. The key device profiles are:

Identity Object (Class 0x01)

The Identity object is mandatory for every CIP device. It provides basic device information: vendor ID, device type, product code, firmware revision, serial number, and product name. When you browse a device and see "1756-L83E, Firmware 35.11", that data comes from the Identity object attributes.

Assembly Object (Class 0x04)

Assembly objects define data structures for I/O exchange. An input assembly groups input data that the device produces. An output assembly groups output data that the device consumes. When you configure a cyclic I/O connection, you are specifying which assembly instances to exchange.

Connection Manager (Class 0x06)

The Connection Manager handles the creation and management of CIP connections. When you open an explicit message session or establish a cyclic I/O connection, the Connection Manager processes the request, allocates resources, and manages the connection lifecycle.

Message Router (Class 0x02)

The Message Router receives incoming explicit messages and routes them to the appropriate object class. It is the dispatcher that ensures a request to read a tag attribute reaches the right object instance.

Explicit Messaging vs Implicit Messaging

CIP defines two fundamental messaging types. Understanding the difference is essential to understanding how EtherNet/IP works.

Explicit Messaging (UCMM)

Explicit messaging is request-response. You send a structured CIP request specifying exactly what you want (read this attribute, write that value, call this service) and you get a response back. It uses TCP port 44818.

Explicit messaging is used for:

• Reading and writing tag values on a Logix controller
• Browsing the tag database
• Reading device identity and diagnostics
• Configuration and setup operations

Because each request carries the full object path, attribute ID, and service code, explicit messaging has higher per-message overhead. It is not designed for high-speed cyclic data exchange.

Implicit Messaging (I/O Data)

Implicit messaging is connection-oriented and cyclic. Once a connection is established, data is exchanged at a configured rate (the Requested Packet Interval, or RPI) without per-message addressing overhead. The meaning of each byte is "implied" by the connection configuration. It uses UDP port 2222.

Implicit messaging is used for:

• Real-time I/O data exchange between PLCs and remote I/O
• Drive control (speed reference, start/stop commands)
• Safety I/O data exchange
• Any time-critical data that must update at a deterministic rate

The tradeoff is clear: explicit messaging is flexible but slower. Implicit messaging is fast but requires pre-configuration. Most EtherNet/IP deployments use both simultaneously.

ENIP Encapsulation Protocol

Before you can send CIP messages over EtherNet/IP, you need to understand the encapsulation layer. EtherNet/IP wraps CIP messages inside an encapsulation header that handles session management.

Session Registration

Communication with an EtherNet/IP device begins with session registration:

1. Register Session. Send a RegisterSession request to TCP port 44818. The device responds with a session handle (a 32-bit identifier).
2. Send Forward Open. Use the session handle to send CIP requests. For implicit messaging, you send a ForwardOpen request through the Connection Manager to establish a cyclic connection.
3. Exchange Data. Read/write tags via explicit CIP services, or exchange I/O data via the open connection.
4. Unregister Session. Close the session when done to release device resources.

Encapsulation Header Structure

Every ENIP packet starts with a 24-byte encapsulation header:

• Command (2 bytes) — the operation: 0x0065 (RegisterSession), 0x006F (SendRRData), 0x0070 (SendUnitData)
• Length (2 bytes) — payload length in bytes
• Session Handle (4 bytes) — assigned by the device during registration
• Status (4 bytes) — 0 for success
• Sender Context (8 bytes) — echo field for request-response matching
• Options (4 bytes) — reserved, set to 0

After the header comes the CIP payload. For explicit messaging (SendRRData), the payload includes the CIP request with service code, object path, and data. For implicit messaging (SendUnitData), the payload is raw I/O data whose format is defined by the connection.

CIP Data Types

CIP defines a set of atomic and structured data types. If you have programmed a ControlLogix or CompactLogix PLC in Studio 5000, these will look familiar. They are the data types behind every tag.

• BOOL (1 byte) — Boolean, 0 or 1. Stored as a byte despite representing a single bit.
• SINT (1 byte) — Signed 8-bit integer. Range: -128 to 127.
• INT (2 bytes) — Signed 16-bit integer. Range: -32,768 to 32,767.
• DINT (4 bytes) — Signed 32-bit integer. Range: -2,147,483,648 to 2,147,483,647. This is the default integer type in Logix controllers.
• LINT (8 bytes) — Signed 64-bit integer.
• REAL (4 bytes) — IEEE 754 single-precision floating point.
• LREAL (8 bytes) — IEEE 754 double-precision floating point.
• STRING — Structure containing DINT length followed by USINT characters. Logix controllers use an 82-byte string type (4-byte length + 82 bytes of character data by default).

Beyond atomic types, CIP supports arrays (fixed-size collections of a single type), structures (user-defined composites, similar to C structs), and strings as structures. A tag like Motor[5].Speed is an array of structures, where each structure contains members accessed by name.

Tag-Based Addressing vs Register-Based

This is one of the most significant differences between EtherNet/IP and Modbus TCP, and it affects how you interact with devices at every level.

Modbus TCP uses register-based addressing. You read holding register 40001. You write to coil 17. The address is a number, and you need a register map document to know what data lives at what address. If the vendor changes the register layout in a firmware update, your application breaks.

EtherNet/IP uses tag-based addressing. You read the tag named Motor1.Speed. You write to Conveyor.Start. Tags have names, types, and are self-describing. The PLC publishes its tag database, and your tool can browse it dynamically.

The advantages of tag-based addressing:

• Self-documenting. TankLevel is more meaningful than register 40103.
• Type-safe. The tag carries its data type. You know Motor1.Speed is a REAL without a separate mapping document.
• Resilient to firmware changes. Tag names persist across firmware updates even if internal register assignments change.
• Structured. User-defined types group related data. Motor1 might contain .Speed, .Current, .Running, and .Fault as a single structure.

The tradeoff is protocol complexity. Resolving a tag name to its memory address requires multiple CIP requests, which makes EtherNet/IP more complex to implement than Modbus TCP. But from a user perspective, tag-based addressing is far more productive.

Allen-Bradley / Rockwell Automation Ecosystem

EtherNet/IP is an open standard, but the Allen-Bradley product line is where most engineers encounter it. Understanding the controller families helps you know what to expect on a project site.

ControlLogix (1756 series)

The flagship PLC platform. Rack-based with interchangeable I/O modules, communication modules, and power supplies. The 1756-L8x controllers are the current generation. ControlLogix supports full tag browsing, user-defined types, structured exception handling, and motion control. This is what you find in large plants, automotive lines, and process industries.

CompactLogix (1769 and 5380/5480 series)

The mid-range platform. Standalone controllers with built-in I/O or expansion I/O on the right side. The 5380 series (e.g., 5069-L306ER) is the current generation. CompactLogix runs the same Logix operating system as ControlLogix with some memory and module count limitations. It is the most common Allen-Bradley controller in small-to-medium applications.

Micro800 (Micro850, Micro870)

The compact controller line for simple machine control. These also support EtherNet/IP but with a more limited CIP implementation. Tag browsing may not work the same way as on Logix controllers, and the tag database structure differs.

All three families use the same EtherNet/IP protocol on the wire. A tool that can read tags from a ControlLogix L83E can also read tags from a CompactLogix 5069-L306ER using the same CIP services.

EtherNet/IP vs Modbus TCP vs OPC UA

These are the three most common industrial Ethernet protocols. They serve different purposes and are not mutually exclusive. For a deeper analysis, see our full industrial protocol comparison.

How to Browse and Read CIP Tags on macOS

Historically, interacting with Allen-Bradley PLCs required RSLinx or FactoryTalk Linx on Windows. These proprietary tools managed the EtherNet/IP driver and tag browsing. If you were on macOS or Linux, you had no official option.

That has changed. The EtherNet/IP specification is publicly documented, and several tools now implement the protocol without requiring Rockwell software. The process on any platform follows the same steps:

1. Discover the PLC. EtherNet/IP devices respond to a ListIdentity broadcast on UDP port 44818. Send the broadcast and you get back vendor ID, device type, product name, firmware revision, serial number, and IP address.
2. Register a session. Connect to the PLC on TCP port 44818 and send a RegisterSession command. The PLC returns a session handle.
3. Browse the tag database. Send CIP requests to the Logix tag object (class 0x6B for controller tags) to enumerate all tags, their types, and their sizes.
4. Read tags. Send a CIP Read Tag Service (0x4C) request with the tag's symbolic path and element count. The PLC returns the raw data.
5. Write tags. Send a CIP Write Tag Service (0x4D) request with the tag path, data type, and new value.

MacTools EtherNet/IP Explorer implements all of this natively. You enter the PLC IP address, click connect, and the tool handles session registration, tag browsing, and formatted read/write operations. It decodes CIP data types automatically, so a DINT displays as an integer, a REAL as a float, and a STRING as readable text. No RSLinx, no Windows virtual machine.

Frequently Asked Questions

Is EtherNet/IP the same as standard Ethernet?

No. EtherNet/IP (Ethernet Industrial Protocol) is an industrial application-layer protocol that runs on top of standard Ethernet and TCP/IP. It uses standard Ethernet hardware (switches, cables, NICs) but adds the CIP application layer for industrial automation. Standard Ethernet is the transport; EtherNet/IP is what your PLCs and drives use to exchange real-time control data over that transport.

What is the difference between EtherNet/IP and CIP?

CIP (Common Industrial Protocol) is the application layer that defines how devices exchange data, including object models, messaging types, and device profiles. EtherNet/IP is one transport that carries CIP messages over TCP and UDP. The same CIP application layer also runs over DeviceNet (CAN bus) and ControlNet. Think of CIP as the language and EtherNet/IP as one of the network types that carries it.

Can you read Allen-Bradley tags over EtherNet/IP without RSLinx?

Yes. Allen-Bradley Logix-series PLCs expose tags through the CIP protocol over EtherNet/IP. Any tool that implements the ENIP encapsulation protocol and CIP tag services can read and write controller tags directly. MacTools EtherNet/IP Explorer does this natively on macOS without RSLinx, FactoryTalk, or any Windows software. You connect to the PLC IP address, browse the tag database, and read or write values.

How does EtherNet/IP differ from Modbus TCP?

Modbus TCP uses a simple register-based model where you read and write numbered addresses (e.g., holding register 40001). EtherNet/IP uses tag-based addressing where you reference named variables (e.g., Motor1.Speed). EtherNet/IP also supports both explicit request-response messaging and implicit cyclic I/O data exchange, while Modbus TCP is purely request-response. EtherNet/IP carries more protocol overhead but provides self-describing data and structured types.

Further Reading

• EtherNet/IP Explorer for macOS: Connect to Allen-Bradley PLCs Without RSLinx
• Industrial Protocol Comparison: Modbus, OPC-UA, EtherNet/IP, and More
• Modbus TCP vs OPC-UA: What System Integrators Actually Need to Know
• SCADA for Siemens S7 and Allen-Bradley: Multi-Protocol Monitoring