Rise of the Robots: IO-Link Maximizes Utilization, Saves Time and Money

Manufacturers around the world are buying industrial robots at an incredible pace. In the April 2020 report from Tractia & Statista, “the global market for robots is expected to grow at a compound annual growth rate (CAGR) of around 26 percent to reach just under 210 billion US dollars by 2025.” But are we gaining everything we can to capitalize on this investment when the robots are applied? Robot utilization is a key metric for realizing return-on-investment (ROI). By adding smart devices on and around the robot, we can improve efficiencies, add flexibility, and expand visibility in our robot implementations. To maximize robot utilization and secure a real ROI there are key actions to follow beyond only enabling a robot; these are: embracing the open automation standard IO-Link, implementing smart grippers, and expanding end-effector application possibilities.

In this blog, I will discuss the benefits of implementing IO-Link. Future blog posts will concentrate on the other actions.

Why care about IO-Link?

First, a quick definition. IO-Link is an open standard (IEC 61131-9) that is more than ten years old and supported by close to 300 component suppliers in manufacturing, providing more than 70 automation technologies (figure 1). It works in a point-to-point architecture utilizing a central master with sub-devices that connect directly to the master, very similar to the way USB works in the PC environment. It was designed to be easy to integrate, simple to support, and fast to implement into manufacturing processes.

Figure 1 – The IO-Link consortium has close to 300 companies providing more than 70 automation technologies.

Using standard cordsets and 24Vdc power, IO-Link has been applied as a retrofit on current machines and designed into the newest robotic work cells. Available devices include pneumatic valve manifolds, grippers, smart sensors, I/O hubs, safety I/O, vacuum generators and more. Machine builders and equipment OEMs find that IO-Link saves them dramatically on engineering, building and the commissioning of new machines. Manufacturers find value in the flexibility and diagnostic capabilities of the devices, making it easier to troubleshoot problems and recover more quickly from downtime. With the ability to pre-program device parameters, troublesome complex-device setup can be automated, reducing new machine build times and reducing part replacement times during device failure on the production line.

Capture Data & Control Automation

Figure 2 – With IIoT-ready IO-Link sensors and masters, data can be captured without impacting the automation control.

The final point of value for robotic smart manufacturing is that IO-Link is set up to support applications for the Industrial Internet of Things (IIoT). IO-Link devices are IIoT ready, enabling Industry 4.0 projects and smart factory applications. This is important as predictive maintenance and big-data applications are only possible if we have the capabilities of collecting data from devices in, around and close to the production. As we look to gain more visibility into our processes, the ability to reach deep into your production systems will provide major new insights. By integrating IIoT-ready IO-Link devices into robotic automation applications, we can capture data for future analytics projects while not interrupting the control of the automation processes (figure 2).

Tire Manufacturing – IO-Link is on a Roll

Everyone working in the mobility industry knows that the tire manufacturing process is divided up into five areas throughout a large manufacturing plant.

    1. Mixing
    2. Tire prep
    3. Tire build
    4. Curing and molds
    5. Final inspection

Naturally,  conveyors, material handling, and AGV processes throughout the whole plant.

All of these areas have opportunities for IO-Link components, and there are already some good success stories for some of these processes using IO-Link.

A major opportunity for IO-Link can be found in the curing press area. Typically, a manufacturing plant will have about 75 – 100 dual cavity curing presses, with larger plants having  even more. On these tire curing presses are many inputs and outputs in analog signals. These signals can be comprised of pressure switches, sensors, pneumatic, hydraulic, linear positioning, sensors in safety devices, thermo-couples and RTD, flow and much more.

IO-Link provides the opportunity to have all of those inputs, outputs and analog devices connected directly to an IO-Link master block and hub topography. This makes it not only easier to integrate all of those devices but allows you to easily integrate them into your PLC controls.

Machine builders in this space who have already integrated IO-Linked have discovered how much easier it is to lay out their machine designs, commission the machines, and decrease their costs on machine build time and installations.

