What Is IO-Link 1-1 and How Is It Used

By Lisa Eitel

Contributed By Digi-Key's North American Editors

This article will discuss IO-Link and how IO-Link 1.1 differs from previous iterations. Then the discussion will shift to outline where IO-Link makes sense in automated installations.

Image of use of IO-Link in roboticsFigure 1: Use of IO-Link has skyrocketed in recent years — especially in robotic end effecting and other pneumatic applications. (Image source: SICK Inc.)

Background on IEC 61131-9

The IEC 61131-9 standard — branded under the trademarked name IO-Link — is an open standard that defines one system to impart connectivity to actuators and sensors commonly employed in machine automation. By some estimates, the sale of devices with IO-Link capabilities could double every year for the next several years (to exceed $12 billion by 2023). That fact, along with an increasing number of OEMs and plant engineers discovering and leveraging IO-Link functions on newly bought and existing hardware, has meant a rather dramatic rise in IO-Link use over the last few years in particular.

A brief history

In 1982, the International Electrotechnical Commission (IEC) established its original conventions for programmable controllers and their software. This standard received an update and renaming to IEC 1131 in 1993; a subsequent update and another renaming to International Standard IEC 61131 took place in 1997.

Part 9 of IEC 61131 (again, the standard of IO-Link) concerns the “single-drop digital communication interfaces for small sensors and actuators” as established by the collaboration of two IEC subcommittees — one focused on measurement and control devices and the other focused on industrial networks. The single-drop communication interface (abbreviated SDCI) means IO-Link employs a single cable (up to 20 m) to connect each sensor or actuator in the system — and that cable is a generic unshielded three-wire cable (or in some cases, five-wire cable) that’s been widely used for industrial I/O applications for decades.

Image of sensor with IO-Link connectivityFigure 2: Shown here is a sensor with IO-Link connectivity. (Image source: SICK Inc.)

An incredibly common misconception is that IO-Link somehow competes against DeviceNet, PROFINET, CC-Link, EtherNet/IP, and EtherCAT. To be clear: IO-Link is only a standardized I/O technology — and its aim is actually to complement current communication networks, backplane buses, and fieldbus protocols. In many instances, IO-Link imparts feedback and automation functions not possible with the chosen network alone.

Image of IO-Link simplifies the integration of field devicesFigure 3: IO-Link simplifies the integration of field devices into other common fieldbuses and industrial networks for an expanded range of IIoT (industrial internet of things) functionalities. (Image source: SICK Inc.)

With the SDCI point-to-point communication of IO-Link, connections are made from one point at a field device (such as a sensor or other slave) to another point at an IO-Link hub or master controller. Some manufacturers refer to masters as IO-Link boxes or modules. Communications between endpoints differ from the cross-device communications of networks and buses, which usually involves packets or “telegrams” globally broadcast and read by recipient end devices or other slaves.

Today, the IO-Link Consortium — the group that is dedicated to continually improving and promoting IO-Link — publishes its rules, standards, and updates at

IO-Link software for configuration

All IO-Link devices require setup before use. Commissioning is usually done through software provided for free by the manufacturers of devices that are IO-Link ready — or from the manufacturer of the PLC or other high-level industrial controller to command the automated installation. Design engineers are often familiar with such control-system software, which simplifies the configuration of IO-Link device parameters within that environment. Such connectivity is also imparted to the installed sensors and other devices… to allow for the adjustment of their parameters on the fly.

Image of light curtains from SICK Inc.Figure 4: Light curtains from SICK Inc. allow desktop configuration of IO-Link functions. (Image source: SICK Inc.)

During the typical setup process, the engineer uses the software to virtually integrate the IO-Link master and its devices into the rest of the automated design. Through a configuration menu, the engineer sets device and master parameters to satisfy the larger system architecture requirements.

Software to setup IO-Link devices employs standardized IO device-description (IODD) files. Complementing IODD files in some cases are proprietary device-type manager or DTM files as well as add-on instructions in addition to function blocks offered by device manufacturers to further simplify device programming via their own GUIs (graphical user interfaces).

