[etherlab-users] How to verify that my distributed clock setup correctly?
gavin.lambert at tomra.com
Mon Oct 7 05:12:00 CEST 2019
I don't think it's normal, at least not unless you've only just started the master application.
The first (DC-capable) slave is selected as the reference clock by default. This could be a factor in the difference you're seeing.
What slaves do you have, and what DC clock method are you using? And what version of the master library are you using?
You might want to try connecting an infrastructure slave (such as an EK1100) as your first slave to see if that improves things.
FYI, there's two different ways to sync master and reference clocks (as shown in the rtai_rtdm_dc example code):
1. If you're calling ecrt_master_sync_reference_clock_to, then you're pushing the master clock down to the reference slave. Normally this should quickly step to the master clock on first update, but some slaves (especially if they were already in OP at the time) may require multiple cycles to "drift" the time to the correct point, to avoid too fast a transition.
2. If you're calling ecrt_master_reference_clock_time (and not the above), then you're reading the reference slave's clock and calculating an offset from the master's clock inside the master, separate from the network.
#1 is "easier" in the master code, because all the slaves will have the same idea of time as the master (eventually, at least) and so you don't need any complicated time-domain conversions.
#2 is "nicer" to the slaves, because they don't need to worry about syncing to a drifting master clock -- but also means that if any of the slaves care about the "real" full 64-bit DC time (eg. if it has some kind of clock display) then they won't have the real wall-clock time. That's rarely important, however. It also means that the master has to manually convert any times it receives from slaves.
Also note that the stable-1.5 library version does some strange things with DC, such as keeping the reference slave in OP inappropriately. You may want to try using the unofficial patchset (https://sourceforge.net/u/uecasm/etherlab-patches/ci/default/tree/ ) to see if that works better for you.
Senior Software Developer
COMPAC SORTING EQUIPMENT LTD | 4 Henderson Pl | Onehunga | Auckland 1061 | New Zealand
Switchboard: +49 2630 96520 | https://www.tomra.com
The information contained in this communication and any attachment is confidential and may be legally privileged. It should only be read by the person(s) to whom it is addressed. If you have received this communication in error, please notify the sender and delete the communication.
From: Louie Lu
Sent: Sunday, 6 October 2019 00:02
To: etherlab-users at etherlab.org
Subject: [etherlab-users] How to verify that my distributed clock setup correctly?
How do I verify that my distributed clock setup in EtherCAT is correct?
I use SDO 0x1C32/0x1C33 check that the slaves are in DC mode, and use 0x92C reg check the system time difference, here is the result of two slaves connected:
# ethercat -p0 -tuint16 upload 0x1C32 1; ethercat -p0 -tuint16 upload
0x1C33 1; ethercat -p0 reg_read 0x92C -t int32; ethercat -p1 reg_read 0x92C -t int32
The second slave seems to work well, only have 2ns difference, but why does the first slave always report with a large number of the time difference? Is that correct?
etherlab-users mailing list
etherlab-users at etherlab.org
More information about the etherlab-users