Forum Menu

Ethercat random jitter fix

More
6 months 2 weeks ago - 6 months 2 weeks ago #345459 by Hakan
Replied by Hakan on topic Ethercat random jitter fix
You have actually switched off the pll, the synchronization code.
You can double-check that with the lcec.pll-err value.
If that one counts up/down it is on. If lcec.pll-err isn't moving it's off.

There is no difference in the code with "-" and syncToRefClock.
It is just two different ways to switch on the option. The actual code is the same.
The bug happens to to be when both options are used, it will be left off in that case
if I understand what I wrote by mistake once.
Last edit: 6 months 2 weeks ago by Hakan.
The following user(s) said Thank You: endian

Please Log in or Create an account to join the conversation.

More
6 months 2 weeks ago #345461 by endian
Replied by endian on topic Ethercat random jitter fix

xml on debian trixie
i have test refClockSyncCycles = -1 , but problem is the same
Warning: Spoiler!

 
what help me during the grinding noise was reinstall driver to chip native or dcConf assignActivate = "300" edit to something as dcConf assignActivate = "730" ... then generic driver works well ...

I have hardware which runs at 250us and generic driver was not capable therefore I searched for other way of grinding avoiding with higher value of assign ... else with native chip driver is 0x0300 good enough 

 

Please Log in or Create an account to join the conversation.

More
6 months 2 weeks ago - 6 months 2 weeks ago #345462 by Hakan
Replied by Hakan on topic 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.
Last edit: 6 months 2 weeks ago by Hakan.

Please Log in or Create an account to join the conversation.

More
6 months 2 weeks ago - 6 months 2 weeks ago #345470 by grandixximo
Replied by grandixximo on topic Ethercat random jitter fix
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
Last edit: 6 months 2 weeks ago by grandixximo.

Please Log in or Create an account to join the conversation.

More
6 months 2 weeks ago #345473 by Hakan
Replied by Hakan on topic Ethercat random jitter fix
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.
 

Please Log in or Create an account to join the conversation.

More
6 months 2 weeks ago - 6 months 2 weeks ago #345474 by papagno-source
Replied by papagno-source on topic Ethercat random jitter fix
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

 
Last edit: 6 months 2 weeks ago by papagno-source.

Please Log in or Create an account to join the conversation.

Time to create page: 0.092 seconds
Powered by Kunena Forum