<div dir="ltr">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">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><div>I'm not quite sure where to properly fix this, and am thus asking for some advice/help. <br></div><div><br></div><div>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></div><div><br></div><div>I myself would like a clean fix however. If somebody could point me in the right direction I would be grateful. </div><br><div>Kind regards,</div><div>Mark</div></div>