IO-Link without the brochure: what the master does, where 20 m ends, and when plain I/O wins

The question I get most about IO-Link isn't what it is. It's whether the 4-20 mA transmitter already bolted to the machine can go straight onto a master somebody picked up cheap. By itself, it can't. The reasons why clear up most of the confusion, so here it is the way I'd explain it at the bench: how the pieces connect, where the cable limit bites, what happens to parameters when a sensor gets swapped, and when I'd wire it the old way instead.

IO-Link is a point-to-point link between one port on a master and one sensor or actuator, standardized as IEC 61131-9. It is not a fieldbus. No addresses, no shared line: one device per port, three wires for power and data, unshielded cable up to 20 m. The PLC never talks to the sensor directly. It talks to the master over whatever network the master has, EtherNet/IP, PROFINET, EtherCAT and so on, and the master handles everything below that.

Where the master sits, and what the PLC actually sees

An IO-Link system has three layers. The controller and its network on top. In the middle sits the master, which is really a gateway: network on one side, a row of device ports on the other. Then one device on each port. A hub that gives you sixteen discrete points off a single M12 is still one device on one port as far as the master cares, and so is an analog converter.

The PLC talks only to the master. Below it, every IO-Link port is a separate point-to-point link to exactly one device, even when that device is a hub or a converter.

Each port moves up to 32 bytes of process data each way per cycle, plus parameters and events on request. One catch. Not every master passes all 32 bytes per port up to the network. Check how many yours does before a sensor with a long data frame goes on a budget master.

Events trip people up too. A master usually forwards only a handful of the common diagnostic codes to the network. The vendor-specific ones, which are often the useful ones, only decode in a configuration tool that has the device's IODD loaded.

The IODD is the XML file every device maker has to publish: parameters and limits, process data layout, what each event means. Configuration tools read it, and the IODDfinder database keeps them in one place. A master can bring a device up with no configuration and no checking, but then you get bytes without names.

How those bytes land in the controller depends on whose master it is. Rockwell's own POINT I/O and PointMax masters register the IODD inside the Studio 5000 project. With Rockwell and partner devices the tags come out named, with other devices you mostly get an array sized from the IODD. A third-party block can go in as a generic Ethernet module plus the vendor's add-on instruction. Balluff's BNI EIP-508-105-Z015 done that way asks for a 392-byte input assembly, 262 bytes of output and 194 of configuration. The 1734-4IOL specifics I covered in a separate troubleshooting article.

Three speeds, and the cycle time belongs to the device

Mode	Bit rate	Recommended minimum cycle time
COM1	4.8 kbit/s	18.0 ms
COM2	38.4 kbit/s	2.3 ms
COM3	230.4 kbit/s	0.4 ms

 

Each IO-Link device declares its own minimum cycle time. The master can poll it slower on a fixed cycle if you set one, never faster. Possible cycle times run from 0.4 ms to 132.8 ms, so a fast distance sensor and a COM2 pressure switch on one master answer at very different rates. Normal, not a fault.

Add the master's own processing time on top, then the network update rate. A sensor counting sprocket teeth at line speed goes on a plain input in my book, and every port can drop back to standard digital I/O for exactly that job.

What a master won't do with your 4-20 mA transmitter

An IO-Link port has a handful of modes: off, plain digital input, plain digital output, or communication. In DI or DO mode it behaves like any 24 V point. A device built for the protocol actually powers up as a plain switching input and only starts talking once the master wakes it up, which is where the backward compatibility comes from.

Analog is where people get stuck. A standard port has no analog input. The conversion lives in the device, and that's the whole point: no D/A in the transmitter, no A/D in an analog card, no conversion losses in between. Keep an existing 4-20 mA transmitter and a converter has to sit between it and the port. That converter is the device the master talks to.

