[etherlab-users] CoE mailbox problem: "Received unknown response while uploading SDO"

Frank Heckenbach f.heckenbach at fh-soft.de
Thu Jun 5 17:02:07 CEST 2014

Jun Yuan wrote:

> The CoE mailbox communication between the master and slave is like the
> following:
> 1) the master sends a request datagram to the slave, and receives the
> acknowledge from the slave;
> 2) the master sends a mailbox check datagram to the slave, asking if the
> slave has a reply mail prepared for him;
> 3) If the slave says no, go to 2) send another check datagram; otherwise,
> go to 4);
> 4) the master sends a fetch-response datagram to fetch the reply mail from
> the slave.
> 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 interrupted/stopped and later be reset to START
> state. And this causes the problem.

I had similar issues and I fixed them. I now sent my patches (a bit
late, sorry) to etherlab-dev. I hope they'll help with your problems
as well. (However, my patches are against 1.5.0, so if you need
1.5.1 or 1.5.2 you may need to port them or wait for someone else to
do it.)

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

Looks like the issue from my patch #26.

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

These more general questions are the focus of my bigger patches
(in particular #09-#15 and #27). Those should also fix (hopefully)
the issues you mentioned in another mail ("BUG in the mailbox

> Without answering the questions above, I find the following possible
> solutions:
> 1) 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?

What I do in #26 is to just fetch the mailbox and ignore the result
(success or error).

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

I haven't looked at your patch, but if the reply is meant for some
other part of the code and you just throw it away, there will be
side effects. ;) Therefore I use internal buffers to dispatch the
replies, see my patches.


Dipl.-Math. Frank Heckenbach <f.heckenbach at fh-soft.de>
Stubenlohstr. 6, 91052 Erlangen, Germany, +49-9131-21359
Systems Programming, Software Development, IT Consulting

More information about the Etherlab-users mailing list