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.vandenkey...@gmail.com] Sent: Wednesday, 20 November 2013 09:52 To: Gavin Lambert Cc: etherlab-dev@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.
_______________________________________________ etherlab-dev mailing list etherlab-dev@etherlab.org http://lists.etherlab.org/mailman/listinfo/etherlab-dev