[etherlab-users] DC sync and arrival times of datagrams

[Graeme Foot]

Which time you use doesn't matter so much as long as it's stable and you get minimal jitter.


With RTAI on startup Linux calculates a cpu frequency and calibrates the timer against it.  Between cold starts Linux will generally get the same value, but if you do a soft restart it will often calculate a different value.  It also only calculates to the nearest micro second.  different boxes with the same hardware specs may also get different values.  If you need a consistent time base then you need to calibrate this value for your hardware and set it explicitly on startup.  If you are using RTAI you can do the following (allowing you to specify a value to 1 nano second):

MODULE_DIR=`/usr/realtime/bin/rtai-config --module-dir`
insmod "${MODULE_DIR}/rtai_hal.ko" rtai_cpufreq_arg=<calibrated_value>

see: https://www.rtai.org/userfiles/documentation/documents/RTAI_User_Manual_34_03.pdf or similar

I don't know if other realtime Linux implementations do a similar thing.


But regardless of how well you calibrate your pc clock there will eventually be drift between the PC and the EtherCAT modules.  So how does the EtherCAT DC system avoid this?

1) assume the PC cycle time is correct and use it as the master time.  (EtherLabs master default option)

In this case you need to:
- call ecrt_master_application_time() to tell the EtherLabs master what the current PC time is
- call ecrt_master_sync_reference_clock() to tell the master DC slave to sync to the current PC time
- call ecrt_master_sync_slave_clocks() to tell the remaining DC slaves to sync to the master slaves time

This option has a lot of jitter which the EtherCAT slaves often don't like, especially if the cycle times are somewhat different.  If you soft reboot and haven't calibrated then expect a different cycle time.


2) assume the first EtherCAT DC slave cycle time is correct and use it as the master time.  (TwinCAT default option)

In this case you need to:
- call ecrt_master_reference_clock_time() to get the DC slave master time, calculate any drift from your PC cycle and adjust your PC cycle to suit
- call ecrt_master_sync_slave_clocks() to tell the remaining DC slaves to sync to the master slaves time
- call ecrt_master_application_time () with a "psudo" time that matches the DC slaves time (I generally just use "last_time + cycle_time" as it's the first thing I do on wakeup)


So in summary:
ecrt_master_sync_slave_clocks() is always required to sync the DC slave to the master DC slave, then it is up to you whether you want to use option 1 or 2 above.


Hope this helps,
Graeme.


PS: I use option 2.  I had all sorts of problems with option 1.



________________________________
From: etherlab-users-bounces at etherlab.org [mailto:etherlab-users-bounces at etherlab.org] On Behalf Of Jeroen Proveniers
Sent: Wednesday, 21 May 2014 20:49
Cc: etherlab-users at etherlab.org
Subject: Re: [etherlab-users] DC sync and arrival times of datagrams

Interestingly, the master thinks it sends 5000 datagrams per second, as the "ethercat master" command shows.
I took timestamps using debug level 2, and the scheduling is correct, sometimes the delta between datagrams is 203us, but the next delta is 197 then. Average is a nice 200us.
It turned out the ACPI_PM timer we use as a timebase is apparently way off, about 5% (the slave only receives about 4700 datagrams per second). We changed it to HPET (with which we have had issues in the past I heard) and it's basically spot on now.

I have to see how we get the master to use actually use slave #0 as reference clock (it is set as reference but somehow not used I think).
Cheers,
Jeroen

On Mon, May 19, 2014 at 12:25 PM, Jeroen Van den Keybus <jeroen.vandenkeybus at gmail.com<mailto:jeroen.vandenkeybus at gmail.com>> wrote:
It looks like the master process isn't scheduling itself properly. To
check, have the master log the timestamps you're using to synchronize
the slaves (whatever you use as argument of
ecrt_master_application_time()). If all is well, you should be sending
timestamps with, on average, EXACTLY the cycle time (what you
programmed to generate SYNC0 in the slaves) as time difference.

Beware of rounding errors when scheduling the master process, as well
as different timebases.


J.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.etherlab.org/pipermail/etherlab-users/attachments/20140521/3e791d1a/attachment-0003.htm>