EtherCAT + CiA402 Servo: OP state reached, but axis won’t move (only Following E

Hello everyone,I am currently trying to commission an EtherCAT servo drive (LC10E series) using LinuxCNC + LCEC + CiA402.
The slave enters OP-state correctly, torque is enabled, the shaft is held, but the servo never moves.
Any motion command (homing or G0/G1) results instantly in a following error.Below is a complete summary of everything that was tried so far.System Setup

• LinuxCNC 2.10~pre0 (uspace), clean installation via
  Code:

  .deb
  packages
• EtherCAT master working
  • Slave recognized
  • Code:

    ethercat slaves → PREOP / SAFEOP / OP
    all OK
• Servo drive: LC10E series (Chinese EtherCAT servo)
• EtherCAT mapping generated via
  Code:

  lcec_configgen
• CiA402 component compiled and installed from GitHub
• Motor shaft is energized and held when LinuxCNC is activated
• Mechanical disturbance triggers an error from the drive → feedback works

What has already been done1. XML generated correctly

• Using:
  Code:

  lcec_configgen > ethercat-conf.xml
• Code:

  lcec_conf ethercat-conf.xml
  loads without errors
• Code:

  halrun → show pin lcec
  lists all expected pins

2. CiA402 integration

• CiA402 compiled successfully
• Configuration created using:
  • Code:

    cia402.ini
  • Code:

    cia402.hal
  • Code:

    ethercat-conf.xml
• CSP mode enabled:
  • Code:

    setp cia402.0.csp-mode 1
• Controlword, Statusword, Velocity pins linked correctly

3. HAL issues fixed

• Fixed type mismatch (drv-fault bit vs u32) by removing problematic nets
• Removed unused / nonexistent pins
  • Example: the LC10E has no
    Code:

    srv-actual-position
    PDO

4. halrun diagnostics

• EtherCAT pins work
• OP-state reached
• Code:

  srv-actual-velocity
  ,
  Code:

  srv-cia-controlword
  etc. update correctly
• BUT actual velocity always stays 0

5. LinuxCNC behavior

• Servo enables and holds torque
• But no movement at all
• Homing → immediate following error
• MDI
  Code:

  G0 X50
  → following error
• Trying as spindle (
  Code:

  M3 S1000
  ) → same issue

6. OP-state OK but drive ignores setpointsThe drive enters OP without issues, but does not react to:

• target position
• target velocity
• target torque (CST also tested)

Setpoints are written by LCEC, but the servo does not act on them.Current suspicionThe LC10E likely does not accept the setpoint PDOs generated by default, or requires:

• additional manufacturer-specific objects
• a different operation mode (CSV instead of CSP?)
• special enable/transition sequence
• custom PDO mapping not included in the ESI

The servo provides status feedback, but ignores motion commands.QuestionsHas anyone successfully used:

• LC10E, LC-EH or similar Chinese EtherCAT servos with LinuxCNC?
• CiA402 in CSP mode on these drives?
• CSV or PP mode with these drives?
• Custom PDO configuration?

Also helpful would be a minimal example of:

• which PDOs are absolutely required for motion
• how to correctly modify
  Code:

  ethercat-conf.xml
  for this family of drives

Any input is greatly appreciated – I am stuck at this very last step.Thanks,
MatthiasDeutsche VersionHallo zusammen,ich versuche derzeit, einen EtherCAT-Servotreiber (LC10E-Serie) mit LinuxCNC + LCEC + CiA402 in Betrieb zu nehmen.
Der Servo geht korrekt in den OP-Zustand, das Haltemoment ist da, aber er bewegt sich nicht.
Jeder Bewegungsbefehl (Homen oder G0/G1) führt sofort zu einem Schleppfehler.Hier eine vollständige Übersicht über alle bisher getesteten Schritte.System

• LinuxCNC 2.10~pre0, frisch installiert
• EtherCAT läuft
• Slave wird korrekt erkannt
• Servotreiber: LC10E-Serie
• XML erzeugt mit
  Code:

  lcec_configgen
• CiA402 kompiliert und installiert
• Motorwelle wird gehalten
• Manuelles Verdrehen erzeugt Fehler → Feedback vorhanden

Bereits getestete Schritte1. XML korrekt erzeugt

• Code:

  lcec_configgen > ethercat-conf.xml
• Code:

  lcec_conf
  lädt Datei ohne Fehler
• Code:

  halrun → show pin lcec
  listet alle Pins

2. CiA402 korrekt eingebunden

• CSP-Modus aktiviert:
  Code:

  setp cia402.0.csp-mode 1
• Statusword, Controlword, Velocity verknüpft
• Nicht vorhandene Pins (z. B. actual-position) entfernt

3. HAL-Fehler behoben

• Typfehler bei
  Code:

  drv-fault
  (bit vs u32) korrigiert
• Fehlerhafte nets entfernt

4. Diagnose mit halrun

• OP-State erreicht
• EtherCAT-Pins aktiv
• Tatsächliche Geschwindigkeit bleibt immer 0

5. Verhalten in LinuxCNC

• Servo geht in Betrieb
• Homen → sofort Schleppfehler
• G0 X50 → sofort Schleppfehler
• Test als Spindel (M3 S1000) → ebenfalls keine Bewegung

6. GrundverhaltenDer Treiber arbeitet grundsätzlich, aber er reagiert nicht auf:

• Soll-Geschwindigkeit
• Soll-Position
• Soll-Drehmoment

VermutungDer LC10E benötigt vermutlich:

• spezielle PDO-Konfiguration
• CSV statt CSP
• zusätzliche Hersteller-Objekte
• besondere Freigabesequenz

Momentan liefert der Servo Statusmeldungen, führt aber keine Sollwerte aus.FragenHat jemand diesen oder ähnliche chinesische EtherCAT-Servotreiber erfolgreich mit LinuxCNC betrieben?Speziell:

• LC10E / LC-EH / vergleichbare Modelle
• CiA402 im CSP-Modus
• CSV / PP als Alternativen
• angepasstes PDO-Mapping

Und:

• Welche minimalen PDOs sind zwingend notwendig, damit Bewegung möglich ist?

Jede Hilfe ist willkommen – ich bin jetzt sehr tief in der Konfiguration drin, aber komme hier nicht weiter.Danke,
Matthias

I see there wasn't an "actual-position" pdo. There absolutely must be an actual-position PDO when using csp.
I think lcec_configgen didn't do a good job this time and maybe selected wrong PDOs.

There is a long thread about Lichuan LC10E and problems to get that to work.
On page 7  forum.linuxcnc.org/ethercat/52341-proble...rive?start=60#304887
they come to a working setup, a working ethercat-conf.xml
And when I look at it, it's just a standard setup with configurable PDOs, often used.
Combine the ethercat-conf.xml with the hal file from cia402 component github.com/dbraun1981/hal-cia402/blob/main/example/cia402.hal
and I think it should move.

The reference to the forum post was helpful. I now have the basic framework up and running. The servo, which is supposed to act as a spindle, is working to the point that it can be controlled with M commands, and the stepper driver (one driver for two closed-loop steppers) is also working. I've attached the files. More to come.

de.aliexpress.com/item/1005008271228331....gatewayAdapt=glo2deu

de.aliexpress.com/item/1005010098887410....gatewayAdapt=glo2deu

 

Okay, so one drive is for a spindle?
I made an adaptation to the cia402 component for the driver to work in PV (Profile velocity) mode
which is better suited to run as spindle.
Check out here  github.com/MetalMusings/cia402pv
This person made it work after a while forum.linuxcnc.org/38-general-linuxcnc-q...tor-as-spindle-motor
 

That worked well. Currently, I'm just testing that the electronics are working; the hardware isn't connected yet, so scaling isn't realistic. What is working is the C-axis and the M commands for spindle movement. The stepper motors are also moving as they should. There are still problems with the M19 command (the servo might be trying to reach a position too quickly, which isn't possible). I'm also checking that the C-axis is working reliably. Currently, there are still problems switching from M3 to S500 for a short time after the C-axis. The servo goes into overload because it seems to be trying to reach a position too quickly, which isn't possible.

