Separating CiA402 Logic from EtherCAT (lcec): Modular Adapter + Drive Stub Valid

I’m currently restructuring my CiA402 integration to make it more modular and deterministic before going back to real EtherCAT hardware.
Instead of debugging everything at once (LinuxCNC motion + EtherCAT + CiA402 + drive behavior), I decided to isolate the CiA402 logic layer and validate it independently inside AXIS SIM.
Overall Structure (3 Layers)
I’m organizing the system into three logical layers:
1) Motion Layer (LinuxCNC)
Standard LinuxCNC motion/joint layer. No changes here.
2) CiA402 Adapter Layer (custom HAL component)
This is a dedicated HAL component responsible for:

• Mode request (6060), e.g. Homing = 6, CSP = 8
• Waiting for 6061 (opmode_display) confirmation before proceeding
• Generating controlword transitions (6040), including homing start (bit 4)
• Mask/value-based evaluation of statusword (6041) for homing done
• Optional mask/value error detection
• Slaving pos_cmd to pos_fb during internal drive homing

This layer does not know about EtherCAT transport.
It only works with abstract CiA402 objects (6040, 6041, 6060, 6061, 6064).The idea is that this logic should work identically whether the transport is:

• lcec (EtherCAT)
• some other fieldbus
• or a simulated drive

3) Drive Stub (Simulated CiA402 Drive in HAL)
Since I don’t have EtherCAT hardware connected right now, I implemented a simple CiA402 drive stub as a HAL component.
It simulates:

• Opmode request → opmode_display with delay
• Rising edge detection of controlword bit 4
• Homing runtime (configurable cycles)
• Statusword “homing done” pattern (e.g. 0x1400 by default)
• Actual position feedback

This allows me to validate:

• Proper gating on 6061
• Correct controlword sequencing
• Deterministic servo-thread behavior
• Statusword mask handling
• HAL wiring correctness

All running inside AXIS SIM.

Relation to Existing Work (rodw, dbraun, EL8)I’ve reviewed:

• dbraun’s hal-cia402 implementation
• rodw’s cia402 component used with lcec
• The Leadshine EL8 integration example

All of them are valid and functional in their intended context.However, my goal here is slightly different:I want a clearly separated CiA402 logic layer that:

• Can be tested without EtherCAT
• Is not tightly coupled to lcec internals
• Can support both internal drive homing and CSP cleanly
• Can later be extended for tandem gantry supervision (Y/Y0 squaring)

This isolation makes debugging much more controlled and avoids mixing transport issues with state-machine issues.

Why Mask-Based Statusword Evaluation?
Instead of hard-coding something like “bit 12 = homing done”, I’m using:(statusword & mask) == valueExample:0x1400 (bits 10 + 12)The reason is simple:CiA402 allows vendor-specific interpretation and combination of bits.
Different drives report homing completion differently (sometimes bit 12 only, sometimes 10+12, sometimes additional bits).A mask/value approach allows:

• Drive-specific configuration
• Future-proofing
• Cleaner abstraction

If mask = 0, the adapter falls back to default CiA402-style bit interpretation.

Long-Term GoalThe final architecture should support:

• CSP as primary motion mode
• Internal drive homing
• Tandem gantry (Y/Y0) with squaring
• Optional gantry delta supervision during homing
• Clear separation between CiA402 state logic and EtherCAT transport

So conceptually:Motion → CiA402 Adapter → Transport (lcec) → DriveAnd currently:Motion → CiA402 Adapter → HAL Drive StubOnce validated, I’ll replace the stub with real lcec + cia402.If anyone has feedback regarding:

• Best practices for controlword sequencing in CSP
• Clean homing mode transitions
• Gantry homing supervision patterns
• Mask-based statusword handling

I’d appreciate technical input.