Ethercat random jitter fix

So, even if you switch to the EK1100 as a coupler and related I/O on the EK1100 backplane, it is not recommended to use them as the first slave. Is it better to install the drives first and then the EK1100?

You might have to do some testing, EK1100 works fine as the first DC with Beckhoff servos, but I don't know how your servos will like it, to be tested, possibly fine, but I wouldn't finalize anything before testing is done.

Good evening, has anyone tried the new fixes in Grandixximo v1.41.0-pre2?
Are the slave pin values ​​read quickly?

I tried, no much difference, and there should be almost none, the "bug" was more cosmetic, not really hindering OP time, if anything we are talking in the milliseconds range, no human perceivable difference.
OP time is not immediate with DC, can you time how long it takes? If the wait is excessive, there may still be something I have not found.
Would love to get remote access on the debian 10 and debian 13 setups, to compare, get that USB to ethernet adapter please, you are the only one that has both quick and slow OP, and I could compare what the drives and lcec are doing.

Good morning everyone. I would like to do more. I can make an image of my HD and put the image somewhere, made with Clonezilla or other software. Luca, I will contact you, so you can give me a link to support the image. While you have Debian 13, so you can try it on your system. In the meantime, today I will try your patch and try to scale the I/O peripheral, the last one on the bus, and if it still doesn't work, I will change PC.

papagno-source wrote:

Good morning everyone. I would like to do more. I can make an image of my HD and put the image somewhere, made with Clonezilla or other software. Luca, I will contact you, so you can give me a link to support the image. While you have Debian 13, so you can try it on your system. In the meantime, today I will try your patch and try to scale the I/O peripheral, the last one on the bus, and if it still doesn't work, I will change PC.

I don't think that would help much without your slave  hardware. Its not just a simple config problem. The remote access is probably the best way.

YangYang found something to do OP real quick, maybe will have update tomorrow.

Greetings everyone.
So I tested Grandixximo's latest fix.
Slave 0, i.e., the VIPA's I/O, wasn't synchronizing, while the drives were. That is, the VIPA card's Run LED wasn't staying on, but blinking.
So I decided to change the slave sequence. The drives were on 0-1-2, and I/O was on 3, last.
Now slave 3, i.e., I/O, is running correctly.
I started testing. I have the impression that the drive quotas are read faster at startup, sometimes almost as fast as Debian 10. I tried refClockSyncCycles=1 and refClockSyncCycles=-1. In the refClockSyncCycles=1 mode, the axes emit noise more frequently.
The refClockSyncCycles=-1 mode seems to work better, but sometimes I hear a little noise, especially if I move the browser windows.
In refClockSyncCycles=-1 mode, the pll-err pin oscillates from about 800 to -1000, but if I move the windows, it sometimes reaches -10000, and I seem to understand that as the value increases, the noise increases. The pll-out pin stays at values ​​from 2 to -2.
In refClockSyncCycles=1 mode, the pll-err pin always remains zero. The pll-out pin always remains zero.

In both modes, the ethercat command upload -p 0 -t uint16 0x1C32 0x01 returns 0x0002 2, on all axes, including the slave.

I tried changing the sync0Shift value to 500000 without any change.

At this point I'm thinking of changing the PC, I don't want the problem now to be the jitter of Debian Trixie, which is greater, at least double compared to Debian 10.

I'd like to point out that with this latest fix from Grandixximo, the pull-err value is hovering around zero, like Debian 10. While in previous versions the pull-err value was around 99200.
Furthermore, with the latest fix, the plug-out pin has a fluctuating value close to zero, while with previous versions it was always zero.

@papagno-source check these as well please
0x1C32:02 (cycle time), 0x1C32:03 (shift time), and 0x1C32:05 (min cycle time), 0x1C33:01 (input side)
Would still love to get direct access to the hardware so that I can check myself...

Edit:
YangYang found a 1.5.2 that is much quicker to OP

github.com/synapticon/Etherlab_EtherCAT_Master

Will try to port to 1.6.9 stable, otherwise make compatible linuxcnc-ethercat package for this 1.5.2

The OP times should not relate to the grinding.

It makes no sense to roll back to a version built for  kernel 2.6 (Trixie's is 6.12) that's not been touched for 7 years...