[etherlab-users] etherlab dc sync check

[Jun Yuan]

Oh, I understand, you're talking about synchronizing the master clock
to the ref slave. This has been implemented in the etherlab master.
You need to use the function ecrt_master_reference_clock_time()
instead of ecrt_master_sync_reference_clock(). An example is given in
example/rtai_rtdm_dc.

Well, I think most of us are still used to sync reference clock to
master. And yes, sync master to ref clock would make the situation a
little bit better, as the ref clock itself doesn't need any adjustment
any more, making the ref clock signal stable for the other slaves. But
since the other slave are still having a bad time offset from the
master to have a same timebase as the ref_clock, they still suffer
from a large diff at the beginning of drift compensation. The problem
is not still there.

I need some volunteers to do a simple experiment for me. You'll just
need a normal master application based on the current etherlabmaster
and a ethercat bus network with at least one slave having DC enabled.
1. running your master application for about 10 minutes. This would be
enough for all the DC sync on the bus get converged. So that all the
DCs are running synchronized. You can check that with „ethercat
reg_read -tsm32 0x92c“, it should  be something below 1000 ns.
2. turn the debug level of master to 1 using „sudo ethercat debug 1“.
3. stop the master application and restart it right away, while don't
shut down your slaves. Your slaves should still have a relative good
sync with each other.
4. check you system log, look for the lines like

[ 9766.885265] EtherCAT DEBUG 0-0: DC 64 bit system time offset
calculation: system_time=xxxxxxxx (corrected with xxxxxxxx),
app_time=xxxxxxx, diff=xxxxxxxx
[ 9766.885268] EtherCAT DEBUG 0-0: „Setting time offset to xxxxxxx
(was xxxxxxx)“ OR: „Not touching time offset.“
…
[ 9767.292758] EtherCAT DEBUG 0-0: Checking for synchrony.
[ 9767.296758] EtherCAT DEBUG 0-0: Sync after    4 ms:    xxxxxxx ns

send these 4 lines of your system log to me, and tell me the cycle
time of your loop. That’s it. Thanks!

On Fri, Jan 3, 2014 at 10:52 AM, Slutsker, Rasty
<rasty.slutsker at servotronix.com> wrote:
> Master clock is accurate (more or less), but delivery is not, since software is involved.
> I'm just asking why slave(s) shall synchronize to "jumpy" clock of master? Maybe be it would be more correct, if master could synchronize itself to the first slave and then will run pll adjusting it's clock to the slave's one?
> In that case we can completely eliminate this time-consuming synchronization phase.
>
> Say,
> a) master sends it's virtual clock to the first slave and that slave becomes a clock master
> b) master re-distributes fist slave's clock to other slaves
> c) master adjust it's clock permanently, relatively to the clock master (first slave)
> d) master periodically re-distributes clock from the first slave to other in order to eliminate time skew in slave.
>
>
> ________________________________________
> From: Jun Yuan [j.yuan at rtleaders.com]
> Sent: Friday, January 03, 2014 11:10 AM
> To: Slutsker, Rasty
> Cc: Jeroen Van den Keybus; Raz; etherlab-users at etherlab.org
> Subject: Re: [etherlab-users] etherlab dc sync check
>
> I'm not saying that the clock of the master is inaccurate. I'm saying
> that the master software does a bad job in the calculation of the time
> offset for each slave. It should not use jiffies in the calculation,
> It should not have any correction at all. The app_time when the fprd
> datagram to 0x0910 is sent, let's call it app_time_sent, is exactly
> the time which should be compared to the system time of the slave.
>
>> Why not just send once a current muster time to the first slave, then propagate(copy)  it to other slaves, and run PLL in the master that adjust itself to the fist slave (clock master)?
>
> I think we cannot do that, it's against the ethercat standard :)
> It actually works similiar like you suggest, just in another way. It
> is something like this:
> Ref clock -> Master clock
> 1. The master asks the first slave which time it has.
> 2. The master compares the timestamp with its app time, and sends a
> new time offset to the first slave.
> 3. The first slave adds the new time offset to its clock. Now he has
> the same time as the master. Drift is the next thing to worry about.
>
> Other slave clock -> Ref clock
> 1. The master asks the slave which is not a ref clock which time it has.
> 2. The master compares the timestamp with the time of the ref clock,
> and sends a new time offset to the slave.
> 3. The slave adds the new time offset to its clock. Now he shall have
> the same time as the ref clock.
>
> I believe the current etherlabmaster doesn't do well in step 2. it
> could be done better.



-- 
Jun Yuan
[Aussprache: Djün Üän]

Robotics Technology Leaders GmbH
Am Loferfeld 58, D-81249 München
Tel: +49 89 189 0465 24
Mobile: +49 176 2176 5238
Fax: +49 89 189 0465 11
mailto: j.yuan at rtleaders.com

Umlautregel in der chinesischen Lautschrift Pinyin: Nach den Anlauten
y, j, q, und x wird u als ü ausgesprochen, z.B. yu => ü,  ju => dschü,
 qu => tschü,  xu => schü.