The Requested Packet Interval (RPI) is the per-connection cyclic refresh period the scanner requests from a target on EtherNet/IP, with the actual interval selected in the connection configuration of the controller project (for example, Studio 5000) or the device DTM [S4][S5]. On a 1734-AENT/B Point I/O or 1794-AENT/A Flex I/O adapter, the RPI field is set per connection once the module is added under the EtherNet/IP adapter in the I/O tree [S2].
The RPI is not a network-wide property; it is a per-connection value, and the scanner's connection request includes the requested rate plus the transport type (multicast or point-to-point) and the input/output assembly sizes [S4]. Typical manufacturer guidance puts digital I/O in the 10-50 ms band and analog I/O in the 20-100 ms band, with a 10 ms default commonly seen in controller and DTM tooling [S2][S6].
What the RPI actually controls in an implicit connection
On EtherNet/IP, the implicit (I/O) connection carries cyclic data between an originator (scanner) and a target; the RPI is the period at which the target produces the next T-to-O packet and the scanner schedules the next O-to-T packet [S3]. When the scanner is idle, the target's behavior varies: some targets stop updating their inputs on a STOPPED or HALTED controller, others continue to update, which is why the RPI must be validated against the target's documentation and EDS file [S6]. The connection also carries an inactivity or timeout that is typically three to four times the RPI, so a smaller RPI tightens both the update and the fault-detection window [S5].
A second connection opened in parallel with a Listen Only or Input Only type mirrors the same RPI and cannot be established before a primary Exclusive Owner or Input Only connection exists [S3]. This is the standard pattern for HMI or second-controller mirroring: one Exclusive Owner owns control, and one or more Listen Only consumers read the same inputs at the same cycle [S3].
Choosing the RPI: a numeric comparison of common options
The right RPI is a trade between control-loop performance, network load, and target capability, and the most common selection ranges are summarised below. [S5]
For high-speed discrete control (pick-and-place, indexing, safety light curtains over standard CIP Safety), the standard pick is 2-10 ms with an Exclusive Owner connection; 2 ms is the typical floor in Studio 5000 and is close to the minimum RPI advertised in most adapter EDS files [S2][S6]. For general discrete I/O (limit switches, valve solenoids, contactor coils), 10-50 ms is the manufacturer default and what most 1734 and 1794 modules ship configured to on first add [S2]. For analog I/O (4-20 mA, RTD, thermocouple over 1734-IE or 1794-IE modules), 20-100 ms is recommended because analog conversion and channel scan add a fixed latency that does not benefit from faster than 20 ms cycling [S2].
Lower RPI values increase the packets-per-second (PPS) budget each scanner must support. A scanner hosting 50 connections all set to 5 ms is producing and consuming about 200 PPS per direction before any other traffic, which quickly exhausts the scanner's connection resources on a ControlLogix or M580-class CPU and is why the controller enforces a minimum RPI per device [S6]. The device RPI in the controller is therefore a floor, not a target: the controller raises it to the highest value the system can sustain without overloading, and the EDS file or device manual reports the device's own minimum [S6].
Connection type, electronic keying, and how they interact with RPI
Three connection types are commonly exposed on a remote I/O module: Exclusive Owner (control read/write), Input Only (one-way input), and Listen Only (mirror of an existing owner connection) [S3]. Exclusive Owner is mandatory for any module that drives outputs; Input Only and Listen Only are used for HMIs, second scanners, and peer controllers that must read process state without owning the writes [S3]. A typical machine-cell has one Exclusive Owner per remote I/O drop plus one or more Listen Only consumers on a panel PC or safety controller, all at the same RPI so the input image stays phase-coherent [S2].
Electronic keying is checked during connection establishment, before the RPI timer starts, and the options are Exact Match, Compatible Key, and Disable Keying [S2]. Exact Match requires identical catalog, major, and minor revision; Compatible Key allows the same catalog and a higher minor revision; Disable Keying skips the check and is appropriate only for non-safety bench commissioning, not for production cells. The keying step has no effect on RPI, but a failed keying check prevents the connection from opening, so the RPI never starts and the input image stays at its last valid or zero state [S2].
Trigger types, priority, and packet size constraints
EtherNet/IP supports two cyclic-data trigger modes: Cyclic (default, the endpoint sends at a fixed interval equal to the RPI) and Change of State (CoS, the endpoint sends on a state change, then a heartbeat at the RPI) [S6]. Cyclic is the right pick when the controller logic expects a fresh value every scan, for example a PID loop reading a pressure transmitter input. CoS is the right pick when the I/O is sparse and event-driven, for example a discrete valve-state input mapped into a SCADA tag, and it cuts idle traffic by an order of magnitude at the cost of slightly higher end-to-end latency on the first change event [S6].
Connection parameters also include input and output priorities (Low, High, Scheduled) and fixed packet sizes: input assemblies of 0-505 bytes and output assemblies of 0-509 bytes are typical bounds, with the Ethernet communication module supporting only fixed-length packets [S4]. Scheduled priority requires a time-synchronisation service (CIP Sync, IEEE 1588) and is the only mode that delivers deterministic latency below the RPI; on a standard RPI scan, jitter is in the low milliseconds and is not bounded by the network [S4].
Failure modes, monitoring, and the scanner resource check
Two failure modes dominate in field troubleshooting. The first is connection timeout, where the scanner stops receiving T-to-O packets within roughly 3-4 times the RPI; the controller flags the module with a connection fault, drops outputs to their configured safe state, and logs a 16#0203 or similar CIP error in the controller's event log [S5]. The second is resource exhaustion, where adding more modules or reducing the RPI on existing modules pushes the scanner past its connection or packet-per-second budget, visible as a "connection request failed, scanner resource exceeded" error at module add time and reproducible on the Scanner Resource Checker view [S6].
Two verification steps belong in every commissioning procedure. First, the EDS file or device manual must be read for the device's minimum RPI, then the controller's RPI is set to max(device minimum, what the system can sustain); this is the same logic the controller applies automatically, but making it explicit in the design document prevents the next engineer from "tightening" the value and breaking the system [S6]. Second, the controller tag namespace must be checked after I/O configuration: in Studio 5000, remote I/O data lands in controller tags using the adapter-slot-channel naming convention (for example, Local:5:I.Data.0 for adapter slot 5, input word 0), and any custom assembly mapping has to be validated against the module's input/output assembly attribute values [S1][S2].
What this looks like in practice across vendor toolchains
Rockwell's Studio 5000 / RSLogix 5000 places the RPI on the Module Properties dialog of every EtherNet/IP module under the Connection tab, with 5 ms as a common default for Logix-class remote I/O and 2-10 ms as the typical tight-loop range [S1][S2]. Schneider's Machine Expert DTM and EcoStruxure Control Expert expose the same parameters on a per-connection page (RPI in ms, input/output size 0-505/0-509, Cyclic or CoS trigger, Low/High/Scheduled priority), with 10 ms as the default and a built-in scanner resource check that flags overload before download [S4][S6]. Lenze's E84 EtherNet/IP adapter documentation for the 8400 motec inverter drive walks the same configuration through RSLogix 5000 version 19 or lower and matches the Rockwell 1734/1794 pattern on I/O configuration tree placement [S1].
The cross-vendor guidance converges on the same numeric envelope: 2-10 ms for tight motion or safety I/O, 10-50 ms for general discrete, 20-100 ms for analog, and a controller-side minimum that respects the highest RPI the scanner can sustain [S2][S6]. For control cabinets housing remote I/O drops next to variable-frequency drives and industrial valve manifolds, the binding constraint is usually the scanner's connection budget rather than the cable plant, and reducing the RPI on one module to chase a few milliseconds of loop time is the most common cause of intermittent connection faults on integrated cells. The next node to watch is the move to CIP Security on EtherNet/IP, which adds handshake overhead per connection and will push typical minimum RPIs upward by a few milliseconds once enabled, and the adoption of CIP Sync / IEEE 1588 scheduled connections, which replace best-effort cyclic RPI with deterministic time slots on supported adapters and controllers.
For component-level specifications, see o ring.
Related analysis: Why chiller and UPS lead times move together on 2026 data center builds.