<div dir="ltr">Looking at the raw data again (I cannot access my setup until tomorrow), my previous statement:<br><br><i>I would currently put my money on twincat internally sending a counter of 0 over the slave network even<br>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><br><br>is incorrect; I miscounted. Hopefully, the results of the tests you suggested will get me back on track. <br><div><i></i></div></div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Mar 30, 2021 at 9:54 AM Mark Verrijt <<a href="mailto:mark.verrijt@vectioneer.com" target="_blank">mark.verrijt@vectioneer.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Graeme,<br>
<br>
Thanks for the info & suggestions.<br>
We are using the latest loader, so apparently no retry mechanism there.<br>
<br>
In light of your info/suggestions I would currently put my money on<br>
twincat internally sending a counter of 0 over the slave network even<br>
if it is a request designated for the master. If this is the case for<br>
twincat the 1001 slave counter would be at 3. I will check this<br>
a.s.a.p. with wireshark to verify (or find out it is something else).<br>
Either way, I will report back with the results.<br>
<br>
Regards,<br>
Mark<br>
<br>
On Tue, Mar 30, 2021 at 1:25 AM Graeme Foot <<a href="mailto:Graeme.Foot@touchcut.com" target="_blank">Graeme.Foot@touchcut.com</a>> wrote:<br>
><br>
> Hi Mark,<br>
><br>
><br>
><br>
> The mbg readme has the following note:<br>
><br>
>   The Mailbox Header has a Cnt parameter (bits 5-7 of the last byte<br>
><br>
>   of the header).  If this value is zero the slave should always<br>
><br>
>   accept the incoming mailbox request.  If the value is non-zero (1-7)<br>
><br>
>   then the slave will only accept the request if the value is different<br>
><br>
>   to the previous mailbox request Cnt value.<br>
><br>
><br>
><br>
> (I can’t dig up where I got this information at the moment.)<br>
><br>
><br>
><br>
> 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.<br>
><br>
><br>
><br>
> i.e. the 1001 response reply for the el side is:<br>
><br>
> 2 -> 1<br>
><br>
> 3 -> 2<br>
><br>
> ...<br>
><br>
> 3 -> timeout<br>
><br>
><br>
><br>
> 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.<br>
><br>
><br>
><br>
> 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.<br>
><br>
><br>
><br>
> You could also check you’ve got the latest TwinSAFE loader.  The latest version might have its own retry built in (or not).<br>
><br>
><br>
><br>
><br>
><br>
> Regards,<br>
><br>
> Graeme.<br>
><br>
><br>
><br>
> From: Etherlab-dev <<a href="mailto:etherlab-dev-bounces@etherlab.org" target="_blank">etherlab-dev-bounces@etherlab.org</a>> On Behalf Of Mark Verrijt<br>
> Sent: Saturday, 27 March 2021 5:13 am<br>
> To: <a href="mailto:etherlab-dev@etherlab.org" target="_blank">etherlab-dev@etherlab.org</a><br>
> Subject: [Etherlab-dev] Ethercat mailbox gateway and TwinSAFE loader issues<br>
><br>
><br>
><br>
> Hi,<br>
><br>
> 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:<br>
><br>
> This setup does work:<br>
> 0  0:0  PREOP  +  EK1100<br>
> 1  0:1  PREOP  +  EL6910, TwinSAFE PLC<br>
> while this setup does NOT work (fails with a timeout when using loader with --list):<br>
> 0  0:0  PREOP  +  EK1100<br>
> 1  0:1  PREOP  +  EL6910, TwinSAFE PLC<br>
> 2  0:2  PREOP  +  EK1110 EtherCAT-Verl�ngerung<br>
><br>
> 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.<br>
><br>
> 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 (<a href="https://www.ethercat.org/memberarea/download/ETG8200_V1i0i0_G_R_MailboxGateway.pdf" rel="noreferrer" target="_blank">https://www.ethercat.org/memberarea/download/ETG8200_V1i0i0_G_R_MailboxGateway.pdf</a>) what it should do.<br>
><br>
> 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.<br>
><br>
> 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.<br>
><br>
> I'm not quite sure where to properly fix this, and am thus asking for some advice/help.<br>
><br>
><br>
><br>
> 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.<br>
><br>
><br>
><br>
> I myself would like a clean fix however. If somebody could point me in the right direction I would be grateful.<br>
><br>
><br>
><br>
> Kind regards,<br>
><br>
> Mark<br>
</blockquote></div>