A decade ago, communications in machines took place on a point-to-point basis. If you were building a multi-axis system, you would have to wire 15 wires per axis from the drive to the controller. If an axis faulted, the system would only return a single digital I/O point indicating a fault. Discovering the source required interrogating the drive—no matter where on the machine it was located—then spending a significant amount of time troubleshooting. The development of industrial Ethernet changed that model and those of us working in machine automation have never looked back.
All those wires involved in point-to-point wiring created significant problems, especially as axis counts rose. All those wires added complexity, took time to install, required space, and cost money. In addition, they were a nightmare to troubleshoot, especially in the case of intermittent faults (and wiring faults are almost inevitably intermittent). Early fieldbuses represented a significant improvement over point-to-point wiring but had limitations in terms of speed and ease of use. Interfacing devices designed for different field buses required custom firmware. Speed restrictions limited the number of devices that could be interconnected, practically speaking. Industrial Ethernet provided a major upgrade.
With Industrial Ethernet, a single cable is all that is necessary to connect master encoders, drives, and controllers. Instead of having to hook up a laptop to each device individually in order to troubleshoot, you can just connect to the master and interrogate the entire network. Instead of just getting a single digital I/O point back after a fault, you can review and interrogate the drive to find out exactly what happened.
The many flavors of industrial Ethernet
Ethernet was initially developed for computer networking. As a result, it was packet-based and built around best-effort delivery. A packet might be delayed simply because of traffic management. Packets might be lost, as well. This isn’t a problem when it involves a print job or an email. If it involves a drive command or feedback for a 100-axis printing machine, however, determinism becomes a huge issue. Packets need to get where they’re going in the order and in the time frame required. This makes determinism a major concern in the design and execution of industrial Ethernet protocols.
At the beginning, there were a number of contenders in the industrial Ethernet space, including CIP, EtherCAT, Ethernet/IP, ProfiNET, and Ethernet POWERLINK, not to mention more conventional field buses like CANopen, DeviceNet, and Profibus.
Common Industrial Protocol (CIP): Media-independent industrial automation standard based on a producer-consumer model. CIP lends itself to various hierarchies, including master-slave, target-originator, and slave-multimaster. It is an object-oriented protocol that describes the operating and communications characteristics of each device. The CIP family of standards includes CIP Motion, which enables drive control, and CIP Sync, which defines a distributed clock.
DeviceNet: Digital fieldbus designed for master-slave control and centralized architectures or peer-peer control over distributed architectures. The protocol can link 64 nodes at up to 500 kbps. It’s not a motion-specific protocol but can be used in simple systems, particularly for tasks like feedback.
EtherCAT: Based on a master-slave architecture, EtherCAT supports deterministic, highly synchronized motion. An EtherCAT telegram goes from the master to each attached node in sequence before returning. It can introduce a certain amount of latency as a result, but the speeds are so fast (100 Mbps) that it is not an issue for practical purposes. EtherCAT operates at cycle times of 100 µs and jitter of 1 µs or less; it can connect more than 65,000 separate nodes.
The EtherCAT protocol defines the physical layer and the data layer of the network. For the network layer itself, EtherCAT supports multiple different communications profiles, including CANopen over EtherCAT (CoE).
Ethernet POWERLINK: A real-time protocol deterministic enough for motion control, Ethernet PowerLink can also send non-real-time data over TCP/IP frames. Built around the master-slave architecture, ethernet PowerLink uses a master clock to synchronize communications. A polling message timed to the clock both sends information to the slave nodes and interrogates them for their replies. It operates at 100 Mbps, with a minimum cycle time of 200 µs and a jitter of about 20 ns. Each master (managing node) can control up to 259 nodes, each of which can act as a master in its own right.
ProfiNET IRT: Based on a producer-consumer model, uses a master clock to schedule communications at asynchronous time frames. ProfiNET uses its own ether type, which enables motion messages to avoid the TCP/IP transport layer and go directly to the application layer. As a result, it is able to support hard-realtime communications.
Each protocol has its pros and cons. In many cases, they are proprietary and in most cases they don’t play well with one another. The exception is CIP, which works well with DeviceNet and Ethernet/IP, but that is because they all originated with Allen Bradley.
From an engineering standpoint, dealing with all these protocols has been more than a little frustrating. As the system designer, you want to use the best technology for the application. You don’t want to be locked into a proprietary protocol because that is the only option available for a given motor or drive—or because the end-user already has that protocol on some of their installed base. So, back in the early days, those of us in the OEM community did the best we could and waited for the competition to shake out.
Fast forward by a decade and it’s all over but the shouting. From where we sit, EtherCAT has won the industrial Ethernet derby. The EtherCAT Technology Group includes hundreds of members. There are commercially available EtherCAT steppers, sensors, drives, controllers, encoders, switches, and even safety. At a series of regular meetings called PlugFests, manufacturers test out their equipment for interoperability. The result is a user-friendly suite of solutions.
The EtherCAT protocol supports highly deterministic and flexible control. Our team at Motion Solutions recently built a 100-axis motion system designed for high-volume testing of consumer electronics products. They wanted to be able to vary the number of devices under test rapidly and without any additional effort.. They wanted to be able to modularly take off 24 axes at a time and make them modular[0608]. If you were to try to wire that type of system discretely, the bundle of wire to make it work would probably be four inches in diameter. With EtherCAT, it was easy. We connected the components with an EtherCAT cable[0730]. We supplied power to the drive and the customer could power it up with three sets of twenty-four axes or zero sets of twenty-four axes, it doesn’t care. [0822] [0940]
There are many applications our team at Motion Solutions has tackled that would have been extremely difficult without EtherCAT. It really lends itself to applications that require coordinating multiple axes.
In the OEM community, we need performance and flexibility. We don’t want to be locked into a single supplier. EtherCAT delivers not just the performance but a broad choice of components from a deep and vibrant supplier ecosystem. Just as important, the members of the ecosystem work to ensure interoperability. When you buy EtherCAT components from two different vendors, you don’t have to wonder whether they will work together. You know they will. Engineering at its heart is about choosing the best technology for the job. EtherCAT has become that technology.
About the Author
Bill Lackey is vice president of automation, Motion Solutions.
