IO-Link Wireless: Industrial Sensor Network Architecture

Cables fail in exactly the places where machines move. A gripper on a robot flange, a sensor on a rotary indexing table, a tool on an automated tool changer: each one pushes copper through connectors and slip rings that wear out long before the machine does. IO-Link Wireless replaces the last few metres of that cable with a 2.4 GHz radio link that keeps the semantics of wired IO-Link, including its process data model, its parameter access and its device description files, while targeting a 5 ms cycle and a residual error probability of 10^-9.

It matters now because the specification is mature. The radio extension was first published by the IO-Link community in 2018, and was published as IEC 61139-3 in November 2023. The 2025 specification package lists System Extensions V1.1.3, with a Wireless System Extensions draft D1.1.4 in review for 2026. Vendors ship masters, bridges and hubs. What is missing in most explanations is the engineering detail: how the cycle is actually built, what happens when Wi-Fi shows up, and where the design stops working.

This article takes the architecture apart and then helps you decide when to use it.

What this covers: the standards landscape, the W-Master and W-Device roles, the F/TDMA cycle arithmetic, retransmission and coexistence behaviour, bridges and hubs, fieldbus, OPC UA and MQTT integration, a comparison with wired IO-Link and other wireless options, failure modes, and a deployment checklist.

Last Updated: October 2026

Context and Background

IO-Link is the dominant point-to-point interface between a control system and the lowest tier of devices: proximity sensors, valves, grippers, light stacks, RFID heads. A device connects to an IO-Link master over a standard three-wire sensor cable, with a maximum cable length of 20 m, and the link carries 24 V power, a switching or communication line and ground. The wired standard is IEC 61131-9, “single-drop digital communication interface for small sensors and actuators” (SDCI). The master aggregates ports (typically four or eight) and talks to the PLC over PROFINET, EtherNet/IP, EtherCAT, or another fieldbus. Wired IO-Link runs at three transmission rates, COM1 at 4.8 kbaud, COM2 at 38.4 kbaud and COM3 at 230.4 kbaud, and each device ships with an IODD (IO Device Description), an XML file that tells engineering tools what its process data and parameters mean.

That model solved the parameterisation and diagnostics problem of analog and binary wiring. It did not solve the mobility problem. Anything that rotates continuously, moves on a vehicle, is swapped automatically, or sits where a cable would be crushed needs a different transport. Before IO-Link Wireless the usual answers were inductive couplers, slip rings, or a proprietary radio. Each of those either limited speed, added wear, or abandoned the IO-Link data model.

IO-Link Wireless is the community’s answer. It reuses the wired application layer: a W-Device presents the same kind of process data and on-request data (ISDU, indexed service data units) as a wired device, which means the same IODD tooling and the same PLC function blocks apply. The standard itself is IEC 61139-3:2023, titled “Industrial networks, single-drop digital communication interface, part 3: wireless extensions”. Per the IO-Link Community, wireless devices are backward compatible with the IO-Link V1.1 sensor profile, which is what lets a bridge attach a wired device to a wireless master.

If you are mapping the surrounding landscape, two sibling posts are worth reading first: private 5G vs Wi-Fi 7 vs TSN for factory wireless covers the plant-level radio layer, and Ethernet-APL reference architecture shows what the equivalent move looks like for process instrumentation. IO-Link Wireless sits below both: it is a cell-level sensor and actuator network, not a plant backbone. The IO-Link Community and IEC specifications are the primary references, listed at the end.

A note on terminology that trips people up. The IO-Link Community describes IO-Link Wireless as specified in IEC 61131-9 on some pages, because the wireless system extends the same SDCI family. The dedicated wireless part is IEC 61139-3. When you write a requirements document, cite IEC 61139-3 for the radio and the IO-Link Wireless System Extensions version, and IEC 61131-9 for the shared application layer.

IO-Link Wireless Reference Architecture: W-Master, Tracks and W-Devices

