How to Size an EtherNet/IP RPI Against Bandwidth

Back to Blog

What You Need

You need a list of every Class 1 (implicit, cyclic I/O) connection the controller will own, each with its intended RPI, plus the datasheet minimum RPI for each adapter. You need the controller's published limits for total connections and its connections-per-second or packets-per-second rating, and the switch's forwarding capacity for the ports in the path. Most of these numbers live in the manufacturer's datasheet, not in a standard, so gather them per device before you calculate.

You also need to separate the two traffic classes cleanly. Class 1 cyclic I/O is what the RPI governs and what dominates steady-state load. Class 3 explicit messaging (reads, writes, HMI polls) is request-response and is usually far lower volume, but it competes for the same connection budget, so count it. The distinction matters because sizing only the cyclic side and ignoring a chatty HMI is how a network that passed the math still runs out of connections.

Work the Packets-Per-Second Math Symbolically

For a single Class 1 connection, the producer sends one packet every RPI and the consumer sends one back every RPI, so that connection generates 2 / RPI packets per second when RPI is expressed in seconds. For N identical connections at the same interval, total load is PPS = 2N / RPI. Worked example: 40 I/O modules each at an RPI of 0.010 s (ten thousandths of a second) give PPS = (2 x 40) / 0.010 = 8,000 packets per second. Halve the interval to 0.005 s and the same 40 modules now demand 16,000 packets per second - the load is inversely proportional to RPI, so every time you double the speed you double the network burden.

When intervals differ, sum per connection rather than averaging: PPS = 2 x sum over i of (1 / RPI_i). This matters because one fast connection dominates the total. A cell with 30 modules at 0.020 s (3,000 PPS) plus a single motion drive at 0.001 s (2,000 PPS) is carrying 5,000 PPS, and the motion drive alone is 40 percent of it. Knowing that lets you argue for slowing the drives that do not need speed rather than the slow bulk I/O that was never the problem.

The RPI is a request, not a guarantee - the adapter grants an Actual Packet Interval that may be coarser if it cannot serve what you asked. So size against the RPI you intend to see granted, and after commissioning read back the actual interval to confirm the network delivered it. Understanding the underlying protocol helps here; the fundamentals are covered in what EtherNet/IP is.

Check the Three Ceilings Before You Commit

First ceiling: the controller connection count. Every Class 1 and Class 3 connection consumes one slot from a fixed pool published in the controller datasheet. Add them up including HMI and messaging; if you are near the limit, you have no headroom for a future device and should consolidate rack-optimized connections where the platform allows it. Second ceiling: the controller's packets-per-second or CPS rating. Compare your summed PPS from the previous step directly against it, and leave margin because that rating is a shared budget across all its ports.

Third ceiling: the adapter minimum RPI. An adapter that lists a floor of five thousandths of a second will simply refuse or coerce a request for one thousandth, so a design that assumed that faster rate was never achievable on that hardware. Check each adapter, because mixed vendors on one network have different floors. If any ceiling fails, the fix order is: slow the connections that do not need speed, then move fast devices onto a dedicated switch or VLAN, then only as a last resort split the controller's load. Do not defeat a ceiling by turning off diagnostics you will want later.

Verifying the Result

After you download the configuration, read the Actual Packet Interval back from each connection's status and confirm it equals or is a clean multiple of the RPI you requested. A granted interval much coarser than requested means the adapter or network could not keep up and your bandwidth math was optimistic. Then watch the connection for lost or missed packets over a representative production cycle, including the machine's worst-case burst, not just idle.

Confirm the controller's actual CPU and connection utilization under that load rather than trusting the paper calculation alone, because background tasks and explicit messaging add real overhead the symbolic model omits. If utilization is comfortable and no connection is dropping packets across a full shift, the RPI is sized. If it is marginal, slow the least critical connections first and re-measure - headroom now is what absorbs the next device you add.

Common Mistakes

Setting every device to the fastest RPI the tool allows, on the theory that faster is safer, is the most common and most expensive error - it multiplies load for data no loop actually uses. Match RPI to the control requirement: a temperature loop does not need motion-grade intervals. Forgetting that each connection is two packets per interval, not one, halves your load estimate and hides the real ceiling until the network is live.

Sizing only the cyclic I/O and ignoring explicit messaging from HMIs and historians leaves the connection budget looking healthier than it is. Finally, calculating bandwidth in bits per second alone and ignoring the packets-per-second and connection ceilings misses the limits that fail first: on EtherNet/IP the network almost never runs out of raw bandwidth before the controller runs out of connections or packet-processing headroom.

Frequently Asked Questions