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

Hello everyone. The machine has only one Ethernet port, dedicated to EtherCAT.

I wanted clarification regarding Hakan's statement:
If any of the slaves have an assignActivate bit 8 set (DC sync), switch on loop synchronization.

The drive's XML file contains these entries:

<OpMpde>
<Name>DC</Name>
<Desc>Dc-Synchron</Desc>
<AssignActive>#300</AssignActive>
<CycletimeSync0 Factor="1">0</CycleTimeSync0>
<ShiftTimeSync0Z0>/ShiftTimeSync0>
<OpModie>

Does this entry mean bit 8? Does the manufacturer declare that the drive supports DC?

So, to conclude.
If I write in the XML file:
refClockSyncCycles=-1 and syncToRefClock="false", DC is enabled, so the slaves synchronize with the master managed by LinuxCNC.

If I write only:
refClockSyncCycles=1 in the XML file, DC is enabled, so the slaves synchronize with the master managed by LinuxCNC.
But I can choose the synchronization frequency from 1-5-1000.

If I write only:
refClockSyncCycles=-1 in the XML file, DC is not enabled, but free mode is enabled, and the drives do not synchronize with the LinuxCNC master.

Correct?

I imagine that the best feature for a CNC machine is DC mode, or am I wrong?

I verified that the lcec.0.dc-phased pin is always false.

refClockSyncCycles=-1 and syncToRefClock="false"

Is identical to 

refClockSyncCycles=1

What synctorefclock false clock does is make -1 become positive, if it was -5 it would be 5

refClockSyncCycles=-1 DC is enabled but master follows the reference slave, master will change its own time
This is identical to syncToRefClock true

About having only one Ethernet, USB to Ethernet adapter could work to give it internet, but I won't insist, but if possible I'd really love to test for myself, as some things get lost in communication 

DC has one start time, that's set on start usually by the first Ethernet DC capable device, from there you have two choices, either the slaves follow the time that the master declares every x cycles with refClockSyncCycles=x

Or everyone follows what the first slaves says the time is, master included. To do that master nudges its own cycle time to match what the first slaves report, the problem with your setup I think, is what the first master is reporting, so this system seems to not work correctly.
This mode is also DC and is set with 
refClockSyncCycles=-1
Or 
syncToRefClock="true"
 

I tried writing in the XML file:
refClockSyncCycles=5, without syncToRefClock, and the machine makes noise.

I also tried:
refClockSyncCycles=1000, without syncToRefClock, and the machine makes noise.

So in my case, the only way to get it to work is:
refClockSyncCycles=1, without syncToRefClock
or
refClockSyncCycles=-1, without syncToRefClock=false

So I'm not using DC mode?

refClockSyncCycles=-1, without syncToRefClock=false

Are you sure this works? I think you stated differently before.

Yes excuse the correct question Is :

So in my case, the only way to get it to work is:
refClockSyncCycles=1, without syncToRefClock
or
refClockSyncCycles=-1, with syncToRefClock=false

So I'm not using DC mode?