Technical questions about CIA402 and homecomp.comp on A6

Hi all,I think the real challenge here is not “making it work for A6” or for any single brand, but making it work generically for any CiA-402 EtherCAT drive — including the obscure or poorly documented ones.I don’t have this hardware on my bench, but I went through the documentation for Yaskawa EtherCAT drives and also some of the available documentation for A6/Lichuan, plus the CiA-402 profile itself. From that, it’s clear that while they all follow CiA-402 at the structural level (6040h, 6041h, modes, state machine), the details around homing status and mode-specific bits can vary quite a lot between vendors.CiA-402 defines the structure, but it does not guarantee that every drive exposes a clean, well-documented “homing started / in progress / done” set of bits, or that bits like “target reached” behave identically across vendors. Two drives can both be “CiA-402 compliant” and still differ significantly in these details.That’s why Andrax’s point about watchdogs and state checks is important, even if the exact bit numbers vary by drive. The idea is not to rely on one vendor-specific flag, but to build a defensive, generic state machine on the LinuxCNC side:

• switch to homing mode and confirm via mode display,
• issue the start command,
• verify that something actually changes within a timeout (state, target reached, position, etc.),
• wait for a generic completion condition (e.g. target reached / mode change / no fault),
• and always have timeouts and fault paths.

Looking at the current logic, it seems to focus mainly on “start homing” and “target reached”, but without explicit timeouts or richer state validation. That may work for some drives, but for a truly generic solution (including obscure ones) it probably needs to be more defensive and timeout-driven, rather than assuming specific bit semantics.So from my point of view, the goal should be to keep this LinuxCNC-centred, but design the homing logic in a way that does not depend on vendor-specific interpretations of CiA-402, and instead survives the worst-case implementations by using state transitions, minimal guaranteed signals, and watchdogs.(This is based on documentation only, I don’t have this hardware on my bench.)

Hi all,I spent some time reading through the existing code and examples ( , , the Leadshine EL8 example, and rodw’s ), plus the available documentation (Yaskawa EtherCAT, some A6/Lichuan docs, and the CiA-402 profile). I don’t have this hardware on my bench, so this is a code/doc-based perspective.One thing that stands out is that the older approaches ( , , and the EL8 example) all implicitly assume that LinuxCNC remains the “owner” of the position loop all the time. That works well in modes where LinuxCNC generates the trajectory (CSP/PP/etc.), but it becomes conceptually fragile when the drive performs internal homing and moves on its own. In those cases, the drive is effectively autonomous for a while, and LinuxCNC still tries to reconcile vs , which is where the following-error / desync problems come from. The EL8 example solves this pragmatically for that specific drive, but it’s still a drive-specific adaptation rather than a generic model.What I think is the important architectural step in rodw’s is that it explicitly acknowledges this: during CiA-402 internal homing, the drive is not under LinuxCNC’s trajectory control. The component tries to temporarily decouple LinuxCNC from the position loop (by keeping in sync with ) while the drive is homing, and then re-synchronize afterwards. That feels like the right direction conceptually, and it’s a step beyond just adapting one specific drive.Where it still seems incomplete (and this matches Andrax’s point) is robustness: today the logic mainly focuses on “start homing” and “target reached”, but there is no explicit, defensive state machine with timeouts, start/progress checks, and clear fault paths. For a truly generic solution that should also work with obscure or poorly documented CiA-402 drives, it probably needs to be more watchdog- and state-driven, and rely only on the minimal, reasonably guaranteed signals (state transitions, mode display, position change, target reached, fault), rather than assuming specific vendor bit semantics.So, from my point of view, the real problem is not “making it work for A6” or any single brand, but defining a LinuxCNC-centred homing flow where:

• LinuxCNC explicitly steps out of the position-control role during internal homing,
• the process is supervised by a small, defensive state machine with timeouts and error paths,
• and then LinuxCNC is cleanly re-attached to the position loop once the drive reports homing done.

This is all based on reading the code and docs, not on hardware testing, but it seems like rodw’s work is already addressing the right architectural issue, and the next step is mostly about making that flow robust and generic rather than vendor-specific.

is that it explicitly acknowledges this: during CiA-402 internal homing, the drive is not under LinuxCNC’s trajectory control. The component tries to temporarily decouple LinuxCNC from the position loop (by keepingpos_cmd
in sync withpos_fb
) while the drive is homing, and then re-synchronize afterwards. 

Ah, that would explain the strange behavior where the servos jump after homing, leading to error E87.1.

Yes, that makes sense. The “jump” after homing and the E87.1 you’re seeing are consistent with that temporary desync between the drive’s internal motion and LinuxCNC’s commanded position. During CiA-402 internal homing the drive is effectively moving on its own, so unless pos_cmd is kept in sync with pos_fb (or LinuxCNC is otherwise decoupled from the loop), you can get that kind of discontinuity when control is handed back. So your observation fits well with what rodw described about the need to resynchronize after homing.

On a side note (and not to derail the thread): I might eventually pick up a used EtherCAT drive/motor myself to learn and test this in practice. I saw your configuration in another post and got curious—what made you choose EtherCAT for your setup specifically? From the outside it looks powerful but also relatively costly and a bit of work to get everything “dialed in”, so I’d be interested in your reasoning.

The mindset should be that the drive decides.
The component can only ask the drive to do things like switch op-mode, start homing, etc
for the rest the drive must react to every status condition that comes from the drive.

There are other circumstances when the position feedback can be out of sync with linuxcnc joint commanded position.
A spindle running in PV mode as a spindle motor, switching to csp mode as an axle comes to mind.
The component handles and offset in such a case.

Ihave a new component in progress that is designed to address many if the things you raise home jump, pv mode etc. be patient as i had to put it aside for a while