IO-Link Wireless is a star network. A W-Master base station owns one to five radio tracks. Each track is a frequency channel shared by up to eight W-Devices through time-division multiple access, so one master serves up to 40 devices, and up to three masters can overlap in one radio cell for roughly 120 devices. The master connects upstream to a fieldbus or Ethernet; the devices are usually line-powered sensors and actuators.

Figure 1: IO-Link Wireless reference architecture. A W-Master presents up to five tracks of eight W-Devices each and gateways to the fieldbus, engineering tools and the edge.

Figure 1 shows the whole system. The PLC or industrial PC sees the W-Master as an ordinary IO-Link master on a fieldbus. Below the master, the radio side is a strict star: there is no mesh, no device-to-device forwarding and no routing. That is a deliberate choice. A mesh network gains range at the price of unbounded, load-dependent latency, and a 5 ms deterministic cycle cannot survive that trade.

Roles: W-Master, W-Device, W-Bridge, W-Hub

The W-Master is the base station. It connects to the backend over a wired fieldbus or Ethernet link, hosts the radio tracks, defines the hopping sequence, schedules every slot, and shares the sequence with devices at commissioning. Because it owns the schedule, no device ever contends for the medium, which is what separates it from Wi-Fi or Bluetooth in the control path.

A W-Device is the wireless end node. Two device classes are defined at the data layer. An SSlot W-Device occupies a short slot with 2 octets of payload (1 excluding the protocol control octet), suited to switches and simple actuators. A DSlot W-Device carries 15 octets (14 excluding protocol control), which fits a smart sensor with a few values. Wireless process data is therefore small by design; the radio is not a bulk transport.

A W-Bridge connects exactly one existing wired IO-Link device to the wireless master, using a backward-compatible wired port. A W-Hub connects several devices, and the specification itself does not define it, though some vendors ship one for backward compatibility. Balluff, for example, lists a bridge with 32 bytes in and 32 bytes out and a hub with 2 bytes in and out, and quotes a range of up to 10 m with multi-track masters and 20 m for single-track masters. The bridge is what makes retrofit plausible: keep the proven sensor, replace only the cable.

The physical layer

The radio is derived from the Bluetooth ecosystem. The published description uses the 802.15.1 (2005) radio PHY with Gaussian frequency shift keying (GFSK), modulation index 0.5, a 1 Mbit/s on-air rate, and 1 MHz channels. The band is 2.401 to 2.480 GHz, giving 80 RF channels of which up to 78 carry cyclic data. Maximum transmit power is 10 dBm (10 mW) EIRP and the required receiver sensitivity is -94.5 dBm or better.

Those figures set the physical envelope. At 10 mW, range is tens of metres at best, which matches the quoted 20 m for a single-track cell and about 10 m when several tracks run. The cell is a machine, not a building. That small footprint is also the reason the technology coexists tolerably well: the radiated energy stays low and short-lived.

The F/TDMA cycle, in actual arithmetic

The reason IO-Link Wireless can promise determinism is that the cycle is a fixed time grid. From the silicon-vendor documentation of the specification: a W-Cycle lasts 5 ms and is divided into three W-Sub-Cycles of 1.664 ms each. Inside each sub-cycle:

Element	Duration
RX to TX switching	208 µs
Downlink (master to devices)	416 µs
TX to RX switching	208 µs
Eight uplink slots (96 µs plus 8 µs guard each)	8 x 104 = 832 µs
Sub-cycle total	1,664 µs

Add the pieces: 208 + 416 + 208 + 832 = 1,664 µs. Three sub-cycles make 4,992 µs, so the nominal 5 ms cycle leaves an 8 µs margin. One downlink broadcast serves all eight devices on the track; each device then answers in its own fixed uplink slot. A frequency hop is synchronised at the start of every sub-cycle, which is the mechanism that produces the diversity discussed below.

