Rethinking Industrial Ethernet

There’s no doubt that Industrial Ethernet (IE) is paving the way for the automated factory of the future. IE is the backbone of modern industrial communications between devices on the plant floor, the enterprise information network, and the cloud services that companies increasingly rely upon to build and grow their business. At the macro level, IE is as essential to automation control as the internet is to e-commerce.

For all its benefits in transmitting essential manufacturing data from one intelligent device to another, can IE ever be too much of a good thing? Are there situations where we ask too much of it? The answer is yes, and some of those situations hit closer to home than one might think. What follows are two examples of automation control applications where IE was the default solution in the designer’s mind. It turned out, however, that in these real-world examples, for simple and practical reasons, IE was ultimately not the best choice. The companies involved will be referred to as ABC and XYZ.

PID Loop Running on an EtherCAT Controller

Company ABC designs and builds high-tech machinery for inspecting and cleaning precision-made parts. The company’s machines (and therefore its reputation) are built upon cutting edge technology, so ABC relies heavily on advanced control topologies and makes regular use of the high-speed, deterministic, industrial Ethernet protocol EtherCAT. In this application, a relatively simple machine function — using compressed air to clean trays of delicate parts — requires an unusually accurate degree of proportional-integral-derivative (PID) control. If the flow rate is too low, the parts do not come clean enough in a short enough amount of time to support downstream processes. If the flow rate is too high, the parts become dislodged from their seats in the trays.

To accurately control the flow rate of compressed air, ABC initially leveraged its EtherCAT master controller to run the PID loop, in conjunction with a proportional pressure regulator to control flow rate and a flow sensor to provide feedback to the PID loop. A remote I/O block converted EtherCAT data to (and from) the 4-20 mA signals needed for the proportional pressure regulator and flow sensor (Figure 1a).

In many applications this control topology would be perfectly adequate. The latency in the remote I/O block from converting the EtherCAT setpoint data into a 4-20 mA command signal and the 4-20 mA feedback signal back to EtherCAT data only added about 4 milliseconds to the PID loop’s response time. But in this application, where precision control of the air flow was essential, that proved to be too much latency and ABC struggled to achieve consistent results.

In the end, ABC engineers decided to rethink the process by moving the PID loop much closer to the pneumatic components. To do this they used a dedicated, intelligent pneumatic valve controller with on-board PID. This allowed them to send the desired flow rate to the valve controller as data over the EtherCAT network and let the valve controller run its built-in PID loop directly on the valves and sensors contained in the valve manifold. The latency in this new topology dropped below 1 millisecond and allowed the system to successfully meet the target cleaning time ( Figure 1b). As an additional bonus, removing the PID loop from the EtherCAT network freed up a significant amount of bandwidth. In the end, ABC discovered that it could improve machine accuracy by offloading a critical control function from the central controller and high-speed EtherCAT network and moving it to a dedicated controller instead.

The Cost of More IP Addresses

Company XYZ assumed, like many, that IP addresses are cheap and nearly endless in supply. What XYZ discovered is that IP addresses are not nearly so endless and inexpensive in practice. Many industry-leading controllers support a limited number of IP addresses, or nodes, that can connect to them, and this number is much less than one might expect. Most engineers are used to having 255 IP addresses on even the most basic office networks and expect that same number to be true in industrial settings. In many cases industrial controllers support only a fraction of that, with as few as 4, 8, or 16 Ethernet devices supported by a single controller. If there are more IE devices to connect, the engineer can certainly upgrade to a controller that supports more, but those controllers cost more and don’t always come with other features that make the additional cost worth it.

Company XYZ manufactures machines in an extremely competitive industry, so it minds every penny that goes into the bills of materials for its machines. In this application, XYZ installed a controller with all the necessary computing power and I/O points required for the machine. The problem was that this controller only supported four devices on the EtherNet/IP network, and at least five were needed (Figure 2a). Upgrading to a more expensive controller capable of eight devices would make it nearly impossible to meet cost targets. XYZ went back to the drawing board.

The new solution was to keep the existing controller and migrate five of the devices on their machine to IO-Link devices. The IO-Link devices were equivalent in function to the other devices that could operate directly on the EtherNet/ IP network, but came with IO-Link communications instead. This meant the five devices could be removed from the IE network by choosing instead to connect those devices to two IO-Link master modules. The IO-Link master modules in turn connected to the controller via a single EtherNet/IP module, meaning XYZ went from a total of five devices on the IE network down to just one (Figure 2b).

In rethinking the use of IE, XYZ was able to maintain the same level of functionality in their machine by switching to IO-Link devices. They suffered no loss of data between the controller and their devices because of IO-Link’s robust data transmission capabilities. The utilization of IO-Link allowed them to keep the less expensive controller in the design, and the cost savings in doing so more than offset the cost of the two IO-Link masters.

Conclusion

IE is here to stay, and industry is better off for it. IE may not, however, be the best solution in every situation. If designers expect too much from the Ethernet network and force it to solve every control aspect of the machine, even a straightforward PID loop may suffer in performance. And though Ethernet is ubiquitous and seems like it nearly comes for free on so many of today’s devices, in practice an Ethernet device isn’t free. There are parallel solutions, such as IO-Link, that can be used in conjunction with IE to provide excellent performance while saving money in some applications.

This article was written by Eric Rice, Product Market Manager – Electric Automation, Festo Corporation (Islandia, NY). For more information, visit here .

---