Posted on

Mastering IO-Link: Best Practices for Seamless Industrial Automation Integration

IO-Link is a versatile communication protocol for use in industrial automation to connect sensors and actuators to control systems. Here are some best practices to consider when implementing IO-Link in your automation setup:

Device selection: Choose IO-Link devices that best fit your application’s requirements. Consider factors such as sensing range, accuracy, ruggedness, and compatibility with your IO-Link master and network. Look to see if add-on Instructions and/or function blocks are available for ease of integration.

Network topology: Design a clear and well-organized network topology. Plan the arrangement of IO-Link devices, masters, and other components to minimize cable lengths and optimize communication efficiency. Remember that the maximum distance for an IO-Link device is 20 meters of cable from the IO-Link master.

Standardized cable types: Use standardized IO-Link cables to ensure consistent and reliable connections. High-quality cables can prevent signal degradation and communication issues. Pay careful attention to the needs of the IO-Link device. Some devices require 3, 4, or 5 conductors in the associated cable.

Parameterization and configuration: Take advantage of IO-Link’s ability to remotely configure and parameterize devices. This simplifies setup and makes it possible to change device settings without physically accessing the device. Learn how to take advantage of the IO-Link master’s parameter server functionality.

Centralized diagnostics: Use the diagnostic capabilities of IO-Link devices to monitor health, status, and performance. Centralized diagnostics can help identify issues quickly and enable predictive maintenance. Of the three types of IO-Link data, pay attention to the event data.

Remote monitoring and control: Leverage IO-Link’s bi-directional communication to remotely monitor and adjust devices. This can improve operational efficiency by reducing the need for manual intervention.

Error handling: Implement error handling mechanisms to respond to communication errors or device failures. This could include notifications, alarms, and fallback strategies.

Network segmentation: If you have a large and complex automation setup, consider segmenting your IO-Link network into smaller sections. This can help manage network traffic and improve overall performance.

Training and documentation: Provide training for your team on IO-Link technology, best practices, and troubleshooting techniques. Create documentation that outlines network layouts, device addresses, and configuration details.

Testing and validation: Thoroughly test IO-Link devices and their interactions before deploying them in a production environment. This can help identify potential issues and ensure proper functionality.

Scalability: Plan for future expansion by designing a scalable IO-Link network. Consider how easily you can add new devices or reconfigure existing ones as your automation needs evolve.

Vendor collaboration: Collaborate closely with IO-Link device manufacturers and IO-Link master suppliers. They can provide valuable insights and support during the planning, implementation, and maintenance stages.

By following these best practices, you can optimize the implementation of IO-Link in your industrial automation setup, leading to improved efficiency, reliability, and ease of maintenance.

Click here to learn more about using IO-Link to improve process quality.

Posted on

Revisiting the Key Points of IO-Link

IO-Link is a communication protocol for use in industrial automation systems to connect sensors and actuators to a central control system. It provides a standardized interface for the communication and configuration of devices, allowing for seamless integration and easy parameterization.

Here are some key points about IO-Link

    • Communication: IO-Link uses a point-to-point serial communication link between the IO-Link master and the IO-Link devices (sensors or actuators). Typically, the communication occurs over a standard 3-wire sensor cable.
    • Master/device architecture: The IO-Link system consists of an IO-Link master, which serves as a gateway between the IO-Link devices and the control system. The IO-Link master can connect to multiple IO-Link devices in a network.
    • Device identification: On the network, each IO-Link device uniquely identifies itself. When the devices connect to the IO-Link master, it automatically recognizes the device and communicates its parameters and capabilities to the master.
    • Configuration and parameterization: IO-Link allows for easy configuration and parameterization of connected devices. Through the master, the control system can read and write device parameters, such as sensor ranges, output behavior, and diagnostic information.
    • Data exchange: IO-Link supports the exchange of process data, event data, and service data. Process data is the primary information exchanged between the device and the control system primarily exchange process data, which represents the measured or controlled variables. Status and diagnostic information make up the event data, while configuration and parameterization use the service data.

Overall, IO-Link offers a flexible and standardized communication platform for connecting sensors and actuators in industrial automation systems. Its ease of use, configurability, and diagnostic capabilities make it a popular choice for modern industrial applications.

Click here for some IO-Link application examples.

Posted on

IO-Link Safety: What It Is and Isn’t

Comparing “IO-Link” and “Safety” to “IO-Link Safety”

