Technical questions about CIA402 and homecomp.comp on A6

Hi,
I have some technical questions about CIA402 and homecomp.comp
First of all, which version of homecomp.comp is currently recommended for the A6?
Since I don't understand the source code of homecomp.comp and CIA402, I would like to know how the basic servo homing process works.
Are all servos put into homing mode and checked to see if they are ready before the sequence starts?

I'm trying to understand how the process works, as I keep getting sporadic errors during homing, even though everything else is running smoothly.

The original component by dbraun was designed with home to index in mind but today many drives home to an external switch. The problem is that the drive moves while not being commanded  by linuxcnc which linuxcnc interprets as a following errors. The secret is to sync linuxcnc's commanded position and its feedback while its moving like this which the original cia402.comp does not do. some people have modified the component to support this.  I have been working on an enhanced cia402 component but it needs more work.

I'm sorry
I think you misunderstood me.
I am using the component and trying to understand how the process works from a control technology perspective.
Are the servos initialized and their status checked first, and then the homing process started, or is the homing process started without checking?
What happens if a servo is not ready?
What happens if a servo does not start the homing process or starts it with a long delay (watchdog)?
How is monitoring performed if a coupled axis on a gantry does not start moving during homing?
Since Linuxcnc has no control over this type of homing, these error cases should be monitored, otherwise the machine could be damaged.

In my opinion, the homing process should be initialized first.
Then check whether all servos are in the correct operating mode.
Then start the homing process.
During the homing movement, monitor whether the axes are synchronized (gantry).

 

What we need is a way to "link" the two joints (example: X and X-slave)... Am I correct, currently we tell both to home and just expect them to go?

If one isn't ready, or simply fails to move, we would prevent both from moving.

What if CIA402 component had some pin, maybe an io pin to monitor, and any drive connected to it could set it, causing them all to halt?

net gantry-halt-interlock   <=> J1.cia402.halt
net gantry-halt-interlock   <=> J2.cia402.halt
If a drive is commanded to move, try clearing the pin just once. If a drive is faulted and sees this pin got cleared, set it again.

Or maybe a better way, (or additionally?) monitor both joint positions, if the difference exceeds some value, stop both?

Just throwing the idea out there. Maybe I'm just making noise.

From what it looks like, the only way out from homing is that is finishes.
This could probably be expanded to include error states and whatever can occur.

 

Hi, 
In PLC-controlled systems, there is a watchdog for each servo controller. This is triggered if the servo does not respond within a specified time.  The same is done with pneumatic cylinders. Here, a timer is started in parallel with the cylinder stroke. If the timer is faster than the cylinder in its end position, there is an error.
The same could be done for homing.
Isn't there a control bit in register 6041h that is set when the servo starts homing? For example, bit 4 or bit 9. I don't know, you would have to visualize the bits. 
If you find such a bit, you could combine it with a watchdog.

 

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.