What you're connecting	What it takes
A sensor or actuator with IO-Link built in	Straight onto a port, configured from its IODD
A plain switch, prox or solenoid	Port set to DI or DO, no communication at all
A 4-20 mA or 0-10 V instrument you're keeping	An analog converter on the port
A cluster of plain on/off points in one spot	A digital I/O hub, one port for the lot
Nothing on the machine speaks the protocol	Ordinary remote I/O, honestly

 

Last row isn't a joke. Out of rack slots and nothing on the machine has the protocol? You're shopping for remote I/O. Hubs and converters will get you there, you've just added a layer that buys you nothing.

How far it runs, and why you can't daisy chain it

IO-Link guarantees 20 m from port to device, on unshielded cable with at least 0.34 mm² per conductor. The cable from the master back to the PLC follows normal Ethernet rules, which is the real reason masters end up on the machine frame: short drops to a block, one network cable home.

The awkward case is the lone sensor 40 m out. Either a whole master goes out there for one device, or you run it as a plain hardwired point, or repeaters go in the line. Two examples, makers' own numbers:

	ifm E30444	Turck IOLR-EH30-H1151
Reach	Up to 100 m, depends on transmission type, cable cross-section and device current	Up to 240 m with three repeaters, 200 m at COM3
Repeaters in series	3 max	3 max
Port in DI/DO mode through it	No	No
Added delay per repeater	Process data up to 1 cycle, acyclic up to 2	Process data 1 cycle, acyclic 2

 

They don't agree on reach, so plan to the datasheet of the exact repeater you buy. And the delay stacks with every unit in the line.

Daisy chaining isn't in the standard at all. Every link is one master port to one device. Some hubs have an expansion port that hangs a second module off the first. That’s the maker’s own scheme, set up through a parameter described in their manual, and it only works with their own modules. Need more ports? More masters or a bigger one, and each standalone block master is one more device on the network for your controller to count.

Class B ports, and the five-core cable that can defeat an E-stop

A Class A IO-Link port gives the device one 24 V supply on pins 1 and 3 and communication on pin 4. Pin 2 is up to the maker, usually an extra digital channel. Class B adds a second supply for actuators on pins 2 and 5, with strict rules: isolated from the first supply, the port marked as Class B, and the device keeps communicating when actuator power drops. That last one is the nice part. Hit the E-stop, the master kills actuator power on pin 2, valves drop out, and you still have diagnostics.

Now plug a Class A sensor into that Class B port with a five-core cable. If the sensor has a contact between its own pin 1 and pin 2, the sensor supply gets bridged onto the actuator supply. The E-stop opens pin 2 at the master, and actuators that should have dropped out can stay powered through pin 1. Where an E-stop is configured on the actuator supply, that wiring is prohibited.

A Class A sensor on a Class B port through a five-core cable: an internal pin 1 to pin 2 contact feeds the actuator supply, and opening the actuator supply at the master no longer de-energizes it.

The fix costs nothing: a three-core cable for a Class A device on a Class B port, or a cable with pins 2 and 5 left unconnected at one end. And on any master sold as Class B, check that the two supplies really are isolated. Some designs tie the grounds together. Find that out from the datasheet, not the E-stop test.

Swapping a sensor: when IO-Link puts the parameters back by itself

This is the feature that sells it to maintenance, and the one that quietly fails more often than it should. The master keeps a copy of each device's parameters, up to 2048 bytes per port, and writes it into the replacement. That only happens when all four of these line up:

·       Master and device are both V1.1 or newer. Anything V1.0 in the pair means no backup.

·       The port's inspection level is "type compatible", so it checks vendor ID and device ID. Set it to no check and the port only allows the commissioning level, which saves nothing.

·       The backup level is Backup/Restore or Restore, not Commissioning.

·       With Backup/Restore, the replacement is new out of the box, or reset to factory defaults before it goes in. Do the same with Restore.

All four conditions should line up for automatic restore. Miss any of the first three and nothing gets restored.

The two production levels behave differently the moment somebody touches a sensor, and that's the part that confuses people.

	Backup/Restore	Restore
