Fixed and rotating wireless I/O
Wi-Fi can carry cyclic I/O to a turntable, a tool changer or a skid that never leaves its cell, but a fixed link still drops from moving metal, shared channels and multicast, so you prove it with long runs measured against the connection timeout.
A machine that turns in place still needs every I/O packet on time. Wi-Fi can stand in for a slip ring or a cable that is hard to run. The link it leaves is fixed, but the radio environment around it is not, and it drops for most of the reasons a roaming link does.
What it carries
Cyclic I/O. A controller, the PLC, exchanges inputs and outputs with remote I/O on a fixed interval, every cycle, for as long as the machine runs. On EtherNet/IP these are implicit I/O connections, which can be unicast or multicast. On PROFINET they are cyclic real-time frames sent at an update time.
Machines that stay put. A validated design guide for EtherNet/IP over Wi-Fi, from Rockwell Automation and a Wi-Fi vendor, names two cases. Fixed-position wireless replaces cable where cabling is too expensive or impossible, such as a stand-alone machine or skid. Equipment that moves without roaming includes rotary platforms and turntables, assembly systems on tracks, and overhead cranes. Siemens’ PROFINET manual lists rotating machines, translation stages and conveyor lines among its wireless examples.
Not every PROFINET class. PI allows wireless only in conformance classes A and D, and devices behind access points do not support IRT, PROFINET’s isochronous class. Wireless I/O is standard real-time I/O, not synchronized motion.
What it needs from the network
Every packet before the connection’s timer runs out. A Logix controller drops an EtherNet/IP I/O connection after the RPI times a multiplier of at least 4, and never in less than 100 ms1. A PROFINET device at a 2 ms update time declares a failure after 6 ms without data2 at the default threshold of 3. The timing budget guide turns those numbers into an outage budget, and the EtherNet/IP and PROFINET entries hold the sources.
Slower cycles than the wire. PI notes that wireless reduces the update rate and the number of clients per access point. Siemens says you may have to increase the update time for wireless devices. The EtherNet/IP design guide warns that RPIs below 10 ms may not be appropriate3 and caps a channel at 2,200 packets per second of EtherNet/IP traffic.
No long runs of loss. A timeout comes from excessive latency or the loss of several packets in a row from the same connection. PROFINET’s threshold works the same way: a disturbance of two cycles is tolerated, and a longer one ends the connection. An isolated lost packet is survivable. A run is not.
How wireless fails it
Fixed links can be very good. In the design guide’s lab tests of its non-roaming design, with 4 or 12 bridges, average latency was 1.5 ms or less, 99.99% of samples arrived within 10 ms, and CIP Class 1 loss was 0.05% or less. Those are the vendors’ own tests. The same guide warns that a very small percentage of packets can be delayed enough to be unusable. At a 10 ms RPI, one packet in 10,000 is one every 100 seconds. Whether those late packets arrive alone or in a run decides whether the machine stops.
The client moves relative to the access point. Turntables can need rapid changes in the client’s position and orientation relative to the access point. The antenna’s view of the access point changes with every degree of rotation.
Metal moves through the path. When a large object blocks the direct path, the link may be lost, NIST notes. Robot arms, guard doors and the parts on the table are all candidates. See moving metal.
The channel is shared. The design guide counts all traffic in the channel, including neighboring WLANs on the same channel. A short link still contends with every radio that hears it. See co-channel contention and neighboring networks.
The network changes under you. The guide lists off-channel scanning, periodic security re-association, channel switching, persistent interference and radar among the events that cause significant delay and loss. Each has a cause page: automatic channel changes, key rotation and radar events.
Multicast I/O. Over Wi-Fi, multicast frames are not acknowledged and not repeated if lost. A lost multicast I/O frame stays lost. See multicast and DTIM with implicit I/O.
Design implications
Unicast only. The design guide is plain: use only unicast connections with wireless I/O.
One channel for the cell. Use a dedicated channel for the control application, not shared with applications under different administrative control. Prefer one without radar detection, since radar is on the guide’s list of disruptive events.
Aim from the side that does not move. NIST notes that directional antennas perform better when the direction of transmission is fixed. On a turntable, only one end is fixed. Siemens adds that on a point-to-point link the antennas determine the range and characteristics of the RF field.
Send fewer packets. The guide’s most efficient case is one wireless packet in each direction per cycle. Run the cycle no faster than the process needs, then recompute the timeout with the timing budget tool.
A second path for critical cells. The guide calls for redundant infrastructure for critical wireless applications. See redundant radio paths.
Safety I/O is not your setting. If the rotating side carries PROFIsafe or CIP Safety, its watchdog and reaction time come from the machine builder’s risk assessment. This page covers availability. The safety over wireless guide explains the boundary.
IO-Link Wireless beside Wi-Fi. For sensors and actuators on the moving part, IO-Link Wireless is a non-Wi-Fi option, standardized as IEC 61139-3:20234. Its specification gives a minimum cycle time of 5 ms with up to 32 octets of payload5, up to 40 devices per master and three masters per cell, and 10 dBm EIRP with a range of up to 20 m, or 10 m with more than one track. The community pitches it for rotary units, carousels and tool changes.
Its headline reliability, a failure probability of 10⁻⁹, is a calculation for a link of about 20 m in a fading channel with three statistically independent attempts. That is the specification’s model, not a measurement in your cell. It also runs in 2.4 GHz with 1 MHz channel spacing and coexists by blocklisting WLAN channels. Give it your Wi-Fi channel list, or keep the cell’s Wi-Fi in 5 GHz.
How to validate
Run long. The design guide’s tests ran continuously for one to two weeks to catch connection losses and maximum values. A one-hour test shows you the average.
Probe from the wired side. Measure what the controller sees, from the controller’s side of the link. The method is in how to measure a roam gap. There is no roam here, and the same probe catches every gap.
Record the longest gap and the longest run of losses. The loss rate alone hides them. The guide’s own tests passed only with no more than 2 packets lost in a row. Compare your longest run with the connection timeout.
Test every position. Run the table through every index position and through continuous rotation. Open the guard doors and run the robots while you measure.
Watch the retries. The design guide treats retries above 2% at the access point or 5% at the bridge as a sign of too many packets or RF trouble.
Write it down, then keep watching. The acceptance test plan turns these checks into a signed test. After that, NIST recommends that the operating network be continually monitored.
A fixed link earns its place on the worst minute of a two-week run, not on the average of a good afternoon.
About this page
Built from 8 sources: 1 standards body or lab, 4 protocol owners and alliances and 3 vendor documents. Researched and drafted with AI assistance. How pages are made
- First published
- Last updated
Change history (1)
- First published
Cite this page
Plain
Ben Rutter. "Fixed and rotating wireless I/O." OT Wireless, published October 8, 2026. https://otwireless.com/applications/fixed-and-rotating-wireless-io/
APA 7
Rutter, B. (2026, October 8). Fixed and rotating wireless I/O. OT Wireless. https://otwireless.com/applications/fixed-and-rotating-wireless-io/
BibTeX
@misc{rutter2026fixedandrotatingwirelessio,
author = {Rutter, Ben},
title = {{Fixed and rotating wireless I/O}},
year = {2026},
howpublished = {\url{https://otwireless.com/applications/fixed-and-rotating-wireless-io/}},
organization = {OT Wireless},
}