Ethercat random jitter fix

That’s exactly what I was getting at.
After their extensive testing, they can confirm that the driver works flawlessly.
Anyone who’s still having problems should take a closer look at their hardware. That’s why I brought this up and mentioned Beckhoff. All compatible chips are listed there, but unfortunately, few people know that.
Maybe I just didn’t express myself clearly.
Here’s my thinking.
Many people already have EtherCAT up and running successfully.
We could collect the hardware information and put it in a wiki. 
System requirements:
>PC, network card, cable, EMC filter
>Configuration examples
>Troubleshooting tips
>Explanation of individual functions
That would help many new users get up to speed on the madness of EtherCAT
before they flood the forum with the same questions over and over.

I can’t do that myself. When I start a thread like that, it disappears into oblivion really fast.
Only the admins can do that

Regards, Andrax
 

Just wanted to report back that since installing grandixximo's fork three weeks ago, I’ve had zero issues. So at least for me and my hardware, that’s the real solution here.

I spoke too soon. I've been helping someone in Italy who has 6 Ethercat drives and says:
When run lcnc the drive pdo are read with after some second , respect debian 10 ( is instantanious). On dmesg have slave did not sync after 5000 ms. The same drive with the same xml file not have problem on debian 10. I have test 2 pc, with realtek nic and intel nic , but the problem is the same. How can resolve. This problem is the same on debian 12.

So I assume he' s experiencing this issue and using grandixximo's repo should fix it. Can someone confirm?
Its odd that he says it works on Debian 10. My live machine (since sold) was running Debian 11 so perhaps its a Debian 12 and up issue.

I've used debian 10 11 and 13
I skipped debian 12 this is for internal timing release reasons, not because 12 had anything wrong with it. I did not notice on my hardware considerable differences between debian releases. If you have issues please share your configuration, be clear about the issue, share as much info as you can, and if you are not using my fork code, you most likely HAVE phasing issues. Those maybe effecting OP times, or motion, or nothing, it depends on the hardware. Will update to my fork fix everything? No, most definitely NOT everything, but I am sure phasing will be as proper as it can be on your system, and you will have debug pins to analyze performance which you can share, run halscope and halshow, see the ecat.0.xx pins, so that we can get to the bottom of the issue.
If Scott was still in the game, he would probably merge it and make a release. I would advise everyone to update, and if you have any issue, I will be here or on GitHub for support.
 
TL;DR
My fork does not magically fix all issues, but it does fix some, and gives you pins to benchmark your setup. Please build and install my fork, then test, and share your configuration and test results if you have issues and you want help.

I'm also on the discord, and I am fluent in Italian 

discord.gg/WwMfD9v9M

If your Italian friend wants to hop in, I'll be glad to help him out.

This is not related to the phasing.
Or perhaps it is, on the way that clocks have started to run with different speeds.

You can switch on debug "ethercat debug 1" and watch the DC time difference between slaves slooowly converge.

It's part of the startup of slaves
gitlab.com/etherlab.org/ethercat/-/blame...e=heads&page=2#L1480

The server issues 5000 sync requests, one every millisec, and waits until clocks are within 10 microseconds.
If they aren't, you get the message. The slaves' clocks will eventually converge.

I had this issue, was unable to fix or even poke at it, and then suddenly it went away.
I suspect it has something to do with ethercat master version, but since I was unable to
diagnoze it, I really don't know.