EtherNet/IP I/O connections, RPI and typical problems
How implicit connections work: assemblies, RPI, connection types, multicast and the timeout rules — and what usually goes wrong.
An I/O connection
The scanner opens a connection with a Forward_Open request (explicit message) that specifies:
- assembly instances for output (O→T), input (T→O) and configuration data and their sizes;
- RPI (Requested Packet Interval) — how often each side sends its data, e.g. 10 ms;
- transport (unicast or multicast for T→O) and connection type.
After that both sides send UDP packets every RPI without requests.
Connection types
| Type | Meaning |
|---|---|
| Exclusive Owner | Controls the outputs; only one per output assembly |
| Input Only | Receives inputs, no outputs; several controllers can listen |
| Listen Only | Receives inputs only while an owner connection exists |
Timeout
If a side receives no packet for RPI × timeout multiplier (commonly ×4), the connection times out: outputs go to their configured fault state and the scanner reports the device as faulted. Choose RPI from the process need, not "as fast as possible" — every connection consumes packets per second in the adapter and switches.
Multicast
T→O data is often multicast so that several scanners can listen. Without IGMP snooping (and a querier) on the switches, multicast floods every port of the VLAN and can overload small devices. Many recent devices default to unicast for this reason.
Typical problems
| Symptom | Cause |
|---|---|
| Connection error at startup | Wrong assembly numbers or sizes in a generic module, wrong IP, EDS revision mismatch |
| Sporadic timeouts | Network load, multicast flooding, RPI too short for the device, duplex mismatch |
| Device shows "owned" by another controller | A second Exclusive Owner connection attempt |
| Data arrives but values are wrong | Byte order or data type of the assembly misunderstood — compare with the device manual |
Connections
Open in Knowledge Graph →Loading the map…
Sources
Updated 2026-10-02