Position vs Velocity mode

That would be the combined lag for all users of that stream of data. Yes. But this does not actually matter.

LCNC is just 73ms behind the truth. But the truth is still happening at the part. Kinda like a time continuum. But the accuracy is not impacted because LCNC is not closing the loop. The drive is. LCNC is just a postman and a UI that also happens to pass out positions on an EtherCat stream.

Unless your round parts are not so round after all, there should be no real concern at all. The time it takes to make a round trip is not effecting the accuracy or overall outcome. The position displayed on the DRO will match the position that is in the drive. The error is only a concern of the actual loop controller which in this case is the drive. If it is within a desired tolerance on the drive then it is good.

Hope that helps.

Actually I would expect the drive to be behind LinuxCNCs command.
This can be determined by the sign of the velocity and sign of the
following error.

The realtime command yes. But the calculated error is downstream of the command and is calculated using the Tx PDO returned by the drive. The round trip time is what the original question was about.

But, like I said LCNC is not closing the loop, that is isolated to the drive in ECAT under LCNC. Hence the document from Etherlabs telling you that position mode is all that is really supported although the v and t modes are available.

The error in LCNC is really just showing the comm delay and not real error. Which if you compare the actual in the drive to LCNC you would see that LCNC has exponentially larger error. Which based on the 2-3ms tick cycle that lcec is capable of managing. The doc is available at Etherlabs.

Thank you Don Bozarth! You saved me a lot of hassle I would undergo with velocity mode!!

Thanks for laying this out. One question remains: what if linear scales come into the equation? Specifically ones that are connected to the servo drive and fed back to linuxcnc via ethercat.
I’d assume thatcher best approach would be to handle this feedback in the drive (again). However, what about gantry setups?

The gantry question is till open ended but I would have to assume like with standard Mesa or any other motion controller using the XXYZ, or XYYZ axis setup would send the synchronized commands for tandem motors. This works. As far as whether this is the case with ECAT, I have nothing specific to offer as I do not use tandem axis control aka gantry.

As far as scales, many drives offer a scale interface that can used within the drive as the primary position FB device and that position from the scale would become the FB sent to LCNC. But, again it is open loop from drive to controller and closed loop in the drive. Nothing changes there.

The difficulty with gantry is if you wanted use an auto squaring routine. Typically, if a 23bit encoder is used this makes the alignment pretty easy. You would unlink the tandem motors and and then use step jog or MPG mode to square the gantry by moving each motor until they are square to the opposing axis, say square x to y. Once complete and you like the final position, you would then use the drives routine internally to set the current locations of both motors to zero and store the motor positions in the drive. At that point you would need to somehow tell LCNC that when the axis FB is known from the drive, assume it has been homed. Or some variation otherwise.

There is another thread on the homing issues. A custom homing function is being tapped about with Rodw. There is a link to the github file. But, as far as I know, it is beta and does not show functionality for gantry type homing for those who do not have the higher grade 23bit multi turn Absolute encoders with battery storage of the encoder position through power cycle. In my opinion this would be the only way as I can tell with LCNC to have homing with a gantry. Given the pure open loop controller/drive interface and the I/O lag based on the Etherlabs ECAT driver, if you tried to use the I/O from the drive to catch the home switch and then catch the index pulse, you could have a roving home target.

You could however, use the RS422 encoder output from your drive which many have to catch the home switch input and then the subsequent index pulse using a mesa card. I do not know if it is 100% possible to do as I have never tried it, nut it is plausible. But, this adds wires and a Mesa card which may be nearly the cost of the upgraded encoder requiring the already available internal drive homing to all the work.

I am still running down this rabbit hole and if by chance I figure it out, I will post it with all the files needed.

I hope you'll do the same.

Glad I could help. This is what I do for a living but not with LCNC. I still learning the ins and outs just everyone else. Some of it makes sense, but much of it is wrapped around older technology with ParPort emulation through hal using step and direction drives. While they work and are cheap, they do not serve my specific interests or needs. I am a CNC engineer so I expect my machines and my builds to be as precise as the ones I build and design for my clients. If not more so. LCNC, is a free software that has ECAT, TCP, and some other functionality that make it affordable for my needs leaving me extra cash for the better hardware. Mach4 also has EtherCat but no TCP nor kinematics. That makes it very hard to to do true 5x work. So, I am going to use LCNC to build a very accurate +-.005mm volumetric 5x mill for my needs. Well, hopefully.

Have a great night guys. Feel free to reach out, I either know or know someone who does and will gladly help as much as I can.