<div dir="ltr"><div>Hi,<br><br>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.<br>
<br>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.<br>
<br>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".<br>
<br>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<br> /* Attention: The initial application time is also used for phase<br>
* calculation for the SYNC0/1 interrupts. Please be sure to call it at<br> * the correct phase to the realtime cycle.<br> */<br><br>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. <br>
<br></div>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.<br>
<div><div><br></div><div>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.<br>
<br> // set first wake time in a few cycles<br>- wakeup_time = system_time_ns() + 10 * cycle_ns;<br></div><div>+ uint64_t time = system_time_ns() + 10 * cycle_ns;<br>+ // notice we shouldn't have a time that is already pasted.<br>
+ wakeup_time = dc_start_time_ns + 50 * cycle_ns;<br>+ while (wakeup_time < time) {<br>+ wakeup_time += cycle_ns;<br>+ }<br><br></div><div>In this way, we may still have the shift_time influenced by the execution_time, but it will be at least constant.<br>
<br></div><div>Regards,<br>Jun<br>
</div><div><br></div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Apr 1, 2014 at 11:58 PM, Graeme Foot <span dir="ltr"><<a href="mailto:Graeme.Foot@touchcut.com" target="_blank">Graeme.Foot@touchcut.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<u></u>
<div link="blue" vlink="purple" lang="EN-GB">
<div>
<p class="MsoNormal"><font face="Arial" color="navy"><span style="font-size:10.0pt;font-family:Arial;color:navy">Hi,<u></u><u></u></span></font></p>
<p class="MsoNormal"><font face="Arial" color="navy"><span style="font-size:10.0pt;font-family:Arial;color:navy"><u></u> <u></u></span></font></p>
<p class="MsoNormal"><font face="Arial" color="navy"><span style="font-size:10.0pt;font-family:Arial;color:navy">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().<u></u><u></u></span></font></p>
<p class="MsoNormal"><font face="Arial" color="navy"><span style="font-size:10.0pt;font-family:Arial;color:navy"><u></u> <u></u></span></font></p>
<p class="MsoNormal"><font face="Arial" color="navy"><span style="font-size:10.0pt;font-family:Arial;color:navy">Therefore your cycles should always start at: initial_master_application_time + cycle_count * cycle_time<u></u><u></u></span></font></p>
<p class="MsoNormal"><font face="Arial" color="navy"><span style="font-size:10.0pt;font-family:Arial;color:navy">Where you start counting cycles as soon as the first ecrt_master_application_time() call is made.<u></u><u></u></span></font></p>
<p class="MsoNormal"><font face="Arial" color="navy"><span style="font-size:10.0pt;font-family:Arial;color:navy"><u></u> <u></u></span></font></p>
<p class="MsoNormal"><font face="Arial" color="navy"><span style="font-size:10.0pt;font-family:Arial;color:navy">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.<u></u><u></u></span></font></p>
<p class="MsoNormal"><font face="Arial" color="navy"><span style="font-size:10.0pt;font-family:Arial;color:navy"><u></u> <u></u></span></font></p>
<p class="MsoNormal"><font face="Arial" color="navy"><span style="font-size:10.0pt;font-family:Arial;color:navy"><u></u> <u></u></span></font></p>
<p class="MsoNormal"><font face="Arial" color="navy"><span style="font-size:10.0pt;font-family:Arial;color:navy">As to answering "</span></font><span lang="EN-US">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 ?</span><font face="Arial" color="navy"><span style="font-size:10.0pt;font-family:Arial;color:navy">":<u></u><u></u></span></font></p>
<p class="MsoNormal"><font face="Arial" color="navy"><span style="font-size:10.0pt;font-family:Arial;color:navy"><u></u> <u></u></span></font></p>
<p class="MsoNormal"><font face="Arial" color="navy"><span style="font-size:10.0pt;font-family:Arial;color:navy">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".<u></u><u></u></span></font></p>
<p class="MsoNormal"><font face="Arial" color="navy"><span style="font-size:10.0pt;font-family:Arial;color:navy">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.)<u></u><u></u></span></font></p>
<p class="MsoNormal"><font face="Arial" color="navy"><span style="font-size:10.0pt;font-family:Arial;color:navy"><u></u> <u></u></span></font></p>
<p class="MsoNormal"><font face="Arial" color="navy"><span style="font-size:10.0pt;font-family:Arial;color:navy"><u></u> <u></u></span></font></p>
<p class="MsoNormal"><font face="Arial" color="navy"><span style="font-size:10.0pt;font-family:Arial;color:navy">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).<u></u><u></u></span></font></p>
<p class="MsoNormal"><font face="Arial" color="navy"><span style="font-size:10.0pt;font-family:Arial;color:navy"><u></u> <u></u></span></font></p>
<p class="MsoNormal"><font face="Arial" color="navy"><span style="font-size:10.0pt;font-family:Arial;color:navy"><u></u> <u></u></span></font></p>
<p class="MsoNormal"><font face="Arial" color="navy"><span style="font-size:10.0pt;font-family:Arial;color:navy">Regards,<u></u><u></u></span></font></p>
<p class="MsoNormal"><u></u><font face="Arial" color="navy"><span style="font-size:10.0pt;font-family:Arial;color:navy">Graeme Foot</span></font><u></u><font face="Arial" color="navy"><span style="font-size:10.0pt;font-family:Arial;color:navy">.<u></u><u></u></span></font></p>
<p class="MsoNormal"><font face="Arial" color="navy"><span style="font-size:10.0pt;font-family:Arial;color:navy"><u></u> <u></u></span></font></p>
<p class="MsoNormal"><font face="Arial" color="navy"><span style="font-size:10.0pt;font-family:Arial;color:navy"> <u></u><u></u></span></font></p>
<p class="MsoNormal"><font face="Arial" color="navy"><span style="font-size:10.0pt;font-family:Arial;color:navy"><u></u> <u></u></span></font></p>
<div>
<div class="MsoNormal" style="text-align:center" align="center"><font size="3" face="Times New Roman"><span style="font-size:12.0pt;font-family:"Times New Roman"" lang="EN-US">
<hr size="2" width="100%" align="center">
</span></font></div>
<p class="MsoNormal"><b><font face="Tahoma"><span style="font-size:10.0pt;font-family:Tahoma;font-weight:bold" lang="EN-US">From:</span></font></b><font face="Tahoma"><span style="font-size:10.0pt;font-family:Tahoma" lang="EN-US"> <a href="mailto:etherlab-users-bounces@etherlab.org" target="_blank">etherlab-users-bounces@etherlab.org</a>
[mailto:<a href="mailto:etherlab-users-bounces@etherlab.org" target="_blank">etherlab-users-bounces@etherlab.org</a>] <b><span style="font-weight:bold">On Behalf Of
</span></b>WIEGAND Ralf<br>
<b><span style="font-weight:bold">Sent:</span></b> Wednesday, 2 April 2014 05:23<br>
<b><span style="font-weight:bold">To:</span></b> <u></u><a href="mailto:etherlab-users@etherlab.org" target="_blank">etherlab-users@etherlab.org</a><u></u><br>
<b><span style="font-weight:bold">Subject:</span></b> [etherlab-users] DC-Synchronization - Sync signal generation</span></font><font size="3" face="Times New Roman"><span style="font-size:12.0pt;font-family:"Times New Roman"" lang="EN-US"><u></u><u></u></span></font></p>
</div><div><div class="h5">
<p class="MsoNormal"><font face="Calibri"><span style="font-size:11.0pt"><u></u> <u></u></span></font></p>
<p class="MsoNormal"><font face="Calibri"><span style="font-size:11.0pt" lang="EN-US">Hello,<u></u><u></u></span></font></p>
<p class="MsoNormal"><font face="Calibri"><span style="font-size:11.0pt" lang="EN-US"><u></u> <u></u></span></font></p>
<p class="MsoNormal"><font face="Calibri"><span style="font-size:11.0pt" lang="EN-US">first of all, thanks to all etherlab-developers for their great job.<u></u><u></u></span></font></p>
<p class="MsoNormal"><font face="Calibri"><span style="font-size:11.0pt" lang="EN-US"><u></u> <u></u></span></font></p>
<p class="MsoNormal"><font face="Calibri"><span style="font-size:11.0pt" lang="EN-US">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
<u></u>Graeme Foot<u></u>, 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
<u></u>Graeme Foot<u></u>, 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 ?<u></u><u></u></span></font></p>
<p class="MsoNormal"><font face="Calibri"><span style="font-size:11.0pt" lang="EN-US"><u></u> <u></u></span></font></p>
<p class="MsoNormal"><font face="Calibri"><span style="font-size:11.0pt" lang="EN-US">Thank you in advance,<u></u><u></u></span></font></p>
<p class="MsoNormal"><font face="Calibri"><span style="font-size:11.0pt" lang="EN-US"><u></u> <u></u></span></font></p>
<p class="MsoNormal"><font face="Calibri"><span style="font-size:11.0pt" lang="EN-US">Ralf Wiegand <u></u><u></u></span></font></p>
<p style="margin-bottom:12.0pt"><strong><b><font face="Arial" color="gray"><span style="font-size:10.0pt;font-family:Arial;color:gray" lang="DE">Ralf Wiegand</span></font></b></strong><font face="Arial" color="gray"><span style="font-size:10.0pt;font-family:Arial;color:gray" lang="DE"><br>
<br>
<br>
<strong><b><font face="Arial"><span style="font-family:Arial">T:</span></font></b></strong> <a href="tel:%2B49%206441%20207-410" value="+496441207410" target="_blank">+49 6441 207-410</a>
<strong><b><font face="Arial"><span style="font-family:Arial">F:</span></font></b></strong> <a href="tel:%2B49%206441%20207-387" value="+496441207387" target="_blank">+49 6441 207-387</a><br>
<strong><b><font face="Arial"><span style="font-family:Arial">E:</span></font></b></strong>
</span></font><font color="gray"><span style="color:gray" lang="DE"><a href="mailto:Ralf.Wiegand@hexagonmetrology.com%20" title="" target="_blank"><font face="Arial" color="#0082bf"><span style="font-size:10.0pt;font-family:Arial;color:#0082bf">Ralf.Wiegand@hexagonmetrology.com</span></font><font face="Arial"><span style="font-size:10.0pt;font-family:Arial">
</span></font></a></span></font><span lang="DE"><u></u><u></u></span></p>
<p><strong><b><font face="Arial" color="gray"><span style="font-size:10.0pt;font-family:Arial;color:gray" lang="DE">Hexagon Metrology GmbH</span></font></b></strong><font face="Arial" color="gray"><span style="font-size:10.0pt;font-family:Arial;color:gray" lang="DE"><br>
Siegmund-Hiepe-Str. 2-12<br>
DE-35578 Wetzlar</span></font><span lang="DE"> <br>
<a href="http://www.hexagonmetrology.de/" title="Hexagon Metrology Web Site" target="_blank"><font face="Arial" color="#0082bf"><span style="font-size:10.0pt;font-family:Arial;color:#0082bf">www.hexagonmetrology.de</span></font></a></span><font face="Arial" color="#0082bf"><span style="font-size:10.0pt;font-family:Arial;color:#0082bf" lang="DE"> |
</span></font><span lang="DE"><a href="http://www.linkedin.com/company/hexagon-metrology" title="" target="_blank"><font face="Arial" color="#0082bf"><span style="font-size:10.0pt;font-family:Arial;color:#0082bf">LinkedIn</span></font></a></span><font face="Arial" color="#0082bf"><span style="font-size:10.0pt;font-family:Arial;color:#0082bf" lang="DE"> |
</span></font><span lang="DE"><a href="http://www.facebook.com/hex.metrology" title="" target="_blank"><font face="Arial" color="#0082bf"><span style="font-size:10.0pt;font-family:Arial;color:#0082bf">Facebook</span></font></a></span><font face="Arial" color="#0082bf"><span style="font-size:10.0pt;font-family:Arial;color:#0082bf" lang="DE"> |
</span></font><span lang="DE"><a href="http://twitter.com/hexmetrology" title="" target="_blank"><font face="Arial" color="#0082bf"><span style="font-size:10.0pt;font-family:Arial;color:#0082bf">Twitter</span></font></a><u></u><u></u></span></p>
<p class="MsoNormal"><font size="3" face="Times New Roman"><span style="font-size:12.0pt;font-family:"Times New Roman"" lang="DE"><a href="http://www.hexagonmetrology.de" target="_blank"></a></span></font><font size="3" face="Arial"><span style="font-size:12.0pt;font-family:Arial" lang="DE"><u></u><u></u></span></font></p>
<p class="MsoNormal"><font face="Arial" color="gray"><span style="font-size:10.0pt;font-family:Arial;color:gray" lang="DE">Hauptgeschäftsführer: Holger Fritze<br>
Geschäftsführer: Per Holmberg - Arno Seuren - Michael Rosenbruch<br>
Amtsgericht Wetzlar, HRB 1201 </span></font><font size="3" face="Times New Roman"><span style="font-size:12.0pt;font-family:"Times New Roman"" lang="DE"><u></u><u></u></span></font></p>
</div></div></div>
</div>
<br>_______________________________________________<br>
etherlab-users mailing list<br>
<a href="mailto:etherlab-users@etherlab.org">etherlab-users@etherlab.org</a><br>
<a href="http://lists.etherlab.org/mailman/listinfo/etherlab-users" target="_blank">http://lists.etherlab.org/mailman/listinfo/etherlab-users</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br>Jun Yuan<br>[Aussprache: Djün Üän]<br><br>Robotics Technology Leaders GmbH<br>Am Loferfeld 58, D-81249 München<br>Tel: +49 89 189 0465 24<br>Fax: +49 89 189 0465 11<br>
mailto: <a href="mailto:j.yuan@rtleaders.com" target="_blank">j.yuan@rtleaders.com</a><br><br>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ü.
</div>