In this blog, we take a closer look into the real-time communication of the Raspberry Pi 5 in combination with our EtherCAT EC-Master Stack. We show you how to setup the EC-Master and we supply additional and interesting background information.

In the end, we run the EC-Simulator in SiL-Mode with 100 simulated SubDevices on the Raspberry Pi 5. You can expect some interesting lecture. Stay tuned…

We realized the tests on a Compute Module 5 IO Board with the Raspberry Pi 5.

To realize the terminal connection via PuTTY, we attached and installed the FT232 communication module. This module converts data from USB-to-serial-UART and we can easily connect via the serial interface to the Compute Module.

Figure 1: Raspberry Pi 5 Computer Module on IO Board

Note: The Raspberry Pi 5 is located under the heat sink on the IO board.

As SubDevices, we connected our acontis performance measurement reference setup, consisting of a

• EtherCAT coupler (EK1100)
• 2x EtherCAT 4-channel digital output Terminal (EL2004)
• 2x EtherCAT 4-channel digital input Terminal (EL1014)
• EtherCAT 2-channel analog output Terminal (EL4132)
• EtherCAT extension (EK1110)

We use this configuration as a reference to test and benchmark different systems. This allows us to have comparable results.

To be prepared to run the EC-Master, we need to create an EtherCAT Network Information (ENI) file, which provides the network configuration to the EC-Master. We generate the ENI-file eni.xml with the configuration and diagnosis tool EC-Engineer.

The well-known BROADCOM System-on-chip (SoC) BCM2712 is used on the Raspberry Pi Compute Module 5. Linux Debian GNU is running on the ARM64Bit architecture.

For the GEM-Ethernet Adapter in the BCM2712, we evolved and tested successfully the acontis Ethernet Driver, called emllGem. With this driver, acontis grants the exclusive access to the Ethernet hardware.

To improve the performance on the system, the acontis kernel module atemsys ensures the direct access from the GEM- Ethernet driver to the Ethernet MAC by bypassing the time-consuming network stack and the native Ethernet driver in the kernel space.

Figure 2: Architecture of Linux system on Raspberry Pi 5

After copying the GEM Driver to the Linux system, we first need to load the atemsys module into the kernel space. This can be done by following command:

insmod atemsys.ko

Snippet 1 The insmod command inserts the atemsys module to the running Linux kernel

As we want to measure the performance of the system running EC-Master, including the Distributed Clock (DC), we start the command:

./EcMasterDemoDc -v 4 -perf -a 0 -f eni.xml -gem 1 1 rpi5 osdriver

Snippet 2 Starting EC-Master Demo with Distributed Clock (DC)

The command line is showing the start of the performance measuring (-perf) and the parametrization of the Ethernet adapter (-gem). The eni.xml is the file which we created with the EC-Engineer as described earlier.

After starting the EcMasterDemoDc, the application will log the results and print to the console in the following format:

Listing 1 EC-Master performance measurement results (emllGEM)

For this test, we set the cycle time to 1 ms (1000 µs). The EtherCAT MainDevice software is responsible for the fast and correct handling of the EtherCAT data. A typical job includes the processing of the received frames (JOB_ProcessAllRxFrames), the writing of the outputs (JOB_SendAllCycFrames), the required administration time to trigger the SubDevices (JOB_MasterTimer) and the sending of acyclic commands (JOB_SendAcycFrames). The App-time is customer specific and can vary depending on the application. The time for the whole job is only 9.9 µs. If we take this value in ratio with the cycle time, only 0,99% of the used cycle time is used for the whole communication process.

Now, let’s look into the EC-Simulator. The EC-Simulator virtualizes EtherCAT networks by simulating the EtherCAT SubDevices, so no hardware EtherCAT SubDevices are necessary to run the EtherCAT Master applications. The EC-Simulator is able to handle Process Data (PDOs), sending and receiving of Service Data (SDOs) and interacting with the SubDevice Stack.

