How good is Ethercat motion control?

Sounds like 100% the right thing!

Huge thanks to everyone for the great discussion. It's crystal clear now. We're sort of running a open loop like system with LCNC and letting the drives handle the motion.

But the added benefit getting a real world following error is great to monitor and possibly to adjust the feed to keep everything tight. Which reminds me of Fanuc AICC.

Professional controllers like Fanuc, Mitsubishi etc. are using fiber optic communication to the drive and has some sort of tracking error control options such as AICC II or smoothing options, I'm guessing they're doing the same thing?

You don’t have a real following error! LCNC is only behind if it measures the following error! It compares an old position which comes time delayed due to the Ethercat cycle! 

I modified the DeAsda Hal driver so that I can read out the real following error of my DELTA Servo driver. At 20m/min, the error is less than 20micron (LCNC is showing something around 1.8mm) At normal speeds e.g. 6m/min, the following error is below 1micron (my servos do have 24-bit encoders)

That means, you can simply forget the LCNC following error….just make it large so that it does not stop your system! Use instead the following error limits in your drive or use the drive following error in LCNC to make your own Stop or Warning routine in LCNC, but don’t forget….the servos must be absolutely perfect tuned in the drive and do not use any p I d parameters in LCNC for that drive!!!

 

The only problem is when you want to synchronize with external movements (like tapping).

That's actually not often the problem. It isn't a very big problem.
For rigid tapping, threading and other synchronized moves repeatability is the key
Always the same starting position, follow the previous tool path
and that is the case even with a slight delay in the position from an axis.
To put in perspective, say a feed of 600 mm/min, gives a following error of 20 micrometer from 2 1 ms servo cycles delay.
Homing with switches should also be okay as long as homing is always done the same.
And, there is usually a slow feed state at say 30 mm/min => 1 micrometer off due to feedback delay.
Repeatability comes down to switch repeatability.
Homing on index is not affected.

The only real situation I can think of right now is with probing.
But again, probing speed of say 30 mm/min gives 1 micrometer off due to feedback delay.

@Hakan:

I would always home using the encoder index (Z-pulse) if it’s available, since it’s the most accurate and repeatable method. When the index is latched close to the encoder or in the drive, homing accuracy is essentially independent of fieldbus or servo latency. I use it with the Probe Basic and it works perfect

You are absolutly right! For probing, the usual and sensible approach is a two-step process:

Fast search pass to find the edge
Even with e.g. 3-4 servo cycles of delay (≈4 ms), probing can be much faster than often assumed.
If you allow 1 mm total overtravel, including braking, and assume a realistic probing deceleration of about 1000 mm/s², the maximum safe speed is still around 40 mm/s ≈ 2450 mm/min.

Slow precision pass
After backing off, the second pass is done very slowly, typically 0.5–1 mm/s.
With a 4 ms delay, this corresponds to only 2–4 µm of additional travel due to latency. At that point, accuracy is dominated by machine repeatability and machine stiffness, not bus or servo delay.

So in short:
Homing: use encoder index --> highest accuracy, latency-independent
Probing: fast find + slow precision pass --> latency is not a practical limitation if speeds are chosen sensibly

Latency really only becomes an issue if someone tries to do single-pass, high-speed precision probing, which is not standard practice anyway.