<div dir="ltr"><div><div>Hi Gavin,<br><br>thanks for the reply. It's very helpful.<br><br></div>It sounds that,<br>1) The master can send max. only one mailbox request in one cycle.<br>2) Before a mailbox request is going to be sent, the master should check the SM0 register 0x800 whether the send mailbox is full or empty, and send the request only if it is empty.<br>

</div><div>3) Mailbox service with different protocol can be executed in parallel. That is, the master can send a new mailbox request, while the last conversation in another protocol is not finished yet, given that the send mailbox is already cleared.<br>

</div>4) We're not sure if all the slave can support multiple CoE conversations in parallel. So the master should start a new CoE conversation only when the last one is finished. The same applies to SoE/FoE/VoE.<br><div>

<div><br></div><div>While reading the documentation and another open source ethercat project SOEM, I found there is a mailbox service "counter" besides the service type in the mailbox header. It says, "Counter of the mailbox services (0 ist start value, next value after 7 is 1)". I wonder if what this counter is used for, how is it implemented in your slave example code, whether it could be useful for us in the multiple conversation situation.<br>

<br>
</div><div>Regards,<br>Jun<br><br></div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On 30 June 2014 02:11, 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 28 June 2014, quoth Jun Yuan:<br>
<div class="">> Are you sure that some slaves will choke with multiple CoE requests?<br>
> Does these slaves then support simultaneous mailbox requests in<br>
> different protocol, i.e. CoE and EoE, or CoE and SoE in parallel?<br>
> Do we always need to wait until the slave have a response mail for<br>
> the last mailbox request, before another mailbox request is able to<br>
> send? I didn't find the answer in the ethercat documentation yet.<br>
<br>
</div>As far as I am aware, all of those things are unspecified and left up to the actual slave implementation, so the answers may vary.<br>
<br>
But for what it's worth, the example slave code that I've seen lets the vendor choose whether to implement internal send/receive queues (such that the mailbox accepts subsequent requests before finishing processing, and will *typically* respond in order -- but asynchronous replies such as CoE emergencies and EoE packets can be injected at any time), or whether to save memory and skip the queues (in which case only one thing can be processed at a time).<br>


<br>
Really it mostly depends on whether the slaves internally process mailbox requests synchronously or asynchronously, which is also left up to the vendor to decide.  And again, looking at slave example code suggests that most commonly processing is synchronous, but in some cases there is some asynchronous plumbing that supports only one pending conversation per protocol.<br>


<br>
The master can sort of tell the difference between these cases; a slave without queues will clear the send mailbox (allowing a subsequent send to succeed) while it is processing a request, but until it finishes and fetches the next request any further attempts to send will fail (as the send mailbox is still full).  Conversely a slave that implements a queue is likely to clear the send mailbox fairly quickly and repeatedly (even if it's still synchronously processing only the first request) and might eventually either stop pulling requests from the send mailbox or pulling them anyway and sending error responses (out of order relative to processing), if the master is sending requests faster than they can be queued.<br>


<br>
I *believe* that in general it is only safe to rely on having one in-progress conversation per protocol, such that the protocol can be used to determine which conversation thread the reply applies to, but that the master must be prepared to accept specific protocols in a different order to when they were sent (and again, asynchronous replies at any time).<br>


<br>
It's likely that many slaves will be able to cope with receiving multiple CoE conversations in parallel (even when internal processing is only synchronous), but then the master logic required to route the replies to the appropriate FSM becomes more complex (in case internal processing is asynchronous).  And I'm dubious that this should be relied on by the master, which is why I'm uncomfortable with the way this patch would work -- it would try to send both requests and then *hope* that the mailbox read lock is acquired by the one that the slave responds to first; if it gets it wrong, it will treat both replies as failures because they were routed incorrectly.<br>


<br>
But no, I can't point to anything concrete in the standards.  This is mostly just a feeling, partly based on slave example code.<br>
<br>
Regards,<br>
Gavin Lambert<br>
<br>
<br>
</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>