Ethercat random jitter fix

This is great news. There has been a lot of ethercat related development activity driven by grandixximo on both Linuxcnc and the linuxcnc-ethercat hal driver. When a few more things come together, I will be refreshing my ISO's which will put everything on the one ISO. 

Its great that Grandixximo is now the owner of the  linuxcnc-ethercat repository and he's implemented a number of changes with more in the pipleine. He's also got a PR with LinuxCNC that will provide a "hook" in linuxCNC to allow synchronizing the servo thread with Ethercat before the servo thread starts which should further improve results and perhaps remove that little squeak even..

Thank you for your endorsement of my kernel tuning optimizations. Its very valuable feedback being able to state Trixie (Ddebian 13) is as good as Debian 10 once tuned. Having a system that queries your PC as it is optimised has reduced manually tuned jitter by 50% in my testing. I have never been very rigorous about this testing as it needs to be installed on hardware  and I have to stuff around compiling a wifi driver every times so its easy to loose data but it seems to improve with every iteration as its given me a place to record every new optimisation I unearth.

At risk of upsetting some, you can find out more about my optimisations on my Youtube channel  www.youtube.com/@MrRodW or the companion website  mrrodw.au/  

Thank you very much for all your hard work. I’ve been following this thread the whole time, and now that the changes are being incorporated into the official repository, I’ll update my repositories and test the new EtherCAT HAL driver.Note 1:From what I’ve read, there does appear to be a dependency between the software and hardware.Note 2:I would ask you to investigate whether Debian, the base thread and the servo thread can each be assigned to a single CPU core.This would further improve stability.This is also done by Beckhoff and Codesys.It makes their runtime independent of the operating system and guarantees real-time capability. 

andrax wrote:

Note 2:I would ask you to investigate whether Debian, the base thread and the servo thread can each be assigned to a single CPU core.This would further improve stability.This is also done by Beckhoff and Codesys.It makes their runtime independent of the operating system and guarantees real-time capability. 

Yes, I believe this is the correct approach but I've never run a base thread or looked at the thread instantiation code in detail.
With a single isolated core (normal case) both threads should end up there.

Ethercat and Mesa configs should not need a base thread

There is no need for base-thread on ethercat machines
base-thread should be set to 0, which will disable it, you can hook up everything to servo-thread, also the "no floating point" situation is completely stripped out form 2.10 master, and disabled on next 2.9 release, 2.9.9 whenever that ships...

Hi,

I installed and tested the new driver.
The installation went smoothly, and the driver is working.
I’ll be testing it thoroughly over the next few days.
I can’t comment on the jitter or synchronization issues, as I haven’t experienced any problems in that regard.
Nevertheless, I’d like to provide some feedback.

Great work

So i installed this on a redone setup of 2.9.8 and im getting constant random joint and limit errors. even mid program. they seem to stem from random spike encoder frames. sometimes it goes 10 mins without anything, sometimes you can move for 1 second without one.

I am not 100% sure they are related to this patch, or what this patch is meant to fix. But its rendered my machine pretty unusable. (i redid the machine to add a 4th axis)

Any thoughts?

ihavenofish wrote:

So i installed this on a redone setup of 2.9.8 and im getting constant random joint and limit errors. even mid program. they seem to stem from random spike encoder frames. sometimes it goes 10 mins without anything, sometimes you can move for 1 second without one.

I am not 100% sure they are related to this patch, or what this patch is meant to fix. But its rendered my machine pretty unusable. (i redid the machine to add a 4th axis)

Any thoughts?

From a message from grandixximo

Also the Ethercat repos have changed to point to linuxcnc-ethercat
The instructions in my Ethercat sticky have been updated so also follow them
2.9.10 ISO should install the new repos mentioned but follow the  instructions in step 2
forum.linuxcnc.org/ethercat/45336-etherc...-how-to-step-by-step
 

rodw wrote:

Code:

can try for now to do loadrt lcec ... initf lcec.activate servo-thread addf lcec.read-all servo-thread

thats already in my hal

I did find something interesting. at least specifically on the 4th. when it give a joint error, the encoder position INVERTS, as does the display. And it STAYS inverted. so ill be jogging at 900 degrees on the A... and then joint error and it become -900 degrees.

I dont know if the other axis joint errors are also inverting, i cant "see" them yet. If they are they are returning back to position the next frame. The rotary axis for some reason doesn't return, it just flips sign.

ok, the joint error is something else. it happens at 912.45 ALWAYS. it must and over run of something. we have like 800 million counts per turn of the axis, so its inverting at 2 billion encoder counts.

Ill put this in my other thread as it i dont think has to do with the ethercat jitter problem.