The eight uplink slots are the reason a track holds eight devices: eight 104 µs slots plus the downlink and two turnaround gaps fill the 1.664 ms sub-cycle exactly. The same budget is why wireless payloads are small. Sizing the slot for more data would lengthen the sub-cycle and the 5 ms cycle with it, so the specification trades payload for cycle time. (The exact frame structure is in the System Extensions document and is not reproduced here.)

Why this is not just “Bluetooth in a factory”

Bluetooth Low Energy uses a connection-oriented scheme with connection intervals negotiated per link, and its application layer has no notion of a fixed, master-owned multi-device grid with guaranteed slots. IO-Link Wireless borrows the radio and discards the access scheme. The master transmits one downlink frame per sub-cycle and every uplink position is pre-assigned. Compared with Wi-Fi’s carrier-sense contention, the upper bound on latency is a property of the schedule rather than of the load.

Deeper Analysis: Reliability, Hopping and Coexistence

How does IO-Link Wireless reach a 10^-9 error target? It combines three things: a fixed schedule with no collisions between its own devices, automatic retransmission within the same W-Cycle on a different frequency, and adaptive blacklisting of congested channels. The 10^-9 figure is a W-Cycle error target comparable to wired communication, not a guarantee against a jammed band.

Figure 2: One W-Cycle with a lost uplink in sub-cycle 1, a synchronised hop, and a successful retransmission on a different frequency in sub-cycle 2.

Retransmission and the spare-sub-cycle logic

A peer-reviewed description of IO-Link Wireless in the Journal of Sensors and Sensor Systems (2022) states that lost packets are repeated automatically for a configurable number of retries, and that retransmissions use a different frequency outside the typical coherence bandwidth so repeats can be treated as independent. The silicon-vendor description adds that failed acknowledgements trigger retransmission on different frequencies within the remaining sub-cycles.

Here is why that matters numerically. The following example is illustrative, not measured. Suppose a device sees a per-attempt packet loss of 1% because Wi-Fi is active on the channel. If attempts were independent, three tries in one W-Cycle give a residual loss probability of 0.01^3 = 10^-6. Suppose instead hopping lands on cleaner channels most of the time and the average per-attempt loss is 0.1%. Then three tries give 10^-9, which is the quoted target. The independence assumption is doing the work: if interference is wideband or correlated across the hop set, the attempts are not independent and the maths degrades. That is the real engineering risk, and it is why channel blacklisting is not optional on a busy floor.

Hopping and blacklisting

Each sub-cycle begins with a synchronised hop. The master sets the hopping sequence and shares it with devices at commissioning. Congested channels can be blocklisted manually, or the master can adjust the sequence adaptively. The IO-Link Community describes this as blacklisting with optional frequency hopping.

Consider a worked coexistence example, again illustrative. A 20 MHz Wi-Fi channel occupies roughly 20 of the 80 1 MHz channels, and the common non-overlapping plan (channels 1, 6, 11) covers about 60 of them. If a factory runs all three 2.4 GHz Wi-Fi channels at high duty, only about 20 channels remain clean. A hopping set limited to those 20 channels still offers frequency diversity, but fewer independent retries. Moving the Wi-Fi access points to 5 GHz or 6 GHz frees the 2.4 GHz band for control traffic. That one change is usually worth more than any radio tuning.

Handover and multi-master cells

Because three masters can run in one cell and one master can host five tracks, mobile devices can move between coverage areas. The IO-Link Community describes a defined handover mechanism between masters and states that there is no speed limit for mobile devices within a cell. The practical consequence for a robot cell or AGV is that a W-Device keeps its identity while the master that serves it changes. Whether handover is seamless to the PLC program depends on how the integration layer maps device identity to process image offsets, which is a vendor-specific integration concern that you should test in a trial.

Latency budget for a real cell

A 5 ms cycle is not the same as 5 ms control latency. Here is a rough budget for a gripper command, again illustrative and dependent on the vendor stack:

