IO-Link Device Not Communicating: A Field Troubleshooting Procedure

intermediate · 30 min

A dead IO-Link port and a port that was never asked to talk look identical from the outside. This procedure separates SIO mode, validation rejection, data storage conflicts, IODD problems and cable faults in four reads — then fixes each, with the steps that can drop outputs called out before you take them.

ℹ️ A dead IO-Link port and a port that never tried to talk look identical from the outside: same silence, same wiring, same sensor. Most "IO-Link not communicating" calls are not a broken cable and not a broken device. They are a port nobody asked to talk, or a master that heard the device perfectly and refused it. Work out which of those two you have before you cut a single cable tie.

Port 1 talks because the master port is set to IO-Link, port 2 can only ever pulse pin 4 because its port was left in SIO/DI — its LED reports the switching bit, not a fault, so nothing looks broken — and port 3 refuses a same-type spare because Identical validation also checks the serial number. The fault lives in the port configuration, not in the sensors.

What "not communicating" really means

IO-Link is a point-to-point link between one master port and one device, on the same wires as an ordinary 24 V sensor: pin 1 (L+), pin 3 (L−), pin 4 (C/Q — the combined switching and communication line). It is not a bus: nothing else shares C/Q. The cable itself may carry more — on a Class A port pin 2 is usually a second, independent digital channel, and on a Class B port pins 2 and 5 carry a galvanically isolated auxiliary supply for devices with a higher power demand, which requires a 5-conductor cable. A Class B device on a Class A port has no auxiliary supply and may do nothing at all.

An IO-Link device does not start talking on its own. The master must ask, by sending a wake-up request — a defined current pulse on C/Q. Until it does, a device that supports SIO (Standard I/O) behaves as a plain switching sensor on C/Q, and a port that never issues the wake-up looks exactly like a broken one.

Split the causes in four reads

Read the port LED. Meanings are vendor-specific; get your master's table. On Belden LioN-X masters the port LED is solid green for "IO-Link COM Mode: IO-Link communication exists", flashing green for "IO-Link COM Mode: No IO-Link communication", yellow for "Standard-I/O Mode: status of digital input or output on C/Q (pin 4) line on", and red for a short circuit on the pin 4 / pin 2 line, or overload or short circuit on the L+ (pin 1) line. Flashing green versus yellow separates "the master is calling and nobody answers" from "this port was never in IO-Link mode". Red is not only a supply fault — on this master it is also how a shorted C/Q shows up.

Read the port mode in the master, not the device. Ports can be set to IO-Link, DI, DQ or Deactivated. A port left in DI still reads the switching output of a device that supports SIO, so a simple binary sensor keeps the machine looking healthy while every IO-Link value in the PLC sits at zero. On a measuring device the SIO output is only a configurable switch point, and on IO-Link-only devices, hubs and many actuators a DI port reads nothing useful at all.

Ask the master what identity it sees. Most masters expose the connected device's Vendor ID, Device ID and, where the device provides it, serial number per port. Populated identity plus invalid process data means the link is up and something is refusing the device — validation or data storage, not cable.

Ask what changed. "We swapped the sensor" puts validation and data storage at the top of the list.

The port is in SIO mode

Set the port to IO-Link in the master's configuration tool. Writing port parameters restarts the port: its outputs drop, and some masters reinitialise the whole module. This applies equally to changing the validation level, the Revision setting, or the data-storage mode. Machine stopped and zone safe before you write any of them.

Validation is rejecting the spare

Validation is the master checking identity before it exchanges process data. Turck's FEN20-4IOL documents four modes: without validation; family compatible (Vendor ID plus the MSB of the Device ID, the byte that defines the product family); compatible (Vendor ID plus full Device ID); identical (Vendor ID, Device ID and serial number).

The giveaway on that master: a mismatch still establishes IO-Link communication but exchanges no process data — the device is held in the safe state (Pre-Operate), with parameters and diagnostics still readable and writable. A live device producing no values.

Two things to know before you change the level:

• "Identical" rejects every spare, because the serial number differs by definition. Use it only where you must block any swap.
• "Compatible" is not a passive comparison. Turck documents that if the Vendor ID matches but the Device ID does not, the master attempts to write the Device ID into the connected device; process data exchange resumes only if that write succeeds. Stepping a port down to compatible can therefore alter the spare. Treat it as a deliberate, recorded change, not a shortcut.

Otherwise, match the spare to the configured Vendor/Device ID.

Data storage is fighting you

Data storage (the parameter server) is the master holding a copy of the device's parameters so a replacement inherits them. It needs IO-Link V1.1 on both sides. A V1.0 device on a data-storage-enabled port is a documented cause of a data storage error — and note that a port whose Revision parameter has been forced to V1.0 has the same effect as a V1.0 device.

Direction is decided by a flag inside the device, DS_UPLOAD_FLAG, but only in the bidirectional mode. On Turck's master:

