[etherlab-users] etherlab dc sync check

Sun Jan 5 23:43:21 CET 2014

Hi,

It's a while ago now that I looked into it, but I originally had all sorts of problems with the dc clock system.  I could never get my yaskawa amps stable using the PC clock as the time master.  There is just way too much jitter.  Instead I wrote the original patch that selects a slave to use as the master time for both the rest of slaves and the PC master clock.

As a side note, this is the default method used by TwinCAT.  They call the mode: "Master time/cycle updated to match ref slave time".

This system in the Etherlab master 1.5.2 is currently broken.  I sent in a patch for it a while ago:
http://lists.etherlab.org/pipermail/etherlab-users/2013/002162.html

The second issue is the time it takes to sync a slave.  My memory is a bit rusty here and I never had time to fully investigate, but essentially the master often seems to calculate an incorrect initial time.  I think I got this down to consistently being within +-1ms which takes approx 3 seconds to sync (my RT cyctle time is 1ms).

However, the more slaves you have, the longer it takes as the master initialises and syncs one slave at a time.

I don't have much time in the next couple of months to help test, but I thought I would let you know about the patch above in case you were going to use the ref slave as the master time clock.

Regards,
Graeme.

-----Original Message-----
From: etherlab-users-bounces at etherlab.org [mailto:etherlab-users-bounces at etherlab.org] On Behalf Of Jun Yuan
Sent: Saturday, 4 January 2014 03:17
To: Slutsker, Rasty
Cc: etherlab-users at etherlab.org
Subject: Re: [etherlab-users] etherlab dc sync check

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ü.
_______________________________________________
etherlab-users mailing list
etherlab-users at etherlab.org
http://lists.etherlab.org/mailman/listinfo/etherlab-users