Accessing host's adapter to run SOEM's simpletest

[JamesKentDemcon]

Hi @2b-t,

I used your configuration to get my vscode dev container up and running, but I cannot get any info from the EtherCAT slaves using SOEM's simpletest tool. No matter what I do, it's always says no slaves found. I double checked it with TwinCAT and I can definitely detect them. I always get the following:

SOEM (Simple Open EtherCAT Master)
Simple test
Starting simple test
ec_init on eth0 succeeded.
No slaves found!
End simple test, close socket
End program

I'm running Windows 10 & WSL2 with the following configuration:

devcontainer.json

// For format details, see https://aka.ms/devcontainer.json. For config options, see the
// README at: https://github.com/devcontainers/templates/tree/main/src/cpp
{
    "name": "Docker PREEMPT_RT real-time",
    "dockerComposeFile": "compose.yaml",
    "service": "docker_realtime",
    "workspaceFolder": "/workspace/framework",
    "shutdownAction": "stopCompose",
    // Features to add to the dev container. More info: https://containers.dev/features.
    // "features": {},
    // Use 'forwardPorts' to make a list of ports inside the container available locally.
    // "forwardPorts": [],
    // Use 'postCreateCommand' to run commands after the container is created.
    // "postCreateCommand": "gcc -v",
    // Configure tool-specific properties.
    // "customizations": {},
    // Uncomment to connect as root instead. More info: https://aka.ms/dev-containers-non-root.
    "remoteUser": "root"
}

compose.yaml

version: "3.9"
services:
  docker_realtime:
    build:
      context: .
      dockerfile: Dockerfile
    container_name: realtime_docker
    tty: true
    cap_add:
      - SYS_NICE
    ulimits:
      rtprio: 99
      rttime: -1
      memlock: 8428281856
    network_mode: host
    volumes:
      - ..:/workspace/framework

Dockerfile

FROM mcr.microsoft.com/devcontainers/cpp:0-ubuntu-22.04

ARG REINSTALL_CMAKE_VERSION_FROM_SOURCE="3.22.2"

# Optionally install the cmake for vcpkg
COPY ./reinstall-cmake.sh /tmp/

RUN if [ "${REINSTALL_CMAKE_VERSION_FROM_SOURCE}" != "none" ]; then \
    chmod +x /tmp/reinstall-cmake.sh && /tmp/reinstall-cmake.sh ${REINSTALL_CMAKE_VERSION_FROM_SOURCE}; \
    fi \
    && rm -f /tmp/reinstall-cmake.sh

# [Optional] Uncomment this section to install additional vcpkg ports.
# RUN su vscode -c "${VCPKG_ROOT}/vcpkg install <your-port-name-here>"

# [Optional] Uncomment this section to install additional packages.
RUN apt-get update && export DEBIAN_FRONTEND=noninteractive \
    && apt-get -y install --no-install-recommends net-tools iputils-ping

[2b-t]

Hi @JamesKentDemcon, Your problem is unlikely to be caused by Docker (or else anything in this repository) but instead simply by particularities of WSL2 and/or TwinCAT3. In my opinion WSL is generally a poor choice when working with hardware, in particular real-time capable one as it relies heavily on virtualization to share the hardware between Windows and the Linux subsystem which will likely impact performance negatively and complicate debugging significantly. I have never used SOEM with WSL and do not have a system to test it on. I have only used SOEM from a container inside a Linux host system which works without any issues with native performance. Anyway here are some observations of mine, hope they might be helpful:

• Are you sure that eth0 is the correct network interface? Connect your slaves to the network interface, launch

  $ for d in /sys/class/net/*; do echo "$(basename ${d}): $(cat $d/{carrier,operstate} | tr '\n' ' ')"; done

  then unplug the cable that your slaves are connected to and run the command again.

  • If eth0's state changes from up to down then you have selected the correct one. If so then it might be an issue with SOEM and WSL2 (and its virtualization) itself. Go ahead and install SOEM directly in the WSL and try again. There is an issue on SOEM https://github.com/OpenEtherCATsociety/SOEM/issues/630 of someone who tried to combine WSL and SOEM. Not sure how far they got, seems like they gave up at some point. In this case you will likely have to 'go deep' and use Wireshark to debug the traffic to see why this is happening.
  • If another interface ethX changes then try running simple_test ethX instead.
  • If no interface changes state then you have no access to the network interface from the Linux subsystem. This might be due to TwinCAT and its RT-Ethernet driver that claim this resource and do not allow anyone else on Windows to access it. In this case you would have to uninstall the RT-Ethernet driver (or uninstall TwinCAT as a whole) so that the Ethercat controller is available in Windows (and likely then in WSL). If you are at it already, you might wipe Windows altogether as well and install Linux. :stuck_out_tongue_closed_eyes:
• I am actually surprised that you can set the ulimits on your container in a WSL. Is it possible to install a real-time patched kernel also in WSL2? I have never tried it but this surprises me as from what I understood the WSL kernel should translate Linux system calls to Windows system calls. Now SOEM does not need a PREEMPT_RT-patched host system to work but for good performance you will need one. I am not sure what the performance will be if you then have to pass through your non-real-time-capable Windows for every system call. I do not think WSL should be used in such a way and likely this is a conclusion that you will also come to after experimenting with it for a while.

[JamesKentDemcon]

Hi @2b-t,

Thanks for the detailed response! After doing some more experimenting, it looks like it isn't possible in WSL1 or WSL2. In WSL1 I have access to the direct NIC, but I cannot get SOEM to bind to it. As you already mentioned, with WSL2 the virtualization makes it seemingly impossible to be able to send the raw packets to the slaves.

Regarding PREEMPT_RT in WSL2, I did manage to patch my kernel, but it is mentioned that performance is not the same as native host. I mostly did it to see how it worked.

I think I will need to look at dual booting Linux to get this up and running. I will close the issue.