Ethercat random jitter fix

the lcec.0.pll-err pin in this case reported a value oscillating from approximately 991902 to 994498 

That's the right behavior even if the actual value is strange.

Which version of linuxcnc-ethercat (lcec) are you using right now during these tests?

System Test Is Debian Trixie 13.3 , kernel 6.12.74 RT, linuxcnc 2.10 ( actual Master), Ethercat 1.6.9.

Hakan is correct, but depends on device, we should check what they report.
could you run these?
ethercat upload -p 0 -t uint32 0x1C32 0x06
ethercat upload -p 0 -t uint32 0x1C33 0x06
ethercat upload -p 1 -t uint32 0x1C32 0x06
ethercat upload -p 1 -t uint32 0x1C33 0x06
ethercat upload -p 0 -t uint32 0x1C33 0x03
ethercat upload -p 1 -t uint32 0x1C33 0x03
Edit: also these please
ethercat upload -p 0 -t uint32 0x1C32 0x09
ethercat upload -p 1 -t uint32 0x1C32 0x09

Run these and write here the output, to confirm if sync0shift 0 is supported

Also

refClockSyncCycles="-1" syncToRefClock="false"
is self contradictory

use only 
refClockSyncCycles="-1"
or only 
syncToRefClock="true"

to enable PLL

grandixximo's linuxcnc-ethercat repo, right?
That pll-err value shows it's not the linuxcnc standard code. That oscillates around zero.

I have looked in the code but don't see why it does what it does.
It is supposed to work like this
When the syncToRefClock option is given the "-" is ignored, "true" means to switch on, any other string means to not activate the pll code.
In lack of the syncToRefClock option, the "-" will switch on the pll code.
Your code doesn't react in that way.

Hakan wrote:

grandixximo's linuxcnc-ethercat repo, right?
That pll-err value shows it's not the linuxcnc standard code. That oscillates around zero.
 

Please expand on what you mean here.

This is a standard RIP install of Debian 2.10 except its in a folder under /usr/lib, grandixximos driver built from source, Ethercat from repos. That should make no difference. For me, latency etc is fine on my hardware which makes it weird.
 

the result is :

ethercat upload -p 0 -t uint32 0x1C32 0x06 return 0x00000000 0
ethercat upload -p 0 -t uint32 0x1C33 0x06 return Failed to upload SDO: Input/output error
ethercat upload -p 1 -t uint32 0x1C32 0x06 return 0x00000000 0
ethercat upload -p 1 -t uint32 0x1C33 0x06 return 0x00000000 0
ethercat upload -p 0 -t uint32 0x1C33 0x03 return Failed to upload SDO: Input/output error
ethercat upload -p 1 -t uint32 0x1C33 0x03 return SDO transfer aborted with code 0x06010001: Attempt to read a write-only object
ethercat upload -p 0 -t uint32 0x1C32 0x09 return 0x00030d40 200000
ethercat upload -p 1 -t uint32 0x1C32 0x09 return 0x00000000 0


I've already tested only refClockSyncCycles="-1" without syncToRefClock="true" and the problem persists.

I've also tested refClockSyncCycles="1" and syncToRefClock="true"
and the problem persists.

Do you want me to try deleting refClockSyncCycles="1" and leaving only syncToRefClock="true"?