AM6421: Ethernet/IP Connection failure

Hi Kai,

does your Forward-Open contain configuration, if yes, are you using EI_API_CIP_setCfgAssemblyCb to register a callback? Is the callback called?

Best regards,
Pourya

Hello Pourya,

Yes, we use the callback for the cfg assembly, but I cannot say if this is called or not because we cannot reproduce the issue.

Is the retun value of this callback used to set extended status code 0x129 in the stack?

BR

Kai

Hi Kai,

yes, one of the possibilities that may lead to this error is, when the return value of your callback is non-zero. Other possibility is, when the path is actually not found (which shouldn't be the case for you). 

If you could somehow reproduce it and found out that in this erroneous state your callback is not called or called but return value is correct, let me know, that might mean something else is the root cause.

Best regards,
Pourya

Hi Poury, thanks for your answer. Because we can reproduce the issue only at customer site but nur in-house we are currently acting on a level of code reading. 
In this context we have one question: Is it possible, the the ForwardOpenCB is called from a different thread context than the ForwardCloseCB?
I am asking because close and open works on a "connectionlist" in our code which is possibly not threadsafe if the callbacks are called by different threads.

Hi Matthias,

the ForwardOpen/ForwardClose callback are both called from the same thread. But the callback I mentioned was not about your registered ForwardOpen/ForwardClose callback, it was about configuration callback when your ForwardOpen contain configuration parameter(s).

Best regards,
Pourya

Hi Pourya,
thanks for answering. Which callback do you mean with the configuration callback?

Hi Matthias,

I meant the callback you have registered via EI_API_CIP_setCfgAssemblyCb.

Best regards,
Pourya

Hello Pourya,

finally, we are able to reproduce the issue now. Our customer sent a configuration that does not differ in size, but in settings for our device.
This seems to trigger the issue sometimes (about 18 to 50 configuration iterations). We also have a wireshark log now showing the error.
It seems that the answer to a "Forward Open" usually takes about 200ms. In the error case it takes much longer, 2 - 3 seconds. So our guess right now is that there might be some timeout, maybe when transferring data to the application core.

We will now add traces to the R5 binary to verify that the callbacks are still called in the error case, e.g. EI_API_CIP_setCfgAssemblyCb. And if that is the case, to identify where the issue might be located in our code.

Thanks for your help,

Sascha

Hi Sascha,

OK, let me know about your findings.

Best regards,
Pourya