EtherNet/IP and CIP Explained: Implicit, Explicit and Why Connections Run Out

How CIP messaging actually works on an EtherNet/IP network: implicit versus explicit traffic, what RPI really costs, why connection limits bite, and how multicast brings down a plant network.

Most plant network problems are not bandwidth problems. A modern switch has bandwidth to spare. They are connection problems, and connections behave nothing like bandwidth.

Two kinds of traffic

Implicit messaging, also called I/O or connected messaging, is how a controller talks to I/O, drives and other controllers’ shared data. A connection is established once, both ends agree a Requested Packet Interval, and data then flows on that schedule with no request per packet. It is cyclic, it is deterministic, and it is what production depends on.

Explicit messaging is request and response: MSG instructions, configuration, diagnostics, software browsing the network. It carries the request and the addressing in every packet, and it is tolerant of delay.

The important asymmetry: explicit traffic can be delayed without harm. Implicit traffic cannot. When implicit connections miss their interval repeatedly, the connection times out, the controller logs an I/O fault, and depending on the program the machine faults. A network carrying both without separation lets the tolerant traffic break the intolerant traffic.

A network carrying both without separation lets the tolerant traffic break the intolerant traffic. That is the whole argument for segmentation.

RPI is not a performance setting

Requested Packet Interval is the rate at which a connection exchanges data. Faster is not better; faster is more expensive in a resource that is finite.

Every connection at a given RPI consumes a share of the controller’s and the network’s capacity continuously, whether or not the data changes. An I/O module at 2 ms costs five times what the same module costs at 10 ms, permanently.

The practical rule: set RPI from what the application actually needs. A safety or motion axis has a genuine requirement. A temperature transmitter does not need to be read every two milliseconds because a process value that moves over minutes cannot be observed faster than it changes. Defaults left in place across a large I/O count are a common and invisible cause of a loaded network.

Connection limits

This is the constraint most teams meet without recognising it.

A controller supports a finite number of simultaneous CIP connections. So does a communication module, and so does each device. These limits are consumed by everything: every I/O connection, every produced and consumed tag, every HMI that browses, every historian that polls, every engineering workstation that goes online.

The symptom is characteristic and misleading: the system works, then a new device or a second HMI client is added and something unrelated stops connecting. Nothing is broken. The connection budget is simply exhausted, and the newest request fails.

Budget connections during design, the way you budget I/O points. Count what the controller will hold, what each communication module will carry, and leave headroom for the engineering workstation and the second HMI client that will certainly be added later.

Multicast, and why unmanaged switches take plants down

Implicit I/O connections commonly use multicast. An unmanaged switch cannot do IGMP snooping, so it treats multicast as broadcast and floods it to every port.

On a small network this is invisible. As device count grows, every device receives traffic destined for every other device, processes it far enough to discard it, and the load rises non-linearly. Devices with modest processing capacity start missing their own connection intervals.

The failure signature: intermittent I/O connection timeouts across the network, no consistent pattern, worse as devices are added, and every individual device tests fine on the bench.

This is the most common root cause we find behind “random” controller faults, and the investigation almost always starts at the I/O module and stays there for weeks. The fix is a managed switch with IGMP snooping configured and a querier present on the network, which is where a lot of otherwise-correct installations fall down: IGMP snooping enabled with no querier is not a working configuration.

Practical design rules

Separate the traffic. Control traffic on its own segment or VLAN, business and engineering traffic elsewhere. See Stratix and segmentation
Managed switches on anything carrying implicit I/O. The cost difference is trivial against one shift of unexplained downtime
Configure IGMP snooping and confirm a querier exists
Set RPI from the application requirement, not from the default
Budget connections at design time and record the budget where the next engineer will find it
Do not bridge segments with a controller unless that is a deliberate architectural decision
Validate under production load. A network that behaves on a quiet Sunday tells you very little

When to suspect the network

If you see any of these, look at the network before the equipment:

I/O faults on multiple, unrelated devices
Faults that increase in frequency as devices are added
HMI dropouts alongside controller faults
Motion following errors with no mechanical explanation
Anything intermittent where every component tests good individually

Individually testing good is the tell. Components that pass on the bench and fail in place are describing their environment, not themselves.