One Approach to Implementing EtherCAT on the 4diac Platform

[wzj7531]

1. Preface

First of all, I would like to thank the founding organizations, members, and all contributors of the 4diac project! 4diac is an excellent open-source platform. I have learned a great deal from it, which has been very helpful for my career development.

I am a C# programmer from China who writes host applications for manufacturing companies. In 2024, my manager asked me to learn the 4diac platform because he had been following it for a long time and was very interested in the IEC 61499 standard. Later, we received a project that required building a hardware-in-the-loop simulation platform. We chose 4diac as the foundation for two reasons: it already implements major industrial data acquisition protocols, and its graphical function-block programming feels similar to using Simulink. We implemented it as follows:

• Write an IDE plugin that converts FMU model description files into function blocks
• Extend forte with code to invoke FMUs

After struggling for a while, we got the above working, but simulation turned out to be harder than we expected…

To explore 4diac more deeply, my manager gave me another task: build the main control program and implement Modbus RTU for data acquisition from I/O cards. At first I had no clear direction and could only read the source code, hoping to find answers. After consulting many resources, I found a community Q&A about how forte’s master–slave architecture uses Modbus TCP. I pulled and read that code, and the door to 4diac opened for me:

• Implement MasterConfigFB, SlaveConfigFB, SlaveHandle, BusHandler, and IOHandle in forte’s IO module
• Wrap Modbus RTU over RS485 in the BusHandler

I eventually completed that task, but I became even more curious about 4diac. Although today’s topic is EtherCAT, those two stories already describe the basic approach for implementing EtherCAT:

• Write a 4diac-ide plugin to import ESI files, read Device and Module nodes, and convert them into function blocks
• Write an EtherCAT-based IO module for 4diac-forte

Of course, I ran into many problems during implementation. That is what this article is mainly about.

2. EtherCAT

EtherCAT is inherently master–slave: the master and slaves are connected over Ethernet, as shown below:

In practice, slave devices can also host plug-in modules. A slave with mounted modules is called a coupler:

The coupler and its mounted modules still form a single EtherCAT slave as a whole.

I do not want to go too deep into the EtherCAT protocol itself, because I am not an EtherCAT expert. However, we need to know the following:

1. EtherCAT’s high performance relies on dedicated network adapters and a dedicated network
2. EtherCAT communication is implemented by the master driver; we only need to call its API
3. The EtherCAT Master API lets us register PDOs and read/write slave process data
4. The master exchanges data with slaves by polling; one poll cycle can exchange data with all slaves

So we keep EtherCAT complexity inside the EtherCAT Master driver. Do not unleash that “demon” yourself—focus only on how to use the API it provides.

From here on, we move into concrete implementation work. Before that, a brief note on my development environment: I use a laptop running Ubuntu 22.04. Most 4diac-forte coding is done in VS Code; 4diac-ide development seems to require Eclipse Modeling Tools.

2.1 Building the EtherCAT Master

