[etherlab-users] DC-Synchronization - Sync signal generation
Jun Yuan
j.yuan at rtleaders.com
Wed Apr 2 11:39:34 CEST 2014
Hi,
I had the same problem once in Hamburg, that sometimes after a program
restart, my LTi drivers make big noises because they receive the same or
jumping pos cmd value in two cycles from the master. And the problem was
caused by the calling of ecrt_master_application_time(master,
dc_start_time_ns) outside the running loop, which should be avoid.
As Graeme already pointed out, the sync0_signal_time is set to be
"initial_master_application_time + cycle_count * cycle_time + sync_shift".
The sync_shift is given in the source code, and won't change during the
program running. It is a measure to adjust the sync0_signal_time, but not
the problem here.
The problem is, when the initial_master_application_time is given outside
of the loop, as in the rtai_rtdm_dc example, the
initial_master_application_time has nothing to do with the cycle start time
for the loop. Just as Graeme said, "your cycles should always start at:
initial_master_application_time + cycle_count * cycle_time". This is,
however, not the case in the rtai_rtdm_dc example, in which the cycles
start actually at "initial_wakup_time + cycle_count * cycle_time +
execution_time
between_wait_period()_and_ecrt_master_application_time()_in_loop".
Actually Florian Pose had warned me in one of his email that I should not
put the ecrt_master_application_time() outside of the loop. There is also a
warning in the example code in v1.5.2
/* Attention: The initial application time is also used for phase
* calculation for the SYNC0/1 interrupts. Please be sure to call it at
* the correct phase to the realtime cycle.
*/
But there is a reason why we all put the ecrt_master_application_time()
outside the loop. Because we all got burned by the error "No app_time
received up to now, but master already active.", which is a timing bug in
Etherlab.
I've resolved the problem by change the code of Etherlabmaster, which get
rid of the "No app_time" bug. Now I don't need to call
ecrt_master_application_time() outside the loop any more. I will publish
the bundle to the mailing list when I have time.
And there's another workaround. I think I saw the efforts in the example
code: the use of dc_start_time_ns. As the first call of
ecrt_master_application_time() uses dc_start_time_ns, we use it to
calculation of the first wakeup_time.
// set first wake time in a few cycles
- wakeup_time = system_time_ns() + 10 * cycle_ns;
+ uint64_t time = system_time_ns() + 10 * cycle_ns;
+ // notice we shouldn't have a time that is already pasted.
+ wakeup_time = dc_start_time_ns + 50 * cycle_ns;
+ while (wakeup_time < time) {
+ wakeup_time += cycle_ns;
+ }
In this way, we may still have the shift_time influenced by the
execution_time, but it will be at least constant.
Regards,
Jun
On Tue, Apr 1, 2014 at 11:58 PM, Graeme Foot <Graeme.Foot at touchcut.com>wrote:
> Hi,
>
>
>
> First off, my understanding of setting up the DC system is that each slave
> that wants a Distributed Clock setup calls ecrt_slave_config_dc()
> specifying the sync0_cycle time and the sync0_shift time (and sync1). The
> sync0_shift time should be specified as the offset from the nominal start
> of cycle time, which is specified by the very fist call to
> ecrt_master_application_time().
>
>
>
> Therefore your cycles should always start at:
> initial_master_application_time + cycle_count * cycle_time
>
> Where you start counting cycles as soon as the first
> ecrt_master_application_time() call is made.
>
>
>
> I set my sync0_cycle to 1000000 (1ms) and sync0_shift to 500000 (0.5ms).
> After waking up at the beginning of the cycle I then have 0.5ms to send my
> EtherCAT frames and have them be processed by all slaves.
>
>
>
>
>
> As to answering "To solve the problem i have to know the systemtime, the
> next sync0-signal is generated in the slave. Does anybody know if this time
> is available in a slave with dc-support ?":
>
>
>
> If the slave has a 64bit DC you should be able to calculate the next sync
> time as "initial_master_application_time + cycle_count * cycle_time +
> sync_shift".
>
> If the slave has a 32bit DC its more annoying reading the clock but it
> should be the same calculation, but then remove the top 4 bytes. (You get
> 4.2 odd seconds before the clock rolls over.)
>
>
>
>
>
> Looking at the ET1100 datasheet document there is a register 0x0990:0x0997
> which says it is the "SYNC0 Start Time" - Local copy of System Time
> (T_localtime + T_offset) (From Section 9.1.5).
>
>
>
>
>
> Regards,
>
> Graeme Foot.
>
>
>
>
>
>
> ------------------------------
>
> *From:* etherlab-users-bounces at etherlab.org [mailto:
> etherlab-users-bounces at etherlab.org] *On Behalf Of *WIEGAND Ralf
> *Sent:* Wednesday, 2 April 2014 05:23
> *To:* etherlab-users at etherlab.org
> *Subject:* [etherlab-users] DC-Synchronization - Sync signal generation
>
>
>
> Hello,
>
>
>
> first of all, thanks to all etherlab-developers for their great job.
>
>
>
> I have a question about the activation of the sync-signal generation with
> distributed clocks. I use the ethercatmaster 1.5.1 with the dc-patches
> from Graeme Foot, kernel 2.6.32.11 with rtai 3.8.1. The application is
> running over the rtdm-interface and the masterclock is synchronized to the
> reference clock in slave 1. The slaves are particular developed for us from
> external companies (FPGA-based designs with Beckhoff IP-Core). The
> synchronization of the masterclock with the reference clock, like the
> patches from Graeme Foot, works very well. But i see a constant phase
> offset between the sync0-signal and the incoming frame (SOF). With every
> restart of the application the offset is constant during runtime, but with
> another value. If the value is in a special range, i read the same input
> pdo values between two cycle times from the slave. To solve the problem i
> have to know the systemtime, the next sync0-signal is generated in the
> slave. Does anybody know if this time is available in a slave with
> dc-support ?
>
>
>
> Thank you in advance,
>
>
>
> Ralf Wiegand
>
> *Ralf Wiegand*
>
>
> *T:* +49 6441 207-410 *F:* +49 6441 207-387
> *E:* Ralf.Wiegand at hexagonmetrology.com
> <Ralf.Wiegand at hexagonmetrology.com%20>
>
> *Hexagon Metrology GmbH*
> Siegmund-Hiepe-Str. 2-12
> DE-35578 Wetzlar
> www.hexagonmetrology.de | LinkedIn<http://www.linkedin.com/company/hexagon-metrology> |
> Facebook <http://www.facebook.com/hex.metrology> | Twitter<http://twitter.com/hexmetrology>
>
> <http://www.hexagonmetrology.de>
>
> Hauptgeschäftsführer: Holger Fritze
> Geschäftsführer: Per Holmberg - Arno Seuren - Michael Rosenbruch
> Amtsgericht Wetzlar, HRB 1201
>
> _______________________________________________
> etherlab-users mailing list
> etherlab-users at etherlab.org
> http://lists.etherlab.org/mailman/listinfo/etherlab-users
>
>
--
Jun Yuan
[Aussprache: Djün Üän]
Robotics Technology Leaders GmbH
Am Loferfeld 58, D-81249 München
Tel: +49 89 189 0465 24
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ü.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.etherlab.org/pipermail/etherlab-users/attachments/20140402/c62c4dd3/attachment-0003.htm>
More information about the Etherlab-users
mailing list