Position vs Velocity mode

Back in the day before the current chips used, the data for position mode was at times difficult to handle and had to be buffered on both ends to avoid stalls in motion because the drive had to process how to handle the coordination in the drive. In most cases Velocity mode was avoided because it forced the controller to do nano second position adjustments and if not tuned perfectly would cause runaway events leaving steps and tool marks in the drive.

In the industrial world the use of either position mode or torque mode are chosen. It reduces internal overhead allowing for faster feeds and more granular accuracy of motion. That said, torque mode requires additional tuning as well. The caveat in torque or velocity mode is that you machine MUST be very stiff mechanically. Otherwise you will forever be retuning the coordinated motion as all axis must be tuned to each other.

In position mode, the controller need only look at the FB compared to the actual and make minor adjustments in realtime on each cyclic data stream as needed. The drives of today have their own internal motion controller and active tuning while in position mode. This cuts out the middleman issue and allows for extremely accurate and fast position updates.

It is my express opinion that using V or T mode while possible, these are very impractical and overkill for hobby or light industrial as the cost of the required measuring equipment to tune the machine as tightly as position mode will pretty much do for you is very high. Ball bars and laser measurement is required and costs nearly $30k. And then there is the know how aspect. If you have tolerances of volumetric accuracy of .0005" or .01mm position mode is more than enough. Even for 5 axis work. Below that, and you must also include temperature compensation in the mix to maintain a true net accuracy below .01mm.

The best practice in position mode is encoder counts, encoder counts, encoder counts. 23bit absolute multi turn encoders area ideal. This gives the TP(Trajectory Planner) internal to the drive more than enough information to do nano second position loop adjustments and control servo error to sub micron accuracy. If you have a loose machine mechanically, this will help tighten the gap but never eliminate it. The second best practice is near zero backlash on all axis.

Hope that helps keep you from running down the rabbit hole of chasing tune.

Thanks for thorough explanation. Drive tuning is no big deal. So if I understand correctly, the position mode is way to go. Now we only have to sort out the excessive following error within linuxcnc in position mode. Can anybody explain, why?

Of course.

Well that is simple yet complex to explain. First, is the following error in the drive a match to the one derived in LCNC. The TP is in the drive so LCNC is not the ideal place to see the true FE.

In position mode, the controller should only need to send position commands as needed. It does not need to even know whether the following error exists given the actual position is dynamically controlled locally in the drive. Now, there are considerations in excess error. Time delay of the cyclic updates. Properly sized servo motors for the load(this is vital to ensure you have a 125% power to load ratio - see final note below), and the FF forward parameters which will ensure enough torque is available to maintain P/T or velocity until the loop position becomes zero. The position control loop receives a command to move 1" at 10 IPM. It will then take that 1" and use the Delta to start positioning the servo via the position FB loop to drive the motor from 1" to zero. The error is calculated within the Delta. The job of the Position loop is to make it to zero in the T requested. If it sees that the T is being stretched it will request more torque to compensate and if to early it will remove torque to comp that. The issue can be in many cases that the LI or load inertia is too great in both ACC/DEC states and continuous travel.

Most higher level drives have several params that adjust the servo response time, power levels, and FF(Aka Loop Gain). These drives also have dynamic auto tuning and if the input calcs for your inertial loads are accurately calculated will allow the auto tuner to account for the calculated load while tuning for you. But, that is the caveat. You must ensure that you have properly calculated the true inertial load of your axis.

Final Note -

The axis has a load characteristic before it actually starts cutting. Cutting requires additional torque to ensure the loop is maintained else you may have a perfectly tuned machine and fined out later while milling a slot that the error is pretty wide and may even see issues with blending or ovular interpolations. It is key to ensure that you know the static load(unloaded machine not cutting) and the dynamic load(machine moving the static while cutting adding a variable load). The math can be a bit much but there are many calcs out there in the ether to help. Once you know that value of what is specifically required, as a rule engineers like myself add 10-25% additional motor KW to ensure that the motion can maintain P/T and make targets without under shoot or overshoot and minimize oscillations at idle.

So if my calc says I need .75kw to handle S and D loads, then I install a 1kw servo. Keep my FF low, and use minor filter adjustments to cancel out ACC/DEC response at higher V.

Following error is more a measure of the servo response not the command response of the controller if in ECAT mode. ECAT can be used in closed loop of course, but that is redundant and increases chances of issues of imbalance of power. ECAT wants to separate concerns. Controller decides where the servo should go, tells the servo go here, the servo does it's job and next. If the servo has an issue, it has its' own ability to stop before disaster. Like I said, ECAT is better at point and shoot than have a controller try to manage everything. That would be like racing a Ferrari while hooked to a tow truck. It works, but the tow truck(controller) is never going to be a Ferrari(servo).

Hope that helps.

PS - Closed loop stepper drives and motors are not Ferrari's. More like a Lota. Lol. But, you can put a spoiler on a Lota and it looks pretty cool.

Thank you for explaining. So basically we are better off with position mode. Because servo drive is better at handling position commands from linuxcnc. I am running 8kHz linuxcnc servo thread which is the same as 8kHz cycle in B3 drives. The following error showed in servo drive is basically zero with proper tuned servo drive. The linuxcnc shows following error 0.22mm at 3000mm/s speed and 0.44mm at 6000mm/s and 0.88 at 12000mm/s. Does it mean that I should just set MINFERROR in linuxcnc with some room (so that I dont get following error errors), because the the following error which lonuxcnc shows is not the true following error? I will come back with screenshots and exact values later.

The problem with LCNC and ECAT is that the master which is lcec driver from EtherLabs has a lag over the true ethercat comm cycle. In their docs they show a .0005-.001 ms offset from the true 1 ms tick cycle required for true ether at frame rate. That means that the FB of position is at a lag. Therefore by the time the position is returned to LCNC and LCNC recalculates the new position and determines the error the data is outdated. So Lcnc will never be able to show the true error nor fully close the loop over ether at in the purest sense.


So yes, set the pos error in LCNC outside the theoretical value it derives from the outdated error value. If you see .22 set it twice the value. And forget about it. The drive error position if you want to actually see the true value can be assigned to a PDO on the Tx side if your drive supports this. But in order to use it in LCNC you will have to use a side routine to monitor it and stop if nth value is exceeded.

The other course of action would be to install a scale and set LCNC to use that position to monitor the actual position to derive error from. But it would be overkill and a waste.


With LCNC over ethercat think of LCNC as a GCODE sender kinda. The sender has no idea if the axis did its job for the most part and assumes it did. But since I have a really smart drive, my assumption can within solid parameters be correctly assume it did its job.

This is the best you will get with LCNC.

Vital Systems has developed a board for MaCh4 that uses an external ethercat controller over an Ethernet connection. It works very well and has the true 1ms tick cycle.

They will not develop one for LCNC due to the license issue with Open Source LCNC. They will only make black box devices. If the connect to LCNC by license they must expose the inner workings of their device. While I support open source software I do not on the hardware side. It is very expensive to develop and it would basically give company b the ability to bypass the cost of developing their own at the expense of company a. That is communism. Not my cup of tea. lol.

In any case in full summary, if you have a mean position tolerance near .0005” or .01mm then you be 99% sure that your motors will maintain the correct position at all times. The only variable after that to maintain that accuracy at the part is the mechanical system the motor is attached.


Hope that helps.

0.22 mm following error at 3000mm/s (and the fact that the error scales
with speed) means there is a ~73 usec difference between where the
drive sampled the position and LinuxCNC's commanded position.