Tire manufacturing plants will find that the visual diagnostics on the IO-Link masters and hubs, as well as alarms and bits in their HMIs, will quickly help them troubleshoot device problems. This decreases machine downtime and delivers predictive maintenance capabilities.

Recently a global tire manufacturer getting ready to design the curing presses for a new plant examined the benefits of installing IO-Link and revealed a cost savings of more than $10,000 per press. This opened their eyes to evaluating IO-Link technology even more.

Tire Manufacturing is a perfect environment to present IO-Link products. Many tire plants are looking to upgrade old machines and add new processes, ideal conditions for IO-Link. And all industries are interested in ways to stretch their budget.

 

How to Take Advantage of IO-Link Parameter Data

IO-Link data packets contain parameter data of an IO-Link slave device that is acyclic and is only transferred when read or write is requested by the machine controller. Having parameter data available on a device is not new or groundbreaking; however, the main advantage of IO-Link parameter data is that it is directly accessible by the machine controller, and it is dynamic, meaning you do not have to take the device offline to change its parameters or configuration. Parameter data determines how flexible or configurable an IO-Link slave device is. Its content will be different from device to device and manufacturer to manufacturer, a differentiator when choosing the right device for your application. We all know that not all IO-Link devices are created equal.

So how can you take advantage of parameter data?

Automatic machine configuration

Imagine if your machine could automatically configure itself upon first power-up? Yes, it is possible. Because IO-Link parameter data is accessible by the machine controller, i.e., the PLC or PAC, one can write a routine/program that first verifies the correct device is connected to the correct port of the IO-Link master, request a parameter read, compare the parameter content to the desired configuration in the program, and overwrite the current device parameter set if necessary. Why would someone do this? Well, if you are an OEM machine builder building ten of the same machines for one end customer, it would be a worthwhile investment in programming development to have IO-Link devices configured automatically. This method would eliminate the need for manual machine parameterization and result in cost savings. Examples of typical configuration would be changing the pin assignment of an IO-Link freely configurable discrete input/output hub as an input or an output, machine home position or offset of an IO-Link linear transducer, set points of an IO-Link pressure transducer, set points of an IO-Link laser distance sensor, and so on.

Recipe change

Another way to take advantage of IO-Link parameter data is to have the machine controller automatically change device configuration based on recipe change. This would eliminate the need for an operator to manually change device parameters, thus saving time and minimizing human error, especially if the device is not easily accessible by a human.

Maintenance

Having direct access to device parameters by the machine controller also enables OEMs to simplify their machines’ serviceability. For component replacement, all the maintenance personnel would have to replace a damaged device with a new device and walk away, eliminating the need for specialized training, software, or hardware.

Some manufacturers add special functions to their IO-Link masters to enable automatic backup and restoration of IO-Link slave device parameters, making replacement of components as easy as plug and play. This function would eliminate the need for OEMs to create custom programs or logic in their PLCs to restore parameter sets on a device automatically.

How to

So how would I do this? Because parameter data is accessible by the machine controller, implementation of auto configuration differs based on what brand of controller you are using. I will mention a few of the most popular.

  • Allen Bradley – For the Allen Bradley family of PLCs, you would use an explicit  instruction to read and write IO-Link device parameters.
  • Siemens -For the Siemens family of PLCs, you would use a standard function block named “FB_IOL_CALL”.

As you can see, every PLC or machine controller manufacturer and their flavor of IDE (Integrated Development Environment) will have their unique way of accessing IO-Link device parameter set. It is best to consult with both manufacturers and review IO-Link devices and PLCs to better understand how to set the read and write parameters of an IO-Link slave device.

Conclusion

Having direct access to device parameters and being able to change them without taking the device offline or needing special software or hardware, and implement it at a device level is game-changing. It opens doors for time and cost savings in design, integration, operation, and serviceability of machines. It is different from what we are used to, so don’t be afraid to think outside of the box and jump in with both feet.

 

IO-Link Parameterization Maximizes Functionality, Reduces Expenses

