<div dir="ltr"><div><div><div><div>Hi Knud,<br><br></div>I thought the same, until I observed the problem in a pure CoE application, see my bug report <a href="http://lists.etherlab.org/pipermail/etherlab-dev/2014/000377.html">http://lists.etherlab.org/pipermail/etherlab-dev/2014/000377.html</a>, in which I mentioned CoE problem in 3 scenarios, while scenario 2 and 3 describe when concurrent CoE requests happens.<br>
<br></div>The slave's CoE FSM instance is not controlled by the master FSM, but by the slave FSM itself. The slave FSM is responsible for the CoE requests in ec_slave_t issued directly by the user via the function ecrt_master_sdo_download, ecrt_master_sdo_download_complete, and ecrt_master_sdo_upload. These functions can be executed either in the user application before the master's activation, or in the terminal in whatever time.<br>
<br></div>The master's CoE FSM instance, on the other hand, is responsible for the CoE requests which should executed in the background by the master FSM, such as automatically fetch slaves' coe dictionary while master is idle, those in the slave->config->sdo_requests, which could be issued via the ecrt_slave_config_sdo functions (which should be configured during the master's activation), or via the function ecrt_slave_config_create_sdo_request (which can be issued afterwards in the user application's RT thread)<br>
<br></div>This made me to believe that the slave could support concurrent CoE requests, but Gavin corrects my thought, as this is actually dependent upon the slave's implementation. So this seems to be another problem we need to fix on the master's side.<br>
<div><div><br></div><div>Regards,<br>Jun<br></div><div><div><div><div><div class="gmail_extra"><br><br><div class="gmail_quote">On 30 June 2014 08:22, Knud Baastrup <span dir="ltr"><<a href="mailto:kba@deif.com" target="_blank">kba@deif.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">Hi Gavin, Jun<br>
<br>
I am still not able to identify a scenario where the EtherCAT master use concurrent CoE requests towards the same slave. I know that both master and slave FSM have CoE FSM instances, but their usage are controlled by the master FSM in dedicated states that should prevent concurrent access. Do any of you have any likely concrete scenario this can happen?<br>
<br>
I believe it is fair to say that an EtherCAT slave only should support a mailbox queue if it wants to support multiple mailbox protocols and that the master always should secure only one running/active instance of a CoE/EoE/SoE/VoE/FoE FSM per slave. I will find it very difficult/impossible to support e.g. multiple instances of an EoE FSM for the same slave as it would be impossible to dispatch the asynchronous replies to the right EoE FSM.<br>
<br>
If it is possible to identify a scenario with concurrent CoE requests towards the same slave, I hope it is a bug that can be fixed within the current design of the EtherCAT master.<br>
<br>
BR, Knud<br>
<div class="im"><br>
<br>
-----Original Message-----<br>
From: Gavin Lambert [mailto:<a href="mailto:gavinl@compacsort.com">gavinl@compacsort.com</a>]<br>
</div><div class="im">Sent: 30. juni 2014 02:11<br>
To: 'Jun Yuan'<br>
Cc: Knud Baastrup; <a href="mailto:etherlab-dev@etherlab.org">etherlab-dev@etherlab.org</a><br>
Subject: RE: [etherlab-dev] Support for multiple mailbox protocols<br>
<br>
</div><div class=""><div class="h5">On 28 June 2014, quoth Jun Yuan:<br>
> 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 the<br>
> last mailbox request, before another mailbox request is able to send?<br>
> I didn't find the answer in the ethercat documentation yet.<br>
<br>
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>
</div></div></blockquote></div><br></div></div></div></div></div></div></div>