<div dir="ltr"><div>In fact, it was a bug in my FPGA implementation of the EtherCAT data link layer protocol. The data were OR'ed with the existing data, as is required for the broadcast type commands. So there is no effect on a compliant slave.</div>
<div><br></div><div>I didn't revoke the request to zero out the datagram since:</div><div><br></div><div>a) otherwise, receive datagrams are always zeroed out;</div><div>b) it's kind of bad practice to have old, variable data lingering around. At least it's annoying for debugging and it wouldn't be the first time that such random data may eventually trigger extremely hard to find bugs.</div>
<div><br></div><div>J.</div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">2014/1/6 Jun Yuan <span dir="ltr"><<a href="mailto:j.yuan@rtleaders.com" target="_blank">j.yuan@rtleaders.com</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Jeroen,<br>
<br>
could you tell me more why the datagram needs to be zeroed out? After<br>
all, it is the slave's responsibility to fill the correct value in the<br>
datagram, isn't it? The master tries to read out those values, why the<br>
slave local system time and offset would become corrupt after the<br>
read?<br>
<span class="HOEnZb"><font color="#888888"><br>
Jun<br>
</font></span></blockquote></div><br></div>