• activated (bidirectional): the device's set is current when DS_UPLOAD_FLAG = 1 and is uploaded to the master; the master's set is current when the flag = 0 and is downloaded to the device. So a used spare out of the drawer, carrying its own changed parameters with the flag set, overwrites the master's good backup instead of receiving it.
• read in: the device is always the reference, upload only — the flag is ignored.
• overwrite: the master is always the reference, download only — the flag is ignored. This is the setting that forces a commissioned set onto a spare.
• deactivated, clear: the master's stored set is deleted and synchronisation is off.

Reset the replacement to factory settings before plugging it in — Turck states this explicitly for a replacement device with unknown parameter data. Moving a different device type onto a port that was already in use? Clear that port's data storage buffer first. Prefer the per-port "deactivated, clear" parameter. Turck also lists a master factory reset as a way to clear the buffer — that is a much larger action than it sounds: it also clears the master's IP address, protocol selection and every other port's configuration, and will drop the module off the network. Do not reach for it on a running plant.

Turck also documents that GSDML-based device parameterization and active data storage are mutually exclusive; leaving both on raises a port parameterization error.

The cable

The specification allows unshielded 3- or 5-conductor standard cable, maximum 20 m, cross-section at least 0.34 mm². Shielding is not necessary and, per the IO-Link Community's system description, no specific guidelines have to be followed when laying the cables. That is deliberate: IO-Link signals at 24 V levels at 4.8, 38.4 or 230.4 kBaud, and a failed frame is repeated twice — only after the second retry fails does the master declare a communication failure and signal it upward. Robustness is bought with voltage and retries instead of shielding, and paid for with the 20 m limit.

Two consequences worth knowing. Over-length or undersized conductors cause voltage drop at the device and degraded edges on C/Q; you see that as retries, invalid value status and dropouts under load rather than as a clean failure. And the two retries actively hide a marginal installation — a link that "works" on the bench can start failing when the load or the ambient noise changes.

The IODD

The IODD (IO Device Description) is an XML file describing one device: parameters, process data structure, diagnostics, identity. It is not firmware, and the link comes up without it — Rockwell's generic IO-Link device profile explicitly runs a device with no unique identity and no IODD, presenting process data in raw IO-Link format and performing no validation. What the IODD adds is meaning: named parameters, units, readable events. Get it from the vendor or from IODDfinder (ioddfinder.io-link.com).

Devices that support both V1.0 and V1.1 functionality have two different IODD versions. The trap is not mismatched parameter names — it is ending up with the port running at Revision V1.0, which silently removes data storage and can itself produce a data storage error.

Step-by-step

1. Note the port LED colour and pattern against your master's LED table. Red is not automatically a supply fault — check whether your master also uses it for a shorted C/Q.
2. In the master's web server or configuration tool, read the port mode.
3. Read the Vendor ID, Device ID and serial number the master reports for that port.
4. Read the port diagnostics and event list. Identity present plus invalid process data points to validation or data storage. No identity at all points to port mode, supply, wiring or device.
5. If the port is DI, DQ or Deactivated, set it to IO-Link. This is a port parameter write: it restarts the port and drops its outputs — stop the machine first.
6. If validation is blocking, compare the configured Vendor/Device ID with the device actually fitted. Change the validation level only as a deliberate, recorded step — and remember that "compatible" may write a Device ID into the device.
7. If the device was replaced: factory-reset the spare before connecting it; if the device type changed, clear that port's data storage using the per-port "deactivated, clear" parameter (not a master factory reset), then reconnect.
8. If nothing is seen at all, isolate in this order — cheapest and most conclusive first:

• measure L+ to L− at the device end, under load;
• confirm the device is on a port of the right class (a Class B device needs pins 2/5 and a 5-conductor cable);
• move the suspect device to a known-good port, and a known-good device to the suspect port — that one swap pair splits master from device;
• only then check pin 4 continuity and confirm the run is 20 m or less at 0.34 mm² or more.

1. Once communication is up, import the correct IODD version and confirm the port is not running at Revision V1.0.
2. Record the port's validation level, data storage mode, Revision setting and IODD version before you leave.

Never do this

Do not "fix" a rejected replacement by switching validation off and leaving it off. It clears the alarm in seconds and removes the only thing standing between the machine and a wrong sensor. The expensive version: a port left without validation, feeding a measurement whose range or scaling differs from the original. The PLC receives plausible numbers, no alarm fires, and the machine runs out of tolerance for a whole shift before anyone looks. Step validation down only as a deliberate, recorded change — never as a shortcut in the middle of a breakdown.

Never clear a master's data storage before you know which side holds the good parameter set — you may be deleting the only backup of a commissioned configuration. And never reach for a master factory reset to do it; that clears the network settings and every port on the module, not one buffer.

That backup was never complete anyway. The IO-Link Community's system description is explicit: sensors often have to be adapted to local conditions by field calibration, and "these types of adaptations that are not included in the backup must be restored after device replacement by performing another field calibration."