Stage	Typical contribution
PLC scan to fieldbus output	one PLC cycle, often 1 to 10 ms
Fieldbus to W-Master buffer	under one fieldbus cycle
Wait for next downlink	0 to 1.664 ms
Radio transfer and device processing	under one W-Cycle
Device output to actuator	device specific

The worst case is roughly one PLC cycle plus up to about 5 ms for the wireless leg, more if retransmissions are used. For a gripper that closes in 100 ms that is irrelevant. For a fast servo feedback loop it is disqualifying, which brings us to the comparison with other options.

Integration: IODD, Fieldbus, OPC UA and MQTT

IO-Link Wireless integrates the same way wired IO-Link does. The W-Master appears to the PLC as a standard IO-Link master on PROFINET, EtherNet/IP or another fieldbus, device parameters are described by IODD files, and above the cell an edge gateway can expose values through OPC UA or MQTT. The radio is invisible to the application as long as the device fits the small payload model.

Figure 3: Two data paths from a wireless sensor. The cyclic path goes to the PLC over a fieldbus, while the contextual path goes via an edge gateway to OPC UA, MQTT and the unified namespace.

Cyclic path and parameter path

IO-Link separates cyclic process data from acyclic on-request data. Process data is what the PLC reads every cycle: a switching state, a measured value, a status bit. On-request data (ISDU) carries parameters, identification and diagnostics and is read or written by service call, not on every cycle. In wired IO-Link this split is cheap. In IO-Link Wireless it is more constrained because the uplink slot is tiny, so bulk parameter downloads are slower. Teams that expect to push a 2 KB parameter set to a wireless sensor mid-production should test that against the cycle budget.

IODD in practice

The IODD is an XML description of process data layout, parameter indices, value ranges and menus. Engineering tools such as a PLC vendor’s configurator import it to generate the process image and a parameter UI. The 2025 package lists the IODD specification at V1.1.5 and an IODD Checker, so conformance can be validated before you commit to a device. For wireless, the IODD is the same artefact as for a wired twin of the device, and a bridge exposes the wired device’s IODD unchanged. That is a large commissioning advantage over proprietary radios, which usually ship a bespoke configuration tool.

OPC UA, MQTT and the unified namespace

Most operations technology teams want sensor data above the PLC too. The IO-Link Community publishes a JSON integration specification (listed as V200 in its downloads) for reading master and device data over a REST-style interface, which is commonly used to feed an edge gateway. From there the pattern is the one covered in OPC UA vs MQTT Sparkplug B and the unified namespace architecture: publish a typed, retained value under a stable topic or node path, and let the namespace carry device identity and context. A wireless device deserves one extra piece of context that wired devices do not: link quality. Publishing receive signal strength, retry counts and the current blacklist next to the process value turns the radio from a black box into something an analytics service can monitor.

For a digital twin, that radio telemetry is also a data quality signal. A reading with a rising retry count may be stale or intermittently missing, and a twin should down-weight it. The brownfield Modbus to unified namespace article covers the gateway side of that pattern.

How IO-Link Wireless Compares: Wired IO-Link, WirelessHART, BLE, Wi-Fi and 5G

Choose by payload, cycle time and mobility. IO-Link Wireless is strongest for many small, cyclic values in one machine cell that must be as deterministic as a cable. It is weaker for large payloads, long range, battery life of years, and any link that crosses a plant. The table compares the options on the dimensions that decide real projects.

Figure 4: A selection flow for sensor connectivity. IO-Link Wireless is the answer when a cable is impractical, cycle and error targets are tight, and the payload per device is small.

