P-07 — IO-Link

Smart sensors over a plain 3-wire cable.

Estimated 13 minutes.

The sensor problem

A classic 24 V proximity sensor gives you one bit: present or not. You cannot ask its serial number, change its switch point, or know it is dirty until the line stops. IO-Link upgrades that single wire into a full digital conversation — without changing the cable.

Designed for the bottom of the pyramid

Profinet, EtherNet/IP and EtherCAT all live one layer up — between PLCs, drives and remote I/O. IO-Link lives below them: between a remote I/O block (the master) and the actual sensor or actuator. It is the "USB for sensors", standardised as IEC 61131-9.

Point-to-point, not a bus

Every IO-Link device wires directly to one master port. No shared bus, no addresses, no termination. The master is the bridge that aggregates 4–16 ports onto a real fieldbus (Profinet, EtherNet/IP, EtherCAT…) and presents the data to the PLC.

Why no addresses?

The port IS the address. "Sensor on Master3, Port 5" is unambiguous — there is exactly one device on the other end. Replace it with a spare and the new device inherits the parameters automatically (data storage). No DIP switches, no commissioning tool.

Topology compared

IO-Link is point-to-point — each sensor is an independent link to the master.

Three speed grades

IO-Link defines three communication rates: COM1 (4.8 kbaud), COM2 (38.4 kbaud), COM3 (230.4 kbaud). The device picks one when it wakes up; the master adapts. Most modern sensors run COM2; high-bandwidth devices like RFID or vision use COM3.

Inspect the 3-wire cable

A standard M12 4-pin connector. Click each wire to see what it does — and why an IO-Link sensor still works on a port that only speaks classic 24 V.

Backward compatibility

You plug an IO-Link proximity sensor into a regular digital input card (no master). What happens?

Nothing — the sensor refuses to power up
It works as a plain PNP switching output (SIO mode)
It damages the input card
It works only after a firmware change

The wake-up pulse

When you plug a device into an IO-Link port, the master sends a brief low-level pulse on C/Q. An IO-Link device responds with a baud-rate negotiation; a classic sensor stays silent and the master falls back to SIO mode. This is automatic — no jumpers, no menus.

How long can the cable be?

IO-Link supports point-to-point cabling up to a maximum length. What is it?

5 metres
20 metres
100 metres

IODD: the device's passport

Every IO-Link device ships with an IODD (IO Device Description) — an XML file that describes its identity, process data layout, parameters, and diagnostic events. The master reads it once and the engineering tool instantly knows everything about the device.

IODDfinder: one registry for all

IODDs are hosted on iodd.io — a vendor-neutral registry maintained by the IO-Link Consortium. Engineering tools (TIA Portal, Logix, CODESYS, vendor masters) download IODDs from here automatically by Vendor ID + Device ID. No more chasing CDs.

Read an IODD

Tap each section to see how a sensor self-documents.

Two kinds of data

IO-Link traffic splits into Process Data — small, fast, exchanged every cycle — and Parameter Data — bigger, on-demand, used for setup and diagnostics. Knowing which is which is the key to using IO-Link well.

Process data is mapped, not requested

The master autonomously polls each port at the configured cycle and writes the latest process data into the PLC's I/O image. Your PLC code reads it like any other %I byte — no function block call, no overhead. This is what makes IO-Link feel as fast as a digital input.

Process vs parameter

Toggle each mode to compare cadence, size, and how the PLC accesses it.

Where does it go?

You want the PLC to change a sensor's switch point during a recipe changeover (once every 30 minutes). What kind of data is that?

Process Data — write it every cycle
Parameter Data — write via ISDU when the recipe changes
It cannot be done over IO-Link

Data storage saves you on a swap

When a device fails and you replace it with an identical model, the master automatically reloads the saved parameter set into the new sensor. No need to recommission, no need for a laptop on the floor. Maintenance pulls a spare from the cabinet, plugs it in, the line restarts.

Events: asynchronous diagnostics

Beyond cyclic data, devices push events: short circuit on C/Q, process value out of range, parameter inconsistency, lifetime exhausted. The master stores them in a per-port buffer. Reading that buffer is your first move whenever a port misbehaves.

A blinking master LED

A port LED on the master flashes red. The PLC still reads "valid" process data from that port. What is the most likely cause?

A short circuit on the cable
An active warning event the device pushed (e.g. dirty optics) — link is fine
The master is reaching end of life

Final challenge

A vibration sensor on Port 3 raises Event 0x8C10 "process value out of range" and the master drops the link. Which is the most useful first diagnostic step?

Re-address every device on the bus
Read the device identity (Vendor/Device ID) and the last events from the master's Port 3 — only Port 3 is affected
Replace the master — all ports are down
Add a bus terminator to Port 3

What you learned

IO-Link is point-to-point — no addresses, no bus, one device per master port (max 20 m).
Three baud grades (COM1/2/3); device negotiates on the wake-up pulse.
Standard M12 3-wire cable: L+ (brown), L− (blue), C/Q (black). Falls back to SIO mode.
IODD XML self-describes identity, process data, parameters, and events. Hosted on iodd.io.
Process data: cyclic, mapped into the PLC I/O image. Parameter data: acyclic, ISDU-addressed.
Data storage auto-restores parameters on device swap.
Faults are isolated per port — diagnostics are read from the master, not the bus.

IO-Link complete

You can wire an IO-Link device and explain SIO fallback.
You can read an IODD and predict the cyclic frame layout.
You know when to use process data vs ISDU parameter access.