<div dir="ltr"><div><div>Hello,<br><br></div>Gavin has mentioned the problem he has with the 0x1C1x:00, which makes me to believe I may be not the single victim of that. BTW, has anyone tried the Etherlabmaster on Ubuntu 14.04? As I turn the debug level of the etherlabmaster to 1, the crash report program Apport always jumps out, saying he observed a crash. Weird because there is no crash, but only several DEBUG messages. This is resolved when I misspell the DEBUG as DEBUH in the master source code. I think Apport parses the kernel log message and takes DEBUG as a BUG.<br>
<br>The CoE mailbox communication between the master and slave is like the following:<br></div><div>1) the master sends a request datagram to the slave, and receives the acknowledge from the slave;<br></div><div>2) the master sends a mailbox check datagram to the slave, asking if the slave has a reply mail prepared for him;<br>
</div><div>3) If the slave says no, go to 2) send another check datagram; otherwise, go to 4);<br></div><div>4) the master sends a fetch-response datagram to fetch the reply mail from the slave.<br></div><div><br></div><div>
The problem I discovered with the etherlabmaster is, when the bus topology changes and a bus rescan is required, the state machine of the CoE mailbox communication will be <span>interrupted</span>/stopped and later be reset to START state. And this causes the problem.<br>
<br></div><div>Take an example, the master sends a request A to the slave, and the slave acknowledges, and prepares the reply A, which takes a while. At that time we attach a new slave to the bus, the bus topology changes, which stops the CoE mailbox communication. No the master scans the bus, and begins to use CoE mailbox to fetch the SDO 1C12:00 for SM2 of the slave. He sends the request, then checks the mailbox and find a reply mail. He fetches the mail from the slave, opens it and it's the reply A, not the reply for the SDO 1C12:00 which he's waiting for.<br>
<br></div><div>At this time the master gets angry, saying "Received unknown response while uploading SDO". He throws the reply A away, and never asks again for SM2. It is buggy.<br><br></div><div>Then he send the request for SM3, the SDO 1C13:00. And no surprise, he receives the reply for SM2. Only this time, he says "Received upload response for wrong SDO", and rechecks the mailbox. Yes, there is another reply there, which is correct for the SM3.<br>
<br></div><div>The consequent: "Failed to read number of assigned PDOs for SM2", and the slave cannot turn on without a PDO assignment. <br><br></div><div>I don't know why, but it seems this phenomenon happens more often in a star bus topology than in a line topology.<br>
<br></div><div>Whose fault is this? Is it the slave who stores an outdated reply in the mailbox? Is it the master who forgets his last pending request A, and complains that he receives reply A during the next request? What if the master get a reboot, and there's no way for him to remember the last request?<br>
<br></div><div>Is there any command in the EtherCAT standard for the master to ask the slaves to clear their mailbox? Why doesn't the mail have any id, so the master can tell which reply is for which request? Is simultaneous multiple request allowed?<br>
<br></div><div>What should the master do when he receives a wrong reply from the slave? How can it tell whether it is a wrong reply or a outdated reply for the last request?<br></div><div><br></div><div>Another thing: why does the master not zero the mail data? Is it only for the performance issue? It is so weird to read the chaos data in the mail request datagram.<br>
</div><div><br></div><div>Without answering the questions above, I find the following possible solutions:<br>1)<span> Before send the request datagram, send a check datagram at first to see if there is any outdated response there, and clean it if it exists. But what if the slave finishes the old response after the check datagram? <br>
<br></span></div><div><span>2) If the master receives a wrong reply, instead of giving up and returning an error, he keeps checking until timeout. That's what I did in my patch, but is there any side effects?<br>
<br></span></div><div><span>Regards,<br></span></div><div><span>Jun<br></span></div></div>