Attribute	Wired IO-Link	IO-Link Wireless	WirelessHART	BLE	Wi-Fi 6 or 7	Private 5G URLLC
Medium	3-wire cable, 20 m max	2.4 GHz, about 10 to 20 m	2.4 GHz mesh	2.4 GHz	2.4/5/6 GHz	licensed or shared spectrum
Access scheme	point to point	master-owned F/TDMA	TDMA mesh	connection events	contention	scheduled
Typical cycle	cable-bound, often a few ms	5 ms nominal	hundreds of ms to seconds	tens of ms and up	variable	targets low ms
Payload per device	up to 32 octets of process data	1 to 14 octets	small	small to moderate	large	large
Topology	star by port	star, 40 per master	self-healing mesh	star or mesh	star	cellular
Device power	line powered	line powered, battery possible	battery, years	battery	mains or battery	module dependent
Deterministic	yes	by schedule	bounded, slow	no	no	by configuration

Several of those cells need qualification. The wired payload figure reflects that IO-Link defines up to 32 octets of process data per port. The cycle times for WirelessHART, BLE and Wi-Fi are order-of-magnitude statements, not specification values, and vary with configuration. WirelessHART’s own limits come from its slotted mesh with 10 ms slots, which is why it targets process monitoring, not discrete control. The private 5G vs Wi-Fi 7 vs TSN decision article and the piece on 5G RedCap for industrial IoT go deeper on the cellular side.

Versus wired IO-Link

Wired IO-Link has the advantages of simplicity and power. It supplies 24 V to the device, needs no radio planning, and has no spectrum. IO-Link Wireless is not a general upgrade; it is a specialised answer for moving or inaccessible points. A wireless port also costs more per point today, which is one reason many sites use wireless on perhaps a few percent of points: those on the tool, the rotor or the vehicle.

Versus WirelessHART and ISA100

These are process-industry sensor networks built for years of battery life and mesh resilience at update rates of seconds. They would be the right choice for a tank level transmitter across a refinery and the wrong choice for a gripper. Both share the 2.4 GHz band with IO-Link Wireless, so they appear in coexistence planning, not as alternatives.

Versus BLE and Zigbee

Bluetooth Low Energy suits phones, tags and configuration, and the UWB and BLE channel sounding article covers location use. For control, its connection events are negotiated per link and there is no master-owned multi-device grid with a guaranteed slot per device.

Versus 5G and Wi-Fi

Private 5G and Wi-Fi 7 are plant-level infrastructure with high throughput and, with the right configuration, bounded latency. They need an IP stack and a radio module in the end device, which is expensive for a proximity switch. The two layers are complementary: IO-Link Wireless collects the small values at the machine, and the W-Master’s Ethernet uplink rides the plant network. The deeper wired-Ethernet side of that story is in PROFINET vs EtherCAT vs OPC UA FX.

Where It Works: Application Patterns

The use cases follow from the architecture. Each one has a moving or hard-to-reach point, small payloads, and a tolerance of a few milliseconds.

Robot tooling and grippers. Vendors such as Zimmer Group and Balluff describe wireless modules that make existing IO-Link grippers wireless, and the Balluff page names robotics and gripper platforms as a prime application. The benefit is fewer cables across the wrist and no pass-through connector that has to survive millions of cycles. A tool changer has a related benefit: a wireless link survives the changer’s coupling events without contact wear, though power must still be delivered across the interface, by contacts or an inductive coupler.

Rotary tables and indexing machines. A sensor on a rotating fixture talks to a fixed master without a slip ring. The 10 mW power and 10 to 20 m range fit well because the geometry is fixed and short. Here the main design task is antenna placement, a topic with its own research literature on base-station placement for manufacturing cells.

AGVs and mobile platforms. Mobile devices can roam among masters with a defined handover. The practical issue is metal: a vehicle body, shelves and robot arms create multipath and shadowing, so use a site survey.

Wireless retrofit. Using a W-Bridge keeps the installed sensor base and replaces only the cable. This is the lowest-risk first deployment, because the IODD and PLC logic stay the same and the wired path can be restored.

Temporary and reconfigurable lines. Test stands and pilot lines change layout often. A wireless sensor network removes recabling from each change.

Safety

