It is important to clearly separate IO-Link and whatever Ethernet based protocol a user might select. While IO-Link adds functionality and diagnostics capability to an "end device" it is still, as was pointed out, a parallel wiring technology and does therefor not simplify installations using Ethernet. As was pointed out the overhead associated with Ethernet is significant. This makes it necessary for Ethernet field I/O to have a relatively high I/O count; perhaps 16 or 32 I/O points per module. IO-Link is not going to change that fact. Considering applications in material handling or storage and retrieval such a high I/O count results in setting up an Ethernet network PLUS a significant parallel (i.e. hardwired) cabling to the sensors and actuators. IO-Link or not, the extra material (cordsets, wiring duct ...) needed is still considerable. In those cases a highly decentralized solutions like AS-Interface offers better functionality, faster installation, reduced material and ultimately lover cost. And since AS-Interface makes use of a proven installation piercing technology adding low density I/O wherever necessary is possible. It should also be mentioned that AS-Interface does not replace Ethernet. On the contrary, users selecting any Ethernet solution will simply add the appropriate gateway and then collect field I/O through low density/ low cost I/O modules (some are as little as a book of matches.) From the PLC's point of view a gateway is simply an Ethernet I/O module with hundreds of I/O points.
Helge, Excellent discussion and analysis. The point is that these technologies can extend networking functionality at low cost the last foot, and provide a way to increase the intelligence of these devices without costs especially for setting parameters, configuration and diagnostics. Thanks.
apresher, the important thing is that Ethernet brings a lot of advantages to the industrial environment, while having a different structure than networking protocols that were designed for that environment. The idea of a two tier approach, with another protocol handling the shorter distance, lower speed aspects of the last foot, is almost inevitable. With the availability of standardized modules that interface these other bus technologies with Ethernet, a system can be created that easily handles modules with different protocols in the same system. As long as the programmer can treat these as I/O points on the Ethernet network, then various suppliers can be used without unduly restricting the design. This is the essence of the systems approach.
Chuck, I am not sure about the development history of IO-Link. Clearly it was motivated by the need for an inexpensive way to easily set dconfiguration parameters, monitor systems and do troubleshooting of inexpensive devices linked to a fieldbus network. Automation suppliers have widely embraced it for all of those reasons. The overhead and expense of adding Ethernet to these simpler devices, such as sensors, plus the openness of the technology has also played a key role in its gaining support.
In an age of globalization and rapid changes through scientific progress, two of our societies' (and economies') main concerns are to satisfy the needs and wishes of the individual and to save precious resources. Cloud computing caters to both of these.
For industrial control applications, or even a simple assembly line, that machine can go almost 24/7 without a break. But what happens when the task is a little more complex? That’s where the “smart” machine would come in. The smart machine is one that has some simple (or complex in some cases) processing capability to be able to adapt to changing conditions. Such machines are suited for a host of applications, including automotive, aerospace, defense, medical, computers and electronics, telecommunications, consumer goods, and so on. This discussion will examine what’s possible with smart machines, and what tradeoffs need to be made to implement such a solution.