Parameters are the key to maximizing performance and stretching sensor functionality on machines through IO-Link. They are typically addressed during set up and then often underutilized because they are misunderstood. Even users familiar with IO-Link parameters often don’t know the best method for adjustment in their systems and how to benefit from using them.

Using parameters reduces setup time
During standard installation, users must acquire all manuals for each IO-Link device and then hope that all manufactures provided detailed information for parameter setting. All IO-Link device manufacturers are required to produce an IODD file, which can be accessed through the IODD Finder. This IODD file provides a list of available parameters for an IO-Link device which will save the user time by eliminating the need for manuals. Some IO-Link masters can permanently store IODD files for rapid IO-Link parameterization. This feature brings the parameters into an online webpage and gives drop down menus with all available options along with buttons for reading and writing the parameters.

1

Maximize functionality of the device
Setpoints can be changed on the fly during normal operation of the machine which will allow a device to expand to the actual range and resolution of each device. Multiple pieces of information can be extracted through IO-Link parameters that are not typically available in process data. One example being an IO-Link pressure sensor with a thermistor included so that temperature can be recorded in the parameters while sending normal pressure values. This allows the user to understand the health of their devices and gather optimal information for more visibility into their processes.

Allows for backup and recovery
IO-Link parameterization allows the user to read and write ALL parameters of IO-Link Data of the device. For example, a two-set point sensor will typically have a teach button/potentiometer that technically limits adjustment for only two parameters and cannot be backed up. This method leaves devices vulnerable to extended downtime from loss of setpoints as well as adding complex teach functions that are not precise. IO-Link parameterization on the other hand pulls teach buttons/potentiometers into the digital world with precision and repeatability. Some IO-Link master blocks have a parameter server function that backs up device parameters in case a sensor needs to be replaced, ultimately providing predictive maintenance, reduced downtime, and easy recipe changes quickly throughout the process.

Using IO Link parameterization is highly important because it reduces setup time, maximizes the functionality of the IO-Link device, and allows for backup and recovery of the parameters. Implementing parameters results in being more cost effective and decreases frustration during the installation process and required maintenance. These parameter functions are just one of the many benefits of using IO Link.

From Design and Build, to Operation and Maintenance, IO-Link Adds Flexibility

With almost twelve million installed nodes as of 2019, IO-Link is being rapidly adopted in a wide range of industries and applications. It is no wonder since it provides more flexibility in how we build and maintain our machines and delivers more data.

Design
As an IEC standard (IEC 61131-9), IO-Link provides consistency in how our devices are connected and integrated. With an already large and ever growing base of manufacturers providing IO-Link devices, we have an incredible amount of choice when it comes to what vendors we use and what devices we incorporate into our systems, all while having the confidence that all of these devices will work and communicate together. Fieldbus independent and based on a point-to-point connection using standard 3 and 4 wire sensor cables, IO-Link allows designers to replace PLC input cards in the control cabinet with machine-mounted IO-Link masters and input hubs. This technology means we are drastically less limited in how we design our machines.

Build/Commissioning
IO-Link is well known for simplifying and reducing build time of machines. Standardization of connections means that readily available double ended quick disconnect sensor cables can replace individually terminated wires, and analogue devices and devices using RS232 connections can be replaced with IO-Link devices which connect directly to a machine mounted IO-Link master or IO hub. Simplified wiring along with delivered diagnostics leads to greatly simplified network architecture and reduced build/commissioning time, as well as increased trouble shooting ability. This all leads to reduced hardware and labor cost.

When it comes to the software side of things, you might think that all of this additional functionality and flexibility increases the burden on programmers, however through the use of configuration files provided by the device manufacturers for both the IO-Link devices and the PLC, this additional functionality and data is at our fingertips with minimal time and effort. With the large adoption of IO-Link and growing manufacturer base comes great amounts of reference material, videos, example programs, and support, all of which can help to get our systems up and running quickly.

Operation
When it comes to operation IO-Link opens a world of possibilities. Bidirectional communication of not only process data but diagnostics and parameter data delivers real time visibility into the entire system during operation all the way down to the device level. Things like automated or guided changeover become possible, for example if a manufacturer produces two different parts on the same line, after the production of part A, devices can be reparameterized for production of part B with the push of a button.

