Ethercat random jitter fix

@papagno-source, can we continue in discord, it is really hard to follow up with you here.
I am testing with generic driver, is the problem the OP time, or the grinding?

There are two problems:
The delay in reading the slave pins when the GUI starts, and the noise the axes make during movement.

Clearly, the main problem is the noise from the axes, because while they move normally, sometimes you hear jumps, noises that represent non-smooth movement.
The machine cannot operate this way, also because the noise is loud.

The problem of updating the positions at startup is secondary, not fundamental to the actual use of the machine. Sure, it's unsightly for a CNC system, but it only requires a few seconds of delay.

About discor. are logged , but how logged in linuxcnc ?

You are still doing the install, and cannot get the system online?

the discord you joint the channel, go the the welcome, read the rules, thumb up the rules, and you can join in general
read the instructions and the rules to joint the linuxcnc channel, they are there when you try to join the channel

edit:
you need to confirm email, and maybe phone number
then add server in discord
discord.gg/uW7KXqMw
then you need to go to the rules, and thumbs up react to the first message in the rules, here you see #rules and you click it
 
here you see this message and you click the hand with the thumb up
 
Then you will be able to write in the linuxcnc general channel with everyone else, I also PM you in discord, but you seem offline.

 

I stay logged here 

click on the + sign top left
and joint this channel
discord.gg/uW7KXqMw

or you can add me as grandixximo, just search for friends, I already sent you an invitation, but never got accepted
 

papagno-source wrote:

I have question at AI:

ethercat on debian 10 with kernel 4.19 and linuxcnc has less latency than debian 13 with kernel 6.12. Why?
 

Don't forget the hardware manufacturers have been adding  power saving features for years even back with Debian 10. But Linux simply ignored these features but now the kernel has caught up. It had to stay current. Generally, there are settings to disable them.  Also there are a lot of new network cards often part of the motherboard that do not have driver support until Debian 11 or 12 or 13.  So Debian 10 is an unsupported version now so you can;t continue to live in the past. Generally with proper tuning , 4 core and up hardware runs well on the later kernels.

4.19 was good. Remember I struggled with 6.x when it came out.
Anyway, what I do now is to have an Intel network card, i210, i217 or i225/i226
and make a modest effort to reduce jitter and latency.
The way I determine it's good enough is when there are no messages in syslog of this kindAll such messages have to go, well one in the beginning is ok, but not more.

I may or may not need to go to isolcpus and so on. On my current plasma system I have no
such tweaks at all. It works good anyway.

I was thinking, can we ask the kernel developers, how can we recompile the kernel, eliminating all the power optimizations, so as to optimize it for RT applications? If we continue like this, soon Linux will only be used for writing emails and using OpenOffice.

papagno-source wrote:

I was thinking, can we ask the kernel developers, how can we recompile the kernel, eliminating all the power optimizations, so as to optimize it for RT applications? If we continue like this, soon Linux will only be used for writing emails and using OpenOffice.

There is no need to dive into the kernel. All of the power saving kernel options are already  set in my optimisations via the kernel boot options. You would just shorten your kernel boot string.

Grandixximo proved that a custom 6.3 kernel I built a long time ago no longer makes any difference now we understand how to configure a modern kernel.. Having run most  kernels since 5.10, latency has actually improved. My original J1900 from 8-10 years ago was at around 130k ns jitter is now down to about 50k or less when optimised.

What has changed is all the networking power settings that need to be carefully mitigated. The problem here is by definition networking was never designed to be real time, but to be a forwarding type of communication protocol through hundreds of switches around the internet. So network drivers are not real time.

You could write your own driver using the DDPK www.dpdk.org/ which eliminates the latency from interrupt context switching and uses polling instead. But it still isn't real time. We are not doing High Frequency Trading where every millisecond of latency affects financial returns so this is not necessary in a CNC environment. 

You could use Time Sensitive Networking (TSN) which is now in the kernel and supported by Ethercat but its hardware dependent so your slave needs to support it. tsn.readthedocs.io/

Remember PREMPT_RT is not fast, its deterministic (reliable and on time) which is exactly what we need for our servo thread.