How to Choose an RPI for EtherNet/IP I/O
Picking an RPI for each I/O connection is a routine commissioning task that is routinely done badly - usually by setting everything to the fastest interval the device allows. This guide gives a deliberate method: match the RPI to what the signal and the loop actually need, respect device and network limits, and budget the total load before you commit. It is aimed at engineers configuring EtherNet/IP scanners.
Choosing an RPI in one line: To choose an RPI, set each I/O connection's interval to the slowest rate that still meets that signal's control and update needs, confirm it is at or above the device's minimum supported RPI, then sum the resulting packet rate across all connections and check the scanner and switches can sustain it. Faster is not better - it only adds load.
Match the RPI to the Signal and the Loop
Start from what the data is for, not from what the device can do. Ask how fast the signal actually changes and how quickly the control logic must react to it. A temperature that drifts over minutes, a tank level that moves slowly, or a status that changes occasionally gains nothing from a fast RPI - a slower interval captures every meaningful change. A fast interlock input, a signal in a tight control loop, or a value the logic must act on quickly genuinely justifies a fast RPI. The interval should reflect the signal's real dynamics and the loop's real deadline.
This per-signal thinking is the opposite of the common habit of setting one fast RPI for everything. Different connections deserve different intervals, and grouping signals by how time-critical they are lets you spend fast RPIs only where they earn their cost. The concept behind the number is covered in the requested packet interval explainer; this step is deciding the value for each connection from its purpose.
Check Device and Network Limits
Confirm the RPI you want is at or above the device's minimum supported interval. A device publishes a floor, and requesting faster than that floor either fails or produces a connection that cannot keep up. The device datasheet or EDS states this minimum, and it varies widely by device class - a simple sensor and a high-performance drive have very different floors. Never assume a device can sustain the fastest RPI the scanner offers.
Also account for the connection timeout the RPI implies. Because the timeout is the RPI times a multiplier, a very fast RPI produces a very short timeout, which on a network with any jitter is more prone to nuisance trips. If a network is not pristine, a slightly slower RPI buys timeout headroom that prevents intermittent I/O faults. This interaction is a recurring theme in the connection timeout guide, and it argues against reflexively minimizing the RPI.
Budget the Total Packet Load
Sum the packet rate across all connections before committing. Each I/O connection at a given RPI produces packets at a rate set by that RPI, in both directions, and the total across every connection is what the scanner and the switches must carry. A scanner has a finite packet-per-second capacity, and exceeding it causes connections to time out collectively even though each looked fine alone. Halving every RPI roughly doubles the load, so the aggregate is where an over-aggressive RPI policy actually fails.
Work out the budget explicitly: for each connection, packets per second scale inversely with the RPI, and the sum must sit within the scanner's rated capacity with margin. If the total is over budget, the fix is to slow the RPIs on the non-critical connections - which is exactly why matching RPI to need in the first step pays off, because it frees capacity for the connections that truly need speed. If the I/O is multicast, factor in the switch-side considerations from multicast versus unicast I/O.
Verifying the Result
After setting the RPIs and bringing I/O online, confirm the connections are stable, not merely established. Watch for connection timeouts or errors over a period that includes normal network activity - a connection that comes up clean and then drops when other traffic bursts is a sign the RPI is too tight for the network, or that QoS is not prioritizing the I/O. Stability under realistic load, not just at idle, is the real pass criterion.
Confirm the data is fresh enough for its purpose by watching the values change at the expected rate. A monitoring platform such as Merobix trends the controller's tags continuously, so a signal that updates more slowly than intended, or a connection that periodically drops and recovers, shows up in the recorded data as stepped or gapped trends. The trend is a practical check that the RPI you chose is delivering the freshness the signal needs without destabilizing the connection.
Common Mistakes
The dominant mistake is setting every connection to the minimum RPI on the theory that faster is safer. It is not - it maximizes packet load for no control benefit on slow signals, shortens every timeout, and is the usual reason a scanner runs out of capacity. The second mistake is ignoring the device minimum and requesting an RPI the device cannot sustain, producing a connection that struggles. The third is never budgeting the total load, so the network works during commissioning with a few devices and fails as the full complement comes online.
A subtler mistake is setting a fast RPI to compensate for a slow control response that actually has a different cause - a slow loop, a filter, a scan-time issue - where a faster I/O update changes nothing because the bottleneck is elsewhere. Diagnose where the latency really is before spending RPI on it. Matching each RPI to genuine need, respecting device and network limits, and budgeting the aggregate is the whole discipline.
Frequently Asked Questions
What RPI should I use for EtherNet/IP I/O?
The slowest interval that still meets that signal's control and update needs, not the fastest the device allows. A slow-changing temperature or level needs only a modest RPI; a fast interlock or tight loop justifies a fast one. Then confirm it is at or above the device's minimum, and check the total packet rate across all connections fits the scanner's capacity with margin.
Is a smaller RPI always safer?
No. A smaller RPI multiplies packet load, shortens the connection timeout so the link is more sensitive to network jitter, and can exhaust the scanner's packet capacity when every connection is set aggressively. On a slow-changing signal it adds cost for no benefit. Reserve fast RPIs for genuinely time-critical connections and let slow signals use slower intervals.
How do I know if my RPIs overload the scanner?
Budget the total packet rate: each connection's packets per second scale inversely with its RPI, and the sum across all connections must fit the scanner's rated capacity with margin. A telltale symptom of overload is connections that are stable individually but time out collectively as the full device complement comes online, because the aggregate packet rate exceeds capacity.
Automation services
Need help turning this into a working system?
Merobix integrates SCADA, programs Allen-Bradley and Siemens PLCs, and designs and fabricates industrial control panels.
Meeting requests are reviewed before confirmation.