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.