Setting changed by teach button or configuration tool	Copied up to the master	Master overwrites it with the stored set
Compatible sensor swapped in	Stored set written to it	Stored set written to it
Where it fits	Production lines where settings still change at runtime	Locked-down production

 

One more gotcha with Backup/Restore. A PLC that writes a parameter has to follow it with the store command, otherwise the master's copy stays old and the next swap brings the old value back.

Two more limits. Some devices need a teach-in after a swap even with backup working; the device manual tells you which kind you have. And the backup lives inside the master. Lose the master, lose the copies. The standard lets a master hand its backups up to a PLC or gateway, but whether yours does is down to the vendor. If not, keep the parameter sets somewhere you can reload them from.

Brand-to-brand swaps got easier for one class of device. Sensors built to the Smart Sensor Profile with the same profile ID are meant to drop in without touching the PLC program, with only the device identification in the port configuration changed. That's sensors carrying that profile, not everything on your shelf.

When IO-Link is worth it, and when it isn't

Situation	My pick	Why
Limit switches, prox switches, photo eyes, solenoids with nothing to set	Hardwired or regular remote I/O	Nothing to configure, and each point eats a port
Sensors with setpoints, teach or ranges	A master port	Settings live in the master and come back after a swap
One sensor reporting several values, like pressure plus temperature	A master port	Several readings over one cable instead of several analog channels
One device more than 20 m out	Plain wiring, or a repeater if the numbers work	A master for one sensor is a waste
Fast edges, counting, timing-critical inputs	Plain input, or a port in DI mode	Cycle time and network update add up
A crew that troubleshoots with a meter	Either, with diagnostics on the HMI	A meter can't read a digital value

 

That last row matters more than people think. Digital values are great until the guy on night shift has a meter, a dark sensor and no idea which LED on the master means what. Put port and device diagnostics on a screen before the first callout.

Buying a used master: what I check first

·       IO-Link version. A V1.0 master runs only V1.0 devices and has no parameter backup. A V1.1 master runs both, and COM3 is mandatory on it.

·       The network matches your PLC, the configuration file (EDS or GSDML) is available, and the maker's setup software still supports that model.

·       How many process data bytes per port it actually passes to the network.

·       Which ports are Class B, whether they're marked, and whether actuator power is isolated.

·       Factory reset before it goes on your machine. The master is where parameter backups live, so don't start from whatever the last machine left in it.

FAQ

What is an IO-Link master?

A gateway with ports. One side speaks the plant network, the other runs a point-to-point link to one device per port. It powers those devices, handles the communication and holds their parameter backups.

Can you daisy chain IO-Link masters?

Not in the standard. Each block master is its own device on the network, and each port takes exactly one device. Expansion-port hubs exist, but they're vendor-specific.

How far can you run IO-Link?

20 m guaranteed, on unshielded cable. Repeaters stretch it to 100 m or 240 m depending on the maker, and a port in DI/DO mode won't pass through them.

Can a 4-20 mA sensor connect to an IO-Link port?

Not directly. There's no analog input on a standard port. Put an analog converter between the transmitter and the port, or replace the transmitter with one that has the protocol built in.

Is IO-Link worth it?

For devices you configure, yes: backup on a swap, digital values, diagnostics down to the sensor. For plain on/off points, usually not.

Before you order a master

If you're adding ports to a machine that already runs, match the master to the network you have. We carry surplus IO-Link masters for most of the common ones: the 1734-4IOL for POINT I/O, behind a 1734-AENTR or 1734-AENT adapter; the ArmorBlock 5032-8IOLM12DR and 1732E-8IOLM12R for EtherNet/IP right on the machine; the ifm AL1322 and the Keyence NQ-MP8L, which also does PROFINET and Modbus/TCP; the Siemens 6ES7137-6BD00-0BA0 four-port module for ET 200SP; and the Beckhoff EP6224-3022, a four-port Class B box for EtherCAT. Check the version and port classes against what you're plugging in, and if you're not sure which one fits, tell us your controller and network.