To use the EtherCAT library, you must build it from the [EtherCAT Master source](https://gitlab.com/etherlab.org/ethercat). For building the library, see the [IgH EtherCAT Master Installation Guide](https://github.com/veysiadn/IgHEtherCATImplementation). Please note:

• It is best to have two network adapters: one for the Internet and one dedicated to EtherCAT
• Connect the PC directly to slaves; do not use a switch between the PC and slave devices

Assuming the build succeeded, run:

sudo ethercatctl start

to start the EtherCAT driver. To check whether the driver started successfully, run:

sudo ethercatctl status

To inspect master information, run:

ethercat master

Below is sample output from the commands above. Your output should look similar:

(base) hyperion@Jarvis:~$ sudo ethercatctl start
Starting EtherCAT master 1.6.7  done
(base) hyperion@Jarvis:~$ sudo ethercatctl status
Checking for EtherCAT master 1.6.7 
Master0  running
(base) hyperion@Jarvis:~$ ethercat master
Master0
  Phase: Idle
  Active: no
  Slaves: 1
  Ethernet devices:
    Main: e0:4e:7a:d1:0b:94 (attached)
      Link: UP
      Tx frames:   111193
      Tx bytes:    6758588
      Rx frames:   111192
      Rx bytes:    6758528
      Tx errors:   0
      Tx frame rate [1/s]:    496    494    483
      Tx rate [KByte/s]:     29.1   29.0   28.4
      Rx frame rate [1/s]:    496    494    483
      Rx rate [KByte/s]:     29.1   29.0   28.4
    Common:
      Tx frames:   111193
      Tx bytes:    6758588
      Rx frames:   111192
      Rx bytes:    6758528
      Lost frames: 0
      Tx frame rate [1/s]:    496    494    483
      Tx rate [KByte/s]:     29.1   29.0   28.4
      Rx frame rate [1/s]:    496    494    483
      Rx rate [KByte/s]:     29.1   29.0   28.4
      Loss rate [1/s]:          0      0      0
      Frame loss [%]:         0.0    0.0    0.0
  Distributed clocks:
    Reference clock:   Slave 0
    DC reference time: 0
    Application time:  0
                       2000-01-01 00:00:00.000000000

Now check how many slaves are connected to the master:

(base) hyperion@Jarvis:~$ ethercat slave
0  0:0  PREOP  +  CN-8033 EtherCAT Adaptor

The output shows one slave named "CN-8033 EtherCAT Adapter". The first 0 is the slave position; 0:0 is alias and position offset; PREOP is the slave state.

Next, inspect the slave’s PDOs:

(base) hyperion@Jarvis:~$ ethercat pdos
SM0: PhysAddr 0x1000, DefaultSize  128, ControlRegister 0x26, Enable 1
SM1: PhysAddr 0x1080, DefaultSize  128, ControlRegister 0x22, Enable 1
SM2: PhysAddr 0x1100, DefaultSize    4, ControlRegister 0x64, Enable 1
  RxPDO 0x1600 "CT-222F"
    PDO entry 0x7001:01,  8 bit, "SubIndex 001"
    PDO entry 0x7001:02,  8 bit, "SubIndex 002"
  RxPDO 0x1601 "CT-4234"
    PDO entry 0x7003:01, 16 bit, ""
    PDO entry 0x7003:02, 16 bit, ""
    PDO entry 0x7003:03, 16 bit, ""
    PDO entry 0x7003:04, 16 bit, ""
SM3: PhysAddr 0x1400, DefaultSize    4, ControlRegister 0x20, Enable 1
  TxPDO 0x1a00 "CT-121F"
    PDO entry 0x6002:01,  8 bit, ""
    PDO entry 0x6002:02,  8 bit, ""
  TxPDO 0x1a01 "CT-4234"
    PDO entry 0x6003:01,  8 bit, ""
  TxPDO 0x1a02 "CT-3238"
    PDO entry 0x6004:01, 16 bit, ""
    PDO entry 0x6004:02, 16 bit, ""
    PDO entry 0x6004:03, 16 bit, ""
    PDO entry 0x6004:04, 16 bit, ""
    PDO entry 0x6004:05, 16 bit, ""
    PDO entry 0x6004:06, 16 bit, ""
    PDO entry 0x6004:07, 16 bit, ""
    PDO entry 0x6004:08, 16 bit, ""

From the PDO listing you can see that CN-8033 hosts four modules: CT-222F, CT-4234, CT-121F, and CT-3238.

2.2 EtherCAT Master API

You can learn how to call the API by reading the examples shipped with the EtherCAT Master. The main points in [examples/user/main.c](https://gitlab.com/etherlab.org/ethercat/-/blob/stable-1.6/examples/user/main.c?ref_type=heads) are:

1. Include ecrt.h; the userspace API and data structures are defined there
2. In main:
   • Call ecrt_request_master to obtain a master, then ecrt_master_create_domain to create a domain
   • Call ecrt_master_slave_config and ecrt_slave_config_pdos for slave and PDO configuration. The example configures four slaves: EL3102, EL4102, EL2032, and EK1100. EK1100 is only a coupler and registers no PDOs
   • Call ecrt_domain_reg_pdo_entry_list to obtain each PDO entry’s offset in the domain
   • Activate the master and start the cyclic process data exchange with slaves
3. You only need to learn the APIs and structures you actually use

Although simple, the code in main.c is the core of our EtherCAT implementation on 4diac.

2.3 EtherCAT Master as a forte Dependency

You can of course build the EtherCAT Master with the same toolchain used for forte and link the resulting static library and headers via CMakeLists.txt. I strongly recommend adding the EtherCAT Master as a forte dependency instead. That greatly simplifies cross-compilation and reduces configuration work—provided you build forte with 4diac-fbe. Add an ethercat recipe under 4diac-fbe/dependencies/recipes:

• Create an ethercat folder under recipes
• Add build.cmake and package.txt inside that folder

Then, whenever EtherCAT IO is enabled, forte’s build will first build ethercat with the same toolchain and use it as a dependency.

3. Adding a Plugin to 4diac-ide

EtherCAT masters and slaves can be wired in several ways. This article covers only the simplest topology, shown below:

To support this kind of configuration, we need the following function blocks and struct types in 4diac-ide:

• ECMaster — master function block
• ECSlave — slave function block
• ECCoupler — coupler function block
• ECModule — module function block
• ECBusAdapter — adapter between master and slaves, and between slaves
• ECSlaveConfig — slave configuration struct

ECMaster, ECBusAdapter, and ECSlaveConfig have fixed interfaces. ECCoupler and ECSlave depend on the specific device (from ESI).

(1) ECMaster — represents the master. Its interface is shown below:

• MasterIndex: master index, default 0
• UpdateInterval: polling interval, default 40 µs
• INIT: triggers master initialization
• REQ: when Enable is true, starts polling; otherwise stops polling

(2) ECBusAdapter — adapter linking master to slaves and slaves to each other. Its interface is shown below:

(3) ECSlaveConfig.dtp — slave configuration struct:

This information is later used by the EtherCAT driver to configure slaves.

3.1 ESI Files

Slave vendors typically ship an ESI (EtherCAT Slave Information) file that describes:

1. Basic device identification

   • Vendor: unique Vendor ID and vendor name
   • Product Code: identifies the hardware product
   • Revision Number: firmware/hardware revision so the master configuration matches the device
   • Name/Descriptions: multilingual device names

2. Process Data Object (PDO) mapping

   • RxPDO: control data sent from master to slave
   • TxPDO: status data sent from slave to master
   • PDO Entry: per-variable Index, SubIndex, data type (e.g. INT, UDINT), and bit length

3. Object Dictionary & SDO

   • DataTypes: vendor-specific composite types and arrays
   • Objects/SDO: application parameters with index, access rights, default values, etc. The master may use these during startup

4. Mailbox & Sync Manager

   • Sync Manager (SM): memory regions; SM0/SM1 often for mailbox, SM2/SM3 for PDO
   • FMMU: maps logical addresses to physical memory and I/O
   • EEPROM image: backup of SII configuration

5. Mailbox protocols

   • Common protocols: CoE (CANopen over EtherCAT), FoE (firmware update), SoE (SERCOS over EtherCAT)
   • Mailbox timeout settings

6. Distributed Clocks (DC)

   • For high-precision motion: sync modes (SM-Synchron, DC-Synchron), Sync0/Sync1 cycle time and shift time

On the IDE side we mainly care about device identification and PDO mapping.

I split the ECSlave and ECModule interfaces into a fixed part:

• EI: MAP
• EO: MAPO
• DI: QI, Config, bus/module adapters
• DO: QO, STATUS, BusAdapterOut, ModuleAdapterOut

The dynamic part is mostly extra DIs: the plugin reads the ESI and maps RxPDO entries to OUT_x and TxPDO entries to IN_x (x = index). The 4diac-ide plugin imports ESI and generates function block types.

(1) Right-click the project Type Library → Import → ESI File Import wizard → Next:

(2) Browse and select the ESI file:

(3) Click Finish. Slave function blocks appear under Type Library:

Inovance is the vendor name. The folder GL_RTU_ECT is a slave category containing the GL20_RTU_ECT coupler and compatible modules.

You can now build the application configuration:

3.2 Generic Function Blocks

Because slave function blocks have a variable number of DIs, we use 4diac’s generic FB mechanism. For example, when forte receives a request to create CLIENT_2_1, it automatically gets two inputs SD_1, SD_2 and one output RD_1. We do not name generated slaves ECSlave_x_y / ECCoupler_x_y / ECModule_x_y; the FB type name should come from the ESI Type attribute so different slaves remain distinguishable. Open GL20_RTU_ECT as text:

I changed some 4diac-ide deployment code: if the Identification node’s Type attribute is non-empty, that value is used as the base class for the generic FB. When the IDE deploys an instance, forte does not create GL20_RTU_ECT directly; it creates something like eclipse::io::ethercat::ECCoupler_0_0.

Here ECCoupler_0_0 means GL20_RTU_ECT is an ECCoupler with no dynamic PDO ports (0 inputs, 0 outputs in the generic suffix). Unlike CLIENT_x_y, for EtherCAT slave generics the generated IN_x and OUT_y are all DIs, because they only carry IO mapping names (WSTRING), not real process I/O pins.

4. Adding an EtherCAT Module to 4diac-forte

We can now add an ethercat module to 4diac-forte. I designed it mainly by following the existing embrick module.

Like embrick, the ethercat module follows forte’s IO layering:

forte IO concept	ethercat implementation	Main responsibility
MasterConfigFB	FORTE_ECMaster	Create bus controller, configure master, propagate INIT via BusAdapter
SlaveConfigFB	FORTE_ECSlave / FORTE_ECCoupler / FORTE_ECModule	Parse slave/module config, register SlaveHandler, MAP event IO binding
BusHandler	ECBusHandler	Wrap IgH EtherCAT Master API, cyclic process data exchange
SlaveHandler	ECDeviceHandler / ECModuleHandler	Process image buffers, input/output handle lists
IOHandle	ECSlaveHandle	Move bytes between domain data and IOMapper, observer notifications

Source code lives under forte/modules/ethercat/:

ethercat/
├── handler/ # ECBusHandler — bus controller
├── slave/ # ECSlaveHandler, ECDeviceHandler, ECModuleHandler, ECSlaveHandle
│ └── model/ # ECDeviceModel — IgH PDO/Sync/EntryReg structures
├── types/ # ECMaster, ECSlave, ECCoupler, ECModule, ECBusAdapter FBs
├── structs/ # ECSlaveConfig, ECModuleConfig struct types
└── utils/ # EsiFileParser — runtime ESI parsing

4.1 Enabling the ethercat Module Build

In 4diac-fbe, enable EtherCAT IO via a configuration file. Example configurations/ethercat.txt:

include=inc/default.txt
DEPS=fmt
DEPS=tinyxml
DEPS=ethercat
IO=ETHERCAT

IO=ETHERCAT enables CMake option FORTE_MODULE_ETHERCAT. DEPS=ethercat builds the IgH EtherCAT Master userspace library via the cget recipe (dependencies/recipes/ethercat/, --disable-kernel, no kernel tree required). tinyxml parses ESI at runtime.

Note: forte links the userspace libethercat, but field communication still requires the EtherCAT kernel master installed and started on the target (ethercatctl start). Both are required.

4.2 ECBusHandler: Bus Controller

ECBusHandler extends IODeviceMultiController and is the core of EtherCAT communication. Its lifecycle has three phases:

(1) init() — request master and domain

mECMaster = ecrt_request_master(mConfig.mECMasterId);
mECDomain = ecrt_master_create_domain(mECMaster);

Only basic IgH resources are allocated; no slaves are configured yet.

(2) prepareLoop() — configure slaves and activate master

After all SlaveConfigFBs finish initialization, runLoop() calls prepareLoop(). It iterates mDevices and for each ECDeviceHandler (skipping ECModule) performs:

1. ecrt_master_slave_config() — match slave by Alias, Position, VendorId, ProductCode
2. ecrt_slave_config_pdos() — apply Sync/PDO from ECDeviceModel
3. ecrt_domain_reg_pdo_entry_list() — register PDO entries; IgH fills domain byte offsets
4. ecrt_master_activate() — activate master (OP state)
5. ecrt_domain_data() — obtain domain process data pointer mECDomainPd

Modules on a coupler (ECModuleHandler) do not call ecrt_master_slave_config separately. Their PDO entries are merged into the parent ECDeviceHandler’s ECDeviceModel and registered as one EtherCAT slave.

(3) runLoop() — cyclic exchange

The main loop uses clock_nanosleep(CLOCK_MONOTONIC, TIMER_ABSTIME, ...). The period is ECMaster.UpdateInterval in microseconds. Each cycle:

ecrt_master_receive()
ecrt_domain_process()
  → for each ECSlaveHandler: update(mECDomainPd)  // domain ↔ slave image buffers
ecrt_domain_queue()
ecrt_master_send()

The Enable input controls real exchange via enableECCycle(). When Enable=false, the loop still advances wake-up time but skips receive/send, pausing polling without tearing down the master.

4.3 ECSlaveHandler Hierarchy

ECSlaveHandler          ← base: image buffers, handle lists, update()
├── ECDeviceHandler     ← physical slave/coupler: ECDeviceModel, IgH slave config
└── ECModuleHandler     ← modular I/O: ModuleIdent + Slot; PDO merged into parent

Each ECSlaveHandler maintains two process image buffers:

• mUpdateSendImage: master → slave (RxPDO / output direction)
• mUpdateRecvImage: slave → master (TxPDO / input direction)

update() runs every cycle from ECBusHandler: sync domain data to handles, then detect changes on input handles with observers and fire onChange().

4.4 ECSlaveHandle and IOMapper

ECSlaveHandle extends IOHandle and bridges application FBs (e.g. E_PERMIT, E_SWITCH) to EtherCAT process data.

ECBusHandler::createIOHandle() picks the IEC type from HandleDescriptor::mByteLength:

Byte length	IEC type
1	BYTE
2	WORD
4	DWORD
8	LWORD

Besides mId, mDirection, and mSlaveIndex, EtherCAT adds mOffset (byte offset in the slave image) and mByteLength.

Data path:

Application FB ←→ IOMapper ←→ ECSlaveHandle ←→ slave image ←→ domain data ←→ physical slave

On the MAP event, SlaveConfigFB reads mapping names from IN_x / OUT_x (WSTRING). EsiFileParser parses ESI and calls initHandle(). Empty mapping IDs are skipped so you can map only some PDO entries.

4.5 ECDeviceModel: PDO Configuration Bridge

ECDeviceModel sits between ESI and IgH API structures:

• mSyncList: sync managers (SM2 = Outputs, SM3 = Inputs)
• mPdoList: PDO index and direction
• mPdoEntryList: entry Index, SubIndex, BitLength
• mEntryRegList: domain registration entries pointing to ECSlaveHandle::mECDomainDataOffset
• mSlotIndexInc / mSlotPdoInc: coupler slot increments from ESI <Slots>

getSyncs() and getDomainRegs() build ec_sync_info_t[] and ec_pdo_entry_reg_t[] during prepareLoop(). getSyncs() uses fixed SM2 (output) and SM3 (input), matching common vendor layouts (e.g. Beckhoff).

4.6 EsiFileParser: Runtime ESI Parsing

The IDE import produces FB type definitions; forte still needs ESI at runtime for PDO Index, SubIndex, BitLen, etc. EsiFileParser is a singleton that scans devices/ next to the executable at startup and indexes all .xml ESI files by:

• ProductCode for devices
• ModuleIdent for modules

On SlaveConfigFB initialization:

1. FORTE_ECSlave::init() calls loadDevice(ProductCode) to verify ESI exists
2. initHandles() calls initDeviceIOHandles() to parse TxPdo/RxPdo, create handles, fill ECDeviceModel
3. FORTE_ECModule::initHandles() calls initModuleIOHandles() to merge module PDO into the parent ECDeviceHandler

Module PDO indices are offset by slot:

entryIndex += mSlotIndexInc × slot
pdoIndex   += mSlotPdoInc   × slot

Some vendors’ ESI entry indices do not match firmware. EsiFileParser includes corrections (e.g. Inovance −1, Odot +1). If a new vendor misbehaves, check whether a similar correction is needed.

Deploying ESI files: place ESI XML next to the forte executable under devices/. Example:

/opt/forte/
├── forte                    # executable
└── devices/
    ├── Beckhoff_EK1100.xml
    └── Inovance_GL20.xml

4.7 Initialization Chain and Slave Indexing

Initialization follows forte’s adapter chain:

ECMaster(INIT)
  → ECBusAdapter → ECSlave/ECCoupler(INIT)
    → ECBusAdapter → ECSlave(INIT)
      → ...

Each SlaveConfigFB runs handleInitEvent() on adapter INIT:

1. Resolve ECMaster via MasterId
2. Set mIndex from BusAdapterIn().var_Index
3. createSlaveHandler() registers with ECBusHandler
4. init() loads ESI
5. If QI=true, initHandles() binds IO
6. Forward INIT to the next slave via BusAdapterOut

Device type	Index rule
First slave on the bus	0
Next slave on the chain	previous index + 1
First module under a coupler	(coupler index + 1) × 100
Next module on same coupler	previous module index + 1

ECModule::initHandles() finds the parent via bus.getSlave(mIndex / 100 - 1) and registers module PDO on the parent model. The coupler also forwards INIT on ModuleAdapterOut with index (parent index + 1) × 100.

4.8 Function Blocks and Handlers

Function block	Base class	Handler	SlaveType
ECMaster	IOConfigFBMultiMaster	— (creates ECBusHandler)	—
ECSlave	CGenFunctionBlock	ECDeviceHandler	ECSlave
ECCoupler	FORTE_ECSlave	ECDeviceHandler	ECCoupler
ECModule	CGenFunctionBlock	ECModuleHandler	ECModule

4.9 End-to-End Data Exchange Sequence

Linking IDE configuration, forte runtime, and the physical bus:

1. User triggers ECMaster.INIT
2. INIT propagates along BusAdapters; slaves/modules register handlers and parse ESI
3. User fills IN_x/OUT_x mapping names on each slave MAP event
4. User sets ECMaster.Enable=true and triggers REQ
5. ECBusHandler.prepareLoop() configures and activates the master
6. Cyclic loop:
   a. IgH receive → domain process data updated
   b. ECSlaveHandle copies domain data into image buffers
   c. On input change, notify IOMapper observers
   d. Application FBs read/write via IOMapper
   e. ECSlaveHandle writes output image to domain
   f. IgH send → data reaches slaves

5. Current Limitations and Future Work

1. Linux only: CMakeLists.txt returns on non-Linux; depends on IgH master and clock_nanosleep
2. Modular couplers first: modules are not separate bus slaves; standalone slaves use ECSlave
3. PDO types: handles support 1/2/4/8-byte aligned entries only; sub-byte (e.g. 1-bit) not yet supported
4. Distributed Clocks (DC): no DC sync; not suited for nanosecond multi-axis sync
5. SDO: PDO only; no SDO object dictionary access
6. Master activation: prepareLoop() calls ecrt_master_activate() per device; multi-slave setups may need a single activate after all slaves are configured

Possible next steps:

• IDE: auto-fill meaningful mapping names (e.g. GL20_AI_Ch0)
• Support BOOL/bit PDO entries
• SDO configuration FBs for startup parameters
• Jitter monitoring and WORK_COUNTER diagnostic FBs when real-time scheduling is enabled
• A motion control framework for 4diac

6. Summary

Integrating EtherCAT on 4diac boils down to:

1. IDE: ESI import plugin → configurable FB types; generic FBs for dynamic IN_x/OUT_x
2. forte: Master / Slave / BusHandler / Handle layering; ECBusHandler for IgH cyclic exchange; EsiFileParser turns ESI PDO data into IgH config and IO mappings at runtime
3. Build: 4diac-fbe cget recipe bundles the EtherCAT userspace library as a forte dependency for easier cross-compilation

EtherCAT complexity stays inside the IgH driver and ECBusHandler. Application developers wire FBs and mapping names like Modbus or embrick. For hardware-in-the-loop platforms that must integrate many industrial IO protocols quickly, this protocol-agnostic IO mapping approach is highly reusable.

Slave index rules:

[azoitl]

@wzj7531 thx for sharing your approach and your willingness to contribute this to Eclipse 4diac.

I must say: wow this is amazing. I like the approach a lot. Especially the idea of a generic implementation for the device FBs in 4diac FORTE and an automatic generation of the required blocks in 4diac IDE is a brilliant idea. I'm currently not sure if the type attribute is the best place as others may have used this for descriptions. We have since 3.0 a very nice infrastructure for attributes which could handle this a bit cleaner. But this is something we can discuss in a later stage.

Having this in Eclipse 4diac would be a major step forward.

As you have seen our contribution guides we are handling contributions according to the Eclipse Project Handbook. For a contribution like yours there are two additional things that we should consider:

1. I assume that this is by now quite some lines of code. In order to make that manageable for us I would be glad if we could split that into small junks. Which allows us to review and give feedback if necessary.
2. As this contribution introduces a new dependency (in Eclipse Project Handbook Terms: Third Party Content) we need to request a review of the library and a license compatibility check by the Eclipse Foundation's legal team. This will take a bit of time.

I hope this is not overwhelming. I'm happy to support you on all of the stages to make your contribution a smooth one.

[azoitl]

I'm happy to give feedback and support in improving the code in the upstream process. I would also expect more testers when this is part of 4diac FORTE.

As open source licenses have liability waivers my main concern is license compatibility and copyright issues.

If you want we can also setup a meting to discuss the process and potential next steps.

[wzj7531]

This is my first attempt to contribute code to the open source community, and I'm still learning the contribution process. Your earlier mention of potential legal risks has raised my concerns. Could you please advise what I need to do to ensure full compliance with relevant laws and regulations?

[azoitl]

Being aware that their are maybe legal risk is the first step. In nearly all cases it is rather straight forward. The most important things that you need to be aware of:

• You are only allowed to contribute things that you are allowed to.
  • This is especially interesting for you as you did this developments for the company you are employed with. So most probably they own the copyright to your code. So you need to get a permission from your manager that allows you to contribute.
  • This also means that you can only contribute code that you have created.
  • With the signing the Eclipse Contributor Agreement you say that you have this permission and that you allow us to use and further develop the code under the rules of the Eclipse Public License v2, or any later version.
  • The permission of your manager should protect you, the signature of the Eclipse Contributor Agreement protects Eclipse 4diac.
• The other thing that is more a problem for Eclipse 4diac is that if you require third party content (i.e., the Ethercat library you are using) it must use a license that is compatible to Eclipse Public License v2.
  For this we do that IP check with Eclipse Foundation.

I think these are the most important things you need to consider.

[wzj7531]

My manager has approved my open-sourcing plan, so this is not an issue. As for the second question: do I need to submit the code to the 4diac organization first for their evaluation? If that is the case, I will start the open-source process right away.

[azoitl]

Yes submitting the code in PRs as you did is a perfect starting point. I would continue commenting at your different PRs.