Interesting to see you switching between spindle and axis.

I wonder how it works with setting a position in PV mode.
Setting position and velocity at the same time, I am not sure that works.

Very short explanation of how PV ↔ CSP switching works:

Only one CiA-402 mode is active at any time.

In spindle mode (PV):
- The drive receives only target-velocity.
- HAL forces: pos-cmd = pos-fb (follow-mode).
- So the axis has no position error while the spindle is turning.

When switching to C-axis mode (CSP):
- HAL switches pos-cmd from “follow-mode” to the motion planner.
- Since pos-cmd == pos-fb at the moment of switching, there is no position jump and no torque spike.

Why this is valid:
- PV mode ignores position commands.
- CSP mode ignores velocity commands.
- Therefore the drive never receives conflicting commands.
- This fully complies with CiA-402 behavior.

Status:
This configuration has been tested electrically only.  
The motors run and switch modes as expected, but the mechanical connection to the machine is not installed yet.
 

Did you also get the M19 and axis-to-spindle switch to work as you said there were some issues?
My first thought there was to just verify the drive is actually switching modes, you have the 
opmode-display from lcec you can watch.

Thanks for the hint regarding opmode-display — I verified that first.Here is the current, confirmed state of M19 and PV↔CSP mode switching:
1. M19 (verified)M19 currently does not produce any motion.
The orient component runs internally, but the LC20E does not react to the orientation command.
No errors are generated — simply no movement.This is the confirmed and reproducible behaviour.
(No assumptions about the cause.)
2. PV ↔ CSP mode switching (verified)The drive does switch modes correctly, which is confirmed via:
   Switching between spindle mode (PV) and axis mode (CSP) is possible.However, the switching reliability depends on the drive state after M5.
