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: [email protected]
[mailto:[email protected]] On Behalf Of Jeroen Proveniers
Sent: Wednesday, 21 May 2014 20:49
Cc: [email protected]
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
<[email protected]<mailto:[email protected]>> 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.
_______________________________________________
etherlab-users mailing list
[email protected]
http://lists.etherlab.org/mailman/listinfo/etherlab-users
