Running a full IO-Link master with no hardware

Let’s say you want to exercise an IO-Link master’s stack. The ISDU parameter server, the cyclic process-data channel, the event path, data storage, all of them. And to do that you need a master, at least one device, the point-to-point wiring, power, and something driving the other end. The stack gets tested by hand, on a bench, and the regression coverage is thin.

LabWired lets developers run the whole exchange. A real master, devices, C/Q wire, all headless, in software, reproducible in a browser tab and on a GitHub CI runner.

How it works

Three virtual STM32L476 microcontrollers inside LabWired. One runs the iolinki master controller firmware; two run the iolinki device stack, each publishing its own process data (0xA5 and 0x3C). IO-Link is point-to-point, one device per master port, so these are separate MCUs, each with its own address space, wired by a modeled C/Q link.

The master’s real stack drives the wire, the device’s stack answers, the bytes cross a simulated UART, and the master checks what came back — the same firmware you’d compile for the silicon, running against itself over a simulated cable.

The full service surface

Reaching OPERATE and reading a cyclic process-data byte is the easy part. The point of a master stack is to run the whole surface on the wire. The test asserts each one completes after the link reaches OPERATE:

Service	What crosses the wire
ISDU read / write	Acyclic parameter access — vendor-name index 0x0010 reads back "LABWIRED"
Cyclic process data	The master’s PD-out byte is echoed back as the device’s PD-in (actuator mirror)
Events	A device WARNING event (0x8CA0) is triggered and read back
Data storage	An Application-Tag record is written and read back byte-for-byte

And because a master that only works when the wire is perfect isn’t a master, three fault paths are covered on the same modeled wire: a single CRC-corrupted frame is survived in place (the master retries and stays in OPERATE); sustained corruption exhausts the retry budget and drives the port to ERROR + restart; and a muted device is detected via response-timeout, instead of the port spinning as if all were well. Startup, cyclic data, acyclic services, events, storage, and the failure modes — the whole master, over a cable that only exists in software.

Try it! In your browser

The actual firmware, compiled to a WebAssembly build of the simulator, running in the frame below. Press Run; all three boards boot together and step in lockstep. Click a sensor board to watch it reach OPERATE and publish its process-data byte to the master.

The receipts

The browser lab and the CI model are the same firmware and the same simulator core, so the exchange in the tab above also runs headless on a CI runner, byte-checked, on every push. The iolink-native-c-master job boots the real master against the real device stack and asserts every service completes on the wire, green, in under two minutes, with no hardware in the loop.

A real IO-Link master, exercised across its full service surface by real device firmware, over a wire that only exists in software. Runnable, testable and observable in a browser tab, and gated in CI. No bench, no PLC, no cable.