CompactCom B40 EtherCAT ESI Generator error

We are working to add support to EtherCAT protocol/module in our product. This is the fifth and last one; Profibus DP-V1, Profinet IRT, Ethernet Powerlink and EtherNet/IP are pretty much done, so major data structures are already in place and working.

EtherCAT is not far off. However, when I try to use ESI Generator I get the following error:

This 0x212F object belongs to the manufacturer specific range, of course. In order to isolate this issue I tried to reduce the size of my APPL_asAdiEntryList[]. But even with that, the software keeps stopping at that point, indicating the problem is elsewhere.

What am I missing?

Thanks in advance,

Hi @lsilva ,

I don’t recognize this error immediately. Can you share your ADI list or check what you have for ADI 0x12F?

What version of the ESI generator tool are you using?

Hello Deryck,

Well, my ADI list is quite long, about 1300 lines. But the relevant part is:

Parameter 0x12F (303d) is ABP_UINT16 type. This specific parameter has a maximum value of 60000, so within the range of this variable.

For testing purposes I have reduced my ADI list to only ten parameters, but the ESI Generator still keeps sending telegrams far above that and it stop at the same point with the same error. Wireshark logs did not provide me valuable information. By the way, HMS IPconfig does not work/recognize this EtherCAT. I may be doing something wrong in the header file configuration.

Regarding the version, I am using very latest,

Hello @lsilva,

Sfor the delay I have opened a support case on to help look into this.

I can’t seem to find a way to recreate the issue. Are you removing that ADI when you limit it to 10? I am trying to determine if it is that unique ADI causing the issue.

IPconfig does not work with EtherCAT without EOE enabled. EOE is typically not used. Here is a doc for setting up EOE.
Basic setup for EoE with an M40.docx (104.1 KB)

Hello Deryck,

Thank you very much for forwarding this question to HMS support.

Concerning the ADI, I have removed it from the array APPL_asAdiEntryList[] only. I thought the ESI Generator would scan the content of this array in order to build the xml. But that doesn’t seem the case. The software keeps sending telegrams no matter the content of this array. So, in the end, I am unable to isolate the problem.

Will continue investigating this issue, and let you know if I find something. Maybe HMS support will come up with some ideas.

Best Regards,

Perhaps there is an issue with the data and not the ADI itself.

What version of the host application and driver do you have?
Enabling debug messages should show us what is going on. If you have 3.08 of the starter kit or later enable the ABCC_CFG_DEBUG_MESSAGING and get a log from power up until it crashes. If you have an older version enable ABCC_CFG_DEBUG_MESSAGING. If you can share this with us we should be able to spot the issue in there.

Hi Deryck,

I am using Starter Kit version 3.08.01, probably it’s the latest. Debugging this device (an accessory board connected to another main board) is a pain in the back; never managed to get Segger RTT working on it. In the main board I used it. So, I have to rely on breakpoints and few gpio’s and leds.

Anyway, I found the issue. Problem was in the size of the messages.

#define ABCC_CFG_MAX_MSG_SIZE ( 1524 )// was 255

For compatibility reason I had change it to 255 bytes couple of months ago. Now I set it to 1524 bytes (which is the default for ABCC 40), and ESI Generator did not complain at that point anymore.

There is, however, one sticking point. At the end of the process I get the following error:

This is to be much simpler. Do you happen to have any idea of what is the cause?

Best Regards,

Hello Gents,

Any idea of could cause this problem in the XML generator?

I have been playing around with TwinCAT 3 this week. I’ve managed to put the module to communicate with the controller. Both PDO/cyclic and SDO/acyclic messages are successfully exchanged between both devices. TwinCAT read all ADIs, presenting the long list of parameters available in my device. This is the same behaviour I was expecting from to see/to be generated in a XML file.


To sum up, I have a functional EtherCAT accessory exchanging data with the TwinCAT, but no XML yet.

Best Regards,

To close the loop for anyone that comes across this post in the future, since this ended up being handled in a support case.
The error mentions an issue with a 0x00 and was likely cause by something not copied correctly and most likely a 0x00 in a sting.
A C-style text string should be null-terminated, and our code should use a ‘strlen()’ to get the size of all strings before they are copied into the MSG response buffer, but if a change was made altering this there could be an issue. Such as a hard-coded size or similar, you might be copying not only the string but also the terminating null, which might make it through to the network, and cause the generator to fail?

found a #define was setting a string incorrectly for the device name.

1 Like