IODD files contain the device name, model, imagery to populate GUIs, typical operating ranges, and signals expected for the IO-Link system interface. The IO-Link Consortium hosts a library of downloadable IODD files organized by the device manufacturer at Ultimately these files get loaded on the IO-Link master (as well as hubs if those are in use on the system) to allow basic operation as well as diagnosis functions.

Process, event, and device data in IO-Link

Every IO-Link installation automatically handles data through its master. Data transmits from field devices either on a regular basis (processed by the controller as cyclic data) or transmits upon request or as required (processed by the controller as acyclic data). In addition, the controller classifies and handles all such data as:

Event data — a form of acyclic data. This includes errors and maintenance alarms as well as troubleshooting information prompted by either axis movements or sensor and switch signals that are problematic or compromised in some way.

Process data — a form of cyclic data. This is basic operating information such as position, level, distance, and more that field devices continually collect and send upstream to the IO-Link master. In some instances, these process-data signals are accompanied by value status data on their way to the master. Leveraging the bi-directional nature of IO-Link communication, process data can also go in reverse (from master to field device) to trigger devices to change behavior or display a preset code for machine operators to note.

Device data— a form of acyclic data. This is information about the field device and its model, parameter settings, status, position, and other read values. Leveraging the bi-directional nature of IO-Link communication, device data can also go from master to device to set new parameters and the like.

IO-Link 1.0 to 1.1 — what changed?

In 2013, the IO-Link Consortium updated IO-Link from 1.0 to 1.1. New in IO-Link 1.1 is the support of a third (and for the standard, fastest) data transmission rate through a channel dubbed COM3 — which enhances the capabilities previously possible with COM1 and COM2 connections.

COM1 — SDCI communication mode with transmission up to 4.8 kbit/sec • Cycle times down to 18.0 msec

COM2 — SDCI communication mode with transmission up to 38.4 kbit/sec • Cycle times down to 2.3 msec

COM3 — SDCI communication mode with transmission up to 230.4 kbit/sec • Cycle times down to 0.4 msec

All IO-Link 1.1 masters must support this new data rate and the field devices that employ it. In addition, 1.1 masters support both 1.0 and 1.1 devices.

Another new feature in 1.1 leverages the requirement that IO-Link devices with similar specifications (even from different manufacturers) be interchangeable. This, and the fact that 1.1 masters can store parameters, allows automatic configuration of hot-swapped IO-Link devices, simplifying the replacement of damaged or failed sensors.

Traditional alternatives to IO-Link

IO-Link improves the processes of automated installations in several situations.

In many automated facilities, there is still heavy reliance on operator-based monitoring — the manual tracking of machine status and potential issues. In such settings, IO-Link provides an alternative that’s viable (thanks to its simplicity) for machine monitoring that’s more efficient and reliable. That’s because unlike traditional I/O, IO-Link includes bi-directional communication to allow for the quick setup as well as diagnosis of actuator and sensor conditions.

IO-Link also frees plants from the manual settings of field-device parameters, which is an approach still relatively common in industry. With this approach, plant engineers are forced to physically access field devices in remote equipment (or buried in machines) to read, troubleshoot, or reconfigure them. Instead, IO-Link lets operators download parameters from online or local libraries; which is especially useful in minimizing machine downtime during repairs or operation changeovers. Often the configuration is through regular control software.

Centralized cabinet-based controls are also common in traditional setups. The hardware associated with IO-Link (to complement IO-Link-capable field devices) is miniaturized, so can fit into even very tight machine footprints and support distributed controls.

IO-Link simplifies the use of analog data — eliminating the need for specialized converters (found in traditional equipment) to make sense of analog 4 to 20 mA signals. IO-Link also expands the amount of information transmittable with analog as well as discrete and binary (off-on) signals.

More on traditional 4-20 mA analog signals with IO-Link

Analog sensors in traditional installations require shielded cable, specialized connectors, and:

• Analog-to-digital or A/D output converters

• Digital-to-analog D/A input converters (for bi-directional communication)

These elements can add design cost and complexity (especially where calibration is required) and in some cases can degrade the transmitted data.

