[Etherlab-dev] Ethercat mailbox gateway and TwinSAFE loader issues

Graeme Foot Graeme.Foot at touchcut.com
Tue Mar 30 01:25:29 CEST 2021


Hi Mark,

The mbg readme has the following note:
  The Mailbox Header has a Cnt parameter (bits 5-7 of the last byte
  of the header).  If this value is zero the slave should always
  accept the incoming mailbox request.  If the value is non-zero (1-7)
  then the slave will only accept the request if the value is different
  to the previous mailbox request Cnt value.

(I can’t dig up where I got this information at the moment.)

Comparing the logs the Cnt values sent by the TwinSAFE Loader are the same in both cases.  However the Cnt value responses from the device 1001 differ.  In the TwinCAT side the sent Cnt value does not clash with the slaves internal Cnt value, whereas on the etherlab mbg side it does.

i.e. the 1001 response reply for the el side is:
2 -> 1
3 -> 2
...
3 -> timeout

So I suspect the slaves internal Cnt value is 3, so on receiving a request with 3 means it thinks it’s a duplicate and is ignored.  So it looks like it is bad luck.  It looks like TwinCAT has previously communicated with device 1001 so it’s count is misaligned enough not to have a problem.

You could do a trial on the TwinCAT side by sending approx. 5 CoE mailbox calls to the 1001 device so that it’s internal counter is the same as the etherlab mbg start condition and see how TwinCAT deals with the problem (you could log the EtherCAT slave network with Wire Shark.)  It’s also possible TwinCAT just internally sends a cnt value of 0.

You could also check you’ve got the latest TwinSAFE loader.  The latest version might have its own retry built in (or not).


Regards,
Graeme.

From: Etherlab-dev <etherlab-dev-bounces at etherlab.org> On Behalf Of Mark Verrijt
Sent: Saturday, 27 March 2021 5:13 am
To: etherlab-dev at etherlab.org
Subject: [Etherlab-dev] Ethercat mailbox gateway and TwinSAFE loader issues

Hi,

We ran into some problems using ethercat_mbg together with the TwinSAFE loader and found some stuff that may be of interest to others aswell:

This setup does work:
0  0:0  PREOP  +  EK1100
1  0:1  PREOP  +  EL6910, TwinSAFE PLC
while this setup does NOT work (fails with a timeout when using loader with --list):
0  0:0  PREOP  +  EK1100
1  0:1  PREOP  +  EL6910, TwinSAFE PLC
2  0:2  PREOP  +  EK1110 EtherCAT-Verl�ngerung

I checked what was happening with wireshark when using the twincat master+mbg, and compared it to what I saw whilst using the ethercat master+mbg for etherlab.

1. With twincat I see that when a request is done to the master via the mbg it responds with a Cnt value (bits [4-6] of last byte of the mailbox header) of 0. With etherlab mbg this value is increasing with each next message, which also seems to be fine. I could not find in the spec Graeme used (https://www.ethercat.org/memberarea/download/ETG8200_V1i0i0_G_R_MailboxGateway.pdf) what it should do.

2. When a request is done to the master via the mbg a response shorter than 16 bytes will be zero padded to make it equal to 16 bytes with twincat mbg, etherlab mbg simply sends a shorter message, which also seems to be fine.

3. A difference of more importance: There is a discrepancy between the way the Cnt value is updated for the two different master+mbg combinations. In some situations this causes a timeout because the request Cnt (coming from the loader) is equal to the slave Cnt value, which the slave will ignore and thus a timeout occurs. I have added the raw data tracing for both the master+mbg combinations if anybody is interested.
I'm not quite sure where to properly fix this, and am thus asking for some advice/help.

For now I made a retry work-around in the CommandMbg class which simply retires once with a different Cnt value in the request (Cnt-1 and wrapped to 1-7) which "solves" the problem. I have attached it as a patch.

I myself would like a clean fix however. If somebody could point me in the right direction I would be grateful.

Kind regards,
Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.etherlab.org/pipermail/etherlab-dev/attachments/20210329/0a7489a1/attachment.htm>


More information about the Etherlab-dev mailing list