Ethercat random jitter fix

Both work. They are two different sync strategies, neither inherently better. It depends on which your drives like.

The two attributes are redundant and confusing. Negative `refClockSyncCycles` without `syncToRefClock` is the same as `syncToRefClock="true"`. The `syncToRefClock` attribute just explicitly overrides the sign convention. The code always takes `abs()` of cycles, so the sign is purely a mode flag.

With `syncToRefClock="true"` (or negative `refClockSyncCycles`), PLL runs every cycle regardless. The count value doesn't matter, only the sign. So `-1`, `-5`, `-100` all behave identically.

With `syncToRefClock="false"` (or positive `refClockSyncCycles`), the count does matter. It controls how often `ecrt_master_sync_reference_clock()` runs, every N cycles. `1` means every cycle, `1000` means once per second at 1kHz. Lower values mean faster convergence and more bus traffic. Watch `pll_err` and `dc_phased` pins to see when it locks. If it locks fast and stays stable, the value is fine. Examples in the repo use 1, 5, or 1000.

My take: positive cycles with `syncToRefClock="false"` is slightly cleaner, because the PLL stops once locked and less continuous computation happens, provided your drives tolerate the master as clock source. Yours do.

Recommendation: Use `refClockSyncCycles=1 or -1
Synctorefclock is just confusing.

I've added some debug pins in my repo

lcec.0.dc-time-valid
lcec.0.dc-time-mod
lcec.0.dc-time-delta

please use halscope to read the values you get, if you are on master you can save the scope log, and you can use the attach button, in the reply editor, to attach the file, or a picture of the scope.

would it be possible to get remote access to the machine via teamviewer host?
download.teamviewer.com/download/linux/t...iewer-host_amd64.deb
I'd really like to experiment with the hardware, really interested in checking why my PLL is not working for you, if it is a case of bad I/O or something else, possibly something wrong with some of my code assumptions.

can you email me if you don't want to post here the teamviewer access

luca at aitalmac.com

Is my personal email, thanks

grandixximo wrote:

Recommendation: Use `refClockSyncCycles=1 or -1
Synctorefclock is just confusing.

It was a mistake from the beginning to let a negative value of refClockSyncCycles activate the pll synchronization method. It wasn't documented, is obscure and not logical. It was a too important option to be hidden in a "-" sign. Therefore the syncToRefClock option was introduced to mark that this is the synchronization option. In discussion with Scott, the "-" option was kept in the linuxcnc spirit of backwards compatibility. The intention and hope was that the usage of "-" should fade away over time. Don't go the "-" route, use syncToRefClock instead.

There is some evolution I guess. refClockSyncCycles was an attempt to synchronize slaves but that doesn't work. Then came the pll method and instead of adding its own option they let the "-" mean to activate the pll code. That was a mistake.

What should have been done was to get rid of refClockSyncCycles option altogether and have an option to either synchronize with the slaves or not. syncToRefClock was meant to be that. One can always argue about the naming, maybe it should be called dcSyncSlaves="true/false" instead?

There are really only two options. Synchronize linuxcnc's loop with the slaves' loops, or not. The first is done and required when using DC sync. For free run or SM synchronization methods a synchronized time is not needed since the slaves don't use it. Slaves don't need to be DC capable, it's optional.

One can extend this and automatically deduce the need for time synchronization.
If any of the slaves have an assignActivate bit 8 set (DC sync), switch on loop synchronization.
Otherwise don't touch the times.

The option was buggy when introduced, and even now that it works, you can see how confusing it gets about what is actually happening when you have two options to do the same thing, I'll force the XML to be properly written with errors if they don't make sense, that seems the only way forward.
Concretely:
syncToRefClock=true + negative refClockSyncCycles = M2R, fine
syncToRefClock=false + positive refClockSyncCycles = R2M, fine
only one set, other at default = take the one that's set, fine
syncToRefClock=true + positive refClockSyncCycles = refuse to start with a clear error message
syncToRefClock=false + negative refClockSyncCycles = refuse to start with a clear error message

this is also what I proposed in github, I did implement but I had to roll it back, I will probably introduce it again, this is the only clear path if we want to keep both without confusion.
The last example was what caused the confusion with papagno-source