As mentioned, IO-Link employs unshielded three-wire cables or equivalent five-wire cable with power, and that applies to analog devices as well, making the signal transmission between the sensor and controller more reliable and eliminating data losses. IO-Link acts as a single interface for the communication, regardless of whether the device is a sensor, actuator, gripper, or valve — far simpler than installations that necessitate disparate interfaces for binary switching, analog IN/analog OUT, or RS232.

Caveats and limitations of IO-Link

So far, some of the ways in which IO-Link is beneficial to automated designs have been discussed. However, the additional effort and complexity of implementing IO-Link where simpler approaches are sufficient (or where the design at hand is a standalone machine) isn’t always justifiable.

In settings where IO-Link does make sense, a potentially limiting factor is that (as mentioned) cable runs must not exceed 20 m. That’s in contrast with alternative systems, especially those employing analog signals for feedback, that can accommodate much longer stretches so common in large-scale automated operations.

Until recently another IO-Link limitation was cycle time. With the introduction of the COM3 communication mode (with cycle times down to 0.4 msec) IO-Link 1.1 is acceptable even for fairly demanding automation tasks — including some of those associated with motion control. Of course, IO-Link 1.0 devices are still held to the limitations of COM1 and COM2; but it’s the norm to have devices with various cycle times working off one master — so incremental system upgrades are possible.

Every device’s IODD file includes information for the master on the time interval (cycle time) at which the master can address that particular device. That, along with the master’s own time required for processing time, affect overall response time. The IO-Link limit on input and output process data holds at 32 bytes, which can prevent or complicate adoption of IO-Link for certain reader and tracker applications. Although even here, devices with onboard processing capabilities are addressing this limitation.

A final potential limitation is that not all specialty sensor types are available in models having IO-Link functionality.

Physical subcomponents and installation

Image of IO-Link hubs (left), single-device IO-Link master modules (middle), and IO-Link mastersFigure 5: Shown here are IO-Link hubs (left), single-device IO-Link master modules (middle), and IO-Link masters. (Image source: SICK Inc.)

IO-Link masters

IO-Link masters (as mentioned, also called modules or boxes by some manufacturers) are pieces of hardware that do three things:

1. They serve as the communication point for connected IO-Link field devices. All devices use one of three standard communication rates; it is the master’s job to determine which rate is being employed.

2. They store all the IODD files and parameters for connected IO-Link field devices. That means upon startup, the master might accept device parameters and then switch to the normal operating mode of accepting cyclic exchanges of process data and values.

3. They connect to top-level machine and automation controls such as PLCs and PACs to communicate data to their fieldbuses, networks, or backplanes. That sharing in turn makes the data more accessible for immediate machine functions as well as enterprise-level analysis in facilities with IIoT programs. As a result of the connectivity of IO-Link masters to PLCs, HMIs, and PACs, manufacturers of these components have in recent years begun releasing to the market their own IO-Link masters — in many cases in the form of terminals and (as mentioned) modules. SICK Inc.’s IOLA2US-01101 is an example of a single-port master.

All of the ports on an IO-Link master in operation are either deactivated, set to accommodate digital input and/or output, or run in IO-Link mode using what is called a universal asynchronous receiver-transmitter (UART) in half duplex mode. A typical IO-Link master might include eight ports to either:

  • Directly couple to various field devices
  • Couple to IO-Link hubs that serve as master extensions (which in turn connect to arrays of field devices)

IO-Link Hubs

Today the most advanced IO-Link hubs (sometimes called distribution blocks) can help a single IO-Link master connect more than 100 (and in some cases more than 200) field devices. A standard hub-to-link protocol outperforms proprietary systems for simplified system configuration. Storage of device information on both the IO-Link master and its hubs maintains the integrity of the system — by verifying that additional or replacement field devices are compatible with the design.

Cable and connector features of the IO-Link standard

Three-wire cable construction: As mentioned earlier, cabling employed by IO-Link has a non-proprietary unshielded three-strand construction to carry 24 V and 200 mA. Where a field device (such as an actuator) necessitates power, a five-wire version is used.