Maintenance
Maintenance sees massive benefits from IO-Link thanks to reduced unplanned downtime through device diagnostics which allow for predictive maintenance practices. If a device does get damaged or fails at an inconvenient time, the issue can be found much quicker and be replaced. Once the IO-Link master recognizes that the device was replaced with the same hardware ID, it can automatically reparameterize the device.

IO-Link is already making our lives easier and providing manufacturers with more possibilities in their automated systems, and as we push into Industry 4.0 it continues to prove its value.

For more information on IO-Link and Industry 4.0 visit www.Balluff.com

 

Reduce the Number of Ethernet Nodes on Your Network Using IO-Link

Manufacturers have been using industrial Ethernet protocols as their controls network since the early 1990s. Industrial Ethernet protocols such as Ethernet/IP, ProfiNet, and Modbus TCP were preferred over fieldbus protocols because they offered the benefits of higher bandwidth, open connectivity and standardization, all while using the same Ethernet hardware as the office IT network. Being standard Ethernet also allows you to remotely monitor individual Ethernet devices over the network for diagnostics and alarms, delivering greater visibility of the manufacturing data.

With Ethernet as the key technology for Industry 4.0 and digitalization, more and more devices will have Ethernet capabilities. Typical industrial Ethernet nodes on a plant floor could include PLC controllers, robots, I/O devices for sensors, actuators, flowmeters, transducers and manifolds. While, it’s great getting all the data and diagnostics of the entire manufacturing process, having every device connected via Ethernet has some downfalls. It can lead to larger Ethernet networks, which can mean more costs in hardware such as routers, switches and Ethernet cables, and some Ethernet software license costs are based on the number of Ethernet nodes being used in the network.

Also, as more Ethernet devices are added to a network, the Ethernet network itself can get more complex. Each individual Ethernet device requires an IP address. If an Ethernet node stopped working and needed to be replaced, an operator would need to know the previous IP address of the device and have quick access to the manual with instructions on how to assign the previous IP address to the new device. Someone must also manage the IP addresses on the network. There will need to be a list of the IP addresses on the network as well as the available ones, so when a new Ethernet device is added to the network, a duplicate address is not use

One way to reduce the number of Ethernet nodes while still getting device data and diagnostics is by using IO-Link for field device communications. IO-Link is an open point-to-point communication standard for sensors and actuators published by IEC (International Electrotechnical Commission) as IEC 61131-9. Since it’s fieldbus and manufacturer independent, there is a long list of manufacturer devices that come with IO-Link. Each IO-Link device can then be brought back to a single Ethernet node, through an IO-Link to Ethernet gateway. Since it’s open technology, there are also multiple manufacturers that make different IO-Link to industrial Ethernet gateways.

On the IO-Link to Ethernet gateway, each channel has an IO-Link master chipset. It is designed to automatically communicate and provide data as soon as an IO-Link device is connected to a port. So, there is no addressing or additional setup required. IO-Link is point to point, so it’s always a single IO-Link device connected to a single port on the gateway using a standard sensor cable. Depending on the number of IO-Link devices to be connected to a single Ethernet node, IO-Link gateways can come in 4, 8 or 16 device channels. This graphic (image 1) shows six IO-Link devices connected to a single 8-channel Ethernet gateway. This gateway then communicates back to the Ethernet PLC controller as a single IP address with a standard Ethernet cable. Without using IO-Link, this might require all six devices to be industrial Ethernet devices. Each device would have its own IP address to set up, along with six Ethernet cables going back to a 6-port managed switch before going to the PLC controller.

 

1
Image 1: Six IO-Link devices connected to a single 8-channel Ethernet gateway.

IO-Link Devices Connected:

  1. Device I/O Hub used to connect to 16 standard discrete sensors/photoeyes.
  2. Valve Manifold used to control up to 24 coils.
  3. Visual Indicator Light
  4. RFID Processor System
  5. Pressure Sensor
  6. IO-Link to Standard Analog (0-10V or 4-20ma) Converter

