Troubleshooting C++ SOEM EtherCAT: Dealing with ‘No Adapter Found’ Issue on Windows 11 with Visual Studio and Vcpkg

Diagnosing Adapter Detection Issues in SOEM with VS2022

Having ventured into setting up the Simple Open EtherCAT Master (SOEM) system using Vcpkg and Visual Studio 2022, I encountered an intriguing issue where the EtherCAT adapter is not found despite all checks and setups appearing correct. My goal was simple: to successfully initiate communication between my PC and an EtherCAT slave using the simple_test example provided by SOEM. This process began smoothly, but I hit a roadblock when I attempted to detect available network adapters.

Initial Setup and Symptom

The setup included installing SOEM using Vcpkg, ensuring all dependencies such as Wireshark and WinPCAP were in place, and verifying that my Ethernet port was active and capable of handling traffic. With everything in place, my first step was running the simple_test, a basic SOEM example that scans for EtherCAT slaves and communicates over a specified network adapter.

However, despite all setups, the test failed to find any network adapter. My subsequent attempts through the provided executable ECAT_TEST_ECL231.exe yielded only these messages:

SOEM (Simple Open EtherCAT Master)
Simple test
Usage: simple_test ifname1
Available adapters
End program

There should have been a list of available network adapters, but none were shown. The next phase was to understand why.

Investigating the Issue

Diving into simple_test, the program first initializes the SOEM with a call to ec_init(ifname), where ifname should be the name of the network adapter. A critical step here is that ifname must correctly reference an existent network adapter’s ID, otherwise the initialization will fail.

While examining the variables in the Visual Studio debugger during the execution when the network adapter should be set, I noticed in the debug output that ifname was set to "/\Device\NTPNP_PCI0025". I presumed some kind of mishap in retrieving or setting the network adapter string.

Delving into the Code

The key function looked like this:

if (ec_init(ifname)) {
    printf("ec_init on %s succeeded.\n", ifname);
}

Here, ec_init is supposed to bind the SOEM instance to the network adapter specified by ifname. The main issue seemed to revolve around how ifname was being handled or identified.

Further in WinPCAP and the SOEM integration, the adapter name should typically start with “\Device\” or have specific formatting distinguishing physical devices or network connections. This pointed to a probable incorrect or unresolved adapter name being used during the ec_init call.

Remedial Actions

1. Validate Adapter Name: I ensured that the adapter name used in the initialization ("\Device\NTPNP_PCI0025") was correct and consistent with what the SOEM and PCAP library expected. Testing this involved using the command GetAdaptersAddresses from the IP Helper API to list and confirm available adapter names on the system.

1. Debugging and Code Walkthrough: Checking through other parts of the initialization sequence and ensuring no other issues, such as permission errors or incorrect API calls, were affecting the process.

1. Try Different Naming Conventions: Since there can be discrepancies between how device names are referenced in different environments or Windows versions, experimenting with variations like removing the slash or modifying the network adapter string format might be necessary.

Through a detailed examination of both the setup requirements and the code execution flow, together with a thorough validation of the network adapter naming and initialization procedures, I aimed to resolve the issue of the undetected network adapter in the SOEM setup. This kind of diagnostic approach not only helps in troubleshooting but also deepens understanding of how different components in a system interact with each other, especially in complex network-related operations.