fix: wait for the highest configured address during discovery by mbloechli · Pull Request #21 · Duatic/soem_interface

mbloechli · 2026-10-15T12:56:05Z

What and Why

Ethercat Discovery compared the device count with the number of configured slaves. The device count though included also switch ports, which led to the problem that the device count can reach the number of configured slaves, without discovering all slaves. Now the Discovery waits until it sees as many devices as the highest configured address.
The DEBUG messages logged at ERROR level are now removed. They were an obsolete artifact of earlier development.
AL status messages looked up the wrong slave name. They now look it up by the correct address.
sdoWrite/sdoRead printed the AL status code of the previous bus position; they now print the failing slave's own.

Discovery compared the device count against the number of configured slaves. Devices without a configured slave, such as EtherCAT switch ports, also occupy bus positions, so a bus could pass while its last devices had not enumerated yet; the address check then aborted startup. It now waits until the bus reaches the highest configured address. Drop the [DEBUG] lines logged at ERROR level on every healthy start, and mark devices with no configured slave in the device list.

The SDO and state-change error paths looked the name up as slaves_[address - 1], but slaves_ is in registration order and devices without a configured slave take bus positions too. Messages named a different slave than the failing one, and addresses past the number of configured slaves read out of bounds. Look the name up by address. sdoWrite and sdoRead also printed the AL status code of the previous bus position (slavelist[slave - 1]); print the failing slave's own.

firesurfer

@mbloechli I wrote a few comments. How far did you test this PR? E.g. on purpose not connect a drive ?

ecx_detect_slaves and ecx_config_init return negative SOEM error codes (EC_NOFRAME, EC_OTHERFRAME, EC_ERROR). Clamping them to 0 hid which one occurred.

mbloechli · 2026-10-15T14:14:33Z

@mbloechli I wrote a few comments. How far did you test this PR? E.g. on purpose not connect a drive ?

I did test if modifying a drives address to being above the detectable adresses would stop the discovery from passing. And I tested if pulling out the ethercat dongle from the PC shuts the system down as intended.

mbloechli added 2 commits October 15, 2026 14:55

mbloechli requested a review from firesurfer October 15, 2026 13:01