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

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.

The stat-zero-speed comes directly from the drive, 12th bit of the statusword. 
No other processing is done. It seems there is some tolerance for zero.
Maybe your drive has some tolerance setting for this, mine didn't.

If the position is drifting in one direction I think you can check actual-velocity in hal
and switch modes when actual-velocity == 0.
Might combine this with oneshot component, so when actual-speed == 0,
you start oneshot to wait say 0.5 second before switching modes.
All done in hal at least when prototyping.
 

I now have reliable switching between spindle mode (PV) and C-axis mode (CSP).
The key issue was not the controlword itself, but the fact that the commanded and actual position of the drive did not match at the moment of switching.To fix this, I’m using a small custom HAL component (c_pos_sync).
While in spindle/PV mode it continuously feeds the C-axis command position with the actual position (a “follow” mode).
When switching to C-axis mode, this offset is preserved — so there is no position jump and no mode-fluttering anymore.With this in place:

• M3/M4 work normally in PV mode
• M5 stops correctly
• M64/M65 switch to C-axis mode without instability
• G0/G1 C… moves work as expected
• Switching back to spindle mode is also stable

The zero-speed bit from the statusword is now used only for diagnostics, not as a gating condition for switching — this was the original cause of the Mode 3 ↔ Mode 8 oscillation.M19 is not fully tuned yet (separate topic), but it no longer affects the mode switching.I’ll attach the HAL file and the small sync component in the thread.