<div dir="ltr"><div><div><div>Interestingly, the master thinks it sends 5000 datagrams per second, as the "ethercat master" command shows.<br><br></div>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.<br>
<br></div>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.<br>
<br>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).<br><br></div>Cheers,<br>Jeroen<br><div><div><div><div><div><div class="gmail_extra">
<br><br><div class="gmail_quote">On Mon, May 19, 2014 at 12:25 PM, Jeroen Van den Keybus <span dir="ltr"><<a href="mailto:jeroen.vandenkeybus@gmail.com" target="_blank">jeroen.vandenkeybus@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">It looks like the master process isn't scheduling itself properly. To<br>
check, have the master log the timestamps you're using to synchronize<br>
the slaves (whatever you use as argument of<br>
ecrt_master_application_time()). If all is well, you should be sending<br>
timestamps with, on average, EXACTLY the cycle time (what you<br>
programmed to generate SYNC0 in the slaves) as time difference.<br>
<br>
Beware of rounding errors when scheduling the master process, as well<br>
as different timebases.<br>
<span class="HOEnZb"><font color="#888888"><br>
<br>
J.<br>
</font></span></blockquote></div><br></div></div></div></div></div></div></div>