There are many I/O blocks that have “IO-Link” and “Safety” in their descriptions, which can cause some confusion about which safety features they include. Here’s an overview of different safety-named blocks and how they compare to IO-Link Safety.

Safety Network Blocks

These blocks have I/O ports that use Pin 4 and Pin 2 as OSSD signals (safety ports). OSSD—output switching signal devices—send 24-volt signals over two wires to confirm that a device is operating in a safe condition. If 0 volts are detected in either signal, besides their safety-checking 0-volt pulses, it’s read as a safety event that signals the machine to go into a safe state. Safety network blocks are only for standard (non-network) safety devices. These blocks communicate directly back to a Safety Controller over safety protocols like CIP Safety, PROFIsafe, etc. These blocks typically can monitor between 8-16 standard safety devices. There is no intelligence built into the safety devices.

Safety Network Blocks with IO-Link

Blocks in this category usually have a mixture of I/O ports on them. The ports can range from standard I/O to standard IO-Link communication, and in addition, include ports that use Pin 4 and Pin 2 as OSSD signals (safety ports). These blocks communicate over the safety protocols with only a few ports to connect standard (non-network) safety devices. There is some versatility with these blocks since you can wire standard sensors, IO-Link devices, and safety devices to it. The drawback is, you will always run short of the port style you need and, in the end, use more blocks to cover either the safety or IO-Link needs of the application. There is no intelligence built into the safety devices.

Safety over IO-Link Blocks

In this system/architecture, there are standard IO-Link Masters communicating to the Safety PLCs/Controllers over standard protocols like EtherNet/IP, PROFINET, etc. Connected to the IO-Link Ports of these Masters are Safety over IO-Link devices, currently limited to only Safety over IO-Link hubs. The Safety PLCs/Controllers communicate via safety protocols like PROFIsafe to the standard IO-Link Master, and then using the IO-Link communication channel, they bridge the gap to the Safety over the IO-Link hub via the “black channel.” These Safety over IO-Link hub’s ports use Pin 4 and Pin 2 as OSSD signals (safety ports), so standard (non-network) safety devices can be connected. This system provided a “gap filler” while IO-Link Safety was being developed. In this system/architecture, the standard IO-Link Masters allowed standard IO-Link devices and Safety over IO-Link hubs to be connected to any ports. This brought even more versatility to an application and the beginnings of the benefits of IO-Link. Still, there is no intelligence built into the safety devices.

IO-Link Safety

IO-Link Safety adds a safety communication layer to IO-Link. The difference between this and Safety over IO-Link is that this safety layer applies to both the IO-Link Master and IO-Link Safety devices. Within a CIP Safety or PROFIsafe network, the safety communication protocol has top priority over standard EtherNet/IP or PRIFONET data if both are existing on the same physical network. The same is true for IO-Link Safety: both standard and safety IO-Link protocols can exist on the same physical cable between the IO-Link Master ports and IO-Link Safety devices, with IO-Link Safety carrying the top priority. For a deep dive into the IO-Link Safety protocol, I suggest visiting the IO-Link Consortium’s website at io-link.com. In this system/architecture, you have IO-Link Safety Masters, which communicate to the Safety PLCs/Controllers over safety protocols like CIP Safety, PROFIsafe, etc. The ports on the Masters can utilize Pin 4 and Pin 2 as OSSD signals (safety ports), so standard (non-network) safety devices can be connected. Pin 4 can also be used to carry standard IO-Link and IO-Link Safety communication to standard IO-Link devices and IO-Link Safety devices, respectively. This allows for the most versatile safety solution in the market–IO-Link Safety Masters that can accept standard (non-network) safety devices, standard IO-Link devices, and IO-Link Safety devices. Intelligence in the IO-Link Safety devices is now available.

Benefits of IO-Link Safety

    • IO-Link Safety devices are fieldbus neutral: you just need to specify the IO-Link Safety Master to match the Safety PLCs/Controllers protocol.
    • IO-Link Safety Master port versatility: standard (non-network) safety devices, standard IO-Link devices, and IO-Link Safety devices can be connected.
    • Parameter storage: standard IO-Link and IO-Link Safety device’s parameters can be stored for ease of device replacement.
    • Smart IO-Link Safety device data: more data available, like internal temperature, humidity, number of cycles, power consumption, diagnostics, etc.
    • Simplified wiring: IO-Link Safety devices are still connected to the IO-Link Master port with a standard 3 to 4 conductor cable.
    • IIoT fit: IO-Link Safety gives more visibility to upper-level systems like SCADA, allowing safety device-level monitoring.

