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