[etherlab-dev] Support for multiple mailbox protocols

[Jun Yuan]

Hi Gavin,

thanks for the reply. It's very helpful.

It sounds that,
1) The master can send max. only one mailbox request in one cycle.
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.
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.
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.

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.

Regards,
Jun



On 30 June 2014 02:11, Gavin Lambert <gavinl at compacsort.com> wrote:

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


-- 
Jun Yuan
[Aussprache: Djün Üän]

Robotics Technology Leaders GmbH
Am Loferfeld 58, D-81249 München
Tel: +49 89 189 0465 24
Fax: +49 89 189 0465 11
mailto: j.yuan at rtleaders.com

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ü.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.etherlab.org/pipermail/etherlab-dev/attachments/20140630/ab5c2cad/attachment.html>