Search the field guide, causes, requirements, and glossary

Time is distance.

Widening a timeout so a connection survives the roam is paid for in meters a vehicle travels before it starts to stop.

Every millisecond of timeout is distance.

When a network engineer hears “widen the timeout,” it sounds free. The connection stops faulting on every roam, the line stops stopping, everyone goes home. On a vehicle it isn’t free. The vehicle keeps moving while the controller waits to decide the network is gone.

The arithmetic is short. Distance traveled before the stop begins is speed times the wait. At 30 mph, which is 13.4 m/s1, a 40 ms wait, the documented default for a CIP Safety input connection, covers about half a meter. Widen it to 500 ms so it rides through a slow roam, and the same vehicle covers about 6.7 meters before anything begins to stop. Braking distance comes on top of that.

Time is distance: a vehicle at 30 mph

Distance covered while the timeout runs, before the stop begins, then while braking.

Drawn to scale

40 msCIP Safety default0.54 m before the stop begins+ 29.97 m braking = 30.51 m500 msassumed timeout6.71 m before the stop begins+ 29.97 m braking = 36.68 m0510152025303540meterswhile the timeout runsbraking at an assumed 3 m/s²

30 mph is 13.41 m/s. Distance before the stop begins = speed × timeout; braking distance = speed² ÷ (2 × deceleration). The 500 ms timeout and the 3 m/s² deceleration are assumed for the arithmetic only; real values come from the machine builder's risk assessment. Onboard reaction time is left at zero.

Sources: NIST SP 811, Appendix B9, constant-acceleration kinematics, and the CIP Safety default limit.

Some devices travel above 30 mph, typically autonomous bots. Today an onboard function watches the network and stops the vehicle after a timer. Before that, it wasn’t thought of, and it caused accidents. That’s why I don’t treat this as a math exercise.

Here’s the line I’d draw. A properly designed safety system treats the network as untrusted. Late or missing packets force a stop, so wireless trouble shows up as downtime, not as a hazard. The dangerous case is different: a vehicle whose ability to stop depends on a message arriving. A disconnect with no safety features for stopping is a major safety concern, and no amount of Wi-Fi tuning fixes it. That is a system design gap. The safety over wireless guide walks through it.

So the trade has owners. The controls engineer and the machine builder decide how long a vehicle may wait and what it does when the wait runs out, from their risk assessment and the standards that apply. The wireless engineer’s job is to know those two numbers for every vehicle, and to deliver an outage budget that fits inside them.

Safety over wireless needs very low roam times to avoid safety timeouts. The alternative is a wider timeout, and that one is paid for in meters.

Run your own numbers in the timing budget calculator.

About this page

Built from 2 sources: 1 standards body or lab and 1 vendor document. Researched and drafted with AI assistance, then reviewed and approved by Ben Rutter on . How pages are made

First published
Last updated
Change history (1)
  • First published
Cite this page

Plain

Ben Rutter. "Time is distance.." OT Wireless, published October 5, 2026. https://otwireless.com/perspectives/time-is-distance/

APA 7

Rutter, B. (2026, October 5). Time is distance.. OT Wireless. https://otwireless.com/perspectives/time-is-distance/

BibTeX

@misc{rutter2026timeisdistance,
  author = {Rutter, Ben},
  title = {{Time is distance.}},
  year = {2026},
  howpublished = {\url{https://otwireless.com/perspectives/time-is-distance/}},
  organization = {OT Wireless},
}