The wired IO-Link Safety extension is standardised as IEC 61139-2. The 2025 specification package lists safety system extensions for the wired system. Do not assume a wireless safety function is available, or acceptable for a given risk assessment, without confirming the current wireless extension and your notified-body requirements. This article treats wireless as non-safety.

Trade-offs, Gotchas, and What Goes Wrong

The honest summary is that IO-Link Wireless buys mobility with a handful of constraints that are easy to miss in a vendor brochure.

Small payloads are a hard ceiling. A DSlot device carries 14 octets of payload and an SSlot device one octet. A sensor that produces a waveform, an image, or a rich diagnostic record cannot stream it over this link. The consequence is architectural: wireless sensors should publish a few processed values, and anything heavier should use a different path.

The 5 ms figure is a floor, not a promise for every device. The community page describes 5 ms as the projected cycle time for future low-power devices. Vendors quote a minimum process data cycle of 5 ms, and one describes it as 1 byte per 5 ms. Check the datasheet for the cycle time of the exact device and number of tracks you will run, and measure it in your cell.

The 10^-9 figure is a design target, not a field guarantee. It assumes the independence between retries that frequency hopping is meant to create. A broadband jammer, a faulty microwave-band emitter, or a Wi-Fi network on all three common 2.4 GHz channels can break that assumption. The system degrades by dropping cycles, which the PLC sees as stale data, not as a communications fault, unless you build the check.

Range is short and geometry-sensitive. The quoted 10 m (multi-track) and 20 m (single track) are line-of-sight style figures. Metal enclosures, robot arms, conveyor frames and personnel shift the real number. A site survey with the real fixtures in place should precede any design that depends on the margin.

The 2.4 GHz band is crowded. IO-Link Wireless shares it with Wi-Fi, Bluetooth, Zigbee, ISA100 and WirelessHART. The coexistence mechanisms mitigate this but cannot create spectrum. A plant that has deployed dense Wi-Fi on 2.4 GHz for scanners and tablets is the single most common failure scenario.

Battery operation is possible but not what the standard optimises. The silicon-vendor description says battery operation is feasible but the standard is not optimised for long battery life. If a design needs multi-year coin-cell life, use a different technology for that point.

Security is not free. A radio link adds an attack surface that a cable does not. Treat the W-Master like any network device: restrict management access, keep firmware current, and segment its uplink. Confirm which authentication and encryption features the specific master supports and whether they are enabled by default, since that varies by vendor and this article does not assert a specific mechanism. The broader hardening mindset is covered in the OPC UA security hardening guide.

Device identity and replacement. With a wired master, a replaced device is recognised by its port. With wireless, a device is bound to a master by commissioning. Document the procedure for replacing a failed W-Device at 3 a.m. and test it, including how the PLC process image behaves while the new device pairs.

Regional radio approvals. Balluff lists radio licences for Europe, the UK, the US, Canada, Brazil and South Korea, with Mexico for some products. If you ship machines worldwide, a market without a listed approval is a blocker.

Anti-patterns

Putting safety-relevant interlocks on a link without a safety-rated wireless profile and a documented risk assessment.
Running a hopping set that overlaps the plant’s busiest Wi-Fi channels because the default blacklist was never tuned.
Treating the radio as transparent and not publishing link quality to the monitoring system.
Using a W-Master with five tracks in a cell without checking that the reduced multi-track range of about 10 m still covers every device.
Using wireless where a short cable would do. Cables are cheaper, powered and quiet.

Practical Recommendations

Start with the problem, not the technology. List the points on your machines that today cost you money because of cable wear, slip rings or recabling. Rank them by how often they fail and how long the line stops. Those are the candidates for IO-Link Wireless, and the first pilot should be the point with the worst failure history and the least safety significance.

Pilot with a W-Bridge on an existing device if you can. It keeps the IODD, the PLC logic and the sensor, and you can revert by plugging the cable back in. Run it in parallel with a wired reference for a few weeks and log the dropped-cycle count and the retry rate.

