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