EtherCAT master cyclic task when the external event is missing

Why is the EVENT_ECM_DC external event missing from the task list?

The event list is part of the runtime image installed on the controller, so your EtherCAT master V3.5.9 shows exactly the events that image implements, and typing EVENT_ECM_DC into a project cannot create an interrupt source the target does not provide.

External task events are a runtime capability: the image raises the event, and any task registered for it runs when it fires. The manual you are working from was written for EtherCAT master V3.5.3 on a target whose image implements the event, so its screenshots list it. The same dialog on your combination lists what your image provides, and on this family of low-cost Linux targets the vendor's guidance is that the event is not implemented and cannot be added. Read the empty list as the answer. A value that looks like a setting but is really supplied by the installed software behaves the same way as a control application config setting that is ignored: the dialog takes what you type and the target never acts on it.

Can I add EVENT_ECM_DC by changing the EtherCAT master version?

No. Downgrading from master V3.5.9 to the manual's V3.5.3 reproduces the manual's screenshots at best, because the event appears in the task dialog only when the runtime image implements it, and no master component version adds that capability to a target that lacks it.

Record the software combination before you touch anything: CODESYS V3.5 SP9 as the engineering system, master V3.5.9 in the project, and the runtime version the controller actually executes. Those are three different numbers, and mixing them up is the most common reason a commissioning note stops matching your screen. If the download itself fails because the project's device description and the controller disagree, that comparison and its safe correction are covered in our note on fixing a PLC runtime device mismatch safely. An older master component also brings its own compatibility constraints, so the downgrade trades a missing event for a new mismatch. Keep V3.5.9 and change the task setup instead.

What task should run the EtherCAT master instead of the external event?

Use a cyclic task: create one in the task configuration, point the EtherCAT master's task assignment at it, and let the scheduler call the master at a fixed interval; on an RT-preempt patched kernel this is accurate enough even to support distributed clocks.

A cyclic task starts on the controller's schedule; an externally triggered task starts when its event fires. The network behaves the same under either one as long as the process-data exchange stays inside the slave's timing window, which is why the vendor offers the cyclic task as the supported replacement. Build it in this order:

1. Add a cyclic task in the task configuration, with the interval and priority from the next section, and attach the POU that carries your network and drive logic.
2. In the EtherCAT master's settings, where the executing task is selected, set the master to be serviced by that cyclic task.
3. Download and start the application with the drive command logic still disconnected, so nothing moves while you verify. Keep the drive's disable within reach until the checks in the next sections pass.

Confirm the task assignment online in the EtherCAT view before you rely on it, using the checks below.

What interval and priority should the cyclic EtherCAT task use?

Start a single-drive network at a 2 ms cycle with the EtherCAT task at a higher priority than visualization and logging tasks; the interval must be no longer than the exchange rate the slave's device description requires, so read that figure from the inverter card's documentation.

2 ms is a widely used starting cycle for a small network with one or two slaves and no axis-synchronized motion, and it is the value the worked example below assumes. The binding limit is the slave's own requirement: the EtherCAT card's documentation and its device description state the exchange rate the slave tolerates, so take your final number from there. The manual you have was written for a different master version, so its screenshots do not set your values either.

On priority, the network task should run ahead of background work. How tasks layer and preempt each other is explained in our guide to PLC execution order across task layers. Where a visualization task, a logging task and the network task compete, the network task wins; when it loses, the drive sees stale process data even though everything looks connected.

Does a cyclic task support EtherCAT distributed clocks on these targets?

Yes, with an RT-preempt patched kernel: the runtime vendor's position is that the cyclic master task is accurate enough even to support distributed clocks on these single-board Linux targets, and distributed clocks exist precisely to cancel the frame jitter the scheduler adds.

Distributed clocks give the EtherCAT slaves a shared time base: each slave derives its SYNC interrupt from a reference clock, so the jitter with which frames pass each port stops mattering to devices that need simultaneous sampling or output. That is the mechanism the missing external event was meant to hook into, and the cyclic task reaches the same mechanism by trading interrupt precision for a short, measured schedule. Treat the RT-preempt kernel as the setup step, then verify on target: read the task's timing in runtime monitoring and the slaves' synchronization status in the EtherCAT online view. For the mechanics of the time base, the page on how EtherCAT distributed clocks compensate frame jitter goes deeper.

