EtherNet/IP and CIP messaging: explicit vs implicit, RPI, and assemblies

EtherNet/IP is standard Ethernet carrying the Common Industrial Protocol (CIP) — the same object model as DeviceNet and ControlNet. Devices expose objects with attributes (a drive's speed reference, a sensor's status word), and everything you do on the network is reading or writing those attributes. The confusion starts with the two messaging styles, which behave nothing alike.

Implicit messaging: I/O over UDP

Implicit (I/O) messaging moves real-time data over UDP multicast or unicast on a fixed schedule. Producer and consumer agree on an I/O assembly — a packed structure of inputs and outputs — and exchange it every Requested Packet Interval (RPI). There is no per-message addressing overhead because the connection setup already defined what moves. This is how a PLC owns remote I/O, talks to drives, and exchanges produced/consumed tags with other controllers.

The RPI is a design choice, not a race: 5–20 ms suits most I/O and drives, and faster rates multiply switch and controller load. Count connections per controller and per switch — connection limits, not bandwidth, are usually what runs out first.

Explicit messaging: requests over TCP

Explicit messaging is request/response over TCP (port 44818): read this attribute, write that one, upload a recipe, pull diagnostics. MSG instructions, HMI reads, and engineering tools all use explicit messaging. It is flexible and routable but not scheduled — latency varies with load, so never put closed-loop control through MSG instructions.

A useful mental model: implicit is the nervous system (fast, cyclic, fixed), explicit is the postal service (flexible, addressed, variable latency).

Assemblies, EDS files, and connection sizing

Each device's EDS file documents its assemblies and objects — which instance numbers carry inputs, outputs, and configuration. Match the EDS revision to firmware, or the assembly sizes in your project will not match the device and the connection will fault with an unhelpfully generic code.

When sizing a cell, budget three things: controller connection count (I/O plus produced/consumed plus HMI/MSG overhead), switch multicast load (use IGMP snooping so I/O multicast does not flood every port), and the RPI aggregate — many fast connections on one controller eventually show up as CPU load and jitter.

Practical rules

• Prefer DLR (Device Level Ring) or star topologies with managed, CIP-aware switches; unmanaged daisy chains hide faults and complicate diagnostics.
• Give every device a persistent IP (static or DHCP reservation) and document it — BOOTP roulette after a power outage is avoidable.
• Separate safety (CIP Safety) traffic design from standard I/O even though they share the wire; safety connection timing has its own validation.
• On comms loss, define per-device behavior: fault the controller, hold last state, or drive outputs to a safe preset. The default is rarely what the process wants.

References

• ODVA: EtherNet/IP and CIP technology — specifications and conformance
• EDS file, Requested Packet Interval, and produced/consumed tags — Shopfloor glossary
• Choosing industrial network topology — designing the Ethernet underneath