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

EtherNet/IP runs CIP, the Common Industrial Protocol, over standard Ethernet, and most plant network problems on it are not bandwidth problems. A modern switch has bandwidth to spare. They are connection problems, and connections behave nothing like bandwidth. This page explains the two kinds of CIP traffic, what a Requested Packet Interval really costs, how connections time out and run out, and why multicast on the wrong switch takes a plant network down.

It belongs to Networks in the Rockwell Automation cluster.

Two kinds of EtherNet/IP CIP 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.

	Implicit (I/O)	Explicit (messaging)
Transport	UDP, unicast or multicast	TCP, point to point
Trigger	Cyclic, at the RPI	A request from a client
Payload	Data only; its meaning is agreed when the connection opens	Service, address and data in every message
Typical users	I/O, produced and consumed tags, drives, motion, safety	HMI, MSG instructions, uploads, downloads, diagnostics
When the network is busy	Packets missed, connection times out, I/O fault	Responses slow down

The rows come from Rockwell’s network devices manual, and the last one is the one that matters. 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.

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 RPI also sets how quickly a connection gives up. Rockwell documents the implicit timeout as the RPI multiplied by a controller-selected multiplier, chosen so that the timeout is at least 100 ms, with a minimum multiplier of four. Its own examples: at a 2 ms RPI the multiplier is 64 and the timeout 128 ms; at 10 ms the multiplier is 16 and the timeout 160 ms. Either way, a burst of congestion lasting a fraction of a second is enough to fault a connection.

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 numbers are in each product’s user manual and they differ by product and revision, so we do not quote them here.

Consumer	How it uses connections	Design lever
I/O modules and racks	One or more per module or rack, at its RPI	Rack-optimised connections where supported; sensible RPIs
Networked drives and motion axes	One per device, and motion is time-critical	Keep motion on its own well-designed segment
Produced and consumed tags	One connection for each consumer of each produced tag	Group data into fewer tags; count consumers
MSG instructions	A cached message keeps its connection open; an uncached one closes it when done (1756-PM012)	Cache frequent messages, do not cache occasional ones
HMI, SCADA and historian clients	Connections through their communication server	Share one server; avoid each client connecting directly
Engineering workstations	Connections whenever someone goes online	Leave headroom; they always arrive

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. The Ethernet design manual adds a limit that is easy to miss: an adapter uses a multicast address for each I/O connection, a controller uses one for each produced tag, and the multicast address limit of a device is separate from its connection limit.

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. Where a connection has only one consumer, configuring it as unicast, where the device and software allow, removes the multicast entirely.

Practical EtherNet/IP and CIP 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. A drive that keeps reporting communication loss is usually one of them; the PowerFlex fault codes page covers how to tell. When the pattern is plant-wide, an OT network assessment finds it faster than module swaps.

---

Related: Stratix Switches and Network Segmentation · Networks and Communications · Rockwell Automation hub