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.
Gavin Lambert
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.
-----Original Message-----
From: Louie Lu
Sent: Sunday, 6 October 2019 00:02
To: [email protected]
Subject: [etherlab-users] How to verify that my distributed clock setup
correctly?
Hi all,
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
0x0002 2
0x0002 2
0x007051ea 7361002
0x80000002 -2147483646
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?
Thanks,
Louie.
_______________________________________________
etherlab-users mailing list
[email protected]
https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.etherlab.org%2Fmailman%2Flistinfo%2Fetherlab-users&data=02%7C01%7Cgavin.lambert%40tomra.com%7C0450b2d7bad34cf99b5b08d7498390d5%7C4308d118edd143008a37cfeba8ad5898%7C0%7C1%7C637058701739232218&sdata=ii0EIghT2wdmVWYLSJqg2oe8RdzWqYLrchIXldNSInE%3D&reserved=0
_______________________________________________
etherlab-users mailing list
[email protected]
http://lists.etherlab.org/mailman/listinfo/etherlab-users
