<div dir="ltr"><div><div>Hi Graeme,<br><br>It is a great pleasure to hear from you. Your original patch helped me a lot, as I once  suffered from the jitter of the master, too. And I sent a Email to the mailing list <a href="http://lists.etherlab.org/pipermail/etherlab-users/2013/002026.html" target="_blank">http://lists.etherlab.org/pipermail/etherlab-users/2013/002026.html<span></span><span></span></a>, pointing out another little problem in the original patch, which still exits in the Etherlab master 1.5.2. I hope Florian would merge those patches into the repository soon. <br>


<br></div>Thank you for supporting my thought that the master calculates an incorrect initial time. <br><br>As Jereon pointed out, it's strange that the convergence time would depend on the number of slaves. I feel the same. Although the master initialises one slave at a time, the function ecrt_master_sync_slave_clocks() send those sync datagrams all the time since the user loop starts. I think the log from the master might make it look like that all the slave are synced once at a time, but the sync process(drift compensation) is carried out for all the slaves all the time in the background. Am I right?<br>

<br></div><div><div></div></div><div class="gmail_extra">Thanks again for all the help you offered.<br><br></div><div class="gmail_extra">Jun<br>
</div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Jan 5, 2014 at 11:43 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:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
Hi,<br>
<br>
It's a while ago now that I looked into it, but I originally had all sorts of problems with the dc clock system.  I could never get my yaskawa amps stable using the PC clock as the time master.  There is just way too much jitter.  Instead I wrote the original patch that selects a slave to use as the master time for both the rest of slaves and the PC master clock.<br>



<br>
As a side note, this is the default method used by TwinCAT.  They call the mode: "Master time/cycle updated to match ref slave time".<br>
<br>
This system in the Etherlab master 1.5.2 is currently broken.  I sent in a patch for it a while ago:<br>
<a href="http://lists.etherlab.org/pipermail/etherlab-users/2013/002162.html" target="_blank">http://lists.etherlab.org/pipermail/etherlab-users/2013/002162.html</a><br>
<br>
<br>
The second issue is the time it takes to sync a slave.  My memory is a bit rusty here and I never had time to fully investigate, but essentially the master often seems to calculate an incorrect initial time.  I think I got this down to consistently being within +-1ms which takes approx 3 seconds to sync (my RT cyctle time is 1ms).<br>



<br>
However, the more slaves you have, the longer it takes as the master initialises and syncs one slave at a time.<br>
<br>
<br>
I don't have much time in the next couple of months to help test, but I thought I would let you know about the patch above in case you were going to use the ref slave as the master time clock.<br>
<br>
<br>
Regards,<br>
Graeme.</blockquote></div></div><div id="xunlei_com_thunder_helper_plugin_d462f475-c18e-46be-bd10-327458d045bd"></div><div id="xunlei_com_thunder_helper_plugin_d462f475-c18e-46be-bd10-327458d045bd"></div></div>