How do I check that the cyclic task is servicing the master?

Watch three readings before any drive command goes into the logic: the task's measured interval and execution time in runtime monitoring, the slave states in the EtherCAT online view, and one live process-data value from the drive with motion inhibited.

First confirm the runtime is executing, because a stopped runtime imitates every other failure on this list; our check for whether the CODESYS runtime is running or stopped takes a minute. Then work through the rest:

• Task timing. In runtime monitoring, read the cyclic task's interval, average execution time and peak execution time. The peak belongs inside the interval with headroom; the arithmetic is in the example below.
• Slave state. In the EtherCAT online view, confirm every slave reaches operational state and holds it, and confirm the master shows your cyclic task as its assigned task.
• Process data. Watch one drive value that reflects a real condition, such as the inverter's actual output frequency, with the machine's established commissioning controls holding motion. A value that tracks the drive proves the exchange; a frozen value means the task chain is not servicing the network, whatever the state LEDs say.

The drive still misbehaves: what does each symptom point to?

Read the first gate that fails and fix that gate alone, because each stage has its own cause: detection failures live in link and identity, state failures in synchronization and mapping, load failures in task timing, and an idle drive behind a healthy network in the command interface.

• Slave not detected. Physical link, the network interface selected in the master's settings, card power, and device identity. The online scan should find the slave the project describes, and the identity it reports must match. Fix detection before touching any timing setting.
• Detected but stuck below operational state. Synchronization mode, distributed-clock settings and process-data mapping. The diagnostics name the transition that failed; correct the configuration attached to that transition and retry.
• Operational state drops under load. Task timing. Correlate the state loss with the execution-time peaks you recorded; a drive that falls off the network when another task wakes up is pointing at a scheduling collision, so move work out of the EtherCAT task's window or lengthen the cycle if the slave allows.
• Network healthy, drive idle. The cyclic task transports process data; the drive's enable logic still has to write the command values. Check the command word your application sends and the drive's enabled-state feedback before suspecting the network again.
• Download fails with a device mismatch. The project's device description and the controller's runtime disagree; use the safe correction path in the device-mismatch note linked above.

Example: one inverter on a 2 ms cyclic task

The setup is a CODESYS V3.5 SP9 project with EtherCAT master V3.5.9 on a low-cost Linux controller, one inverter with an EtherCAT option card, an RT-preempt patched kernel, and no external event in the task list.

Set the cyclic task to 2 ms with a priority above the visualization task, and leave the runtime image, master version and kernel as commissioned. Then read the numbers back from the running application.

Interval to cycles: 1000 ms / 2 ms = 500 cycles per second. Over a 10 s monitoring window that is 500 × 10 = 5000 cycles, which settles a stable peak reading.

Execution time from monitoring: average 0.3 ms, peak 0.6 ms. Peak load on the cycle: 0.6 / 2 = 0.30, so the task fills 30% of its cycle at the worst and leaves 2 - 0.6 = 1.4 ms of headroom.

Decision threshold: hold peak execution time below 80% of the interval, here 0.8 × 2 = 1.6 ms. The measured 0.6 ms sits well inside, and the 1.4 ms of headroom absorbs the visualization task waking up.

Result and decision: the slaves hold operational state across the whole window and the inverter's actual-frequency value tracks the drive, so the network side of commissioning passes. Add the drive command logic to that same cyclic task and bring the axis up under the machine's normal enable procedure.

Recommendation: when EVENT_ECM_DC is absent from your target's task configuration, keep the EtherCAT master version you have, create a cyclic task at 2 ms for a single-drive network, place it at a higher priority than the visualization and logging tasks, run the controller on an RT-preempt kernel, and release the drive only after task monitoring shows peak execution time under 80% of the interval and the online view shows the slaves holding operational state.

Questions