[etherlab-dev] Mailbox handling of interleaving responses

[Gavin Lambert]

Well, I don't know if it's typical of "real" slaves, but the example slave
code certainly appears (via code inspection) capable of unsolicited posts to
the mailbox, in particular for CoE emergencies.  I haven't checked EoE
specifically but it certainly seems like the sort of thing that ought to be
able to generate unsolicited posts.  And certainly any of the services can
produce delayed responses, during which waiting time it could be possible to
complete a different service request (though it's possible some slaves might
not support this, and it's likely parallel requests would always have to be
for different service types).

 

There are also provisions for multi-fragment responses for all the service
types.  I haven't checked further whether multiple replies can normally be
generated without master action but the slave code seems capable of tracking
and posting (in arbitrary order) queued messages from multiple services to
the mailbox whenever it gets released by a read from the master.

 

I'm fairly certain that the standard specifies that you're only supposed to
have two mailboxes, one for outgoing messages and one for incoming ones; not
one per service type.  (I think it also specifies that they're optional, but
when they exist they're required to be on SM 0 and 1.)

 

In any case, I brought up this topic in the hope that Florian would have a
look at it - even if the master doesn't go to the extent of interleaving
requests itself, I do think that it's a bug if it can't cope with receiving
interleaved responses from slaves.  It's possible that this could be an
explanation for some of the EoE issues that people have been reporting from
time to time.  (I don't use EoE myself so I can't confirm or deny.)

 

It's notable that the CoE state machine appears to be littered with checks
for "wait, was that reply unexpectedly an emergency response", which
suggests that these at least are asynchronous - but I'm not sure that this
behaviour is correct as it stands either, as a CoE emergency could be sent
just after the master posted an FoE or EoE message, for example, and in this
case it looks like it will be discarded, as I mentioned in my original
email.  (It also looks like it won't pick up emergencies unless some other
CoE request is in progress, or until the next request is made, which also
seems wrong.)

 

I must admit that I haven't looked too closely at the datagram-level parts
of the standards, so I don't know if there's an easier way to ask the
network if there's a slave with something in their mailbox short of
individually polling every slave.  Though I think there's supposed to be
some sort of network-based interrupt mechanism for per-slave events, related
to slave registers 0x0200/0x0210.  (Appears to be related to the bit that
you mentioned too.)

 

But I think that's what's needed - some sort of central dispatch that's in
charge of detecting (ideally via the normal domain datagram) and fetching
mailbox data from all slaves and then posting it to the appropriate
slave+service FSM, rather than leaving it up to the individual service FSMs
to explicitly post datagrams to check and read data.

 

From: Jeroen Van den Keybus [mailto:jeroen.vandenkeybus at gmail.com] 
Sent: Wednesday, 20 November 2013 09:52
To: Gavin Lambert
Cc: etherlab-dev at etherlab.org
Subject: Re: [etherlab-dev] Mailbox handling of interleaving responses

 

Dear Gavin,

 

I think a more robust solution would be to always scan for and fetch data
out of the slave->master mailbox, and then queue these to the appropriate
protocol-specific FSM to handle as they arrive, according to the type
specified in the data itself (so that while FoE was waiting for a response
it could successfully process a CoE or EoE response, for example).

 


Does that make sense, or have I missed something?

 

I think it does. Incidentally, the Ethercat standard specifies to use the
Sync Manager (SM) write flag (SM offset 0x5 bit 0) for precisely that (or
try to read the buffer and observe the WKC).

 

But I also think that any protocol available in slaves (...oE) does not post
into the mailbox on its own initiative. Therefore, if the master does not
initiate any EoE, it should not fear encountering EoE traffic. Keeps things
simple, especially at the slave side.

 

To make matters more complicated, I have long lived in the belief that a
mailbox (sync manager) pair was needed per type of mailbox. The standard is
inconveniently unclear about that kind of details. But I found not a single
example of a multi-mailbox configuration.

 

 

J.

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.etherlab.org/pipermail/etherlab-dev/attachments/20131120/b167818c/attachment.html>