EtherNet/IP has become the backbone of modern warehouse automation, carrying control traffic, safety signals, and device-level data across the same infrastructure that supports order fulfillment systems. While the protocol itself is well understood in principle, the practical engineering challenge lies in predicting how many connections a system can support, where latency will accumulate, and which components will fail first as the facility grows. This article is intended for warehouse operators, maintenance engineers, and controls teams who need a structured way to think about EtherNet/IP capacity, diagnose performance issues, and make defensible decisions before problems force an unplanned shutdown. It does not replace the guidance of your system integrator, original equipment manufacturer, or the engineering authority responsible for your site. Site procedures, lockout requirements, and OEM documentation always take priority over general recommendations.
The Role of EtherNet/IP in Warehouse Automation #
EtherNet/IP operates at the application layer of standard Ethernet, using the Common Industrial Protocol (CIP) over TCP/IP and UDP/IP. In a warehouse context, it connects programmable logic controllers (PLCs) to motor drives, barcode scanners, photoelectric sensors, radio-frequency identification readers, robotic controllers, and conveyor control nodes. The same network often carries HTTP traffic from camera systems, file transfers from inventory databases, and diagnostic messages from network management tools. This convergence of OT and IT traffic is convenient but complicates capacity planning because EtherNet/IP is sensitive to latency and packet loss in ways that ordinary office traffic is not.
A warehouse control system typically issues a handful of implicit (I/O) connections that operate cyclically, such as a conveyor adapter sending status bytes to a PLC every 10 milliseconds. Each connection reserves a portion of network bandwidth and consumes processing capacity on both the scanner and the adapter. If the total number of connections exceeds the PLC’s connection limit, or if the switch infrastructure cannot forward the aggregate packet rate, the system will exhibit intermittent faults that are difficult to trace. Understanding the difference between raw bandwidth and connection capacity is therefore the first step in any meaningful capacity plan.
Capacity Planning Fundamentals #
Capacity planning for Ether/IP is not simply about link speed. A 1 Gbps switch port can carry far more data than a conveyor control system will ever generate, but the same switch may struggle with 10,000 packets per second if its forwarding engine is undersized or if the PLC is overwhelmed by protocol processing. The correct planning model must consider three independent constraints: network bandwidth, packet processing rate, and the connection or session limits of the endpoints.
Warehouse engineers should build a capacity inventory before expanding a line or adding a new robotic cell. That inventory includes the number of devices, the type of connection each device uses, the requested packet interval (RPI) for implicit connections, the message frequency for explicit messages, and the expected peak traffic during order surges. An automated storage and retrieval system (AS/RS) crane, for example, may have six or eight drives, each with a 5 ms implicit connection, plus explicit messages for parameter uploads during startup. If the facility runs two or three waves per shift, the startup burst can be the true bottleneck even though steady-state traffic appears low.
Connection Types and Their Cost #
EtherNet/IP connections fall into two broad categories. Implicit I/O connections are cyclic, maintaining a scheduled stream of data at a fixed RPI. They are the lifeblood of real-time control and consume network resources continuously whether the data changes or not. Explicit messages, by contrast, are unscheduled transactions used for configuration, diagnostics, and data collection. They use TCP and are typically bursty. A maintenance technician reading drive status through a web interface or a controls engineer uploading a new parameter set creates explicit traffic that shares the same switch fabric as the cyclic I/O.
The cost of an implicit connection is not symmetrical. A PLC with a connection limit of 256 nodes may support 512 connections total, but each connection consumes memory and CPU time. The adapter on the other end—the drive, the scanner, the robot controller—also has a connection budget. Overloading an adapter with too many simultaneous connections can cause it to reject new connections, which in turn forces the PLC to go into fault. Capacity planning must therefore account for the endpoint limits as well as the switch infrastructure.
Bandwidth versus Packet Rate #
Bandwidth is the amount of data that can pass per second, measured in bits or bytes. Packet rate is the number of individual frames that the switch, PLC, or adapter can process per second. Small packets are the norm in control networks; a typical implicit I/O frame might carry 16 to 64 bytes of data, which translates to a frame size of 60 to 100 bytes on the wire including headers. At a 1 ms RPI, a single connection generates 1,000 packets per second in the forward direction and approximately the same number in the reverse direction for the returned data. Multiply that by 50 connections and the switch must process around 100,000 packets per second, which is trivial for modern switches but significant for an embedded PLC or a low-cost unmanaged switch in a remote bay.
Warehouse facilities often use daisy-chained topologies to reduce cabling cost, with drives and sensors connected through their embedded two-port switches. This approach conserves switch ports but creates a cumulative packet load on each intermediate device. A drive at the end of a chain of eight devices must receive and forward the traffic of all devices behind it, adding latency and processing burden. Capacity models should treat each device’s embedded switch as a real forwarding element, not as a passive tap.
Where Bottlenecks Actually Form #
Bottlenecks in EtherNet/IP systems rarely announce themselves in a single obvious failure. More often they appear as random, short-lived faults that disappear when a maintenance engineer starts capturing data. The art of diagnosis is knowing which component is most likely to saturate under load, and that requires a structured view of the entire data path.
Switch and Cable Plant Considerations #
Managed switches are the norm in new warehouse installations because they offer port statistics, diagnostics, and the ability to set quality-of-service priorities for EtherNet/IP traffic. Unmanaged switches remain common in older facilities and in remote conveyor segments. An unmanaged switch cannot prioritize control frames over broadcast traffic, so a faulty device that floods the network can disrupt every control connection on that segment. Even with managed switches, the cable plant can become the limiting factor. Damaged connectors, loose RJ45 clips, and improperly routed patch cords cause CRC errors and late collisions, forcing retries that consume bandwidth and increase effective latency. Warehouse environments are particularly harsh on cabling because floor-scrubbing machines, fork trucks, and personnel lifts can crush or abrade patch cords.
Scanner and Adapter CPU Saturation #
The PLC’s Ethernet scanner is a common point of failure because it must service every implicit connection, every explicit request, and the device’s own internal logic. When a PLC reaches roughly 70 to 80 percent of its communication CPU capacity, the response time for explicit messages increases sharply, and the scan time for logic may jitter. Adapters, meanwhile, have smaller processors and less memory. A barcode scanner with an embedded two-port switch may handle two or three connections comfortably, but adding a fourth connection for status monitoring can push it over its limit. The result is a rejected connection or a reset, neither of which the PLC will necessarily log clearly.
PLC Task Timing and Requested Packet Interval #
Capacity planning must align the PLC’s task timing with the RPI of the devices. If the PLC’s periodic task has a period of 10 ms, then configuring a device at 5 ms RPI forces the PLC to handle data twice per task cycle, increasing CPU load without improving control quality. Conversely, if the PLC task runs at 5 ms but the device RPI is 20 ms, the PLC sees stale data and may trigger false faults. These mismatches are often the hidden cause of intermittent conveyor jams or unplanned stops. The solution is to group devices by their required response time and set the PLC task period to the fastest needed RPI, then avoid configuring devices at faster rates than the task can consume.
Wireless Links and Roaming Behavior #
Wireless EtherNet/IP connections, typically used for automated guided vehicles (AGVs), automated mobile robots (AMRs), and operator terminals, introduce an additional layer of uncertainty. Wi-Fi access points can handle the raw data rate of a single AGV’s control connection, but the roaming transition when the vehicle moves from one access point to another can interrupt the connection for 100 to 500 milliseconds, which is far longer than a typical 10 ms RPI. If the PLC’s connection fault tolerance is set to three missed packets, a single roaming event will fault the connection. Capacity planning for wireless links must therefore consider the number of simultaneous roaming events, the density of access points, and the tolerance of the control logic to short gaps in data.
Observable Symptoms and Evidence Collection #
When an EtherNet/IP network reaches its capacity limit, the symptoms are often attributed to the wrong cause. A conveyor that stops randomly may be blamed on a sensor when the actual cause is a saturated PLC scanner. A drive that goes offline for a second during a wave surge may be caused by packet loss in the switch, not by the drive itself. The following table summarizes common symptoms, their likely causes, and the evidence worth collecting.
| Observed Symptom | Likely Capacity Issue | Evidence to Collect |
|---|---|---|
| Device faults intermittently during high production waves | PLC scanner CPU saturation or explicit message burst | PLC scan time, connection fault counters, CPU utilization over time |
| Multiple devices on the same switch segment fault together | Switch broadcast storm or buffer exhaustion | Port statistics, broadcast rate, switch CPU utilization, error counters |
| Single drive or scanner drops offline for 1–5 seconds | Adapter connection limit reached or cable fault | Device log, port CRC errors, reconnect attempts, packet captures |
| AGV/AMR connection faults when crossing access point boundaries | Roaming delay exceeds connection tolerance | Wi-Fi association logs, packet capture timestamps, RSSI history |
| Control response varies with production rate | RPI/task period mismatch or switch QoS missing | RPI configuration, PLC task timing, Wireshark inter-frame timing |
| Explicit messages time out during startup sequences | Too many simultaneous explicit requests | Number of clients initiating messages, TCP retransmissions, server response times |
Evidence collection should be a deliberate process, not an afterthought. Begin with the PLC’s connection diagnostics, which normally include the number of active connections, the number of I/O connections vs. explicit connections, and the total communication load. Next, capture switch port statistics for CRC errors, dropped frames, and utilization on the uplink. Finally, run a packet capture at the PLC port using Wireshark or a commercial tool to observe the actual inter-frame timing. A healthy EtherNet/IP network will show consistent inter-frame spacing with occasional bursts. A saturated network will show erratic spacing, TCP retransmissions, or late messages that trigger the scanner’s fault timer.
Time Alignment and Event Data in Diagnostic Logs #
Warehouse control systems generate a continuous stream of event data: barcode scans, photoeye transitions, driver faults, and PLC alarms. When a capacity problem occurs, the event logs from different devices are often compared to understand the sequence of failures. This comparison is only meaningful if the clocks of all devices are aligned to a common time source. EtherNet/IP supports a CIP Sync extension based on Precision Time Protocol (PTP), but many devices in a typical warehouse do not have a PTP-capable clock. Without time alignment, an event logged by a drive at 14:03:12.500 and an event logged by the PLC at 14:03:12.542 may actually be reversed in real time.
Evidence collection should record the clock offset of every device relative to the PLC or to the network management server. For devices that lack PTP, the offset can be estimated by comparing the device’s time-of-day to a known reference during commissioning, but this offset drifts with temperature and uptime. For highly intermittent faults, the solution is to use a network tap and a single time-synchronized capture point rather than relying on the device logs. A packet capture at the switch uplink can show the exact timing of a connection timeout and correlate it with a mechanical event such as a motor overload or a safety relay trip, even when the device clocks disagree.
Resilient Interfaces and Redundant Paths #
Capacity planning also involves the design of resilient interfaces. A warehouse control network should have redundant paths for the most critical controllers, using either ring topologies with rapid spanning tree or device-level ring (DLR) protocols. However, redundancy is not automatic. A ring topology only helps if the switch and PLC are configured to fail over quickly and if the capacity of the remaining path is sufficient to handle the combined traffic. If a 1 Gbps ring carries 600 Mbps of normal traffic, then a cable break in a non-optimized ring may cause the entire traffic load to shift to one path, pushing utilization above 80 percent and causing packet loss. The ring capacity must be planned so that the worst-case post-failure load remains below the forwarding capacity of every switch and the processing capacity of the PLC.
Similarly, dual homing a PLC to two switches—one primary, one backup—does not double capacity. It provides failover, but if both switches connect to the same uplink, that uplink remains a single point of failure. Resilient interfaces require independent physical paths, independent power supplies, and careful attention to the routing and VLAN configuration. Site engineers should review the failover tests annually and measure the actual failover time compared to the PLC’s connection timeout. If the failover takes 1.2 seconds and the PLC times out at 1.0 second, the redundant path is effectively useless for control traffic.
Common Interpretation Errors #
Diagnosing EtherNet/IP capacity issues is full of interpretation traps. The following errors are common across warehouse sites.
First, equating link speed with performance. A 1 Gbps link with a high packet rate and tiny frames can be saturated at 150 Mbps of actual throughput if the switch cannot forward enough packets per second. The port utilization percentage is a misleading metric for small control frames. Always look at packet-per-second counts and buffer drops, not just bandwidth utilization.
Second, blaming the wireless network first. When an AGV stops, the natural assumption is Wi-Fi interference. Often the true cause is a programmed pause in the vehicle controller or a network discontinuity that was present long before the Wi-Fi link degraded. A captured log at the AGV’s PLC port showing the connection timeout exactly overlapping a Wi-Fi roam is evidence of a wireless issue. A log showing the PLC task overloaded, causing the scanner to delay sending data, is not a wireless issue even if the AGV’s screen displays a communication error.
Third, misreading connection fault counts. A PLC that reports “connection timed out” for a device does not necessarily indicate a network problem. The device may have rebooted due to a firmware crash, the device’s embedded switch may have lost power, or the device’s CPU may have been too busy to service the connection. The fault counter is a symptom, not a root cause. Only by correlating the fault time with device logs and power events can the engineer determine whether the network or the endpoint is responsible.
Fourth, assuming explicit messages are harmless. Explicit messages, especially those generated by a maintenance PC polling every device for status, can consume significant PLC CPU time. A single PLC with 200 devices and a 2-second polling interval may spend 30 percent of its communication capacity handling explicit traffic. During a startup surge, when multiple technicians connect laptops and upload parameters simultaneously, the explicit traffic can spike and starve the implicit I/O connections, causing random faults.
Maintenance Implications and Decision Boundaries #
Capacity planning is not a one-time activity. Warehouse expansion, new automation cells, and changes to order fulfillment logic alter the traffic profile of the network. Maintenance teams should treat the EtherNet/IP network as a managed asset with documented capacity limits, periodic traffic surveys, and planned upgrade triggers. A good maintenance practice is to record the baseline communication load for each PLC and switch at least once a quarter, using the same measurement method each time, so that deviations become visible.
Decision boundaries should be defined before a crisis. For example, if the PLC scanner CPU utilization averages above 60 percent during a normal wave, plan to move explicit messaging to a secondary network or upgrade the PLC. If switch uplink utilization exceeds 40 percent during peak, investigate before adding new devices. If device connection timeouts occur more than once per shift, open an incident rather than cycling power. These thresholds are not universal; they depend on the specific hardware and application. Site engineers should derive them from the OEM documentation and from observed behavior during stress testing.
When a capacity issue is confirmed, the range of possible responses is broad. Reducing the number of explicit message clients, grouping devices into separate networks, and increasing the connection fault tolerance are all legitimate mitigation options. Sometimes the most cost-effective solution is to reduce the RPI for non-critical devices, for example slowing a condition monitor from 10 ms to 50 ms. But changing RPI affects control behavior, so it must be validated by the controls team. In all cases, the change should be documented in a change management system and reviewed after a trial period. Site procedures for electrical safety, lockout/tagout, and machine guarding must be followed before any physical work on the network. This article does not provide instructions for bypassing safety devices, and no capacity issue justifies defeating those protections.
The decision to upgrade hardware should be based on the trend of measured data, not on a single worst-day event. A single peak during a large order wave may not justify a PLC upgrade. But if the measured utilization grows consistently with order volume, and the model predicts a violation of the target threshold within the next two quarters, the upgrade should be scheduled. The same logic applies to switch port counts, wireless access point coverage, and cable plant changes.
Key Takeaways #
- EtherNet/IP capacity planning must consider bandwidth, packet-per-second processing, and connection limits on both the PLC and the endpoint devices; a single constraint can saturate the system even when link speed is high.
- Implicit I/O connections consume continuous resources, while explicit messages are bursty; both should be measured during startup surges, not just steady-state operation.
- PLC task timing and device RPI must be aligned; a mismatch between a 10 ms task and a 5 ms RPI causes unnecessary CPU load and can induce false faults.
- Wireless AGV/AMR connections fail during roaming if the connection timeout is shorter than the roaming delay; design the network to minimize handoff time or increase the tolerance within acceptable limits.
- Diagnostic evidence should be time-aligned across devices; use a single time-synchronized packet capture for intermittent faults and treat connection fault counters as symptoms, not root causes.
- Switch port utilization is a misleading metric for small control frames; packet rates, buffer drops, and CRC errors provide a more accurate picture.
- Establish defined decision thresholds for PLC CPU load, switch uplink utilization, and connection timeout frequency, and review the traffic baseline quarterly to detect trends before failure.
- Every network change—RPI adjustment, moving devices to a different switch, adding explicit message clients—should follow the site’s change management process, and all physical work must respect site safety procedures, lockout requirements, and OEM guidance.
