<div dir="ltr"><div><div><div>Hi Frank,<br><br></div>thank you very much for your mail. Your patches are very precious for me. I'll test them as soon as I can.<br><br></div>Regards,<br></div>Jun<br></div><div class="gmail_extra">
<br><br><div class="gmail_quote">On 5 June 2014 17:02, Frank Heckenbach <span dir="ltr"><<a href="mailto:f.heckenbach@fh-soft.de" target="_blank">f.heckenbach@fh-soft.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="">Jun Yuan wrote:<br>
<br>
> The CoE mailbox communication between the master and slave is like the<br>
> following:<br>
> 1) the master sends a request datagram to the slave, and receives the<br>
> acknowledge from the slave;<br>
> 2) the master sends a mailbox check datagram to the slave, asking if the<br>
> slave has a reply mail prepared for him;<br>
> 3) If the slave says no, go to 2) send another check datagram; otherwise,<br>
> go to 4);<br>
> 4) the master sends a fetch-response datagram to fetch the reply mail from<br>
> the slave.<br>
><br>
> The problem I discovered with the etherlabmaster is, when the bus topology<br>
> changes and a bus rescan is required, the state machine of the CoE mailbox<br>
> communication will be interrupted/stopped and later be reset to START<br>
> state. And this causes the problem.<br>
<br>
</div>I had similar issues and I fixed them. I now sent my patches (a bit<br>
late, sorry) to etherlab-dev. I hope they'll help with your problems<br>
as well. (However, my patches are against 1.5.0, so if you need<br>
1.5.1 or 1.5.2 you may need to port them or wait for someone else to<br>
do it.)<br>
<div class=""><br>
> Take an example, the master sends a request A to the slave, and the slave<br>
> acknowledges, and prepares the reply A, which takes a while. At that time<br>
> we attach a new slave to the bus, the bus topology changes, which stops the<br>
> CoE mailbox communication. No the master scans the bus, and begins to use<br>
> CoE mailbox to fetch the SDO 1C12:00 for SM2 of the slave. He sends the<br>
> request, then checks the mailbox and find a reply mail. He fetches the mail<br>
> from the slave, opens it and it's the reply A, not the reply for the SDO<br>
> 1C12:00 which he's waiting for.<br>
<br>
</div>Looks like the issue from my patch #26.<br>
<div class=""><br>
> Is there any command in the EtherCAT standard for the master to ask the<br>
> slaves to clear their mailbox? Why doesn't the mail have any id, so the<br>
> master can tell which reply is for which request? Is simultaneous multiple<br>
> request allowed?<br>
><br>
> What should the master do when he receives a wrong reply from the slave?<br>
> How can it tell whether it is a wrong reply or a outdated reply for the<br>
> last request?<br>
<br>
</div>These more general questions are the focus of my bigger patches<br>
(in particular #09-#15 and #27). Those should also fix (hopefully)<br>
the issues you mentioned in another mail ("BUG in the mailbox<br>
handling").<br>
<div class=""><br>
> Without answering the questions above, I find the following possible<br>
> solutions:<br>
> 1) Before send the request datagram, send a check datagram at first to see<br>
> if there is any outdated response there, and clean it if it exists. But<br>
> what if the slave finishes the old response after the check datagram?<br>
<br>
</div>What I do in #26 is to just fetch the mailbox and ignore the result<br>
(success or error).<br>
<div class=""><br>
> 2) If the master receives a wrong reply, instead of giving up and returning<br>
> an error, he keeps checking until timeout. That's what I did in my patch,<br>
> but is there any side effects?<br>
<br>
</div>I haven't looked at your patch, but if the reply is meant for some<br>
other part of the code and you just throw it away, there will be<br>
side effects. ;) Therefore I use internal buffers to dispatch the<br>
replies, see my patches.<br>
<br>
Regards,<br>
Frank<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Dipl.-Math. Frank Heckenbach <<a href="mailto:f.heckenbach@fh-soft.de">f.heckenbach@fh-soft.de</a>><br>
Stubenlohstr. 6, 91052 Erlangen, Germany, <a href="tel:%2B49-9131-21359" value="+49913121359">+49-9131-21359</a><br>
Systems Programming, Software Development, IT Consulting<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>
</font></span></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>