How good is Ethercat motion control?

Hakan wrote:

You hit the weak point in linuxcnc Ethercat.
Position feedback from a drive is always two servo cycles behind.
Following error due to this is at least axis speed x 2 x servo cycle time.
You can easily verify this.

 

Not sure how this can be. The servo thread fires every 1 Ms (1000 usec), If you do a trace, It might take 200 usec to execute, then it sleeps for the remaining 800 usec) until it fires gain. The Ethercat thread and the Linuxcnc servo thread are synchronized. We read from lcec at the beginning of the servo thread execution, do our stuff, pids and position adustments etc then write write the result back to lcec then sleep as normal for the remaining 800 usec. How does it lag 2000 usec behind?
  

rodw wrote:

Hakan wrote:

You hit the weak point in linuxcnc Ethercat.
Position feedback from a drive is always two servo cycles behind.
Following error due to this is at least axis speed x 2 x servo cycle time.
You can easily verify this.

 
Not sure how this can be. The servo thread fires every 1 Ms (1000 usec), If you do a trace, It might take 200 usec to execute, then it sleeps for the remaining 800 usec) until it fires gain. The Ethercat thread and the Linuxcnc servo thread are synchronized. We read from lcec at the beginning of the servo thread execution, do our stuff, pids and position adustments etc then write write the result back to lcec then sleep as normal for the remaining 800 usec. How does it lag 2000 usec behind?
  

I thought it was 1 frame behind. but it definitely is behind. People trying the lichunan drives were having this issue when trying to use velocity command.

The WHY is above my pay grade.

@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.

Hakan wrote:

And my brain hurts. 

That, i believe!
Thank you for the detailed explanation.

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 (