Ethercat random jitter fix

Did a bit of digging. not related to my issue, but a trend did seem to crop up and Id like to see if it holds as it might start to narrow down the search for a solution.

What network interface are you using? Beckhoff only really supports a few intel select chips for ethercat. They flat out block realtek in twincat for real time motion.

So I want to know if there is a strong indication people with these issues are on unsupported network interfaces, or it's happening across all of them including the intel 210/211

Thanks.

The initial resonance could be something with the drivers internal PID unless you are running in torque mode?

If you run in position mode, probably something with the gain of the servos.

If you have not experienced any grinding noise, it maybe that you have incredibly stable latency, or your hardware is incredibly fine tuned, and you have it well dedicated and setup to run only linuxcnc. But there is no question that the original linuxcnc-ethercat, including the last stable release by Scott, has issues, this is confirmed by all core developers, the original code previous my PR to master has random phasing, if your hardware was somehow able to keep the phasing, it was just luck, not because it was setup to be in sync.

I use intel 210

Never experienced looping OP, not sure if it's related, did you give a test to my version?

ihavenofish wrote:

What network interface are you using? Beckhoff only really supports a few intel select chips for ethercat. They flat out block realtek in twincat for real time motion.

So I want to know if there is a strong indication people with these issues are on unsupported network interfaces, or it's happening across all of them including the intel 210/211

Thanks.

The real explanation why Beckhoff block Realtek NIC's is they use about 30% more system memory than Intel NIC's which can't be good for real time performance. However, I have never had issues with Realtek NIC's when properly configured regardless if they are driving Ethercat or mesa devices.

Its not enough today to just install linuxcnc and Ethercat and expect things to work. The kernel and NIC has to be tuned for optimum real time performance and that is something of a black art that is not well documented anywhere.

I offer kernel tuning services to manufacturers and have an installer that fully configures ethercat and tunes the kernel. You just need to add your config and plug in your slaves. If interested, reach out here mrrodw.au/ or via the email on my Youtube channel. www.youtube.com/@mrrodw 

latency is not fine tuned or incredibly stable.

It's actually a realtek interface. I don't think this is luck. I've cycled the machine probably 1000 times and never seen anything of this nature. Literally never even hear of the issue before and I know a number of people on ethercat/linuxcnc (tormach 1500 people included). And this was all news to them.

I've forwarded some info to the people that make the stepperonlione servos to see If they have any thoughts - and one of my customers is setting up their kit at the moment.

I find this all... peculiar to be simply random.

It's based on the execution time between two processes which is not guaranteed to align well in all systems, it may be ok on some hardware, very little difference, and completely random on others.

I know what you are saying.

What have the tormach guys said about it? The 1500mx doesn't seem to have any issues. is there something to take from their new source code?

I never discussed with Rob, maybe on next meeting 

@grandixximo Good news. The patch you did worked. DC-phased is now active and I can see changing values for drift, err, final, out and reset-count. Nothing on the drift and jitter signals though, not sure if that is how it should be. 

Also, regarding the pll-step value with the older version of the patch, it was at 1000. 

Yes, drift is a testing value, you need set pll-step to 0 and then set drift, and you can go into the grinding window, it's just for testing, and finding where the grinding window is. You don't need to use, system should be working now, no more grinding.

Thanks Luca for all your work around this. I am experiencing grinding noise myself. Very random and I really only noticed it because I have my EtherCat system on a bench for testing, so no machine noise. 

Until now I was running the latest 1.40.0 release from Scott (9/2024) and wanted to try your code to see if that fixes the issue for me. 

While testing your current linuxcnc-ethercat code I encountered a reproducible SIGSEGV in lcec_parse_config().

Minimal configuration:
<masters>
  <master idx="0" appTimePeriod="1000000">
  </master>
</masters>

The crash happens during:
for (slave = master->first_slave; slave != NULL; slave = slave->next)
Even though no slave is defined in the XML.
Looking at lcec_main.c, both master and slave structures are allocated via:

master = LCEC_ALLOCATE(lcec_master_t);
slave  = LCEC_ALLOCATE(lcec_slave_t);

but are not explicitly zero-initialized.

If master->first_slave contains a non-NULL value, the code enters the loop and
dereferences an invalid pointer.

Adding explicit initialization fixes the issue:

master = LCEC_ALLOCATE(lcec_master_t);
memset(master, 0, sizeof(*master));

slave = LCEC_ALLOCATE(lcec_slave_t);
memset(slave, 0, sizeof(*slave));

After applying this change the driver starts correctly.

The issue may have existed previously but remained hidden depending on memory layout or allocator behavior.

I thought I share if anybody else has the exact same issue. 

BTW, I am not that good in coding and had a bit of help from my "buddy".