Position vs Velocity mode

Thanks for the reply, sorry, I wasn't clear in my post - I'm not targeting nm error, it's not even possible on my machine, just that ~160nm would be the max possible error caused by the latency in EtherCat master at the worst case for my mill. This is such a small number in comparison to all of the mechanical induced error that surely it wouldn't stop me using linuxcnc in closed loop with linear encoders?

I currently have just under 20um of following error using steppers with linear encoders on my X and Y axis, and was hoping I could use the same setup on my Z axis but with an ethercat servo instead of a stepper.

That error is well within normal ranges even using a scale. It is never recommended to use a combination of stepper and servo though. It can be a challenge to match the FF gains due to the mismatched inertial loads of the motors. This will become apparent when you do an interpolation in 2 axis XZ or YZ or a 3 axis XYZ where blending will be an issue. Other than that, your experiment should yield some measure of success. The extent of which will be trial and error your part.

Are you using a Mesa for scale feedback? Typically, the scale will be connected to the TP connect device. In Ecat this is the drive. The A3 drive as far as I can tell accepts an external CL feedback device. But I think it is serial using SSI, or EnDat. I don't remember seeing an incremental scale interface for the A3 in the manual.

Like I said, as far the Ecat driver for LCNC, I do not see the support for closed loop control which makes sense given the pos mode only true support. But, I have been wrong before and have no experience trying to get LCNC closed loop over ECAT. Typically you want to close the loop as close as possible to the TP and PID controller. In POS mode, that will be the drive. In VEL or T mode the choice is yours.

Finally, in ECAT the DC(distib clock) is used to sync a specific bit to all devices so that for motion all drives will react simultaneously to commands within the same time domain. That is the SYNC bit. Once the Tx is returned with all devices ACK through the working counter they are ready to do work, the sync bit is set and the drives go to work. This happens every bus cycle. Using non-ECAT drives would preclude any ability for you to control the sync domain. It may not be too much of an issue unless doing any machining that require absolute sync during interpolation. The drives individually may no error of substance but the axis to axis or linking error will certainly be undeniable. How much error is a crap shoot on every interpolation start.

Good luck Sir.

Page 6-39 of the ASDL-A3 drive manual shows support for an Inc. scale interface input for CL mode internal to the drive on CN5 pins 1-9.

I have doing some experiments today and it is possible to run ethercat sync below 1ms interuption.. I have tried 250us sync and it was fine... but I do not know how it will be outside of bench top ...my prehistoric servo drivers has limit at 250us ... I did not test them with sync motion just communication setup and I have generic ec driver only... 

It should be great to test them then anyway.. 

I followed with interest the initial discussion on the machining precision, with respect to the response delay of the motor position, via PDO to the LNCNC. In reality the numerical controls, for example Siemens 840d, have 2 parameters for each axis, which are the coarse stop and the 'precise stop. The problem arises, for example, when you finish one movement and start the next. Siemens at least waits for the axis interested in making the first movement to return to the precise stop control window.
Only after returning to the precise positioning window will the next line be executed.
LNCNC does not have this parameter, so in reality the passage between one movement and another does not take into account the real position of the axis, unless it is in the following error window.
Therefore, a tracking error that is too high, or an excessive delay in the information via ethercat, will lead to a premature transition to the next line of gcode and therefore a profile that is not perfectly equal to the programmed one, especially when you go faster.

Hi!
@zmrdko : 
thank to you and other experienced users in this thread for educating other folks and providing invaluable linuxcnc knowledge. I have some follow up questions on one of your posts:

- Would you mind sharing which z390 motherboard manufacturer / series do you have that allowed you to achieve 2.3us latency?
- What Intel PCIe Ethernet card did you choose? I saw that in this thread: gitlab.com/etherlab.org/ethercat/-/issues/104 they recommended "cheap realtek 100mb/s" ethernet card.
- Did you go with intel integrated graphics?
- IIRC, you (or maybe other user?) mentioned that with newer kernel the performance dropped from 8kHz (at 4.19rt) to 4kHz.
- Were there any other factors that positively affected performance besides the servo thread latency to get 8kHz? (e.g. ethernet roundtrip was quick)
- Have you measured how long does it take to execute your HAL components in each control cycle?
- Is there some other computer hardware that you leaned about and would be eager to try out with EtherCAT?

I hope this is not too much off-topic. Please correct me if there is a better form to ask these questions.

Thank you for your consideration,
Regards, Jakub