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.
