Device with no Dictionary and no full Assignment Object

[phamnhatha090805]

Hi sir,
I'm trying to use KickCAT to simulate the Beckhoff EtherCAT modules. In this case it's the EL1004.
Unlike some other devices, this ESI files provide PDO information through TxPdo sections but do not contain a complete CoE dictionary. Because of this the flag is_mapped will never be set to TRUE.
I don't know if you gus are already awared of this.

[leducp]

I'm not aware of this bug no. Can you send me the EL1004 ESI and the way you are currently using it so I can have a look?

[phamnhatha090805]

I'm not aware of this bug no. Can you send me the EL1004 ESI and the way you are currently using it so I can have a look?

Sure. Attached is the EL1xxx ESI XML file. The EL1004 section is representative of the issue I'm seeing.
The EL1004 only defines Fixed TxPDO mappings and does not provide a complete CoE object dictionary with the corresponding PDO entries. In my use case with KickCAT, I need to access the PDO data of each virtual slave through the CoE dictionary. However, because the ESI only contains the fixed PDO mapping information, KickCAT is currently unable to create the corresponding PDO entries in its object dictionary, which prevents PDO access and mapping.

Beckhoff EL1xxx.xml

[phamnhatha090805]

Hi,
I'm testing the recent ESI parser changes from PR #398 and trying to simulate a Beckhoff EL1004 terminal using the network simulator
Setup: I run the KickCAT on the Rasp Pi and I pass 2 EtherCAT device to the network_simulator EK1100 (EtherCAT bus coupler) -> EL1004

The problem is that the entry remains: <is_mapped = false> for the entire runtime even the TwinCAT showing all devices move to OP state.
Is there currently any limitation in the new ESI-generated dictionary path for terminals such as EL1004 that only define PDOs in the ESI?
Should the generated PDO target objects (0x6000, 0x6010, ...) be marked by PDO::configureMapping() automatically, or is there an additional step required to make these synthesized entries participate in PDO mapping?
Any guidance would be appreciated.

[leducp]