There are two scenarios how and where the EC-Simulator can run on systems.

First, the EC-Simulator can run on a separate hardware. In this case, the EC-Master is communicating via a physical cable with the simulation system running on a standard PC or an embedded microprocessor. This scenario is called Hardware-in-the-Loop, short HiL Simulation.

The second scenario is the Software-in-the-Loop, known as SiL Simulation. We explain this simulation mode more in detail in the next chapter.  

The Software-in-the-Loop (SiL) Mode is a complete simulated mode of the EC-Simulator. The big advantage of this mode is that there is no separate hardware necessary at all. The EtherCAT MainDevice software EC-Master is exchanging EtherCAT frames directly with the simulation software, there is not communication with any Ethernet Controller. In the picture below,  you can easily see how the Sil-Mode works without any additional hardware.

Figure 3: SiL-Mode

If we look into the software architecture, we see that the EC-Simulator is loaded as Link-Layer on the same system as the EC-Master. As there is no physical network required, the EC-Simulator replaces the Ethernet controller. The EC-Master is now communicating and exchanging EtherCAT frames with the EC-Simulator library.

Figure 4: Software architecture of EC-Simulator and EC-Master

Now we want to simulate exactly the same system as described above. The idea is to simulate our acontis performance measurement reference setup. Therefore, we first need to generate a corresponding EXI File with the EC-Engineer. An EXI-File is similar like an ENI-File, but the EXI-File includes some more information about SubDevice hardware like EEPROM content and other information. But don’t worry, the simulator is very flexible. The simulator can also handle existing ENI files as simulation files. An EXI file is not mandatory for a successful simulation. To create a simulation file, you need to select “EtherCAT Simulator” at the start of the EC-Engineer application. Then you can create on our local system the preferred topology with the flexible amount of SubDevices. After we created the “exi.xml”-File, we save the file, transfer the file to the Raspberry Pi 5 and we start the EC-Simulator with following command:

./EcMasterDemoDc -v 4 -a 0 –sp -f eni.xml -simulator 1 1 exi.xml

Snippet 3 Starting EC-Simulator Demo in SiL Mode

As we see in the snippet above, we use exactly the same application EcMasterDemoDc. We only change the parameter for the link layer. Instead of the GEM Ethernet  driver, we use the simulator with the arguments: first device (1) and polling mode (1), followed by the EXI file.  

Please note: Don’t be afraid of pulling out the network cable. As the simulation is on the same device as the EC-Master, no physical cable is needed. Also note, that the evaluation version of the EC-Simulator has two restrictions: First, EC-Simulator stops after 10 minutes. And second, there is a maximum of five SubDevices which can be simulated. Therefore, I started my application with a license key.

As shown in the Screenshot below, the application starts exactly in the same way as with the “real” Ethernet adapter. Both applications, the EC-Master and the EC-Simulator are started. In the yellow box, you can see that the application scans the seven SubDevices of the acontis performance measurement reference setup virtually. After the successful scanning, the EC-Master changes state from Unknow to Init, pre-operational (PREOP), safe operational (SAFEOP) and finally to operational (OP).

Figure 5: EC-Master changes state to operational (OP) with seven simulated SubDevices

As the EC-Simulator is now running on the Raspberry Pi 5, we want to look onto the configuration with the EC-Engineer. To make the task a little bit more challenging, we now create an ENI file with 100 SubDevices . After the start of the EcMasterDemoDc, we get the following successful feedback, that all 100 SubDevices are scanned and that the EC-Master is now in operational (OP) state.

Figure 6: Figure 5: EC-Master in state operational (OP) with 100 simulated SubDevices

We connect with the EC-Engineer in Remote mode to see the different In-/Outputs of the simulation. As an example, we look onto the topology with 100 SubDevices, see below:

Figure 7: Screenshot of EC-Engineer in Online Remote Diagnosis Mode