The timing budget: from RPI and watchdogs to a roam time you can design to

Your roam-time requirement is not a Wi-Fi number.

It is what is left of the application’s timeout after everything else on the path has taken its share. Start from the timeout. Subtract what the wired network and the endpoints need. The remainder is the longest outage your wireless design may ever cause, worst case, not average.

Wi-Fi will never be deterministic. The job is to prove the worst case fits inside the application’s timeout. This guide shows where those timeouts come from in the protocols you will meet on a plant floor, how to read their parameters, and how to turn them into a number you can design and test against.

Every cyclic connection carries a clock

Industrial I/O runs on a schedule. The producer sends at a fixed interval: the requested packet interval (RPI) on EtherNet/IP, the update time on PROFINET. The consumer tracks how long it has been since the last valid packet. Past a limit, it declares the connection dead, and the device goes to its fault or safe state.

Most limits are built from the interval, a count of packets you can afford to lose, and sometimes an allowance for delay. The names change by protocol. The structure barely does.

CIP Safety: the connection reaction time limit

CIP Safety is the safety layer that runs over EtherNet/IP. Its limit is the connection reaction time limit, which Rockwell Automation’s safety reference manual defines as the maximum age of safety packets on the connection. If a valid packet does not arrive within it, the connection times out and the data goes to the safe state, which is off.

Three parameters set it:

RPI. How often packets go on the network. The documented default for a safety input is 10 ms¹. For a safety output, the RPI is fixed at the safety task period.
Timeout multiplier. The number of RPIs to wait for a packet before declaring a timeout. At 2, one message may be lost as long as a packet shows up in every two RPIs. The manual says never to set it below 2 on a safety connection.
Network delay multiplier. An allowance that accounts for known delays on the network, shown as a percentage with a valid range of 10 to 600 and a default of 200².

The documented formulas are:

Input limit = input RPI × (timeout multiplier + network delay multiplier)
Output limit = safety task period × (timeout multiplier + network delay multiplier - 1)

The network delay multiplier is entered as a percentage but works as a plain multiplier, so 200% enters the formula as 2. The manual confirms it: at defaults, the input limit is 4 × RPI and the output limit is 3 × RPI.

Two worked examples:

Input, at defaults. 10 ms × (2 + 2) = 40 ms, the limit the manual quotes for default values.
Output, with a 20 ms safety task period and the same multipliers. 20 ms × (2 + 2 - 1) = 60 ms, from the output formula.

The default CIP Safety input connection reaction time limit, drawn to scale

The default CIP Safety input connection reaction time limit, drawn to scale
Item	Time	Against the budget
CIP Safety input limit, defaults (budget)	40 ms	Budget

Budget source: Rockwell Automation, Connection Reaction Time Limit (1756-RM015)

That 40 ms is the whole budget, not the wireless share of it. Everything between the producer and the consumer spends from it.

The manual also warns that the defaults can cause connection loss to safety I/O and sometimes have to be raised, with the new limit carried into the safety reaction time calculation. That decision belongs to the machine builder’s safety calculation, not to the wireless design.

The controller helps you measure. The safety view of each module’s properties shows the maximum observed network delay, which you can reset online and watch. That reading is evidence of what the path actually spends.

EtherNet/IP standard I/O: the RPI times a multiplier

Standard EtherNet/IP I/O uses the same idea with a single multiplier. The connection times out after the RPI multiplied by a connection timeout multiplier.

Beckhoff’s scanner documentation gives a plain example: a 20 ms cycle with a timeout multiplier of 4 detects an interruption after 80 ms³. Delta Motion’s documentation for its motion controllers lists support for multipliers from 4x to 512x⁴ and notes that a device that hears nothing for the timeout closes the connection.

Who picks the multiplier depends on the controller. On Logix controllers, Rockwell documents that the firmware selects it so the timeout is at least 100 ms, with a minimum multiplier of 4⁵. Its examples: a 2 ms RPI gets a multiplier of 64 and a 128 ms timeout, and a 10 ms RPI gets 16 and 160 ms. A 2008 Rockwell developer guide describes the same 100 ms minimum⁶, so the floor is long-standing.

Do not assume that floor anywhere else. Other controllers and scanners let you set the multiplier, and a fast RPI with a multiplier of 4 leaves far less room. OMRON’s NJ/NX controllers, for example, set the timeout at 4 to 512 times the RPI, 4 by default⁷, and require only that it be at least 10 ms. At a 10 ms RPI and the default multiplier, that controller gives up after 40 ms, where a Logix controller waits 160 ms. Read the value from the project, not from habit.

PROFINET IO: update time times accepted missed cycles

PROFINET calls its limit the watchdog time. Siemens defines it as the product of the update time and the accepted update cycles without IO data. When it expires, the IO device outputs substitute values and the controller reports a station failure.

PI’s PROFINET Design Guideline sets the standard threshold at 3 missed cycles: at a 2 ms update time an error is detected after 6 ms, and at 4 ms after 12 ms⁸. It recommends keeping 3 and, if you change it, checking that the response time in a fault is still short enough. The same guideline tells designers to adapt update times when using wireless.