Hi
It is still a work in progress. The last PR is not merged yet (@trns1997 didn't had the time to review it) but this is the one that should parse and populate the dictionary from the PDO section if no dictionary provided by the ESI. Did you try with this one?

[phamnhatha090805]

Hi It is still a work in progress. The last PR is not merged yet (@trns1997 didn't had the time to review it) but this is the one that should parse and populate the dictionary from the PDO section if no dictionary provided by the ESI. Did you try with this one?

To share a bit about what I'm doing. The goal is to simulate EtherCAT slaves using FMU models. KickCAT acts as the EtherCAT slave stack, while a mapping layer synchronizes PDO entries with FMU variables at runtime. This allows TwinCAT to interact with virtual EtherCAT devices whose behavior is defined by simulation models.
While integrating an FMU mapping layer on top of KickCAT, I encountered an issue related to CoE::Entry::is_mapped.
My application needs direct access to the memory location associated with each PDO entry. Therefore I search the CoE dictionary for the entry referenced by a PDO and only use entries whose is_mapped flag is set.
Here is the architecture and the key source files if you're interested because at this point I don't know if the problem is the KickCAT PDO mapping or my mapping. Any suggestion to this etherdog.cpp is super appreciate!
If you are interested in the fully implemented, take a look at https://github.com/phamnhatha090805/etherdog-fmu

etherdog.cpp

[phamnhatha090805]

I think it also good to mention that when you simulate the Beckhoff EL3004 which is the analog input module, it cannot reach SAFEOP or OP state in TwinCAT and TwinCAT reports: Timeout: clear sm pdos (0x1C12). However, this does not happens when you simulate the Beckhoff EL4004 which is the Analog Output module.

One important difference is that EL3004 and EL4004 use opposite PDO directions:
EL3004 is an analog input terminal:

• No RxPDO assignment
• 0x1C12 only has subindex 0 = 0
• TxPDO assignment is in 0x1C13
• 0x1C13 contains assigned TxPDOs such as 0x1A00, 0x1A02, 0x1A04, 0x1A06

EL4004 is an analog output terminal:

• RxPDO assignment is in 0x1C12
• 0x1C12 contains assigned RxPDOs such as 0x1600, 0x1601, 0x1602, 0x1603
• 0x1C13 is empty / subindex 0 only

So I still don't know where is the problem with the EL3004.
To be fair, I feel like every time I try a new Beckhoff module, there's a new problem.

[leducp]

I can understand the frustration: the emulator is mostly experimental feature wise, mainly because I didn't have access to a lot of various hardware and ESI. ESI parser in the other hand was written initially in a rush to support a specific use case on my side: the OD generator for a slave I was developing.

My current main focus is now both of them: I don't expect a 100% full features ESI parser soon as I don't plan to spend too much time on some features that are uncommon, but your current use case IS common so thanks about the sharing.
On the ESC emulator side, I would like to support all SM/FMMUs use cases but I will probably not address complexes features like DC soon.

I'll try to have a look on your problems this weekend and see if I can fix the ESI/OD generator/Emulator for EL3004, EL4004, EL1004, and in general the whole ESI file of Beckhoff ELxxxx series. I think it is a good 'stress test' to have a wide enough support :)

[leducp]

Do you have the ESI for the EL3xxx and EL4xxx so I can add them to my analysis?

[phamnhatha090805]

Do you have the ESI for the EL3xxx and EL4xxx so I can add them to my analysis?

Yes, here is the ESI xml files of the whole EL3xxx series and EL4xxx series which contain the EL3004 & EL4004. You can find all these on Beckhoff website https://www.beckhoff.com/en-us/support/download-finder/
I also uploaded the ESI files that I have been testing to https://github.com/phamnhatha090805/etherdog-fmu in the Examples folder.

Beckhoff EL4xxx.xml
Beckhoff EL30xx.xml

[leducp]

This PRs should unlock you:
#400

I test the stack against the main Beckhoff ESI archive

[phamnhatha090805]

This PRs should unlock you: #400

I test the stack against the main Beckhoff ESI archive

Thanks for the pointer. I tested PR #400 with my EtherDOG/KickCAT setup using Beckhoff ESI files.
The original issue I reported was that some Beckhoff terminals, such as EL1004, only contain Fixed PDO definitions in the ESI and do not provide a complete CoE object dictionary. Because of that, I was unable to access the PDO entries through the dictionary generated by KickCAT.

After testing PR #400, I still observe two issues:

EL1004
The slave reaches OP state in TwinCAT.
However, the PDO entries I resolve from the dictionary never become mapped (is_mapped remains false), so I still cannot access the process data through the dictionary.
In contrast, EL4004 works correctly and its PDO entries become mapped.

EL3004
TwinCAT still reports:
Timeout: clear sm pdos (0x1C12)
The slave does not complete PDO configuration.

For reference, EL4004 works correctly in the same setup and I can see PDO mapping being configured successfully.
Would it be useful if I provide the debug logs?

[phamnhatha090805]

EL1004.log
EL4004.log

This is my log that I have implemented for the etherdog-fmu application. It basically prints out the dictionary of the simulated EL1004/EL4004. And it prints out warning until the device reach OP and configure PDO.
For EL4004, I can see configureMapping() being executed and the PDO entries eventually become mapped. Process data exchange then works as expected.
For EL1004, the slave reaches OP, but I never observe the corresponding PDO entries becoming mapped. The dictionary entries remain with is_mapped == false.
My current suspicion is that there may be a difference in how PDO assignment/mapping is handled for devices using fixed TxPDO definitions (such as EL1004) compared to devices like EL4004. However, I have not yet been able to determine whether the issue is in the ESI parsing stage, PDO assignment handling, or somewhere later in the mapping process.
I also don't see any problem with the LoadMapping() in the etherdog.cpp.

[leducp]

I found the problem about EL1004 is_mapped flag: this slave does not have a mailbox advertised to the master, which means that currently KickCAT does not serve properly the OD to the slave stack so no is_mapped at all. I didn't even knew it was possible to have a CoE slave without a mailbox ^^' (seems that it was common in the past as theses ones are quite old)

Cooking a fix so that the slave will always own a mailbox but not advertised to the master so the OD can be properly served to the slave stack.

[phamnhatha090805]

I found the problem about EL1004 is_mapped flag: this slave does not have a mailbox advertised to the master, which means that currently KickCAT does not serve properly the OD to the slave stack so no is_mapped at all. I didn't even knew it was possible to have a CoE slave without a mailbox ^^' (seems that it was common in the past as theses ones are quite old)

Cooking a fix so that the slave will always own a mailbox but not advertised to the master so the OD can be properly served to the slave stack.

Yep, now I see. Thank you so much, I will test your fix again and give you some feedback results. By the way, do you have any suspicion about the root cause of the Timeout: clear sm pdos (0x1C12) with the EL3004.