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

[Mark Verrijt]

Looking at the raw data again (I cannot access my setup until tomorrow), my
previous statement:


*I would currently put my money on twincat internally sending a counter of
0 over the slave network evenif it is a request designated for the master.
If this is the case for twincat the 1001 slave counter would be at 3.*

is incorrect; I miscounted. Hopefully, the results of the tests you
suggested will get me back on track.


On Tue, Mar 30, 2021 at 9:54 AM Mark Verrijt <mark.verrijt at vectioneer.com>
wrote:

> Hi Graeme,
>
> Thanks for the info & suggestions.
> We are using the latest loader, so apparently no retry mechanism there.
>
> In light of your info/suggestions I would currently put my money on
> twincat internally sending a counter of 0 over the slave network even
> if it is a request designated for the master. If this is the case for
> twincat the 1001 slave counter would be at 3. I will check this
> a.s.a.p. with wireshark to verify (or find out it is something else).
> Either way, I will report back with the results.
>
> Regards,
> Mark
>
> On Tue, Mar 30, 2021 at 1:25 AM Graeme Foot <Graeme.Foot at touchcut.com>
> wrote:
> >
> > 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/20210330/8bff61b5/attachment-0001.htm>