Tech Blog
EtherCAt on labview/crio
EtherCAT on LabVIEW / cRIO
Blog overview
This blog discusses EtherCAT, a powerful industrial real-time communications protocol, used in combination with the National Instruments cRIO / LabVIEW environment. This includes bench-marking the timing latency that can be achieved on a cRIO system.
Using EtherCAT with the National Instrument cRIO
The NI cRIO system is inherently designed to deal with the EtherCAT communication protocol. Unlike many other real-time protocols (e.g. CanOpen, Ethernet / IP etc), no additional hardware (e.g. c-Series module) or license is required to use EtherCAT on the cRIO. We suspect this inherent support is largely due to the NI9144 expansion chassis, which uses EtherCAT to communicate with the cRIO master.
The lower of the two RJ45 (Ethernet) ports on the cRIO (shown on the left hand side) can be configured to work as an EtherCAT Master port instead of TCP/IP. This port can then be used to communicate to the NI9144 expansion chassis (shown on the right hand side, used for additional c-Series modules via EtherCAT Slave). The cRIO EtherCAT Master port can also be used to communicate to other EtherCAT slaves (see example below).
Before using EtherCAT on the cRIO, two simple configuration steps are required. First, install the NI-Industrial Communications for EtherCAT divers on your LabVIEW host PC. The drivers can be found here, with some compatibility notes located here.
Once the NI-Industrial Communications for EtherCAT software is installed on the host machine, you will also need to install extra software on the cRIO. Note that this software is only available after installation on the host. Open the NI Measurement and Automation Explorer (MAX), discover your remote target (cRIO), and select add software.
From the list of available software, select the NI-Industrial Communications for EtherCAT component (latest version at the time of writing is 18.5, check this link for compatibility with your LabVIEW version).
Once the installation is complete, check in MAX that the software component is available as shown below.
To enable the EtherCAT port, switch to the Network Settings under the cRIO in MAX, and select the EtherCAT option under adapter mode. For our cRIO 9038 used here, this option is only available under Ethernet Adapter eth1, but this may vary for other cRIO variants.
Adding the EtherCAT Master to a LabVIEW project
As a starting point, we assume you have a LabVIEW project set up with cRIO chassis added. If you are unsure how to add the cRIO RT target, follow the instructions here.
The cRIO generally acts as the EtherCAT Master. Note that the cRIO cannot be directly configured to be an EtherCAT Slave, which would require this additional c-Series module.
To add the EtherCAT Master functionality, right click at the NI-cRIO level and select New > Targets and Devices.
Under the Add Targets and Devices dialog, select the EtherCAT Master Device.
With the cRIO Chassis and the EtherCAT Master Device added, your project should now look similar to this.
Adding EtherCAT slave devices to a LabVIEW project
EtherCAT is most commonly implemented on Beckhoff Industrial automation equipment. However, the protocol is also widely supported by third party hardware suppliers (I/O modules, Motor drives etc). For the example in this blog, we will use the Advantech AMAX-4830 module. This module features 16 digital inputs and 16 digital outputs, and can easily be sourced via Mouser or similar for under $300 (most of the Beckhoff equipment needs to be sourced from specialist suppliers). The I/O channels for the AMAX-4830 module are capable of 100 us operation.
Like all EtherCAT slave devices, the AMAX-4830 has two EtherCAT ports, one IN and one OUT port for connection to additional slaves. To communicate with EtherCAT slaves, LabVIEW requires the information stored in so-called EtherCAT Slave Information (ESI) files. ESI files are based on an XML format and contain all the relevant information about the slave (number of channels, memory addresses etc). For most applications, you will not need to make any modifications to the ESI files, which are generally supplied by the hardware manufacturer. The ESI file for the AMAX-4830 module can be obtained here.
For the cRIO to recognize third party EtherCAT slaves, the ESI files must be placed in a particular directory on the LabVIEW host PC. This is described in detail here and here, and the directory location (from LabVIEW 2013 SP1 onward) is
<Program Files>\National Instruments\LabVIEW XXXX\resource\Framework\Providers\indcomecat\DD
where XXXX is the LabVIEW version you are running (e.g. 2018). Note that <Program Files> is likely <Program Files (x86)>, particularly if you are running the FPGA module, which is only partially supported on 64 bit. For most default LabVIEW installations, the directory already contains some NI-9144 content (and a “Module” sub folder), which enables the communication with the NI-9144 expansion chassis. Simply copy your additional third party ESI file into the above directory. Restart LabVIEW as any new ESI information is only picked up at the LabVIEW initialization stage.
You can now add the EtherCAT slave to your LabVIEW project. Right click on the EtherCAT Master and select New > Targets and Devices
On the Add Target and Devices dialog, you should see the third party device (AMAX-4830 in our case) in the list of available EtherCAT slave devices.
Once the EtherCAT slave device is added, you can expand the Device details in the LabVIEW Project Explorer. This shows all the channels available for this particular slave device, e.g. “Digital Input Port 0 – DI0” in the list shown below. The information displayed here is stored in the ESI XML file, so you can explore this file if you wish to learn more about the structure of the EtherCAT protocol. The channels shown under the Device tree can be used as regular LabVIEW I/O channels (drag and drop into any VI at the RT level), and are handled by the LabVIEW Scan Engine.
Bench-marking the EtherCAT performance in LabVIEW
EtherCAT is designed for control systems that operate in the micro second (us) range. This part of the blog shows a simple benchmark experiment for the AMAX-4830, which supports I/O operations of order 100us. This is not a full benchmark test up to the full capability of the EtherCAT protocol, but rather a brief analysis of what can be achieved in the context of the cRIO Linux RT system.
The limiting factor on the cRIO Linux RT system is the operation of the Scan Engine. The Scan Engine can easily be operated with a scan period of 1ms, see this blog for details. Choosing a loop rate under 1ms is generally not recommended, but possible. For our example, we have selected a Scan Engine period of 400us, for which LabVIEW issues the warning below.
We do not recommend to use a Scan Engine period under 1ms for any commercial applications, but the 400us setting is helpful for the present example without involving the cRIO FPGA.
The EtherCAT benchmark LabVIEW VI is shown below. The main timed loop is synchronized to the Scan Engine (400us). In this VI, we toggle a boolean signal every 50 loop iterations (20ms). This boolean is connected to the AMAX-4830 output channel “Digital Output Port 0-DO0”. The output channel is then physically connected (in hardware) to the AMAX-4830 input channel “Digital Input Port 0-DI0”. The Edge Detect block is used to detect the rising edge on both the input and output lines in LabVIEW. The timings of the rising edges are then recorded, and the difference between the output rising edge and the input rising edge gives the total “round-trip latency” of the I/O operation.
The input channel cannot activate in the same LabVIEW loop cycle in which the output is activated (rising edge), as the Scan Engine rate is the same as the loop rate. As such that we would expect a minimum of 400us between the two rising edges. In practice, we find that it takes 3 LabVIEW loop cycles (1200us) until the rising edge is detected on the input. This means that the total latency of LabVIEW -> EtherCAT -> AMAX output switching -> AMAX input switching -> EtherCAT -> LabVIEW is of order <400us (one loop cycle). The other two loop cycles (800us) are due to the fact that both the output writing and input reading are handled in the same loop, synchronized to the Scan Engine. A short time history of the timing measurement is given below.
The approximately 400us I/O latency (outside LabVIEW) is in line with our expectation. EtherCAT is typically capable of <50us latency (depending on number of connected devices), the AMAX switching is 100us (for input and output), such that around 50us + 100us + 100us + 50us = 300us is certainly reasonable. For a more refined analysis, we would need to involve the cRIO FPGA (loop rates of order us possible), which is planned for a future blog.
At this stage, our conclusion is that for projects requiring 1ms loop times on the NI cRIO RT system, EtherCAT is an excellent communication option, as a latency of under 1ms can be achieved with relatively little effort and no additional hardware cost on the cRIO side. We hope you enjoyed this blog.
If you have any questions, just let us know.