What Is the Requested Packet Interval (RPI)?
Every EtherNet/IP I/O connection you configure asks for an RPI, and the number you enter directly sets how fresh your data is and how much network load the device creates. It is one of the few EtherNet/IP settings with an immediate, measurable effect. This page explains what the requested packet interval is, how it drives both the update rate and the connection timeout, and why a smaller number is not automatically better.
Requested Packet Interval (RPI) in one line: The requested packet interval (RPI) is the rate, in milliseconds, at which an EtherNet/IP I/O connection produces its data. If the RPI is set to, say, twenty milliseconds, each side sends its assembly on that interval. The RPI also sets the connection timeout, typically a multiple of the RPI, after which a silent connection is declared faulted. Faster RPIs mean fresher data but more network and CPU load.
What the RPI Actually Controls
The RPI is a request from the connection originator, usually the controller, for how often the cyclic I/O data should be produced. In a producer/consumer scheme both ends produce on their own RPI: the device produces its input assembly toward the controller at the RPI, and the controller produces its output assembly toward the device at the RPI. It is not a poll and there is no request per packet - each side simply sends on its interval, which is why implicit I/O is so lightweight.
Because the data updates on the RPI and not on the controller scan, the RPI and the scan are independent. A value can update faster than the program scan reads it, or slower, and neither is wrong - they are decoupled by design. What the RPI guarantees is the cadence of the network exchange, not the moment your logic happens to look at the tag. This decoupling is a frequent source of confusion when someone expects an I/O value to change exactly once per scan.
The RPI is requested, not commanded. The device can constrain it: many devices publish a minimum RPI they support, and asking for a faster interval than the device or the network can sustain will either be rejected or will produce a connection that cannot keep up. Choosing the value deliberately is the subject of choosing an RPI for EtherNet/IP I/O.
The RPI and the Connection Timeout
The RPI does double duty: it also sets the connection timeout, through a connection-timeout multiplier. The timeout is the RPI multiplied by that factor, and if a consumer hears nothing for that long it declares the connection timed out and faults the I/O. A common default multiplier means the connection tolerates a handful of missed updates before giving up, which balances fast fault detection against nuisance trips from a single dropped packet.
This coupling has a real consequence: a very fast RPI produces a very short timeout, so a fast connection is quicker to declare a fault on a marginal network. On a network with occasional jitter, an aggressively small RPI can cause the connection to time out and recover repeatedly, which looks like intermittent I/O and is really the timeout being too tight for the network's behavior. Loosening the RPI, or adjusting the multiplier where the platform allows it, is the fix, and it is a common thread in the EtherNet/IP connection timeout guide.
The Cost of a Fast RPI
A faster RPI is not free. Every I/O connection at a given RPI generates a fixed rate of packets, and the total packet rate across all connections is what a scanner and a switch must sustain. Halving every RPI roughly doubles the packet load. Push it far enough and the scanner runs out of packet-per-second capacity, or a switch's multicast handling saturates, and connections that were individually fine start timing out collectively. The right RPI is the slowest one that still meets the control requirement, not the fastest the device will accept.
The RPI should be matched to how fast the signal actually changes and how fast the loop must react. A temperature that drifts over minutes gains nothing from a single-digit-millisecond RPI; a fast interlock may genuinely need one. Setting every point to the fastest available interval is a common way to exhaust a scanner's capacity for no control benefit. Downstream, a monitoring platform such as Merobix trends the controller's tags at its own cadence regardless of the RPI, so choosing the RPI is purely a control-and-network decision, not a SCADA one.
Frequently Asked Questions
What does RPI stand for in EtherNet/IP?
RPI stands for requested packet interval. It is the rate in milliseconds at which an I/O connection produces its data - for example an RPI of twenty milliseconds means the assembly is sent on that interval. It is requested by the connection originator and may be constrained by the device's minimum supported interval and by available network and scanner capacity.
How does the RPI relate to the connection timeout?
The connection timeout is the RPI multiplied by a connection-timeout multiplier. If a consumer hears no update for that long, it declares the connection timed out and faults the I/O. A faster RPI therefore yields a shorter timeout, which detects faults sooner but is also quicker to trip on a jittery network. Loosening the RPI or the multiplier relieves nuisance timeouts.
Is a faster RPI always better?
No. A faster RPI gives fresher data but multiplies packet load on the scanner and switches, and it shortens the connection timeout so the link is more sensitive to network jitter. The right RPI is the slowest interval that still meets the control requirement for that signal. Setting every point to the minimum interval is a common way to exhaust a scanner's capacity for no benefit.
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.