I am looking forward to seeing how quickly IO-Link Safety will be accepted, with how IO-Link numbers have skyrocketed over the last few years. The future looks great for IO-Link with IO-Link Safety, IO-Link Wireless and in the future, Single-Pair Ethernet (SPE). With all these new capabilities, what application can’t IO-Link support?

Posted on

IO-Link Event Data: How Sensors Tell You How They’re Doing

I have been working with IO-Link for more than 10 years, so I’ve heard lots of questions about how it works. One line of questions I hear from customers is about the operating condition of sensors. “I wish I knew when the IO-Link device loses output power,” or, “I wish my IO-Link photoelectric sensor would let me know when the lens is dirty.” The good news is that it does give you this information by sending Event Data. That’s a type of data that is usually not a focus of users, although it is available in JSON format from the REST API.

There are three types of IO-Link data:

      • Process Data – updated cyclically, it’s important to users because it contains the data for use in the running application, like I/O change of states or measurement values like temperature and position, etc.
      • Parameter Data – updated acyclically, it’s important to users because it’s the mechanism to read and write parameter values like setpoints, thresholds, and configuration settings to the sensor, and for reading non-time critical values like operating hours, etc.
      • Event Data – updated acyclically, it’s important to users because it provides immediate updates on device conditions.

Let’s dig deeper into Event Data. An Event is a status update from the IO-Link device when a condition is out of its normal range. The Event is labeled as a Warning or Error based on the severity of the condition change.

When an Event occurs on the IO-Link device, the device sets the Event Flag bit in the outgoing data packet to the IO-Link Master. The Master receives the Event Flag and then queries the IO-Link device for the Event information.

It is important to note that this is a one-time data message. The IO-Link device only sends the Event Flag at the moment the condition is out of range, and then again when the condition is back in range.

Event Data Types, Modes, and Codes

Event Data has three following three components:

      • Event Type – categorized in three ways
        • Notification – a simple event update; nothing is abnormal with the IO-Link device
        • Warning – a condition is out of range and risks damaging the IO-Link device
        • Error – a condition is out of range and is affecting the device negatively to the point that it may not function as expected
      • Event Mode – categorized in three ways
        • Event notice – usually associated with Event Type notifications, message will not be updated
        • Event appears – the condition is now out of range
        • Event disappears – the condition is now back in range
      • Event Code
        • A two-byte Hex code that represents the condition that is out of range

IO-Link condition monitoring sensor

To bring all these components together, let’s look at a photoelectric IO-Link sensor with internal condition monitoring functions and see what Events are available for it in this device manual screenshot. This device has Events for temperature (both warning and error), voltage, inclination (sensor angle is out of range), vibration, and signal quality (dirty lens).

By monitoring these events, you have a better feel for the conditions of your IO-Link device. Along with helping you identify immediate problems, this can help you in planning preventive and planned maintenance.

An IO-Link condition monitoring sensor uses Event Data similarly to report when conditions exceed the thresholds that you have set. For example, when the vibration level exceeds the threshold value, the IO-Link device sends the Warning event flag and the IO-Link Master queries for the event data. The event data consists of an Event Type, an Event Mode, and an Event Code that represents the specific alarm condition that is out of range. Remember this is a one-time action; the IO-Link sensor will not report this again until the value is in an acceptable range.

When the vibration level is back in range, the alarm condition is no longer present in the IO-Link device, the process repeats itself. In this case the Event Type and Event Code will be the same. The only change is that the Event Mode will report Event Disappears.

Within the IO-Link Specification there is a list of defined Event Codes that are common across all vendors. There is also a block of undefined Event Code values that allow vendors to create Event Codes that are unique to their specific device.

“I wish the IO-Link device would let me know….” In the end, the device might be telling you what you want to know, especially if the device has condition monitoring functions built into it. If you want to know more about condition monitoring in your IO-Link devices, check out the Event section in the vendor’s manuals so you can learn how to use this information.

Posted on

IO-Link Wireless – IO-Link with Even Greater Flexibility

In a previous blog entry, I discussed IO-Link SPE (Single-Pair Ethernet). SPE, in my opinion, has two great strengths compared to standard IO-Link: cable length and speed. With cable lengths of up to 100 meters and speed of 10 Mbps, compared to 20 meters and max baud rate of 230.4 Kbps, what could be out of reach?

