Allen-Bradley CIP: Explicit Polling Beats Implicit I/O

The panel shows remote I/O disconnected, intermittent connection faults, or SCADA values that update slowly and then go stale. On a 20 kbps UHF or VHF link, start by identifying whether cyclic implicit I/O or polled explicit messages are consuming the channel. The practical answer is to move noncritical data to scheduled MSG instructions or a buffering controller; changing only the radio rarely fixes an overloaded link.

Identify the traffic before changing anything

Start here. Separate the application into three traffic classes:

• Implicit CIP I/O: A connection exchanges data cyclically at its requested packet interval, or RPI. It continues whether values change or not.
• Explicit CIP messaging: A controller initiates a request with a MSG instruction and receives a response. Your logic controls when the request runs.
• SCADA polling: The SCADA server requests displayed tags, historian values, alarms, or other configured data at its scan rates.

Changing a SCADA poll rate does not slow an implicit I/O connection. Increasing an I/O connection's RPI does not slow unrelated SCADA requests. Identify the initiator and connection type before touching either setting.

Symptom	Likely cause
Remote I/O repeatedly connects and disconnects	Implicit packets are late or lost relative to the configured connection timeout.
SCADA pages are slow while remote I/O remains connected	Tag polling, historian requests, or excessive concurrent requests are filling the link.
Failures began after replacing a controller	The new controller or program may execute message requests faster than the old system.
Values update correctly until several messages run together	The application lacks scheduling, completion handshakes, or retry control.
Increasing RPI helps but does not eliminate faults	Loss, interference, retransmissions, or other traffic still exceed the connection budget.

Measure whether the 20 kbps channel can carry the load

The stated 20 kbps is the link rate, not guaranteed CIP payload throughput. Radio framing, Ethernet and CIP headers, acknowledgements, retries, latency, and interference consume part of it. A long-distance licensed narrowband path can therefore saturate before application data reaches 20 kbps.

1. Record the configured RPI for every implicit connection crossing the radio.
2. Record each SCADA scan group, tag count, historian interval, and number of simultaneous requests.
3. Record every MSG trigger interval and whether another trigger can occur before the prior request completes.
4. Read radio statistics for channel utilization, retries, discarded frames, signal condition, and latency. Use the fields provided by the installed radio rather than assuming a Wi-Fi failure mode.
5. Capture PLC connection diagnostics while the panel fault occurs. Correlate connection timeouts with radio congestion or packet loss.

For periodic traffic, estimate each stream as:

offered bit rate = transmitted bits per exchange / interval in seconds

Include requests, responses, and protocol overhead from a capture or device diagnostic. Do not size the channel from tag payload bytes alone. If total offered traffic approaches the usable radio throughput, proceed to the RPI test for noncritical implicit data or replace it with scheduled explicit messaging.

Increase RPI only for suitable implicit connections

A larger RPI means fewer cyclic packets per second. A reported remote-rack installation improved reliability by increasing RPI to at least 80 ms. That value is a test point, not a universal setting; the acceptable interval comes from the process response requirement and the connection's timeout behavior.

1. Select one noncritical connection and note its present RPI, timeout setting, and observed packet-loss rate.
2. Increase its RPI in a controlled step. If the application can tolerate 80 ms, use that reported value as a diagnostic trial.
3. Download or apply the configuration using the required controller procedure, then monitor connection status and radio utilization.
4. If utilization falls and the connection stabilizes, repeat the capacity calculation for the remaining connections.
5. If faults remain while utilization is low, investigate RF loss, latency variation, routing, or radio failover rather than increasing RPI indefinitely.

The reported installation also used a timeout multiplier of 4 where the connection permitted it. Read the configured timeout behavior before changing it. A longer timeout can reduce nuisance disconnects, but it also delays declaration of a real communication loss.

One installation observed an implicit I/O connection dropping after three consecutive missed packets. That is not the fault by itself; the fault is that the connection's packet-loss sequence exceeded its configured timeout budget. Extending the budget does not create bandwidth or recover missing data.

Move noncritical data to explicit messaging

If the application only needs periodic values, use explicit CIP with MSG instructions. This creates the poll/response behavior required on a slow link: trigger one request, wait for completion or error, then advance to the next request.

1. Group related data so each transaction returns useful blocks instead of many isolated tags.
2. Create a round-robin sequence with one active message at a time.
3. Trigger the next message only after the active instruction reports completion or error.
4. Place a timer between cycles to set the remote update interval.
5. On error, record status, delay the retry, and limit consecutive retries so one unreachable station cannot monopolize the channel.
6. Expose communication health, last successful update, and data-valid state to SCADA.

Do not trigger MSG instructions every program scan. A controller upgrade can expose this mistake because faster routine execution produces requests faster than the network can clear them. Slowing the entire routine may reduce traffic, but gating each message by completion and a timer fixes the request mechanism directly.

Explicit messaging needs an addressable controller or device at the remote end. It also moves loss handling into your program: when the link fails, retain, invalidate, or replace stale values according to the process requirement.

Buffer SCADA data at the radio boundary

If SCADA controls the polling pattern poorly, place a controller or gateway between the fast local network and the slow radio path. Poll remote stations in a simple sequence, store results in local tags, and let SCADA read that local image. Maintain a separate outbound data set for commands or setpoints.

This buffer decouples two rates:

• The local controller-to-SCADA side can update at the rate required by displays and historians.
• The narrowband side runs at a rate the 20 kbps link can sustain.

Configure SCADA scan groups deliberately even with a buffer. Reduce duplicate tags, avoid unnecessary page-driven requests, group related values, and limit concurrent connections. Switching to Modbus can help because its normal request/response pattern is naturally scheduled, but a protocol change does not fix an uncontrolled polling loop. An asynchronous Modbus interface can isolate the controller scan from completed radio handshakes when that architecture fits the installed hardware.

Do not carry critical control or safety I/O across this wireless path merely because a slower RPI appears stable. A reported preference of 150 ms for a safety card is installation experience, not authorization for a safety architecture. Validate safety communication against the approved hardware, risk assessment, and required safety documentation.

Implement the resolving branch and verify it

1. Preserve only the implicit connections whose cyclic behavior is operationally required.
2. Increase RPI for suitable noncritical implicit connections, starting with a measured 80 ms trial only where the process tolerates it.
3. Convert periodic noncritical transfers to completion-driven, timer-paced MSG sequences.
4. Add a buffering controller or gateway if SCADA cannot be made to poll predictably.
5. Set SCADA scan groups and historian rates so their combined demand stays below measured usable throughput.
6. Test normal traffic, a temporarily unavailable remote station, message errors, and radio recovery. Confirm that retries remain bounded and other stations continue updating.
7. Trend radio utilization, retries, PLC connection status, message completion time, last-good-update age, and stale-data indication during the test.

Pass the change only when the link remains stable at peak application demand, every data item meets its required update interval, and communication loss produces the intended process response. Redundant radios on separate channels can improve availability where supported, but failover does not correct sustained bandwidth overload.

FAQ