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

By Dzulfikar Ats Tsauri, founder of Voltrus / JoyoDigitama. He builds the protocol tools covered in these posts. Updated October 28, 2026.

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). You usually enter it in milliseconds, although the Forward_Open request carries it in microseconds, 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

Values you'll commonly see are a few milliseconds for fast motion I/O, around 10–20 ms for general machine I/O, and tens to hundreds of milliseconds for slow process or monitoring points. These are habits from the field, not limits set by the protocol; the allowed range depends on the module.

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	Set per connection; the allowed range depends on the module and controller
Connection timeout (RPI × timeout multiplier)	How long to wait for a missed packet before killing the connection	The originator sets a timeout multiplier in the Forward_Open; CIP encodes values from ×4 up to ×512

The connection timeout is the RPI multiplied by a connection timeout multiplier chosen by the originator in the Forward_Open request. With a ×4 multiplier and a 20 ms RPI, a connection that sees no packet for 80 ms is dropped and the I/O faults. Check the multiplier your controller actually uses in the module's connection settings and in a capture, since vendors choose their own defaults.

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, answering with the actual packet interval it will use, or
• Reject the connection if the RPI is not supported, for example because it is faster than the module can serve. Many modules have a documented minimum RPI.
• The originator can then retry the Forward_Open with a different RPI that the module accepts.

Forward_Open (originator → target)
  O→T RPI requested: 2 ms

Forward_Open response (failure):
  General Status:  0x01  (connection failure)
  Extended Status: 0x0111 (RPI not supported)

Retry with a larger RPI → connection established

This is why a failed connection in Studio 5000 can come from an RPI problem: the Forward_Open response carries a general status with an extended status such as 0x0111 (RPI not supported), and the module then shows a connection fault. The same fault can also come from other causes, such as a path that cannot carry the packet rate or a connection that timed out (for example extended status 0x0203). Read the code the module reports instead of guessing.

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 any multicast I/O traffic, and a "small" change from 20 ms to 5 ms quadruples the packet rate: twenty connections go from 1,000 to 4,000 packets per second. Industrial switches are usually fine with this; consumer-grade or daisy-chained links often aren't.

Also note: implicit I/O can be multicast or unicast. Input data from an adapter is often multicast so several scanners can consume it, and many modules let you choose unicast instead. Multicast needs IGMP snooping or similar on the switches, otherwise it floods every port.

Choosing an RPI: Practical Guidance

Application	Typical starting point	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

The ranges above are common field practice, not values from a specification, so check the module's documentation. Two 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 multiplier on a 5 ms RPI (20 ms) can false-fault. Consider a longer timeout if your network can't guarantee delivery.

Debugging RPI Problems

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

1. Read the Forward_Open error: the general and extended status (for example 0x0111 RPI not supported, 0x0203 connection timed out) tells you which side rejected the negotiation and why.
2. Check the module's minimum RPI: the module's documentation lists its minimum, and some adapters have a higher minimum than the controller's default.
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.

Keep reading

Guide NATS JetStream Explained: Streams, Consumers, KV, and Core NATS August 16, 2026 How-To EtherNet/IP ListIdentity: How Device Discovery Works (UDP 44818) August 11, 2026 Comparison CIP Explicit vs Implicit Messaging: When to Use Each August 11, 2026