Definition
EtherNet/IP is an industrial Ethernet protocol developed by ODVA, based on standard Ethernet and CIP (Common Industrial Protocol), used for interconnecting PLCs, robots, inverters, servo devices, and others. It supports real-time I/O and explicit messaging, suitable for discrete manufacturing and production line automation. Protocol converters can convert EtherNet/IP data to OPC UA for MES and upper-level system collection.
Protocol Architecture
EtherNet/IP is based on standard TCP/IP and Ethernet, using the CIP application layer, and shares an object model with DeviceNet and ControlNet. Explicit messages are used for parameter reading and writing, as well as diagnostics, and are based on TCP; implicit messages (I/O) are used for real-time data exchange, based on UDP encapsulated in CIP. It supports a producer/consumer model, where multiple devices can consume the same data simultaneously. A typical network uses a star topology, with switches connecting each node, supporting 100M/1G Ethernet.
Application Areas
EtherNet/IP is widely used in discrete manufacturing industries such as automotive manufacturing, food and beverage, packaging, and logistics. Rockwell (AB) PLC ecosystem is its main promoter. Drives, servos, robots, vision systems, I/O modules, and other devices are interconnected with PLCs via EtherNet/IP. Industrial gateways can convert EtherNet/IP to Modbus, OPC UA, enabling data integration with DCS, SCADA, and MES.
Comparison with other industrial Ethernets
Profibus is a fieldbus, while EtherNet/IP is an industrial Ethernet; OPC UA is a data access standard that can interface with EtherNet/IP devices through gateways. EtherNet/IP, along with PROFINET, EtherCAT, and Powerlink, are all industrial Ethernet protocols. When selecting, PLC brand, device ecosystem, and system integration requirements need to be considered.
Implicit messaging and the connection path
An explicit message is for parameters and diagnostics. It uses reliable transport, one request and one reply. An implicit message is for the input and output image. It is sent on the requested packet interval and is not acknowledged one by one. The connection path says which slice of the scanner image reaches which object in the target device. A path that is short one instance makes the device reject the connection or write the data to the wrong object. The requested packet interval has to be longer than the cycle the device can handle, and it still has to meet the process need for fresh data. Too small, and frames pile up in the switch and the device, so the connection opens and drops again. Too large, and an emergency stop or an interlock is sometimes half a beat late.
The condition is an industrial Ethernet of its own, with a fixed address plan, and no arbitrary address translation rewriting ports between the scanner and the adapter. With multicast, the same input can be received by several consumers, and the switch has to let that multicast through. Otherwise only devices on the scanner's own segment receive it. The device's electronic data sheet revision has to match the firmware. Otherwise the connection opens and the assembly length does not match the tags in the controller. Clock synchronization only fixes timestamps. It does not replace the requested packet interval.
Requested packet interval and switch isolation
Putting production frames and the office network on one switch with no isolation is the most common site mistake. Broadcasts, address clashes, and spanning-tree recalculation on the office side break the cyclic frames. The controller reports a connection timeout and recovers a few seconds later, and the device itself shows no damage. Another mistake is to copy a controller project and keep the old connection path. The new drive's slot and instance differ, the download reports no syntax error, and at run time the data is all zeros. If the network address changed and the connection still points at the old address, that node stays offline in the scan list while its neighbors stay normal.
A half-duplex port, a 100-megabit port that negotiates down to 10 megabits, or a cable with only two pairs connected starts dropping implicit messages once the load rises. If ring recovery takes longer than the connection timeout, every switchover makes every adapter reconnect. During that time outputs follow each device's own fault policy. Some hold, some go to zero. See that during commissioning. Do not assume it. A gateway feeding a higher-level system should read an assembly that is already connected. Do not publish the initial value of the image area while the connection is still down. After the requested packet interval is changed, recompute frame volume and controller load for the whole network. Changing one device and calling it local is not enough.
Output policy during a switchover
If a ring or link switchover lasts longer than the connection timeout, an adapter handles its outputs by its own fault policy. Some hold the last value, some go to zero. Look at that policy device by device during the trial run. Do not assume it matches the program in the controller. After the switchover the scanner rebuilds the connection. Until that rebuild finishes, a gateway should not report the initial value of the image area as a process quantity.
Before shortening the requested packet interval, compute frame volume and controller load for the whole network. Changing one device still adds cyclic traffic on the switch. After an address changes, change the connection path and the scan list together. Copying a project is the easiest way to leave an old address behind. When a cable negotiates to a low rate, or pairs are missing, light load looks normal and timeouts start as soon as production frames increase. Keep the office network and the input-output network apart. A spanning-tree recalculation should not happen on the control network. Assembly length follows the firmware actually in the device. An old electronic data sheet connects successfully and shifts the tags.
When a connection fails to open, look first at the path, the assembly length, and the electronic data sheet revision. Any one of the three disagreeing can mean no process data at all. Keep the failure code as received. Showing only "timeout" mixes a bad path with network congestion. When multicast is filtered by a switch, devices in the same cabinet stay normal and devices in the next cabinet have no inputs, which looks a lot like a wrong address. The requested packet interval has to match on the device and on the scanner. Changing only the scanner leaves the device sending on the old cycle. Write the observed output state after communication is lost into the trial record, including hold, zero, and freeze as actually seen. Do not copy the default sentence from the manual. Do not give the production network an address that expires on its own. When the address changes, every connection path fails with it.