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?

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.

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.

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.

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.

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.

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”

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”

Where does IO-Link go in 2011?

As I sit and ponder what 2011 will look like, only one thought comes to mind, the endless possibilities of IO-Link.

I have written many entries on IO-Link and as I see it there are much more to come.  Why more IO-Link?  The answer is simple; we have just scratched the surface of the potential of what an IO-Link system can offer an end-customer or OEM.  Let’s talk about a few upcoming milestones in 2011 to look forward to:

Continue reading “Where does IO-Link go in 2011?”

IO-Link Scalability Animation Video


Share

How can I use IO-Link in my application?  How is IO-Link scalable?  If these are questions you still have, watch this animation describing the scalability of IO-Link.  To learn more about Balluff’s IO-Link offering, click here