[etherlab-users] How to verify that my distributed clock setup correctly?

Louie Lu git at louie.lu
Tue Oct 8 12:00:43 CEST 2019


Hi Gavin,

Thanks for your reply,
I'm using CPC TC-1, which is using LAN9252 slave controller, with
64-bit DC capable (Distributed clocks: yes, 64 bit),
IgH 1.5.2 w/ all unofficial patches, and using option 2 you mention
(ecrt_master_reference_clock_time, Beckoff refer as Master mode, rtdm
example MASTER_TO_REF).

I can observe the second slave stable 0x92C & 0x932 value after
several seconds of cycle, but the first slave still gave a large
number of the 0x92C,
I check for the Beckoff document that said if the 9x92C or 0x932
locked in, then the DC can consider as synced, is that still valid in
my case?

Thanks,
Louie.

Gavin Lambert <gavin.lambert at tomra.com> 於 2019年10月7日 週一 上午11:12寫道:
>
> 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: etherlab-users at etherlab.org
> 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
> etherlab-users at etherlab.org
> 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



More information about the Etherlab-users mailing list