EtherNet/IP is the industrial network defined by ODVA that runs the CIP application protocol over standard Ethernet and TCP/IP. The IP stands for Industrial Protocol, not Internet Protocol. It combines on-demand explicit messaging over TCP with cyclic implicit messaging over UDP, whose rate is set by each connection’s RPI parameter.
Where EtherNet/IP shows up on the plant floor
EtherNet/IP is the native field network of the Rockwell Automation ecosystem, so you find it wherever control is Allen-Bradley: automotive suppliers, food and beverage lines, and generally machinery of North American origin. It is not confined to the PLC: drives, I/O blocks, barcode readers, scales, robot controllers and vision systems all speak EtherNet/IP as adapters. Unlike other industrial networks its traffic is routable, which is why it is often already integrated into IT-managed network infrastructure, with a dedicated plant VLAN.
EtherNet/IP versus PROFINET
Both are industrial Ethernet over standard cabling and solve the same problem with opposite philosophies. PROFINET lifts its real-time frames out of the TCP/IP stack and sends them as Layer 2 frames, gaining priority and predictability at the cost of never leaving the segment. EtherNet/IP does the reverse: everything, cyclic exchange included, rides on ordinary UDP and TCP, so the traffic is routable in principle, though moving it between segments is still a network design decision, and for cyclic traffic it depends on how multicast is configured. The trade-off is that determinism depends on that network design rather than on the protocol: implicit messaging defaults to multicast in the device→controller direction, recent controller firmware allows configuring it as unicast, and without a managed switch doing IGMP snooping and traffic prioritisation, process traffic can flood segments that have no use for it. They also differ in device description: EDS files in EtherNet/IP versus GSDML in PROFINET. Do not confuse EtherNet/IP with DeviceNet: they share CIP as the application layer, but DeviceNet carries it over the CAN bus.
Getting data out of an EtherNet/IP network
Of all industrial networks, EtherNet/IP is the friendliest to a data layer, and the reason lies in the protocol itself: explicit messaging is on-demand client/server. A CIP client can open a TCP session to the controller and read values without joining any existing cyclic connection and without modifying the program. On tag-based controllers the read is symbolic too: you request the variable by name rather than by memory address, which removes the register map other protocols force you to maintain.
That convenience comes with conditions worth checking before promising anything. The variable must be controller-scoped, or accessed by specifying the path of the program that owns it, and its external access attribute must not be disabled: a tag marked as inaccessible simply cannot be read from outside. Each connection also consumes controller communication resources and CPU time, so a badly sized read, one request per variable at an aggressive period, lengthens program scan time. Good design groups variables per request and matches the period to what the decision needs, not to what the network allows.
The alternative is passive capture of implicit traffic, which travels over UDP between controller and adapters. An edge device on the right segment can listen without transmitting, but it needs to actually see that traffic: where the connection is multicast that is a matter of IGMP configuration on the switches, and where it is unicast it is only visible from a mirror port or a TAP on the path between the two endpoints. It also needs the connection configuration and EDS files to know which byte maps to which variable of which device. Adding a new adapter to the controller I/O tree is an engineering change with a download, and therefore needs a window. Reading over explicit messaging does not.
One last point worth stating: the base protocol neither authenticates nor encrypts. A read client is not inherently harmless, because the same services also write. Sensible practice is to segment the network, restrict access to the controller port and limit the client to read operations, alongside the security extensions ODVA defines for CIP.
Related terms
EtherNet/IP occupies the same layer of the automation pyramid as PROFINET and EtherCAT, and coexists with OPC-UA, which many modern controllers expose in parallel with a semantic information model. Its data feeds the edge computing layer and from there the rest of the systems. At Captia Connect it maps to PLC connectivity: connection engineering across any vendor, without reprogramming the control logic.