<div dir="ltr">Hi Gavin,<br><div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Apr 9, 2014 at 3:40 AM, Gavin Lambert <span dir="ltr"><<a href="mailto:gavinl@compacsort.com" target="_blank">gavinl@compacsort.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">On 8 April 2014, quoth Jun Yuan:<br>
<div class="">> Thank you so much for the test. I am sorry for the formatting error.<br>
> I should test it before send it out but I didn't have the chance.<br>
<br>
</div>I think this was actually from the original code, not your changes.<br></blockquote><div><br>well, it is my fault trying to log the value with sign by changing the original code<br> EC_SLAVE_DBG(slave, 1, "Sync after %4lu ms: %10u ns\n",<br>
diff_ms, abs_sync_diff);<br>to <br> EC_SLAVE_DBG(slave, 1, "Sync after %4lu ms: %10u ns\n",<br> diff_ms, EC_READ_U32(datagram->data) & 0x80000000 ? -abs_sync_diff: abs_sync_diff);<br>
and clearly I forgot to change the formatting <span class="">accordingly :P<br></span></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Fair enough. Although in that case I wonder why this isn't more of a widespread problem (or why it hasn't been solved somehow if it is). The slave isn't doing anything weird, it's just using whatever default timing behaviours are built in. And as I said according to the debug output the timing actually seemed to be diverging, which it definitely shouldn't be doing. I wonder if there's some extra register that's supposed to be set during initial setup to help it along? Some way to tell it "the network's restarting, forget about slowly adjusting the clock and just step it directly to this value".<br>
</blockquote><div> </div><div><div>Yes, I also observed that the converging curve is somehow zig-zag. I don't quite
understand why the difference sometimes diverges neither. But thank God,
it always converges to zero when we give it some time. <br><br></div>I'm
not familiar with the implementation of the DC Sync on the slaves, but I
think it is effected by some hardware limitations. Our master, on the
other side, has a clock with more resolution, although it might not be
so accurate. And it can have more complicated software solution with
control loop feedback to make the convergence much faster. I also read
somewhere that the slave can only have 3 choices to sync its
clock: it increases its clock either with 9, 10, or 11 ns every 10ns.
Stability is more important than the converge speed.<br><br>I think the
problem with the reboot is that the register 0x0932 Speed Counter Diff
is reset to zero, and the slave need to find out the proper value for
that again, which takes time. If the master - slave pair will not be
changed, we may read out the value before the reboot of the slave, and
write the old value to the register after the boot. But It's not
generally a good idea.<br> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
There's a note in the slave datasheet about resetting the time filters by writing to 0x0930. I can't see anywhere that this is happening at the moment, but I might just be missing it. If not, maybe it should be doing this after updating the reference clock slave's time for the first time?<br>
</blockquote><br>According to the EtherCAT documentation, the register 0x0930 Speed Counter Start is related to the bandwidth of the drift compensation. And when 0x0930 is set by the user (a write access on 0x0930), the time filter (0x092c and 0x0932) will be reset to zero. <br>
<br>I don't get what you mean above. Maybe we can adjust it to a smaller value at the beginning to make the convergence faster for the first time after the reboot, and change it back later to have it more stable. But the change back will reset the time filter, which is bad for us. Well, I don't know. It seems complicated, and need many experiments.<br>
<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class=""><br>
> 2) sync the master to ref slave<br>
> sorry about the error message. It is because I let the<br>
> ecrt_master_reference_clock_time return EAGAIN error when the system<br>
> time offset has not been calculated yet. I tried to avoid the error<br>
> message in lib/master.c, but apparently I didn't do it right. I'll<br>
> fix it ASAP.<br>
<br>
</div>That part worked; the issue is that if a reference clock is not explicitly selected (eg. ecrt_select_master_reference_clock(master, NULL) or not called) then calls to get the time will return ENXIO until later in the startup cycle when it actually finds a clock to use. And this causes the user library to generate spam. (The library error output seems like a misfeature to me, especially for functions intended to be called from realtime code that probably doesn't want to go near fprintf. But that's an entirely separate topic.)<br>
</blockquote><div><br>Thanks for pointing out it's a ENXIO error, not a EAGAIN error. So it's not my fault. And I can‘t agree with you more on the realtime issue with the fprintf in the userspace lib. I did remove those in my code, but I didn't commit it into the repository yet. <br>
</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Incidentally, I tried this userland code with the original 1.5.2 master code (with modification to lib/master.c to avoid spam) and it produced the same results with one slave -- almost instantly locking in the timing. I assume for the differences to become apparent, more slaves are required.
<br>
<br>
</blockquote></div>Well, could you try it with a 4ms cycle loop? It should be more apparently when the cycle time become larger.<br><br><br></div><div class="gmail_extra">Regards,<br>Jun<br></div><div class="gmail_extra">
<br></div><div class="gmail_extra"><br></div></div></div>