Ethercat random jitter fix

Scott thought so too forum.linuxcnc.org/ethercat/52200-defaul...a-402-devices#297315

One should really have a look in the servo's ESI file and see what it says.

Demystifying syncToRefClock and refClockSyncCycles

syncToRefClock="true" means the master syncs to the slaves, adjusting its period every cycle to track the DC reference clock (PLL/bang-bang mode).

syncToRefClock="false" means the slaves sync to the master. refClockSyncCycles then controls how often (every N cycles) the slaves perform a sync adjustment.

refClockSyncCycles="-1" (any negative number) means master syncs to slaves, identical to syncToRefClock="true". The magnitude does not matter.

So all four combinations you tested:


refClockSyncCycles="1" syncToRefClock="true"
refClockSyncCycles="5" syncToRefClock="true"
refClockSyncCycles="1000" syncToRefClock="true"
refClockSyncCycles="-1" syncToRefClock="true"


are completely identical. When syncToRefClock="true", the slaves are not in a mode where they sync to the master, so refClockSyncCycles is simply ignored.

The combination refClockSyncCycles="-1" with syncToRefClock="false" is a contradiction and will be treated as invalid in a future version.

Why you heard noise with syncToRefClock="true" and sync0Shift="0"

This is expected and correct behaviour. With sync0Shift="0", SYNC0 fires exactly at t=0, right as the cyclic frame is arriving. The slave latches output data at the same instant it is being written, creating a race condition every cycle. The grinding noise is the mechanical result.

The fix is not to disable syncToRefClock. Set a proper shift:


<dcConf assignActivate="300" sync0Cycle="*1" sync0Shift="300000"/>


300000 to 500000 ns on a 1ms cycle is a reasonable starting point. Try that with syncToRefClock="true" and the noise should go away.

If you think sync0Shift="0" always worked for you

It did not work correctly, it appeared to work. The race condition was present but your hardware was consistently winning it by luck. The code now behaves strictly per ETG.1020. If it seemed to work before, it was not according to the standard. Update your configuration.

To help investigate the OP regression, can you run the following and paste the output?


dpkg -l | grep ethercat

Do this on the system with the 1.5.2 that OP's quickly please
maybe we get more than just 1.5.2 we can get some build reference, and I can look at the code, the 1.5.2 I found is identical in OP time as 1.6.8

I think you are using shiftTime in the wrong way.
Your work should focus on the SM2/SYNC0 distance, that it is sufficient.
shiftTime is a slave requirement, not a synchronization requirement.
My slaves work with shiftTime 0.
 

Good morning everyone.
I did the following test:
refClockSyncCycles="1" syncToRefClock="true" with <dcConf assignActivate="300" sync0Cycle="*1" sync0Shift="300000"/>

The problem returned, noise on the axes.

I ran this other test:
refClockSyncCycles="1" syncToRefClock="true" with <dcConf assignActivate="300" sync0Cycle="*1" sync0Shift="500000"/>

The problem returned, noise on the axes.

the lcec.0.pll-err pin in both cases reported a value of 0 for about 1 second and then changed to 5072592 for about another second, before repeating the cycle.

The only way to make the noise disappear is:
refClockSyncCycles="-1" syncToRefClock="false" with <dcConf assignActivate="300" sync0Cycle="*1" sync0Shift="0"/>

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


I haven't tried :
refClockSyncCycles="-1" syncToRefClock="false" with <dcConf and sync0Shift= values ​​other than zero.

The result of the command:
dpkg -l|grep ethercat on debian Trixie is:

ii ethercat-dkms 1.6.9.gb709e58-1+28.1 all IgH EtherCAT Master
ii ethercat-master 1.6.9.gb709e58-1+28.1 amd64 IgH EtherCAT Master
ii libethercat 1.6.9.gb709e58-1+28.1 amd64 IgH EtherCAT Master
ii libethercat-dev 1.6.9.gb709e58-1+28.1 amd64 IgH EtherCAT Master


same command on Debian 10, returns nothing.

if I run : ethercat version
IgH EtherCAT 1.5.2 unknown

 

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"?