Issue with OP Entry Delay and Failures in LinuxCNC + EtherCAT System

Work through this which Hakan was referring to.
docs.google.com/document/d/1jeV_4VKzVmOI...diY/edit?usp=sharing

Thanks for support.

Hi at all.
I have install r8168-dkms, but not have result , the wait time for read pdo is present again and in dmesg have again wait synch message.

I have in refClocksynccycles =1.
If change refClocksynccycle at -1 , not have error synch , the wait time for read pdo is more short, but on debian 10 is more fast .

I thing the problem is in ethercat version, the version installed on debian 10 , the 1.5.2 is more fast at start up .

And i don't undestand why with debian 10 and the same ethercat configuration use
refClocksynccycles =1 and on debian 12 use refClocksynccycles =-1

Why do you use refclocksynccycles=1? That's low.

I have see value 1 on much example the xml file and not have problem with this value on debian 10 , lcnc 2.9.0-pre0 and ethercat 1.5.2.

I have test on debian 12, lcnc 2.10.0 and etehrcat 1.6.3 with value 1 and 5 and 1000 , but have error synch 5000 ms foe every drive.

only with -1 the error disappears.

What I don't understand is why on Debian 12, when LCNC starts, the PDO information is written to HAL after a few seconds and in sequence, one Ethercat node at a time from 0 to 5, while with the Debian 10 configuration, the PDOs are immediately read and updated in HAL, as soon as LCNC is running.

another difference between debian 10 and debian 12.
I use PCs with two ethernet ports.
With devian 10, with ip a I have 2 network cards enp1s0 and enp2s0,
while with debian 12 I have three, the two physical network cards and one with written: eoe0s0, which is created when ethercat is running.

Could it be that ethercat 1.6.3 unlike 1.5.2 uses a virtual card that in turn closes on a real one?

With -1 you ask the master not to synchronize the dc clocks for the slaves. I would think 1000 could be a good number, every 1000 cycles the master will synchronize the dc clocks of the slaves. The clocks will run with good precision by themself in between syncs.
Sounds like you got a weird setup with EoE, never seen that before. It is explained in the IgH ethercat master manual. A way to establish ethernet connection to a slave over ethercat. Doesn't happen by itself must be something in your setup.
The message "Slave did not sync after 5000 ms" may not be fatal, most likely its clock got synchronized later.
You can enable debug with "ethercat debug 1" and check debug messages with "sudo dmesg". Maybe you can get something out of that. There will be more messages about the synchronization and how that succeeds.

If remain -1 can have some problem on real machine ?

Normally the next version the ethercat, it should be more performant, but in reality on debian 10 there are no such problems

The test results of versions 2.9.3 and 1.6.4 are consistent

Please , i want understand :

If remain refclocksynccycles = -1 in xml file, can have some problem on real machine ?

I also encountered exactly the same problem. With the same hardware, the only differences were debian10+ethercat1.5 and debian12+ethercat1.6