What Is EtherNet/IP?

Back to Blog

CIP, Implicit and Explicit Messaging

EtherNet/IP adapts the Common Industrial Protocol to standard Ethernet. CIP is an object-oriented, media-independent application layer also used by DeviceNet and ControlNet, which means the same device profiles and object model carry across those networks. On EtherNet/IP, CIP messages travel two ways. Explicit messaging uses TCP for request/response transactions - reading a tag, changing a parameter, uploading configuration - where timing is not critical.

Implicit messaging (also called I/O messaging) uses UDP for real-time, cyclic data such as the produced/consumed I/O between a PLC and remote I/O racks or drives. UDP is used because its low overhead suits the repetitive, time-sensitive nature of control data, with connection setup and health monitoring handled by CIP. For deterministic motion, CIP Sync and CIP Motion add time synchronization on top.

EtherNet/IP in Oil and Gas SCADA

Because Allen-Bradley ControlLogix and CompactLogix processors use EtherNet/IP natively, it is extremely common on oil and gas skids, compressor packages, pump stations, and separator control panels across North America. A SCADA system typically reads controller tags over EtherNet/IP explicit messaging or through an OPC server that speaks the protocol.

For cloud SCADA, an edge gateway or driver reads the PLC's tags over EtherNet/IP locally and forwards a curated set upward over a routable, outbound connection. Merobix supports EtherNet/IP among its device protocols, so an operator running Allen-Bradley controllers can bring wellhead, compressor, or pump-station data into cloud dashboards, alarms, and a historian - polling the PLC locally and pushing data outbound, with no inbound ports opened on the site firewall.

Ports and Traffic Types on the Wire

EtherNet/IP uses a small, fixed set of well-known ports, which makes its traffic easy to recognize and easy to police:

Traffic	Transport	Port	Purpose
Explicit messaging	TCP	44818	Tag reads, configuration, diagnostics
Encapsulation discovery	UDP	44818	List Identity and device discovery
Implicit I/O	UDP	2222	Cyclic produced and consumed control data

The firewall rule that follows from the table: implicit I/O has no business crossing a zone boundary. Keep the cyclic UDP traffic inside the local control network where its timing is protected, and let only explicit, request-based reads leave - preferably originating outbound from an edge device rather than allowing anything inbound toward the controller. If a remote system needs controller data, the pattern described in connecting EtherNet/IP to cloud SCADA keeps the PLC polled locally with only an outbound connection leaving the site.

Multicast, Unicast, and the Switch Underneath

Implicit connections are established as multicast or unicast, and the choice decides what your switches must do. Multicast without IGMP snooping and a querier degenerates into flooding - every device on the segment receives every I/O packet, and small devices choke on traffic that was never meant for them. Modern practice prefers unicast connections where the devices offer the choice, and reserves multicast for topologies that genuinely need one producer feeding several consumers, running on managed switches configured for it.

When an I/O connection drops, the controller logs a connection fault and the I/O goes to its configured fault state, so treat the network as part of the machine: duplicate IP addresses, a flapping link, a saturated uplink, or an unmanaged switch quietly discarding bursts all present as intermittent connection loss. The walkthrough on diagnosing an EtherNet/IP I/O connection fault gives an ordered procedure; the short version is to establish whether the loss affects one device, one switch span, or the whole segment before touching any configuration.

Budgeting Connections and Update Rates

Every controller has a finite communications budget: a maximum number of CIP connections and a bounded number of packets per second it can service, both stated in the manufacturer's documentation for the specific processor and communication module. Each I/O connection consumes packet budget in proportion to how fast it cycles - its requested packet interval - so tightening every connection's update rate at once is how otherwise healthy systems run out of headroom. Plan the rates by need: machine-critical I/O fast, slowly changing skid data much slower, and verify the totals against the budget before commissioning rather than after the first mysterious connection timeout. Working through the arithmetic is covered in budgeting EtherNet/IP connections on a controller.

Polling Tags Without Hurting the Controller

Explicit reads from SCADA and historians land on the same communications budget, so poll design matters. Fewer, larger requests beat many small ones: group related tags into arrays or structures the driver can fetch in one transaction instead of scattering hundreds of individual tag reads. Split polling into rate classes - operator-facing values on a faster class, configuration and slowly moving values on a much slower one - and resist the reflex to poll everything at the fastest rate the driver allows. After any polling change, check the controller's reported communications load with the manufacturer's tools and confirm the control task scan has not stretched; the PLC's first duty is the machine, and a chatty SCADA driver should never compete with it.

Frequently Asked Questions