Ethercat random jitter fix

Posting here with some pictures and any stylization is hell, trust me ...

it looks pretty ... reduction of any jitter in the rt system is more than welcome ... pll is very critical stuff for system and it is nice to see its major improvement 

Which driver for network card are you usig for testing it for now? jittering can be produce by generic drivers too i think

I saw it was merged in the master ... we will wait for scott to public new feed or version? 

I use Intel I225 with ec_igc driver, but I also tested generic and seems ok, I plan to do more extensive testing on something worse, just to see how bad I can go before I hit any issue, to have an idea on how cheap a system I can make lol.

The newest PR has not been merged yet at this time, you can get the code from my repo, or wait a few weeks for Scott, he mentioned he was going out of town.

I really think now the code respects the ethercat standard as closely as possible, it might just be a matter of exposing some phasing paramets for picky applications, but visualiziotion with halscope and sync0shift gets you all the way there too, and you have two options to choose from syncToRefClock true or false, if your latency is decent I advise to keep it false, with a refClockSyncCycles of 2, or 10 if you can wait a bit before start moving.

I have been using negative ref cycles setup ... everything works well, but I have been using native drivers with custom configuration ... latency is very low in my case

it is here ? github.com/grandixximo/linuxcnc-ethercat

Yes, it is there, unfortunately to test the original code you have to have subpar CPU latency, have some glxgears running, and halscope to simulate/induce bad latency, then you probably have to restart a whole bunch of times, in my case I methodically restarted 100's of times, moved and checked the ferror while moving for the grinding, the better your latency is the less probability you will land on the bad window randomly, by inducing some strong latency on my system running graphical processes which I know give me spikes, I was able to get grinding in the ferror about 20% of the times, without purposely inducing latency I would see it 5% of the times, and I'd really have to look for it with halscope, because opening halscope and plotting the ferror would actually make the latency worse, and the consequently I spotted it more often, without halscope running I could potentially see it only once every 100 restarts if ever, which makes the issue incredibly rare with good latency, the original code was good at syncing, but phasing was random so if you ever were to end up in the grinding window, a restart would have fixed it almost always, phasing was random as far as I tested before my fix.

This is really awesome work. I would stick to the igc driver which is real time when generic isn't
But from what I am hearing, optimising for system and network latency will probably avoid the issue.
I have a video about that and one user reports he got latency down to about 6 usec following my tutorial.
I suspect by running a latency optimised system has meant I have never experienced this.

Yes, if you have good latency it does not really matter how close you are to the sync0shift window, as long as you never jump ahead and back, I also had to force the issue to come up and induce latency in my system by opening graphical intensive applications. But I believe my fix is a real game changer for running ethercat on something that is not super latency optimized, and not see the grinding issue, I hope the community will receive it well, I'm here for any bug fixes or whatnot...