Robots. We see robots with cabling routed either through the arm itself or tracking along the outside of the arm. Every time the robot moves, we know the conductors within these cables are deteriorating. Is there another “tool” in the IO-Link Consortiums special interest groups that can aid us? Yes, IO-Link Wireless.

Basics

Let cover the basics quickly. The architecture will contain a wireless master, wireless in terms of the connection to the IO-Link devices and wireless IO-Link devices. There is no real change to the physical connection of the IO-Link master to the controls system, just the elimination of cabling between the IO-Link master and IO-Link devices. It is perfect for a robot application.

Power

Wireless concepts are not new. When I saw the specification to IO-Link Wireless, the first question that came to mind was about powering the IO-Link devices. Luckily, we are in an age of batteries. and with the evolution of the EV market, battery technology has come a long way. This eliminates my concerns for low power devices. IO-Link was designed to bring more data back from our sensor and actuator devices, so IO-Link is perfectly suited to pass along battery diagnostics; low or failing batteries diagnostics/information should be readily available for a control and/or IIOT system. IO-Link devices with high current consumptions will still need to be wired to a power system.

Density of IO-Link Devices per IO-Link Master

Currently, with wired IO-Link masters, the most common configuration is eight IO-Link ports (i.e., 8 IO-Link devices can be connected), with the rare 16 port version. There is a huge advantage to wireless here within the IO-Link specification. One wireless IO-Link Master can contain up to 5 transmission tracks, where each transmission track can communicate to up to 8 IO-Link devices. That is 40 wireless IO-Link devices per wireless IO-Link master. There are a lot of details within the IO-Link Wireless specification that I will not even begin to discuss, but to go one layer more; within a physical area that the specification calls a “cell”, three wireless IO-Link Masters can exist, giving us a total of 120 wireless IO-Link devices occupying a designated area. We all know that wireless will come with a larger price tags, but at least there is a tradeoff of fewer masters (wired = 15 master, wireless = 3, for 120 devices).

Distance and Speed

I started this blog entry referencing the two strengths of SPE — length and speed. Here is where there is a great difference between Wireless and SPE IO-Link exists. If a wireless master is using one transmission track, the 8 IO-Link devices can be 20 meters away, equaling the standard wired architecture of IO-Link. As soon as we enable another transmission track, the maximum distance drops to 10 meters. The minimum transmission cycle time is 5 milliseconds. Still, I believe the pros of IO-Link Wireless outweigh the length restrictions.

Non-wireless IO-Link devices

Within the specification, there is the ability to have wireless bridges in the architecture. These bridge modules would contain a master IO-Link port to communicate to the standard IO-Link device, and then on the other side communicate to the wireless IO-Link master as a IO-Link Wireless device.

Applications

Obviously, robot end-efforts are the first to come to mind for a wireless solution. Food, beverage and medical applications also comes to mind. By eliminating the cabling, there is less surface area where contaminants can exist. Also, it could be used in inductive race ways, where a “pallet” moves along an inductive rail, which is supplying power, but I may not want to put a controller on each pallet. Lastly, IO-Link Wireless could be a good solution in any place where cabling is flexed and bent.

Conclusion

Does standard wired IO-Link fit every application? No. Does Single-Pair Ethernet and IO-Link Wireless? No. Thankfully, the IO-Link Consortium is giving us multiple methodologies to create our IO-Link architectures, where one application may need to encompass all three. For those applications that require fewer or the elimination of cables, the IO-Link Wireless solution can fit this space. For further information on the IO-Link specification, go to the consortium’s website at: IO-Link.com.

Posted on

Is IO-Link with Single Pair Ethernet the Future?

20 meters.

That is the maximum distance between an IO-Link master port and an IO-Link device using a standard prox cable.  Can this length be extended?  Sure, there are IO-Link repeaters you can use   to lengthen the distance, but is there an advantage and is it worth the headache?

I hope you like doing some math, because the maximum distance is based on the baud rate of the IO-Link device, the current consumption of the IO-Link device and finally the cross section of the conductors in the cabling.  Now throw all that into a formula and you can determine the maximum distance you can achieve.  Once that is calculated, are you done? No.  Longer cables and repeaters add latency to the IO-Link data transfer, so you may need to slow down the IO-Link master’s port cycle time due to the delay.

Luckily, there is a better and easier solution than repeaters and the sacrifice of the data update rate — Single Pair Ethernet (SPE).

