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.f...@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-boun...@etherlab.org> On Behalf Of Mark > Verrijt > Sent: Saturday, 27 March 2021 5:13 am > To: etherlab-dev@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 -- Etherlab-dev mailing list Etherlab-dev@etherlab.org https://lists.etherlab.org/mailman/listinfo/etherlab-dev
