How good is Ethercat motion control?

@Gogonfa, yes you can just increase ferror limit. Even better if you can use the real following error from the drive, there is often a pdo for that.
Not sure how to feed real ferror into motion but maybe there is a way.

Consequence is to not use PID loops involving linuxcnc. Let the drive do the job, tune it well like Gogonfa seems to have done.
Time sensitive signals like for homing - do it on the drive. Most other signals are not that time critical and can accept a couple of miilisecond delay without problem. Zeroing of encoder counters - on the drive.

Here is how it works.
Hal variable with direction In and Out are exchanged with the Ethercat drive, InOut is not suppported.
There is a distinct time when data is taken into hal: lcec.read-all. And written from hal: lcec.write-all
Data is then exchanged with the drive at the end of lcec.write-all.

It is a double exchange: out an in. Data for the pdos are sent from the ethercat master to the drive and
a few microseconds later data is received from the drives. Data is exchanged with the ethercat clients'
sync manager. The client app need a little time to prepare that so data is sent ahead of the Sync0 event. 

At Sync0 - which is the time that counts for the drive -  the drive now have the new commanded position
and can go ahead and do its thing.
The client puts the current position value (at time Sync0) into the syncmanager for later shipping.

At next data exchange event, next lcec.write-all, the current position is sent to linuxcnc.
However, no-one is interested in the data at this point, it is well beyond the lcec.read-all that reads in data to hal.

At the start of next linuxcnc servo period, the previously read data is read into hal with the lcec.read-all function.
There is no actual data exchange at this point, actual data exchnage only happens at end of lcnec.write-all,
so it uses the data the Ethercat master has kept from the earlier data exchange.

Note that this compares commanded position with current position. Not sure if that's fair,
maybe one should compare commanded position with position at end of the cycle so one can
see the effect of how well the servo actually can control. Delay is then three servo cycles. And my brain hurts.


 







 

Hi Hakan,

thank you very much for the detailed explanation - it was extremely helpful. It’s absolutely clear to me now how the timing works (lcec.read-all / lcec.write-all, the Sync0-based PDO exchange, and why the position feedback seen by LinuxCNC is inherently delayed by a couple of servo cycles).

Also, thanks a lot for the sketch/diagram … that made the whole sequence much easier to understand.

I’ll now check whether my delta drives provide a real internal following error / tracking error value as a PDO, and if so, I’ll try to map it into LinuxCNC.

Thanks again for taking the time to explain it so thoroughly.

Hi Hakan,
just a quick follow-up to my previous reply: I can confirm that extending the LCEC driver to expose the drive’s internal following error works fine with the Delta ASDA-B3 drives.I mapped 0x60F4 (Following error actual value) into the TxPDO and added it as a HAL pin (including scaling to mm). This gives a much more reliable “real” tracking error compared to the LinuxCNC ferror which is affected by the EtherCAT timing delay.For reference:
I patched the LCEC driver , rebuilt linuxcnc-ethercat and had everything working within a couple of minutes. Two additional pins are now available: srv-ferror-raw and srv-ferror (scaled to machine units).

You can also make your own following error check routine in LinuxCNC (HAL-side).
It could even be a more intelligent solution, for example reducing speed/feed when the error becomes significant, instead of immediately throwing a fault.

For anyone who wants to implement this: just clone the linuxcnc-ethercat repo, replace the file in the, build and install it (

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.