Welcome to KickCAT Discussions!

[leducp]

👋 Welcome!

We’re using Discussions as a place to connect with other members of our community. We hope that you:

• Ask questions you’re wondering about.
• Share ideas.
• Engage with other community members.
• Welcome others and are open-minded. Remember that this is a community we
  build together 💪.

To get started, comment below with an introduction of yourself and tell us about what you do with this community.

[kopecn]

@leducp, Fantastic work here, really appreciate the effort!

Just to confirm (and to leave a trail for others who might be wondering the same). If someone is using this SubDevice code alongside a commercial EtherCAT Slave Controller (ESC) chip, then the licensing from the ETG is effectively covered because the EtherCAT license is embedded in the chip itself, correct?

From what I’ve gathered, that seems to be the case per the ETG’s guidance:

• https://www.ethercat.org/en/faq.html#795
• https://www.ethercat.org/en/faq.html#789
• https://www.ethercat.org/download/documents/ESC_Overview.pdf

So, for folks looking to implement a SubDevice using this code and a licensed ESC, they should be in the clear licensing-wise, assuming they also follow proper Vendor ID usage and ETG membership terms?

Appreciate any confirmation or clarification you can offer here.

Nick

[leducp]

You are right: the license is associated with the ESC chip so there is no additional costs (nor licensing management).

However, if you plan to sell an EtherCAT SubDevice as a product, I strongly recommend to pass the conformance validation at least internally with the CTT (Conformance Test Tool), and maybe officially through a dedicated center (it is not really expensive).
The stack in itself can pass the conformance test, but it really depends on its setup. Specifically the CoE dictionary can be tricky to handle without a tool to ensure the EtherCAT compliance.

Philippe