How good is Ethercat motion control?

After a quick look it seems the deasda driver includes a layer that kind of resembles the cia402 driver.
The drive itself is cia402.
deasda gives a large set of hal pins, with "generic" and cia402 one needs to puzzle that together self.

These drivers don't do very much more than translate between pdos and hal names, there is no real processing.
Some logic is in there, but there is no performance reason to select one or the other.


 

Thanks, Rod, for your fast answer.

I have a general question regarding following error (FERROR) when controlling servo drives via EtherCAT.

Is there a generally expected/inevitable following error caused by the EtherCAT cycle time (latency/jitter), even in a properly configured system?
Or would a noticeable following error usually indicate a configuration/implementation issue?

For reference: my servos are tuned and run with a very small following error of about 20 encoder counts in the Delta software (24-bit encoder, so basically negligible).
However, in LinuxCNC the reported following error increases with speed and can reach about 1–2 mm.

What would be a typical/acceptable following error range in a properly configured EtherCAT servo system? Any ideas?

Thanks for the clarification, Hakan

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.
 

Hi Hakan,

If LinuxCNC always receives the position feedback ~2 servo cycles late, can I simply “ignore” this by increasing the following-error limits (FERROR / MIN_FERROR), or does this latency actually affect the LinuxCNC motion planner/trajectory execution?

In other words:
Does LinuxCNC only use the feedback for monitoring/fault detection (so the part accuracy is still fine as long as the drive itself tracks well and has near-zero internal following error)?

Or does LinuxCNC actively “react” to the delayed feedback (e.g. by slowing down, modifying the commanded motion, degrading contour accuracy), meaning I cannot machine precise parts even if the servo drive is perfectly tuned?

So the decisive question for me is:
Can I still mill accurate parts with this inherent 2-cycle EtherCAT feedback lag, as long as the servo drive is properly tuned and its internal following error stays low — or does the lag directly reduce machining accuracy?

Thanks a lot for clarifying this.

Gogonfa wrote:

Hi Hakan,

If LinuxCNC always receives the position feedback ~2 servo cycles late, can I simply “ignore” this by increasing the following-error limits (FERROR / MIN_FERROR), or does this latency actually affect the LinuxCNC motion planner/trajectory execution?

In other words:
Does LinuxCNC only use the feedback for monitoring/fault detection (so the part accuracy is still fine as long as the drive itself tracks well and has near-zero internal following error)?

Or does LinuxCNC actively “react” to the delayed feedback (e.g. by slowing down, modifying the commanded motion, degrading contour accuracy), meaning I cannot machine precise parts even if the servo drive is perfectly tuned?

So the decisive question for me is:
Can I still mill accurate parts with this inherent 2-cycle EtherCAT feedback lag, as long as the servo drive is properly tuned and its internal following error stays low — or does the lag directly reduce machining accuracy?

Thanks a lot for clarifying this.

In position mode it has no impact, the drive is closing the loop. The feedback is just for "knowledge". So you set f error in linuxcnc to something reasonable (about 2mm on my machine cause its impossible to move that far in 2ms). Set the drives f error to something smaller if you need to.

 

For the CSP and similar modes generally the target position is fed directly from the joint pos-cmd output, so it does not go through a PID control to account for error like you might see in a velocity control loop with positional feedback.

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.