Do an RF survey first. Measure 2.4 GHz occupancy in the cell with a spectrum analyser during real production, not on a quiet Sunday. Decide which Wi-Fi access points can move to 5 or 6 GHz, and set the blacklist accordingly. Define the PLC behaviour on stale data: hold last value, fall to a safe state, or alarm after N missed cycles.

Instrument the link. Pull signal strength and retry counters from the master’s interface and publish them next to the process data in your namespace, so the digital twin and maintenance tools can see degradation before it becomes a stop.

Deployment checklist

[ ] Standards references recorded: IEC 61139-3 for the radio, IEC 61131-9 for the application layer, and the exact System Extensions version the vendor certifies against.
[ ] Device payload fits SSlot or DSlot limits, and acyclic parameter traffic is tested.
[ ] Measured cycle time and number of tracks confirmed against the datasheet.
[ ] RF survey completed under production load; Wi-Fi moved off 2.4 GHz where possible.
[ ] Blacklist and hopping configuration documented.
[ ] PLC stale-data and missed-cycle logic implemented and tested.
[ ] Link-quality telemetry published to the unified namespace.
[ ] Device replacement and re-commissioning procedure written and rehearsed.
[ ] Radio approvals verified for every market the machine ships to.
[ ] Master firmware, access control and network segmentation reviewed.
[ ] Safety functions excluded from the wireless path, or separately assessed.

Frequently Asked Questions

What is IO-Link Wireless?

IO-Link Wireless is the radio extension of IO-Link, standardised as IEC 61139-3:2023. A W-Master base station talks to wireless sensors and actuators called W-Devices in the 2.4 GHz band using a fixed time and frequency schedule, with a nominal 5 ms cycle and a residual error target of 10^-9. It keeps the IO-Link process data model and IODD description files, so engineering tools and PLC code work much as they do for wired IO-Link.

How many devices can one IO-Link Wireless master support?

A W-Master offers up to five tracks and each track serves up to eight W-Devices, which gives up to 40 devices per master. Up to three masters can operate in one radio cell, so roughly 120 devices per cell. Range drops from about 20 m with a single track to about 10 m when multiple tracks run, so the larger configurations suit compact machine cells and not wide areas.

Is IO-Link Wireless deterministic?

Within its own cell, yes by design: the master owns a fixed schedule of downlink and eight uplink slots in each 1.664 ms sub-cycle, and three sub-cycles make a 5 ms W-Cycle, so there is no contention among its devices. Determinism has limits: external interference can still cause lost cycles, and retransmissions use remaining sub-cycles. The 10^-9 error target depends on hopping providing independent retries.

Can IO-Link Wireless coexist with Wi-Fi and Bluetooth?

It is designed to, using frequency hopping, retransmission on different channels and blacklisting of congested channels. The band is shared with Wi-Fi, Bluetooth, Zigbee, ISA100 and WirelessHART. In practice, coexistence works best when you survey the band, move Wi-Fi to 5 or 6 GHz where possible, and blacklist the busiest channels. A dense 2.4 GHz Wi-Fi deployment reduces the independence that hopping depends on.

Can I connect my existing wired IO-Link sensors?

Yes, through a W-Bridge, which connects one wired IO-Link device to the wireless master and is backward compatible with wired IO-Link, or a vendor W-Hub for several devices (the hub is not defined by the standard). The sensor keeps its IODD. Check that the device’s process data fits the bridge’s data width, and that your master supports the required IO-Link wireless version, such as 1.1.3.

How do I get IO-Link Wireless data into OPC UA or MQTT?

The W-Master presents device data to the PLC through its fieldbus, and many masters also expose a REST or JSON interface that the IO-Link Community specifies for integration. An edge gateway reads values and publishes them as OPC UA nodes or MQTT topics, often Sparkplug B, into a unified namespace. Add link-quality metrics beside each value so the twin and monitoring tools can judge data quality.