Back to blog

Commissioning IO-Link From Master Ports to IODD Data

Commission IO-Link systematically from master addressing and port modes through IODD selection, PLC byte mapping, parameter backups, device validation, and failure-injection tests.

IO-Link commissioning succeeds when three layers agree: the physical port, the device description, and the PLC data contract. A sensor can show a healthy LED and still deliver unusable process data if the master port is in the wrong mode, the IODD does not match the device variant, or the controller interprets bytes in the wrong order. Treat the job as a controlled integration, not a plug-and-play assumption.

IO-Link master sensors actuator hub and M12 cables prepared for commissioning

An IO-Link segment includes the master port, point-to-point device connection, device description, and the higher-level fieldbus connection to the controller.

Define the Architecture Before Applying Power

IO-Link is standardized as IEC 61131-9 and provides bidirectional point-to-point communication between a master and a sensor or actuator. It is not a multidrop fieldbus on the device cable. Each master port communicates with one IO-Link device, although an IO-Link hub can present multiple conventional discrete signals through one IO-Link connection.

Start with an inventory containing the exact master catalog number, firmware, port class, device catalog number, IO-Link revision, communication speed, cable type, and required power. Separate Class A and Class B port requirements where applicable, and document whether auxiliary actuator power is needed. Do not assume every M12 connector has the same pin function or current capacity.

The official IO-Link community site describes the technology's process, service, event, and identification capabilities. Those capabilities reach the PLC only through the master's upstream network—such as EtherNet/IP, PROFINET, EtherCAT, or another supported system. The master therefore has two configurations: its fieldbus identity and its IO-Link port behavior.

Establish Network Identity Without Creating a Duplicate

Connect the master on an isolated commissioning network first. Record its factory addressing method, assign the approved IP address or station name, set the subnet and gateway only where required, and change default credentials. Confirm the controller, engineering workstation, and master agree on the same address plan before connecting to production.

IO-Link master web interface used to verify network identity and port status

The web interface is a commissioning and diagnostic tool; it does not replace the controller configuration or command-ownership design.

A master web server can expose firmware, port mode, device identity, supply state, events, and raw process bytes. Use it to prove the field side independently of the PLC. Save a configuration backup or screenshots before making changes. On a running machine, treat web changes as online control changes because a new port mode, parameter, or output state can affect the process immediately.

Set Each Port for Its Intended Device

For every port, explicitly select IO-Link mode, standard input, standard output, or disabled mode as supported by the hardware. Verify cycle time, validation policy, data-storage behavior, and any port power setting. A port left in automatic mode may be convenient during a bench test but can allow the wrong replacement device to start without the validation the machine requires.

Check the device identification reported by the master against the nameplate. Vendor ID, device ID, product variant, and serial number are more reliable than a generic description. Define the response to a mismatch: alarm only, inhibit the machine function, or allow a controlled substitution. The choice belongs in the machine risk and maintenance strategy.

Use the Correct IODD and Fieldbus Description

The IODD describes an IO-Link device's identity, parameters, process-data layout, events, and display text. Download it from the manufacturer or the official IODD source and match the device variant and IO-Link revision. An IODD for a related sensor can appear to load correctly while assigning the wrong units or bit meanings.

Manufacturer download files for IO-Link masters on different industrial networks

The IODD describes the field device; the EDS, GSDML, or ESI describes how the master appears on its upstream network.

The PLC engineering tool may also need an EDS for EtherNet/IP, GSDML for PROFINET, or ESI for EtherCAT. These files define the master's connection sizes and module structure, not the sensor's meaning. Balluff's official commissioning example shows selecting a master port and assigning the correct IODD. Preserve the file names and versions with the machine project so a future replacement does not depend on an engineer's download folder.

Build a Controller Data Contract

Before writing logic, document the process-data length for every port, byte and bit order, signedness, scaling, units, valid range, and quality indication. Separate cyclic process data from acyclic parameter access. A PLC can usually read or write device parameters through indexed service requests, but that does not mean every parameter should be changed during production.

Create named tags that convert raw bytes once at the I/O boundary. The rest of the program should use engineering values and explicit status bits, not scattered byte offsets. Add a stale-data timer, device-mismatch alarm, port-event diagnostics, and a defined fallback for invalid data. For hardware selection and expansion planning, review industrial I/O modules and communication and networking components.

Parameterize With Change Control

Use the IODD-aware engineering tool to set thresholds, filters, output behavior, measurement range, and device-specific diagnostics. Export or record the final parameter set. Decide whether the master will use IO-Link data storage to restore parameters automatically after replacement, and test the direction of transfer. A mistaken upload/download choice can overwrite the validated configuration with factory defaults.

IO-Link device configuration software used to verify parameters and diagnostics

Parameter tools should leave a reproducible device record, not an undocumented working state.

Prove Normal and Abnormal Operation

Test every input over its meaningful range and every output under safe conditions. Confirm units and scaling at minimum, normal, and maximum values. Disconnect the device, substitute the wrong device where safe, remove auxiliary power, break the upstream network, and restart the master. Verify the PLC distinguishes bad quality, stale data, and a legitimate zero.

Finally, record master firmware, device firmware, IODD revision, network file revision, controller connection size, port settings, parameter backup, and test results. IO-Link's engineering value is repeatability: a replacement device can be identified, parameterized, and verified quickly. That value appears only when the configuration chain and failure behavior are documented end to end.

Leave a comment

Please note, comments need to be approved before they are published.