This article is a quick introduction to EtherNet/IP for PLC and SCADA programmers who are using it for the first time, or who want a refresher on the terminology. EtherNet/IP is the protocol behind almost every Allen-Bradley ControlLogix and CompactLogix communication path, and it is the reason a SCADA system can ask a controller for Pump_1.Speed by name instead of by register number.
We'll build the vocabulary from the top down: EtherNet/IP, then CIP, then objects, services, addressing, messaging types, and device roles. We finish with a tutorial that reads data from one ControlLogix controller into another.
What is EtherNet/IP?
EtherNet/IP is an industrial communication protocol published by ODVA (the Open DeviceNet Vendors Association). The "IP" does not stand for Internet Protocol, it stands for Industrial Protocol.
EtherNet/IP does not invent a new application language. It takes an existing one, the Common Industrial Protocol (CIP), and defines how to carry it over ordinary Ethernet and TCP/IP.
Because it runs on unmodified Ethernet, EtherNet/IP works over the same switches, cables, and VLANs as the rest of your plant network. No special media, no special NICs.
What is CIP?
CIP is a media-independent application layer. It defines what the message means, not how the bits get across the wire. Three concepts are crucial to understand the data in the CIP packet:
- Objects — everything inside a device is modeled as an object (its identity, its network interface, a tag).
- Services — the verbs you can perform on those objects (get, set, reset, read tag, write tag).
- Connections — the agreements two devices make about how data flows between them (on demand, or cyclically at a fixed rate).
Because CIP sits above the network, the same objects and services appear on every CIP network. An object read via DeviceNet reads the same over EtherNet/IP. That is the whole point of the family.
EtherNet/IP is one adaptation of CIP. Its siblings are ControlNet, DeviceNet, and CompoNet.
Objects in CIP
An object is a self-contained collection of related data and behavior inside a device. CIP sorts objects into three buckets.
Required objects
Every conformant device implements a set of required objects so that any client can interrogate any device without prior knowledge. The most common ones you'll meet:
| Object | Class code | What it holds |
|---|---|---|
| Identity | 0x01 | Vendor ID, device type, product code, revision, serial number, product name |
| Message Router | 0x02 | Routes every explicit request to the right target object |
| Assembly | 0x04 | Blocks of I/O data grouped for cyclic transfer |
| Connection Manager | 0x06 | Opens, maintains, and closes CIP connections |
| TCP/IP Interface | 0xF5 | IP address, subnet, gateway, hostname |
| Ethernet Link | 0xF6 | Link speed, duplex, interface counters |
Application objects
Application objects model the data specific to the device's function. They are defined in the CIP specification so that similar information in a device created by one manufacturer will be stored in the same format as that of another manufacturer. Examples of application objects are:
- Analog Input Point (0x0A) and Analog Output Point (0x0B)
- Discrete Input Point (0x08) and Discrete Output Point (0x09)
Vendor-specific objects
Vendor-specific objects let device vendors define custom data structures unique to their devices. Vendors typically document these objects and how EtherNet/IP clients can interact with them.
Class codes from 0x64 upward are reserved for vendors.
ControlLogix PLCs provide a great example of vendor-specific objects. EtherNet/IP itself does not provide a mechanism for reading a tag database, so ControlLogix PLCs use custom vendor objects to allow clients to query tag names and tag values:
- Symbol object (0x6B) — used to represent the controller-scoped tag information including tag name, data type, and value.
- Template object (0x6C) — the definitions of UDTs, so a client can decode a structured tag's bytes.
These two objects are why a ControlLogix PLC tag database can be viewed by EtherNet/IP clients as a list of human readable names and values as opposed to a list of numeric addresses and hard to decipher values.
Classes and Instances
All objects in EtherNet/IP are either a class or an instance. A class is a template for an instance. The class contains the definition for what data an instance will hold when an instance is created. It's very similar to classes and instances in object oriented programming languages. If your coming from a ControlLogix PLC programming environment, you can think of templates like user defined data types (UDTs) and instances like tags set to a UDT type.
- Class — the type of object. "Analog Input" is a class. Identified by a class code.
- Instance — one specific occurrence of that class. Analog input #1 and analog input #2 are two instances of the same class.
EtherNet/IP clients can query a class for information about its instances — for example, ask it to report the list of instance IDs created from it.
This is useful for EtherNet/IP clients in SCADA software that want to present a list of tags in a ControlLogix PLC to the user. In ControlLogix PLCs, the Symbol Object class (0x6B) has an instance for every tag in the controller-scoped tag table. First, SCADA EtherNet/IP clients ask the Symbol Class (0x6B) to provide a list of all instance IDs belonging to the Symbol Class (0x6B) class. Then, the client queries each instance to get the tag name, data type, and value.
Again, the Symbol Object class is a Rockwell specific vendor object and not specified by ODVA in the EtherNet/IP standard. Other PLC vendors supporting EtherNet/IP can choose to represent their tag tables a different way. That's the flexibility EtherNet/IP provides with vendor defined objects.
Attributes
An attribute is one data item inside an instance — a value, a status word, a data type, an alarm limit, a product name. Attributes are identified by a numeric attribute ID within the instance, and each object class definition dictates which attribute IDs its instances carry and what each one means.
Example Identity Object (0x01) for ControlLogix PLC
Here is an example of an address to the product name attribute stored in the identity object of a ControlLogix PLC, expanded to show several of the attributes the identity object carries and the values a real 1756-L83E controller could store in them:
| Term | Value | Meaning |
|---|---|---|
| Attribute | 1 | Vendor ID — 1 for Rockwell Automation |
| Attribute | 2 | Device Type — 0x0E for a programmable logic controller |
| Attribute | 3 | Product Code — a number specific to the model of CPU and is set by Rockwell |
| Attribute | 4 | Revision — e.g. 4.011 |
| Attribute | 5 | Status — a bit-packed word showing the controller state |
| Attribute | 6 | Serial Number — a unique hex value, e.g. 0xA3F27B10 |
| Attribute | 7 | Product Name — a short string, e.g. 1756-L83E/B |
Services: what you can do with objects
Objects hold data, but on their own they are inert. A service is the action a client requests against an object, the verb of the sentence. When an EtherNet/IP client wants to take some form of action on data held within an EtherNet/IP server, it sends a request to trigger a service (e.g. read an attribute value) along with certain parameters (which attribute value to read).
Services are like methods of an instance of a class in an object oriented programming language. They allow actions to be taken on the data within an object.
Object = the noun (data). Service = the verb (what to do with it). Path = the address (which one).
Services belong in one of three categories:
- Common services — defined by CIP and understood by every device (get an attribute, set an attribute, reset).
- Object-specific services — defined by one object class.
- Vendor-specific services — defined by device vendors for their own custom objects.
Common service codes
| Code | Service | What it does |
|---|---|---|
| 0x01 | Get_Attributes_All | Returns every attribute of an instance in one shot |
| 0x02 | Set_Attributes_All | Writes every attribute of an instance |
| 0x05 | Reset | Resets the object (and often the device) |
| 0x0A | Multiple_Service_Packet | Bundles several services into one request |
| 0x0E | Get_Attribute_Single | Returns one attribute — the workhorse read |
| 0x10 | Set_Attribute_Single | Writes one attribute — the workhorse write |
| 0x55 | Get Instance Attribute List | Browses the Symbol object to enumerate tags |
Object specific services
Several required objects in the object model have object specific services. These services are defined by a single object class and are only meaningful for that class. The table below shows a couple examples, along with the object class each service belongs to.
| Code | Service | Object class | What it does |
|---|---|---|---|
| 0x54 | Forward_Open | Connection Manager Object (0x06) | Opens a connection between devices |
| 0x4E | Forward_Close | Connection Manager Object (0x06) | Closes a connection between devices |
Vendor Specific Services
Just as device vendors can create custom classes, they can also create services specific to their devices.
ControlLogix PLCs are a great example. The Symbol Object (0x6B) and Template Object (0x6C) vendor specific classes mentioned earlier also come with object specific services. The most common object specific services for Symbol Object (0x6B) are listed below.
| Code | Service | What it does |
|---|---|---|
| 0x4C | Read Tag (Logix) | Reads a named tag value |
| 0x4D | Write Tag (Logix) | Writes a named tag value |
| 0x52 | Read Tag Fragmented (Logix) | Reads a tag value too large for a single request |
| 0x53 | Write Tag Fragmented (Logix) | Writes a tag too large for a single request |
Referencing Data
Referencing data (a class, an instance, an attribute) is done via something called a path in EtherNet/IP. A path is simply a concatenation of ID numbers that starts with the highest container to the most specific. For example, if attempting to identify the Identity object class (0x01), instance 1, product name (attribute 7), the path in human readable form is: 0x01, 1, 7.
When a path is encoded in EtherNet/IP transmissions, it's encoded using a data type definition called an EPATH, which simply defines how the ID numbers are packed and encoded into binary when transmitted over the wire to separate devices.
| Human readable path | EPATH byte breakout |
|---|---|
| Class 0x01, Instance 1, Attribute 5 | 0x20 0x01 0x24 0x01 0x30 0x05 |
| Class 0x01, Instance 1, Attribute 7 | 0x20 0x01 0x24 0x01 0x30 0x07 |
Breaking the bytes down:
0x20— Class segment, 8-bit value follows0x01— the class ID (Identity object)0x24— Instance segment, 8-bit value follows0x01— the instance number0x30— Attribute segment, 8-bit value follows0x05/0x07— the attribute ID (Status / Product name)
Messaging
CIP allows for two very different types of messaging, explicit and implicit messaging.
Explicit Messaging
Everytime an EtherNet/IP client wants something from an EtherNet/IP server, it sends an explicit message. The request includes a service code (what the server should do), a path (what data the server should execute the service on), and other parameters specific to the service. It is transmitted via TCP, so if the transmission packet is lost on the wire somewhere, the network hardware is guaranteed to attempt retransmitting or notifying the client of a transmission failure. While this is a very reliable way to provide on demand information to the client, it has a lot of overhead and is less efficient than implicit messaging.
Implicit Messaging
When an EtherNet/IP device needs data at frequent periodic intervals, implicit messaging is the better alternative. A typical use case is sending I/O point values from a remote I/O chassis to a PLC several times a second. Implicit messaging uses a "producer/consumer" model, which can be thought of like a subscription type model: a consuming device notifies a producing device that it would like data X, Y, Z sent every # ms, and the producer sends it as requested.
Rather than TCP, implicit messaging uses UDP, so the network does not spend time ensuring every packet arrives — if one is dropped, a newer packet arrives a few milliseconds later anyway.
With implicit messaging, a single message is sent from producer to consumer each time data is needed, rather than with explicit messaging where a request is always sent before the response. This effectively cuts network overhead in half.
| Explicit | Implicit | |
|---|---|---|
| Transport | TCP | UDP |
| Pattern | Request / response | Cyclic producer / consumer |
| Packet contents | Service + path + data | Data only |
| Typical rate | 100 ms – seconds | 5 – 20 ms |
| Typical use | SCADA polling, MSG instructions, configuration | Remote I/O, drives, safety |
Types of EtherNet/IP devices
A device is classified by the roles it can perform. Many devices perform several at once — a ControlLogix PLC does all four.
| Role | What it does | Typical example |
|---|---|---|
| Scanner | Originates implicit connections to cyclically exchange data with Adapters. | ControlLogix PLC gathering data from remote I/O chassis |
| Adapter | Receives implicit connections from scanners and sends data cyclically to scanners. | Remote I/O chassis and motor drives |
| Client | Originates explicit requests to interact with a server's data | SCADA/HMI, MSG instruction block in ControlLogix PLC |
| Server | Responds to explicit requests send from clients | ControlLogix controller, SimServe |
For a SCADA programmer, the pairing that matters is the bottom two: your SCADA is the EtherNet/IP client, and the controller is the EtherNet/IP server.
Where SimServe fits
Usually there isn't a second ControlLogix sitting on the bench, and the SCADA work still has to happen.
SimServe acts as the ControlLogix PLC. It presents a simulated PLC on the network — Identity object, Symbol object, tag names, data types, and live values — so an explicit message client can read and write it exactly as it would a real controller. Point your SCADA (or a MSG instruction from a real PLC) at SimServe's IP address, browse or type the tag names, and you get real EtherNet/IP responses with no controller, no chassis, and no rack of I/O.
That means tag databases, alarm logic, HMI screens, and historian configuration can all be built and validated before the panel ships — and re-validated any time you change something, without borrowing production hardware.