M5, M8, and M12 connectors: Where the IO-Link master takes the form of a DIN-rail block or similar designs meant to reside inside control cabinets, the wire connections are through the usual push-in terminals. But where the IO-Link connections employ cable connectors (as on IO-Link masters with construction meant to be machine mounted), the IO-Link standard requires M5, M8, and M12 geometries. Five-wire connectors are typically rated to IP65/67.

Quantifying IO-Link component ruggedness

The automotive industry leads in its use of IO-Link. However, the pharmaceutical and food and beverage industries have begun employing more IO-Link components — especially those with washdown ratings. Such ruggedized components support machine-mounted I/O arrangements for fully distributed control. Ratings for IO-Link components in such installations include:

  • IP20 — indicates zero water protection but the ability to withstand normal dust and handling
  • IP67 — indicates full dust protection and temporary resistance against ingress during water submersion (which can be useful outdoors)
  • IP69K — indicates protection against the ingress of the hot and high-pressure washdown associated with disinfecting procedures

In addition, some IO-Link components include ECOLAB certification — a designation to help machine builders in the food and beverage industry comply with regulations, including those associated with the Food Safety Modernization Act, and prevent unsafe food handling or packaging.

How IO-Link 1.1 is Used

Common components with IO-Link capabilities

The field devices supported by IO-Link can be classified as actuators and sensors.

Actuators in IO-Link systems: Actuators are the electromechanical components that accept electric input and bring about some mechanical output. IO-Link-compatible actuator options abound — and include those based on pneumatic linear actuators, pneumatic manifolds and valves, other solenoids, and even stepper motors. Connections to these devices are usually the five-strand variation and employ dual-channel real-time communications without the delays introduced by controller cycle times. This enables simultaneous IO-Link communications to prompt data evaluation or other secondary responses.

Sensors in IO-Link systems: Common sensors with IO-Link connectivity include those to track and report position, displacement, temperature, pressure, and color. Other widely available options include IO-Link photoelectric sensors and (supported more fully with the increased capabilities of IO-Link 1.1) RFID sensing systems.

The following are examples of SICK Inc. sensors:

The special case of light curtains

Though the topic of safety is beyond the focus of this article, it is worth noting that some light curtains have IO-Link connectivity to allow access to statistics and the real-time data associated with the curtain.

Here are some examples:

Specifics on employing IO-Link communications

IIoT Functionality and Cloud Connectivity: IO-link has the ability to store data on its masters — and send data onward for backup. This, as well as the way in which IO-Link complements existing industrial networks, supports IIoT functionality; leveraging all the benefits of automated parameterization and data collection.

Data Transmission to Other Buses and Networks: Because IO-Link integrates into all common industrial networks and fieldbuses — and allows bi-directional master-device communications — process, service, and event data can be shared upstream to top-level controls and even enterprise systems.

Using IO-Link to Upgrade Legacy Equipment

Backwards compatibility: As mentioned previously, IO-Link 1.1 accommodates sensors that use COM1, COM2, and COM3 communication speeds, which lets plant engineers continue to use legacy technology having somewhat less sophisticated electronics and slower data rates. Backwards compatibility is maintained with new 1.1 masters, which are all required by the IEC 61131-9 standard to support 1.0 and 1.1 devices.

Industries and users making the most use of IO-Link technology

Manufacturers, OEMs, machine assemblers, plant technicians, and end users all benefit from IO-Link. For more information on IO-Link, download an IO-Link handbook from Maxim Integrated in PDF form by clicking here.

Disclaimer: The opinions, beliefs, and viewpoints expressed by the various authors and/or forum participants on this website do not necessarily reflect the opinions, beliefs, and viewpoints of Digi-Key Electronics or official policies of Digi-Key Electronics.

About this author

Lisa Eitel

Lisa Eitel has worked in the motion industry since 2001. Her areas of focus include motors, drives, motion control, power transmission, linear motion, and sensing and feedback technologies. She has a B.S. in Mechanical Engineering and is an inductee of Tau Beta Pi engineering honor society; a member of the Society of Women Engineers; and a judge for the FIRST Robotics Buckeye Regionals. Besides her contributions, Lisa also leads the production of the quarterly motion issues of Design World.

About this publisher

Digi-Key's North American Editors