CiA402 framework for LinuxCNC (follow-up: runnable + simulation + easier debuggi

 was struggling with the forum editor formatting, so the first post didn’t come out right.

Hi,
Some time ago I opened a topic about separating CiA402 logic from EtherCAT and validating it in a more modular way.

forum.linuxcnc.org/ethercat/58434-separa...ter-drive-stub-valid

Since then I kept working on that idea and turned it into something more complete that is now actually runnable and easier to test.

What problem I was trying to solve:
While studying and experimenting with CiA402 setups (and reading quite a few forum threads), I kept running into the same kind of issues:
often ending up debugging everything at once (motion + HAL + EtherCAT + drive)
not knowing if a problem comes from logic, wiring or hardware
drive-internal homing causing unexpected behavior or following errors
difficulty understanding what the controlword / statusword is really doing at runtime


So the goal here is not to replace anything, but to make those problems easier to isolate and understand.

What this does differently
The main idea is to separate things a bit more clearly:
keep LinuxCNC motion as-is
isolate CiA402 semantics (state machine, CSP, homing, etc.)
keep hardware/backend separate (EtherCAT, etc.)
This way it's possible to:
test CiA402 behavior without hardware first
see what's happening internally instead of guessing
debug logic without mixing it with transport issues

You can run it directly (no EtherCAT required):
git clone github.com/MarcosDuqueCesar/linuxcnc-cia402-layer
cd linuxcnc-cia402-layer
find comp -name "*.comp" -exec halcompile --install {} \;
linuxcnc ini/examples/runtime_validate_xyz.ini
scripts/diag.sh

This runs a full CiA402 pipeline using a stub backend.
You can observe things like:
controlword behavior
statusword transitions
mode switching (CSP / HOMING)
basic sequencing / watchdog behavior

Debugging focus:
One thing I tried to improve is visibility.
Instead of guessing, you can see internal state and get a better idea if the issue is:
logic / sequencing
HAL wiring
or backend / hardware

About homing:
This is one area that motivated the work.
In some setups, using drive-internal homing can lead to following errors if the LinuxCNC side is not kept consistent with what the drive is doing.
Here, homing is treated as a separate semantic part instead of being embedded inside the driver logic, so it's easier to observe and reason about.

Current status:
simulation: working
CiA402 logic: validated in runtime
hardware integration: not yet tested
This is intentional so far — the focus was to understand and validate the CiA402 behavior first without requiring hardware.

Scope:
This does not replace:
real-time tuning
EtherCAT setup complexity
Those are still necessary.
This is mainly about structuring and understanding CiA402 behavior.

Feedback:
If anyone is working with CiA402 in LinuxCNC, I’d really appreciate feedback.
Especially from real hardware setups, to validate the adapter/binding side.
Thanks