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

Defining IP Ratings and NEMA Ratings

Share

As I was preparing to write my blog entry, I was browsing my e-mail and came across an article in the October Issue of TIA Newsletter (Totally Integrated Automation) from Automation World, concerning IP Ratings.  I found the article , very informative as it broke down the different degrees of IP ratings, as well as some similarity and differences between IP ratings and NEMA ratings.  I only wish there was some information involving IP69K. 

This article, IP Ratings – What are they and what do they mean,  is a great starting point to learn about IP Ratings, I suggest you stop by and read it. 

For more information about IP67, check out The Secret of IP67 Protection.