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

[Jeroen Proveniers]

We just implemented option 2, and so far it seems to work perfectly now :)

Cheers,
Jeroen


On Thu, May 22, 2014 at 12:33 AM, Graeme Foot <Graeme.Foot at touchcut.com>wrote:

>   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.pdfor 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> 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/20140522/98ac7ad9/attachment-0004.htm>