EtherCAT for PC-based Motion Control

The EtherCAT protocol is an excellent way to implement motion control in an automation control system.  Let’s examine the benefits and techniques for using industrial PC-based control platforms for such a system.

Why EtherCAT?

First, a few words about EtherCAT itself.  Developed as an open standard, the protocol is now supported by dozens of vendors of servo drives, remote I/O blocks, linear actuators and other actuation and sensing devices.  EtherCAT addresses the need for rapid cyclical update of all slave devices with very low rates of jitter.  This is essential for motion control applications, which is one of the primary fields for which it was developed.

One of the benefits of EtherCAT as a field bus is that it can use standard Ethernet cabling and, with some limitations, can even make use of standard Ethernet hardware.  This can help lower implementation costs and simplify the process of planning and specifying a network.  On the other hand, certain precautions must be observed – for example, standard TCP/IP communications should not be intermingled on the same network as EtherCAT, as the deterministic nature of EtherCAT requires complete control over the wire.

A Short Introductory Video to EtherCAT as Implemented by CTC

Using EtherCAT for PC-based Motion Control – challenges and considerations
Several challenges must be overcome to use standard industrial PC-based platforms for automation control, and in some cases these challenges are greater still in implementing EtherCAT:

1. Determinism is the ability to reliably offer the precise, repetitive timing required to consistently control a process, including the ability to service an EtherCAT network on a timely basis. Typical PC operating systems (e.g., Windows, MacOS, Linux) must service numerous asynchronous tasks which interfere with this ability. One way to overcome this issue is to run an EtherCAT master controller on a separate CPU core in the PC-based control system, typically under a real-time operating system (RTOS) that can provide the needed determinism.
2. Standard Ethernet interfaces are not all capable of delivering the necessary performance to implement EtherCAT. This is largely a function of the processing capabilities integrated into the Ethernet chip and how it interacts with main CPU of the system.  We have discovered a number of interfaces which can reliably perform with the required degree of determinism, while others failed in testing.
3. One of the most important reasons for using PC-based control systems is to allow for the coexistence of Windows applications – for instance, HMIs, vision processing systems, data gathering and processing applications – and to provide the ability to interact with higher-level plant IT systems. Providing these capabilities while simultaneously meeting the critical timing requirements of the EtherCAT network can be accomplished using separate CPU cores for the two functions, as mentioned above, but a robust communication path must exist between these two worlds if the potential of a fully integrated system is to be achieved.

We have found that, by implementing a comprehensive control library that can be linked into a C#, C++, or VB.Net program on the Windows core, a clean interface can be established between the Windows world and the real-time world.  This library, communicating with the EtherCAT master controller running under the RTOS, can bridge the communications gap in a controlled manner without any performance impact.

An Example PC-based EtherCAT Master Controller System
Combining the above principles, it’s possible to envision a PC-based control system incorporating all the benefits of EtherCAT without having to add specialized hardware for the purpose.  This example uses the CTC Incentive™ series of software components running on a multicore industrial PC.

The EtherCAT master controller (IncentiveECAT) occupies its own CPU core, shown as core 4 in the diagram.  IncentiveECAT is supplied with its own RTOS, and in the case of our example this RTOS will be running on both cores 3 and 4.  The EtherCAT master controller takes over one of the system’s standard Ethernet ports, to which is attached a network with several EtherCAT devices.

Also shown in the diagram is an optional control system, IncentivePLC, running on the other core controlled by the RTOS.  This software component implements a powerful multi-tasking programmable automation controller (PAC) communicating directly with the EtherCAT master controller.  It also has the capacity to communicate via a second Ethernet port to one or more Modbus/TCP devices, although not with the same degree of determinism that EtherCAT provides.

Finally, cores 1 and 2 are both dedicated to running Windows 10, making them capable of running a wide variety of applications.  In each case the cores are shown running IncentiveAPI, providing the hooks for any of the Windows apps to communicate bidirectionally with the EtherCAT master controller or the PAC.  These cores may make use of any remaining Ethernet ports to connect to a plant network or to devices requiring Ethernet connectivity to their native Windows apps (e.g., vision systems).

This approach results in a highly-flexible control system based on standard hardware and capable of incorporating standard Windows-based applications and protocols without the need for specialized hardware or multi-system integration.