EtherNet/IP RPI Explained: Requested Packet Interval, CIP I/O, and How to Tune It

When an Allen-Bradley PLC runs implicit I/O with a remote rack or a scanner, both sides agree on a timing value called the Requested Packet Interval (RPI). Get it wrong and you get a "connection not established" error, or worse — a connection that flaps in production.

This guide explains what RPI actually is, how it differs from the connection timeout, how CIP negotiates it, and how to choose sane values for ControlLogix and CompactLogix systems.

What Is the RPI?

RPI stands for Requested Packet Interval. It's the time between the packets in a CIP implicit I/O connection — the cyclic, UDP-based traffic that carries real-time I/O data. It's specified in milliseconds, and it's the heartbeat of EtherNet/IP I/O.

Implicit I/O connection (UDP 2222)
│
├── Packet 1  (t=0 ms)    ← RPI
├── Packet 2  (t=RPI)     ← e.g. every 20 ms
├── Packet 3  (t=2×RPI)
└── ...cyclic until connection closes

Common RPI values you'll see in practice: 5 ms for fast motion/servo I/O, 10–20 ms for general machine I/O, 50–100 ms for slow process points, and 200–500 ms for monitoring-only data.

The key distinction: RPI is only meaningful for implicit (cyclic I/O) connections. Explicit messaging — tag reads, configuration, CIP messages over TCP 44818 — is request/response and has no RPI.

RPI vs Connection Timeout (and Why People Confuse Them)

These two values live next to each other in every CIP connection configuration, and mixing them up causes most "it worked in the office, failed on site" stories.

Value	What it controls	Typical range
RPI	How often packets are sent/received	1 ms – several seconds
Connection timeout (Network Connection Timeout)	How long to wait for a missed packet before killing the connection	4× RPI (Rockwell default), user-configurable

Rockwell's default connection timeout is 4× the RPI. If your RPI is 20 ms and a packet goes missing for 80 ms, the connection is dropped and the I/O faults.

How CIP Negotiates the RPI

RPI isn't a unilateral setting — it's negotiated. In the connection's Forward_Open request, the originator (scanner, PLC, or software client) proposes an RPI. The target (the I/O adapter or module) can:

• Accept the proposed RPI, or
• Reject it if it's faster than the module supports, or
• Return a reduced RPI — many modules have a minimum RPI (often 5 ms or 10 ms). If you request 1 ms and the module's minimum is 5 ms, the connection fails unless the originator retries with an acceptable value.

Forward_Open (originator → target)
  RPI requested: 2 ms

Target response:
  Error "RPI is smaller than the minimum"
  Minimum RPI: 5 ms

Retry with RPI 5 ms → connection established

This is why "connection not established" errors in Studio 5000 often quote an RPI problem — the proposed value violated a module's limit, or the packet rate exceeded what the network path can carry.

How RPI Interacts with Packet Rate and Bandwidth

RPI directly sets your I/O packet rate. The math is trivial but the consequences aren't:

Packet rate = 1000 / RPI (ms)  →  packets per second

RPI 5 ms   → 200 packets/s per connection
RPI 10 ms  → 100 packets/s
RPI 50 ms  →  20 packets/s
RPI 200 ms →   5 packets/s

Multiply by the number of connections on the switch and add the UDP 2222 multicast traffic, and a "small" change from 20 ms to 5 ms across twenty connections quadruples the load. Industrial switches are usually fine with this; consumer-grade or daisy-chained links often aren't.

Also note: EtherNet/IP implicit I/O is typically multicast for I/O adapters (all scanners see the same data). Multicast groups are organized by RPI — connections with the same RPI share a multicast group, which is why Rockwell docs suggest grouping connections by RPI instead of scattering values.

Choosing an RPI: Practical Guidance

Application	Suggested RPI	Notes
Servo / motion control	1–5 ms	Needs a clean, dedicated network
General machine I/O	10–20 ms	The default sweet spot
Process values (temp, level)	50–200 ms	Slow-changing points don't need fast RPI
Monitoring-only data collection	200–1000 ms	Lowest bandwidth, most tolerant
Software clients reading tags	No RPI (explicit)	Tag reads are request/response, not cyclic

Three rules to apply on real projects:

• Match the RPI to the process, not to the fastest number. A temperature loop at 5 ms is wasted bandwidth and fragility for zero benefit.
• Keep the connection timeout above network worst-case latency. If your plant has congested switches, a 4× default timeout on a 5 ms RPI (20 ms) can false-fault. Consider a longer timeout if your network can't guarantee delivery.
• Group connections by RPI to share multicast groups and reduce switch load.

Debugging RPI Problems

When a CIP connection won't establish or keeps dropping, walk this list:

1. Read the Forward_Open error — a "requested RPI too small" or "connection timeout" reason code tells you which side rejected the negotiation.
2. Check the module's minimum RPI — older and third-party adapters often cap at 10 ms or 20 ms.
3. Look at actual packet arrival — a tool that shows UDP 2222 traffic and connection state reveals whether packets are arriving late or missing.
4. Check switch statistics — CRC errors, drops, and port counters on the I/O path explain missed packets that fault fast connections.
5. Raise the RPI or the timeout as a test — if the connection stabilizes, the network was the problem, not the settings.

A very common trap: monitoring software that opens an implicit connection with a tiny RPI "for fast updates" and then sits on the same switch as the PLC's real I/O. The connection consumes bandwidth and makes the I/O path more fragile. For tag-level monitoring, an explicit read is usually the better tool.

The Bottom Line

EtherNet/IP RPI is the interval between packets in a CIP implicit I/O connection — the cyclic heartbeat of real-time data over UDP 2222. It's negotiated in Forward_Open, subject to module minimums, and paired with a connection timeout (default 4× RPI) that determines how many missed packets kill the connection.

Choose RPI by process need: 1–5 ms for motion, 10–20 ms for machine I/O, 50–1000 ms for process and monitoring data. Remember that faster RPI means more bandwidth and less tolerance for network hiccups — so tune the timeout and the network with the same care as the interval.

And when you just need to read tags, skip implicit connections entirely — explicit messaging does the job without touching RPI at all.

Keep reading

Comparison EtherNet/IP vs PROFINET: Rockwell vs Siemens Industrial Ethernet August 11, 2026 How-To How to Read Allen-Bradley Tags Without RSLinx or FactoryTalk August 11, 2026 How-To EtherNet/IP ListIdentity: How Device Discovery Works (UDP 44818) August 11, 2026