Hello,
I’d like to share a project for review and comment: a standalone Linux
kernel transport for deterministic EtherCAT cyclic I/O on top of the
EtherLab (https://etherlab.org/) master.
Repository: https://github.com/latproc/etherlab-cyclic-kmod
What it is
User space describes the network at runtime (slaves, Sync Managers,
PDOs, setup SDOs, Distributed Clocks, validity domains). The module
validates that description, configures EtherLab, runs one cyclic
exchange, and exchanges bounded copied process images through a
versioned ioctl API (/dev/elc_ethercat0).
The transport is policy-free: no machine layout, servo/CiA 402
semantics, XML parsing, or control-system policy in the kernel. Those
decisions stay in user space so the same module can serve different
devices and controllers without a kernel rebuild.
Why this exists
Anyone who has followed etherlab-users for a while will recognise the
pattern: the master itself is solid, but getting a clean application
around it—ownership, configuration, cyclic exchange, and teardown—is
hard when every project reinvents that layer in its own code.
If we have got this right, that shared part should be much easier. You
describe the network generically; the module owns EtherLab lifecycle,
validated configuration, and the cyclic path. Your code keeps device
recipes and machine policy.
That includes devices that need mailbox/SDO setup before activation:
ordered typed setup SDOs run as a pre-activation transaction (distinct
from PDO mapping and from ad-hoc runtime SDOs), so CoE startup
parameters and similar commissioning writes are first-class, not
something each controller has to re-implement against the master API.
Other pieces of the same boundary:
• runtime topology / PDO / DC / domain configuration
• one cyclic task and cycle timeline for all domains
• stable user-supplied entry IDs → offsets
• independent validity domains and per-domain output authority
• explicit publish → arm → disarm (publication never arms by itself)
• optional controller liveness lease
• coherent cycle timing and DC motion-clock records
• userspace library (libelcethercat) plus reference tools
Status
This is experimental and only lightly tested so far. Anyone evaluating
it should test thoroughly on their own hardware and systems before
relying on it.
Where to start
Start with the README. It covers the design intent, requirements, build,
first safe tests, and a short map into docs/ (architecture, UAPI,
developer/operator guides, safety, testing, and the current architecture
review).
Feedback I’m looking for
I’d especially value comments on:
1. Architecture boundary — is the kernel/user-space split clear and
sustainable? Does this actually ease the “own EtherLab application” problem?
2. UAPI / lifecycle — open → configure (including setup SDOs) → activate
→ publish/arm → disarm → close: gaps, footguns, missing capabilities?
3. Domain model and output authority — multi-domain WC isolation,
arm/re-arm, lease semantics
4. Documentation — is the path from README → developer guide → UAPI
navigable for a new controller author?
5. Safety story — fail-safe output gating, controller death, power loss;
anything understated or overstated?
6. What’s missing for real adopters (delegated domain fds, scheduled
outputs, packaging, examples, etc.)
Please reply with comments, open issues at
https://github.com/latproc/etherlab-cyclic-kmod/issues, or mark up the
docs. Even high-level “this is unclear / this would block adoption”
feedback is useful.
Thanks for taking a look.
--
Mike O'Connor
OEG Australia
Mb. 0416 106 040
--
Etherlab-users mailing list
[email protected]
https://lists.etherlab.org/mailman/listinfo/etherlab-users