Improve Error Proofing with IO-Link and IoT-Enabled Sensors

Though error-proofing sensors and poka yoke have been around for decades, continuing advancements related to the Industrial Internet of Things (IIoT) are making both more accessible and easier to maintain.

Balluff - The IO-Link Revolution!

Designed to eliminate product defects by preventing human errors or correcting them in real time, poka yoke has been a key to a lean manufacturing process since it was first applied to industrial applications in 1960. Today, error proofing relies far less on manual mechanisms and more on IoT-enabled error proofing sensors that connect devices and systems across the shop floor.

IoT is enabling immediate control of error-proofing devices such as sensors. This immediacy guards against error-proofing devices being bypassed, which has been a real problem for many years. Now, if a sensor needs adjustment it can be done remotely. A good example of this is with color sensors. When receiving sub-components from suppliers, colors can shift slightly. If the quality group identifies the color lot as acceptable but the sensor does not, often the color sensor is bypassed to keep production moving until someone can address it, creating a vulnerable situation. By using IoT-enabled sensors, the color sensor can be adjusted remotely at any time or from any location.

The detection of errors has been greatly improved by integrating sensors directly into the processes. This is a major trend in flexible manufacturing where poka yoke devices have to be adjusted on-the-fly based on the specific product version being manufactured. This means that buttons or potentiometers on discrete sensors are not adequate. Sensors must provide true data to the control system or offer a means to program them remotely. They must also connect into the traceability system, so they know the exact product version is being made. Connections like this are rapidly migrating to IO-Link. This technology is driving flexible manufacturing at an accelerated rate.

IO-Link enables sensors to process and produce enriched data sets. This data can then be used to optimize efficiencies in an automated process, increase productivity and minimize errors.

Additionally, the easily expandable architecture built around IO-Link allows for easy integrations of poka yoke and industrial identification devices. By keeping a few IO-Link ports open, future expansion is easy and cost effective. For poka yoke, it is important that the system can be easily expanded and that updates are cost-effective.

Using Data to Drive Plant Productivity

What is keeping us from boosting productivity in our plants to the next level? During a recent presentation on Industry 4.0 and IIoT, I was asked this question.

The single biggest thing, in my opinion, that is keeping us from boosting productivity to the next level is a lack of DATA. Specifically, data about the systems and the processes.

1

Since the beginning of time, we have been hungry for efficiency. While early man invented more efficient methods to hunt and survive, today we are looking for ways to produce more efficiently in our plants with minimum or zero waste. After exhausting all the avenues for lean operations on plant procedures and our day-to-day activities, we are now looking at how we can recover from unanticipated downtime quickly. I am sure in future we will be seeking information on how can we prevent the downtime altogether.

There are plentiful of reasons for downtime. Just a few examples:

  1. Unavailability of labor – something we might be experiencing these days, when the COVID-19 pandemic has reduced some labor forces
  2. Unavailability of raw materials
  3. Unavailability of replacement components
  4. Unavailability of assets
  5. Failures in machines/components

In this list, the first two reasons, are beyond the scope of this blog’s intentions and frankly somewhat out of controls from the production standpoint.

The next two reasons, however, are process related and the last one is purely based on the choices we made. These three reasons, to a certain extent, can be reduced or eliminated.

If the downtime is process related, we can learn from them and improve our processes with so called continuous improvement initiatives. We can only do these continuous improvements based on observable factors (a.k.a. data) and we cannot improve our processes based on speculations. Well, I shouldn’t say “cannot”, but it will be more like a fluke or luck. It is apt to say “ what can’t be measured, can’t be improved!”

A good example for elaborating my point is change-over in the plant to produce a different product. Unless there is a good process in place for ensuring all the change-over points are properly addressed and all the change parts are correctly installed and replaced, the changeover time could and will likely lead to tremendous amounts of lost productivity. Secondly, if these processes are done manually and not automated, that is also a loss of productivity or, as I like to say, an area for continuous improvement to boost productivity based on observable facts. Sometimes, we take these manual change-overs as a fact of life and incorporate that time required as a part of “planned” downtime.  Of course, if you do change-overs once a year – it may be cost effective to keep the process manual even in today’s situation. But, if your plant has multiple short batch productions per day or per week, then automating the changeovers could significant boost productivity. The cost benefit analysis should help prove if it is continuous improvement or not.