Siemens says more about wireless. Its application note on managing watchdog factors calls adjusting the watchdog time advisable where WLAN is the communication medium. For wired rings running the Media Redundancy Protocol (MRP), it recommends a 200 ms watchdog⁹ so the ring can reconfigure. That is a useful sense of scale: a recovery mechanism built for wired networks needs a watchdog more than 30 times the 6 ms in the 2 ms example above.

PROFIsafe: the F-monitoring time is entered directly

PROFIsafe is the safety layer on PROFINET. Its limit is entered as a value rather than built from multipliers. The F-parameter F_WD_Time specifies a number of milliseconds for a watchdog timer that monitors reception of the next valid PROFIsafe message. In Siemens engineering it appears as the F-monitoring time, set centrally on the F-CPU or individually per F-I/O. On a communication error, all channels of the F-I/O are passivated.

Siemens states the trade-off as plainly as anyone. Monitoring times must be large enough not to trip in error-free operation, and small enough that the process safety time is not exceeded. PI puts wireless on the same terms: it is permitted as long as sufficient availability, with no nuisance trips, can be guaranteed.

For your budget, take the configured F-monitoring time as the starting number. The timing budget calculator accepts it directly.

Fleet managers and other application timeouts

Not every timeout lives in a PLC. Mobile robots also talk to a fleet manager, and that link runs its own clocks.

VDA 5050, the open interface between mobile robots and fleet control, runs over MQTT, a publish-subscribe protocol. In MQTT the keep-alive is set by the client and measured in seconds, and the broker must close the connection if it hears nothing for one and a half times that interval. VDA 5050 builds on this: the broker publishes a CONNECTION_BROKEN message when the heartbeat between broker and robot fails.

Two things follow for your budget. A heartbeat counted in seconds is unlikely to be the tightest timeout on a link that also carries I/O, so find the I/O and safety limits first. And the fleet timeout is not the vehicle’s behavior. Under VDA 5050, a robot that loses the broker keeps its order and continues up to the last released node. That is one design choice. Boston Dynamics documents another for Spot: during an automatic mission the robot continues on a lost connection until a controller supervision window runs out, 9 seconds by default, 30 seconds at the moderate setting, or 18.2 hours unsupervised¹⁰, and then sits and powers off its motors. The vehicle vendor makes these choices, so ask two questions in writing: what does the vehicle do when it loses the network, and how long does it wait before deciding?

The method: from timeout to outage budget

Every protocol above reduces to the same procedure.

List everything that rides the link. Safety connections, standard I/O, fleet traffic, and anything else the machine or vehicle needs to keep running.
Take the tightest configured timeout. Use the values in the project, not the defaults. Defaults are where the conversation starts.
Subtract what the rest of the path needs. Part of every limit is spent before the radio is involved: the producer’s interval, transport delay across switches and access points, and the consumer’s own processing. Measure it where the system exposes it, such as the maximum observed network delay on a CIP Safety connection.
What remains is the outage budget. It is the longest stretch without valid packets that the wireless network may ever cause, whether from a roam, a scan, a rekey, or retries queued behind a large transfer.
Test the worst case, not the average. A timeout fires on one gap. A design that roams quickly on average but stalls once a shift still stops the machine once a shift.

Where a timeout goes

Subtract what the rest of the path needs. What remains is the longest outage the wireless network may ever cause.

Schematic, not to scale

The method from this guide, drawn. The proportions are illustrative: every system splits its timeout differently, so measure each part on yours, then test the worst case against what remains.

Field note. Required roam time depends on what is connected and whether safety runs over wireless, such as CIP Safety. Safety over wireless needs very low roam times to avoid safety timeouts.

Why not just raise the timeout

The obvious objection: if Wi-Fi cannot fit the timeout, widen the timeout. Sometimes that is right, and the manuals allow for it. Rockwell notes that the defaults sometimes have to be increased.

But a timeout is not free slack. PI’s model of safety function response time adds, for the one part assumed to fail, the difference between its watchdog time and its worst-case delay. Lengthen the watchdog, and the worst-case response grows with it. That is why Siemens insists monitoring times stay small enough that the process safety time is not exceeded.

Time is also distance. A vehicle keeps moving while its controller waits for the timeout to expire.

Field note. Some devices travel above 30 mph. A disconnect with no safety features for stopping is a major safety concern. Those vehicles are typically autonomous bots. An onboard function now monitors the network and stops the vehicle after a timer. Before that, the case was not thought of, and it caused accidents.

At 30 mph, about 13.4 m/s, a vehicle covers roughly 1.3 m for every 100 ms of timeout before any stop begins. Whether that is acceptable is a question for the machine builder’s risk assessment and the applicable standards, not for the wireless design. Safety over wireless covers what fails safe and why time is distance at speed.

Run your own numbers

The timing budget calculator runs these formulas, draws the budget to scale, and converts it to distance for a moving vehicle. It is a planning aid. The values that count come from your project and from the machine builder’s safety calculation.

Raising the timeout is the machine builder’s call. Fitting inside it is yours.