Advanced Search

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.

Wie ich schon sagte, du bist nicht der einzige der das Problem hat. Aus irgendeinem einem Grund bekommen die servos nach dem homing einen Fahrbefehl, der zu dem Fehler führt. Bei mir hat geholfen das Handrad abschalten.
Zusätzlich habe ich eine sehr niedrige homing Geschwindigkeit und ich habe die joggeschwindigkeit auf 6mm/min als Grundeinstellung. 

hey, danke für die schnelle antwort, macht bei mir aber leider keinen unterschied. könnstest du vielleich nochmal über meine config drüber schauen ob dir was auffallen tut? Wäre dir echt dankbar

Thank you for reporting back.

Willkommen in Club.
Schalte das Handrad erst nach dem homing ein.

Danke, habe mit deiner config hab ich die paar fehler in meiner config gefunden. Habe nur noch ein kleines problem, nach dem homing springen die motoren beim modus umschalten (automatisch von linux cnc von 6 auf 8) schlagartig an eine andere position, dadurch ensteht beim mir im drive öffters der Fehler E87.1, hast du das problem auch? wenn ja wie hast du es gelöst? oder was denkst du was es sein könnte?

LG

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 reconcilevs, 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’sis 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 keepingin 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.

Yes that was my problem... thanks a lot!!!

Following this with interest (I had the exact same problem) - my goal was rebuilding the mot2-eth driver. Will review all the advice here when I've had more coffee but PITA if we can't build from a Trixie installation.

Further experimenting seems to have determined the cause of the failure at Grub install

I was performing the install in the workshop where I have wifi access to the internet but no Ethernet connections 
Everytime without fail the install of 2.9.8 failed at the install Grub stage

Now on the same PC with a Ethernet cable plugged in the install ran through without any issues at all

i therefore believe that something critical to installing Grub is missing from the 2.9.8 ISO, as the 2.9.7 iso installed ok WITHOUT the Ethernet cable being plugged in

hopefully this rather time consuming and frustrating experience of installing 2.9.8 will help other following the same path

Thanks to all who replied with ideas, very much appreciated

best regards. Paul

That example shows how to connect the servos to the joints in linuxcnc.
It is done in the same way for all cia402 servo drives.
You do need to modify vid and pid for your specific drives.
You find those numbers in the output of "ethercat slaves -v".

There is of course a lot more like configuring switches, spindle, mpg, hmi, but since you already
have a linuxcnc system running that is no surprise. The same way now.

What can be a differentiator between the servo drives is how to tune the servos.
Is there software for that? How to connect to the drives?
Tuning process? How to store the tuned parameters?
 

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 currentlogic, 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.)

Run the simulator to ensure your installation is good, if so, compare its configuration files to your machine config. You'll be able to find where your errors are coming from between that and the docs

 kcjengr.github.io/probe_basic/machine_config.html

Follow the docs exactly and you will have no errors..

This is telling you your error

"raise IOError('The specified POSTGUI_HALFILE does not exist: %s' %
OSError: The specified POSTGUI_HALFILE does not exist: /home/cnc/linuxcnc/configs/Fräse_Probe/custom_postgui.hal
1550"

Remove it from your ini hal section call. You can only have one post gui hal file and it must be the supplied probe basic postgui halfile