Assets are an important part of the equation for smooth operations. An example would be molds in the stamping plant or cutting-deburring tools in metal working plants. If plants have no visibility or traceability of these important assets for location, shape or form, it could lead to considerable downtime. The calibration data of these tools or number of parts produced with the tool are also important pieces of data that needs to be maintained for efficient operations. Again, this is data about the system and the integration of these traceability initiatives in the existing infrastructure.

Failures in machines or components could cause severe downtime and are often considered as unavoidable. We tackle these failures in a two-step approach. First, we hunt for the problem when it is not obvious, and two, we find the replacement part in the store room to change it out quickly. And, as process improvement, we schedule preventative maintenance to inspect, lubricate and replace parts in our regular planned downtime.

The preventative maintenance is typically scheduled based on theoretical rate of failure. This is a good measure, especially for mechanical components, but, predictive or condition-based maintenance usually yields higher returns on productivity and helps keep plants running smooth. Again, predictive maintenance relies on data about the condition of the system or components. So, where is this data and how do we get to it?

Standardization of interfaces is another important component for boosting productivity. In my next blog, I will share how IO-Link as a technology can help address all of these challenges and boost productivity to the next level.

Are machine diagnostics overburdening our PLCs?

In today’s world, we depend on the PLC to be our eyes and ears on the health of our automation machines. We depend on them to know when there has been an equipment failure or when preventative maintenance is needed. To gain this level of diagnostics, the PLC must do more work, i.e. more rungs of code are needed to monitor the diagnostics supplied to the sensors, actuators, motors, drives, etc.

In terms of handling diagnostics on a machine, I see two philosophies. First, put the bare bones minimum in the PLC. With less PLC code, the scan times are faster, and the PLC runs more efficiently. But this version comes with the high probability for longer downtime when something goes wrong due to the lack of granular diagnostics. The second option is to add lots of diagnostic features, which means a lot of code, which can lessen downtime, but may throttle throughput, since the scan time of the PLC increases.

So how can you gain a higher level of diagnostics on the machine and lessen the burden on the PLC?

While we usually can’t have our cake and eat it too, with Industry 4.0 and IIoT concepts, you can have the best of both of these scenarios. There are many viewpoints of what these terms or ideas mean, but let’s just look at what these two ideas have made available to the market to lessen the burden on our PLCs.

Data Generating Devices Using IO-Link

The technology of IO-Link has created an explosion of data generating devices. The level of diversity of devices, from I/O, analog, temperature, pressure, flow, etc., provides more visibility to a machine than anything we have seen so far. Utilizing these devices on a machine can greatly increase visibility of the processes. Many IO-Link masters communicate over an Ethernet-based protocol, so the availability of the IO-Link device data via JSON, OPC UA, MQTT, UDP, TCP/IP, etc., provides the diagnostics on the Ethernet “wire” where more than just the PLC can access it.

Linux-Based Controllers

After using IO-Link to get the diagnostics on the Ethernet “wire,” we need to use some level of controller to collect it and analyze it. It isn’t unusual to hear that a Raspberry Pi is being used in industrial automation, but Linux-based “sandbox” controllers (with higher temperature, vibration, etc., standards than a Pi) are available today. These controllers can be loaded with Codesys, Python, Node-Red, etc., to provide a programming platform to utilize the diagnostics.

Visualization of Data

With IO-Link devices providing higher level diagnostic data and the Linux-based controllers collecting and analyzing the diagnostic data, how do you visualize it?  We usually see expensive HMIs on the plant floors to display the diagnostic health of a machine, but by utilizing the Linux-based controllers, we now can show the diagnostic data through a simple display. Most often the price is just the display, because some programming platforms have some level of visualization. For example, Node-Red has a dashboard view, which can be easily displayed on a simple monitor. If data is collected in a server, other visualization software, such as Grafana, can be used.

