<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=us-ascii"><meta name=Generator content="Microsoft Word 12 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-NZ link=blue vlink=purple><div class=WordSection1><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>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).<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>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.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>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.)<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>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.)<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>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 <b>unless</b> some other CoE request is in progress, or until the next request is made, which also seems wrong.)<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>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.)<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>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.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><div style='border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt'><div><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm'><p class=MsoNormal><b><span lang=EN-US style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span lang=EN-US style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> Jeroen Van den Keybus [mailto:jeroen.vandenkeybus@gmail.com] <br><b>Sent:</b> Wednesday, 20 November 2013 09:52<br><b>To:</b> Gavin Lambert<br><b>Cc:</b> etherlab-dev@etherlab.org<br><b>Subject:</b> Re: [etherlab-dev] Mailbox handling of interleaving responses<o:p></o:p></span></p></div></div><p class=MsoNormal><o:p> </o:p></p><div><div><div><div><p class=MsoNormal>Dear Gavin,<o:p></o:p></p></div><div><p class=MsoNormal> <o:p></o:p></p></div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm'><p class=MsoNormal style='margin-bottom:12.0pt'>I think a more robust solution would be to always scan for and fetch data<br>out of the slave->master mailbox, and then queue these to the appropriate<br>protocol-specific FSM to handle as they arrive, according to the type<br>specified in the data itself (so that while FoE was waiting for a response<br>it could successfully process a CoE or EoE response, for example).<o:p></o:p></p></blockquote><div><p class=MsoNormal><o:p> </o:p></p></div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm'><p class=MsoNormal style='margin-bottom:12.0pt'><br>Does that make sense, or have I missed something?<o:p></o:p></p></blockquote><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>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).<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>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.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>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.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>J.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div></div></div></div></div></div></body></html>