[etherlab-dev] Support for multiple mailbox protocols

[Knud Baastrup]

Hi Gavin, Jun

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?

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. 

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, Knud


-----Original Message-----
From: Gavin Lambert [mailto:gavinl at compacsort.com] 
Sent: 30. juni 2014 02:11
To: 'Jun Yuan'
Cc: Knud Baastrup; etherlab-dev at etherlab.org
Subject: RE: [etherlab-dev] Support for multiple mailbox protocols

On 28 June 2014, quoth Jun Yuan:
> Are you sure that some slaves will choke with multiple CoE requests?
> Does these slaves then support simultaneous mailbox requests in 
> different protocol, i.e. CoE and EoE, or CoE and SoE in parallel?
> Do we always need to wait until the slave have a response mail for the 
> last mailbox request, before another mailbox request is able to send? 
> I didn't find the answer in the ethercat documentation yet.

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.

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).

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.

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.

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).

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.

But no, I can't point to anything concrete in the standards.  This is mostly just a feeling, partly based on slave example code.

Regards,
Gavin Lambert