Position vs Velocity mode

Hello,
i have EtherCAT setup with Delta B3 servos. There is option to go for Position or Velocity mode when configuring servo drives in xml file.
The position mode works straightforward, but the following error is quite big - up to 1mm depending on actual speed. Actually it is proportional - the faster you go, the bigger the following error.
The other option is Velocity mode, I guess you need to use PID component to be able to tune the velocity loop.
I only tried velocity mode on my other setup (mesa 7i95t with Delta B3L drives) and I was able to tune following error down to 0.00X mm at peaks.

So my question is, what are the pros and cons for both modes if its over EtherCAT?
Also how is following error calculated in position mode over EtherCAT?

I think lot of people go for linuxcnc due to ability to use EtherCAT, so deeper explanation for correct configuration would help to many of us.

Thanks

I have configured my ethercat z-axis to velocity mode and used pid to adjust the following error. The advantage of position mode should be that it can be used without much adjustment, while velocity mode requires a lot of adjustment.

If using position mode, you will have to adjust servo tuning and following error in the servo drive

I think you have to adjust servo tuning either way. There are parameters impacting speed loop, which is used in velocity mode. In position mode there is extra position loop.

Are you talking about the tuning on the servo drive? I have already turned it off. I have only adjusted the stiffness setting on the servo drive, but it seems to be useless. I adjusted the stiffness using the p item in the pid

I’m talking both. How to make the whole setup accurate and reliable. Tuning a servo drive is a necessity.

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.