SPE is being discussed in all the major communication special interest groups, so it makes sense that its being discussed within the IO-Link Consortium.  Why?  A couple of key factors: cable lengths and updated speeds.  By using SPE, we gain the Ethernet cable length advantage. So, instead of being limited to 20 meters, your IO-Link cabling could stretch to 100 meters!  Imagine the opportunities that opens in industrial applications.  It is possible that even longer runs will be achievable.  With 10 Mbit/s speed, to start, the update rate between IO-Link devices and the IO-Link master could be less than 0.1 millisecond.

Latency has been the Achilles heal in using IO-Link in high-speed applications, but this could eliminate that argument. It will still be IO-Link, the point-to-point communication protocol (master-to-device), but the delivery method would change. Using SPE would require new versions of IO-Links masters, with either all SPE ports or a combination of SPE and standard IO-Link ports. The cabling would also change from our standard prox cables to hybrid cables, containing a single twist Ethernet pair with two additional conductors for 24 volts DC.  We may even see some single channel converts, that convert standard IO-Link to SPE and vice versa.

There likely would have been pushback if this was discussed just five or ten years ago, but today, with new technology being released regularly, I doubt we see much resistance. We consumers are ready for this. We are already asking for the benefits of SPE and IO-Link SPE may be able to provide those advantages.

For more information, visit www.balluff.com.

Posted on

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.

Posted on

Adding a higher level of visibility to older automation machines

It’s never too late to add more visibility to an automation machine.

In the past, when it came to IO-Link opportunities, if the PLC on the machine was a SLC 500, a PLC-5, or worse yet, a controller older than I, there wasn’t much to talk about. In most of these cases, the PLC could not handle another network communication card, or the PLC memory was maxed, or it used a older network like DeviceNet, Profibus or ASi that was maxed. Or it was just so worn out that it was already being held together with hope and prayer. But, today we can utilize IIoT and Industry 4.0 concepts to add more visibility to older machines.

IIOT and Industry 4.0 have created a volume of products that can be utilized locally at a machine, rather than the typical image of Big Data. There are three main features we can utilize to add a level of visibility: Devices to generate data, low cost controllers to collect and analyze the data, and visualization of the data.

Data Generating Devices

In today’s world, we have many devices that can generate data outside of direct communication to the PLC.  For example, in an Ethernet/IP environment, we can put intelligent devices directly on the EtherNet/IP network, or we can add devices indirectly by using technologies like IO-Link, which can be more cost effective and provide the same level of data. These devices can add monitoring of temperature, flow, pressure, and positioning data that can reduce downtime and scrap. With these devices connected to an Ethernet-based protocol, data can be extracted from them without the old PLC’s involvement.  Utilizing JSON, OPC UA, MQTT, UDP and TCP/IP, the data can be made available to a secondary controller.

Linux-Based Controllers

An inexpensive Raspberry Pi could be used as the secondary controller, but Linux-based open controllers with industrial specifications for temperature, vibration, etc. are available on the market. These lower cost controllers can then be utilized to collect and analyze the data on the Ethernet protocol. With a Linux based “sandbox” system, many programming software packages could be loaded, i.e. Node-Red, Codesys, Python, etc., to create the needed logic.

Visualization of Data

Now that the data is being produced, collected and analyzed, the next step is to view the information to add the extra layer of visibility to the process of an older machine. Some of the programming software that can be loaded into the Linux-based systems, which have a form a visualization, like a dashboard (Node-Red) or an HMI feel (Codesys). This can be displayed on a low-cost monitor on the floor near the machine.

By utilizing the products used in the “big” concepts of IIOT and Industry 4.0, you can add a layer of diagnostic visualization to older machines, that allows for easier maintenance, reduced scrap, and predictive maintenance.

Posted on

Defining Your Next Network Architecture: Cost Effectiveness

In my previous blog entry, Defining Your Next Network Architecture: Topologies and Global Standards, I addressed two topics to consider when moving from the “bus” to the “net”.  Here is the next topic I feel you should consider.

Cost Effectiveness – how can we lower the cost and not lose functionality?

Continue reading “Defining Your Next Network Architecture: Cost Effectiveness”

Posted on

Defining Your Next Network Architecture: Topologies and Global Standard

As many machine builders, OEMs, individual plants, and large corporations decide to move from the “bus” to the “net” (Profibus or DeviceNet to Profinet or EtherNet/IP) they have a chance to look at all the new architectures available and decide on which is the best for them.  Here are the first two topics to take into consideration:

Continue reading “Defining Your Next Network Architecture: Topologies and Global Standard”