3. Behaviour after M5 (verified)After stopping the spindle:

• Code:

  actual-position
  continues to drift for some time
• Code:

  pos_fb
  and
  Code:

  axis.c.eoffset
  follow this drift
• zero-speed becomes TRUE early, but the position is still changing
• CSP switching during this drift often causes a drive fault

This post-M5 settling is the core issue.However, switching is possible if you wait until the drift has fully settled.Once the position stops changing, CSP can be enabled without a fault.So the mode switching itself works — the problem is only the time it takes for the LC20E to reach a stable state.
4. Safety logic (current state)I currently use safety conditions that require:

• zero-speed = TRUE
• no position change during a short window

With these checks, switching is reliable as soon as the drift has stopped.If the safety thresholds are made more permissive (larger allowed window),
switching becomes possible earlier, even before the drift is fully gone.Therefore the switching problem is not fundamental —
it is tied to how strict the safety logic is while is still changing.
5. axis.c.eoffset (verified)C-axis following via external offset works as intended:
   This avoids position jumps when switching to CSP.
The only difficulty is that eoffset must follow the drift until the drive settles.
6. Next stepsTo improve switching reliability, I am looking at:

• refining the “stable position” detection
• adjusting the time window or allowed variation
• possibly applying a controlled zero-velocity ramp before switching
• or any CiA402 hints to get the LC20E into a stable hold state sooner

Summary (facts only)

• M19: no movement from the drive (verified)
• Mode switching: works and the drive changes operation modes correctly
• Switching is reliable once the post-M5 drift has stopped
• Stricter switching rules block early switching
• More permissive switching rules allow earlier switching
• opmode-display confirms correct mode transitions
• The remaining issue is the LC20E’s long settling period after stopping the spindle

Any hints or experience with LC20E behaviour after M5 or with CiA402 PV→CSP transitions would be very helpful.

Since a servo drive is generally very well suited for use as a C-axis — because of its precise positioning capabilities, torque at low speed and built-in encoder feedback — it would be highly beneficial to find a reliable solution for the remaining PV → CSP switching behaviour.If this last issue can be solved in a practical and reproducible way, the same hardware could be used both as a high-speed spindle and as a fully functional C-axis, which would make this setup useful for many other users as well.Any insights or suggestions that could help move in this direction are therefore very welcome.