EtherNet/IP Implicit vs Explicit Messaging
Short answer
- Implicit messaging is the cyclic, time-driven exchange of I/O data on an EtherNet/IP network, while explicit messaging is a one-off request and response such as reading a parameter.
- Implicit messaging uses UDP and is connection-based, so each packet carries only data and a small header, and a lost packet is simply replaced by the next one.
- Explicit messaging uses TCP with acknowledgement and retransmission, and it fits settings, diagnostics and recipes, while control-loop data such as run commands, speed references and sensor values belongs on an implicit connection.
On an EtherNet/IP network, implicit messaging is the cyclic, time-driven exchange of I/O data that runs by itself without being asked, and explicit messaging is a one-off request and response, such as reading a parameter. Implicit uses UDP and is connection-based; explicit uses TCP. Most of the traffic that keeps a machine running is implicit.
Why are there two kinds of EtherNet/IP message?
A machine needs two different conversations with a device. The first is constant and predictable: "here are my inputs, here are your outputs, again, and again." The second is occasional and conversational: "what is your firmware revision?" or "change this drive parameter." One mechanism serves neither well. EtherNet/IP, which uses the Common Industrial Protocol (CIP), splits them.
What is implicit messaging in EtherNet/IP?
Called "implicit" because the meaning of the data is fixed when the connection is set up. The packet carries no description of what each byte means. Controller and device agreed on the layout up front, so each packet is just data and a small header. That keeps it small and fast.
- Transport. UDP, so there are no acknowledgements and no retransmission. A lost packet is simply replaced by the next one.
- Timing. Each connection has a requested packet interval (RPI), the rate at which each side sends its data. The scanner and the device both send on that schedule.
- Connection type. Often called a class 1 connection. It is opened by the scanner with a forward-open request and stays open until closed or until a timeout.
- Delivery. Produced data can go unicast to one receiver or multicast to many.
What is explicit messaging in EtherNet/IP?
Called "explicit" because every message states what it wants: a class, an instance and an attribute, plus a service such as get or set. It is a normal request and reply.
- Transport. TCP, with acknowledgement and retransmission, so the request is confirmed delivered or the sender is told it failed.
- Timing. Not periodic. It happens when a program instruction, an HMI, a configuration tool or a diagnostic asks for it.
- Connection type. Unconnected, or a connected class 3 session where a path is kept open for repeated exchanges.
- Typical uses. Reading and writing drive parameters, pulling diagnostics, configuring a device, controller-to-controller data exchange and message instructions in the PLC program.
How do implicit and explicit messaging compare?
| Feature | Implicit (I/O) | Explicit |
|---|---|---|
| Purpose | Cyclic process data | Configuration, diagnostics, occasional data |
| Transport | UDP | TCP |
| Triggered by | Timer (RPI) | Request |
| Delivery guarantee | None per packet; next one replaces it | Acknowledged, retried |
| Packet content | Raw data, layout fixed at setup | Self-describing request |
| Can be multicast | Yes | No |
| Good for | Sensors, valves, drives running state | Settings, firmware info, recipes |
When should implicit or explicit messaging be used?
If the data is needed every cycle and is part of the control loop, it belongs on an implicit connection. Run commands, speed references, sensor values and fault status all fit. If the data changes rarely or only when someone asks, use explicit. A parameter you read once at startup, or a recipe downloaded on a product change, is a good fit. Pushing a rarely-changing value through I/O messaging wastes bandwidth. Polling a fast-changing value with explicit messages is slower, less regular and tends to load the controller.
How should the RPI be set?
RPI is the setting people get wrong most. Typical values run from a few milliseconds for fast motion or high-speed I/O to a hundred milliseconds or more for slow process points, but the right figure depends on the device and the application. The aim is not "as fast as possible". It is "fast enough that the process cannot tell the difference".
- Set the RPI about as fast as the data really changes and the program really uses it, not faster.
- Remember the scan: if the controller scans slower than the RPI, extra packets arrive that the program never sees.
- Many connections at very short intervals multiply quickly. Fifty devices at a short RPI is a very different load from fifty at a relaxed one.
- Devices have a minimum RPI they can support. Ask for less and the connection will not open.
How does multicast affect switches and bandwidth?
When an input device produces data for several consumers, it can send it as multicast. A switch that does not understand multicast treats it like broadcast and floods it out every port, so devices that have nothing to do with it have to receive and discard it. On a lightly loaded network nobody notices. On a busy one, small devices with weak network stacks begin to drop out. A managed switch with IGMP snooping and a querier keeps multicast only on the ports that need it. Where possible, configure connections as unicast, which sidesteps the issue.
What are common EtherNet/IP messaging faults?
- Connection timeouts. Usually a network that dropped too many packets in a row, a duplex or cable fault, or an RPI the network or device cannot sustain.
- Duplicate IP addresses. Two devices fighting for one address produce intermittent, baffling dropouts.
- Flooded multicast. Everything works with ten devices and falls over at forty.
- Too-fast RPI. High CPU load on the controller or a slow device, shown as occasional faults rather than a dead connection.
- Wrong electronic keying or data size. The connection refuses to open, or opens with bad data layout, after a device is swapped.
What do people ask about EtherNet/IP messaging?
Is implicit messaging faster than explicit?
Per message, yes, because it is smaller and has no handshake. Its main advantage is regularity: data arrives on a schedule.
Does UDP mean the data can be lost?
A single packet can be, and it is not resent. That is acceptable because a newer packet follows. If several in a row are lost, the connection times out and raises a fault.
Can I use explicit messaging for fast control?
It is possible, but it is not designed for it. Timing varies and each request adds load. Use an I/O connection.
Do I need a managed switch?
For small networks with unicast connections, often no. For larger ones that use multicast, a managed switch is usually the safer choice.
Further reading on this site: industrial Ethernet protocols; managed vs unmanaged switches; industrial Ethernet cable; Modbus RTU vs Modbus TCP; the PLC scan cycle.
If you need help matching an Ethernet I/O module, drive option card or switch for an existing network, send us the details and we can help find an equivalent.
Need a quote on a specific part?
Request a QuoteFrequently asked questions
What is the difference between implicit and explicit messaging in EtherNet/IP?
Implicit messaging is the cyclic, time-driven exchange of I/O data that runs by itself on a schedule, using UDP and a connection opened by the scanner. Explicit messaging is a one-off request and response over TCP, where each message states a class, an instance and an attribute plus a service such as get or set. Most of the traffic that keeps a machine running is implicit.
Why does implicit messaging use UDP?
Implicit messaging uses UDP, so there are no acknowledgements and no retransmission. A lost packet is simply replaced by the next one, which is acceptable because newer data follows on the schedule. The packets stay small and fast because each carries only data and a small header. If several packets in a row are lost, the connection times out and raises a fault.
How should the RPI be set for an implicit connection?
The requested packet interval should be about as fast as the data really changes and the program really uses it, not faster. The aim is not as fast as possible but fast enough that the process cannot tell the difference. If the controller scans slower than the RPI, extra packets arrive that the program never sees, and devices have a minimum RPI they can support.
Can explicit messaging be used for fast control?
Explicit messaging is possible for fast control but is not designed for it. Timing varies and each request adds load, and polling a fast-changing value with explicit messages is slower, less regular and tends to load the controller. Data needed every cycle in the control loop belongs on an implicit I/O connection, which is also the type that can be multicast.