To conclude, let’s not overburden the PLC with diagnostic; lets utilize IIoT and Industry 4.0 philosophy to gain visibility of our industrial automation machines. IO-Link devices can provide the data, Linux-based controllers can collect and analyze the data, and simple displays can be used to visualize the data. By using this concept, we can greatly increase scan times in the PLC, while gaining a higher level of visibility to our machine’s process to gain more uptime.

What data can IO-Link provide?

As an application engineer, one of the most frequent questions I get asked by the customers is “What is IO-Link and what data does it contain?”.

Well, IO-Link is the first worldwide accepted sensor communication protocol to be adopted as an international standard IEC61131-9. It is an open standard, and not proprietary to one manufacturer. It uses bi-directional, single line serial communications to transfer data between the machine controller and sensors/actuators. No other communication protocol is manufacturer and fieldbus independent, and yet provides this level of communication down to the sensor/actuator level. It provides the user with three different data types: process data, parameter data, and diagnostics or event data.

Process Data

Process data of an IO-Link smart device is considered the latest state of that device. Containing both input and output data, process data is cyclically exchanged between IO-Link master and IO-Link slave device (i.e. sensor or actuator). The time interval or data update rate solely depends on amount of data, 1 to 32 bytes, and speed at which an IO-Link slave device communicates. IO-Link standard (IEC61131-9) defines three different communications speeds; COM1 is set to 4.8kBaud (slowest), COM2 is set to 38.4kBaud and COM3 is set to 230.4kBaud (fastest). Depending on the device, process data may contain status of inputs or outputs of remote I/O hub, position feedback of linear transducers, pressure feedback from pressure transducers, information from am RFID (Radio Frequency Identification) reader, and so on. For more information about process data content, refresh rate, and data mapping, one should reference an IO-Link slave device datasheet or user manual.

Lastly, process data is then buffered in memory of the IO-Link master device and passed to the controller via a specific fieldbus at request packet interval. Request packet interval is set in the controller settings.

Process Data

Parameter Data

Parameter data contains information and parameters specific to the IO-Link slave device. This data is exchanged acyclically, which means that it is requested from the IO-Link master or controller and not time based. Parameters can be read from a specific device or written to. Parameter data is primarily used for device configuration, or verification. A key advantage of IO-Link is that it gives the controller the full access to IO-Link slave device parameters, down to a sensor/actuator level. This means that your controller, PLC or PC based, can change the configuration of an IO-Link’s slave device dynamically without taking the device off line, and without use of proprietary cabling or configuration software.

Typical use of parameter data is for automatic machine configuration, recipe change, process tuning, maintenance, and easy component replacement.

Parameter Data

Diagnostics or Event Data

Diagnostic data provides the controller with events that affect the operation and performance of the IO-Link smart device. Content can vary depending on the device used, and the manufacturer. IO-Link smart devices can provide crucial data such as load, temperature, stress level, overload and short circuit diagnostics, error codes, configuration or parameter issues, access issues, etc., as part of diagnostic or event data. The event code size is 2 bytes, and in hexadecimal data format. This information can then be interpreted by the controller/user using a lookup table or IODD (I/O Device Description) file. User manual will have diagnostic data table that can be used as a reference.

Diagnostic and Event Data

Conclusion

In conclusion, IO-Link enables a plug-and-play relationship between the controller and the devices on the machine. Using IO-Link data, the controller can automatically recognize and configure an IO-Link slave device that is connected to its network. Process and diagnostic data provide continuous feedback on machine status and health down to a sensor level — the lowest level of the automation pyramid.

Keep in mind that the content of process data is specific to the device and will vary from device to device, and manufacturer to manufacturer. This makes IO-Link data one of the main differentiators between smart devices and their manufacturers. Luckily, IO-Link is an open standard, and fieldbus and manufacturer independent, so you can mix and match devices best suited for your application without worrying about device compatibility, special cabling, or third-party configuration software packages.

automation pyramid