Analog servos: torque mode, velocity mode, both?

I am still in the construction process of a steel/epoxy concrete gantry style milling machine with 2 ballscrews driving the gantry/Y axis, single ballscrews for X and Z.
Initially I intended to use stepper motors to drive the axes, and I bought a 5i25+7i76 combo for that.

But I was lucky, and managed to trade 3 steppers+drives for 2x400W AC servo+drive and 1x750W AC servo+drive. The drives are an older model (model year 1994, construction year 1999) Omron OMNUC-U drives which accept analog control voltages. These drives are rebranded Yaskawa Sigma I series drives, and also recognised as such by Yaskawa's SigmaWin software. Motors are equipped with 2048ppr incremental encoders.
I intend to drive the gantry/Y axis using the 2x400W motors, one on each side of the gantry, and the X axis using the 750W motor (and Z axis using a stepper motor).

Now, it is quite obvious that I need to get myself a 7i77 to produce the +/-10V analog control signals for the drives. Buying that and hooking it up is something I can manage. But I would like some help about what control strategy to choose.

I can setup the drives in the following basic modes:
- Velocity mode. Single analog voltage required on REF input, the current/torque loop is then tuned on the drive.
- Torque mode. Single analog voltage required on TREF input.
- Velocity mode with torque feedforward; external torque input value is added to the internal calculated input. Two analog voltages required.

Velocity mode plus torque feedforward sounds ideal; fairly easy to get up and running using the drives' autotune for the speed loop and progressing from there. But that would consume all 6 analog outputs of the 7i77. None left for future expansion.
Thus, I am leaning towards torque mode; after all the control loop inside the drive is likely no different from what can be archieved using LinuxCNC's PID controllers. But how hard is that to tune compared to velocity mode?

So, what mode am I going to choose, and why?

So basically you are saying 'use velocity mode, and let the drive close the torque loop internally. Everything else is only better in theory but in reality there is no difference'?

Might be true. After all the servo loop must differentiate motor-pos-cmd to get velocity, and once again to get acceleration, which adds 1 servoperiod latency to the velocity command and 2 servoperiods latency to acceleration. Weird that there are no pins on axis.N providing this essential information, but that's another story.

I do need some way to control the spindle, indeed. Currently I use this , works OK and is fully isolated. Currently it runs on a PDM signal generated by LinuxCNC in the basethread, but running off a PDM signal generated by Mesa HW or a pwmgen at the servo rate is fine too.
RS485 is also possible and probably even better. Or I can keep the 7i76.

I would vote for velocity mode, especially if the drive has a high resolution absolute encoder...

Might be true. After all the servo loop must differentiate motor-pos-cmd to get velocity, and once again to get acceleration, which adds 1 servoperiod latency to the velocity command and 2 servoperiods latency to acceleration. Weird that there are no pins on axis.N providing this essential information, but that's another story.

For feedback velocity the encoder section of the driver calculates the average velocity of the last servo period
for commanded velocity, the pin is available from motion as a debug pin: axis.N.joint-vel-cmd,
but I think that is at the same pipeline level as FF1.

A lot of this oddness has to do with motions servo model in Linuxcnc that the servo loop be handed the
position of the _next_ waypoint even though its feedback position is current. This unfortunately causes a velocity
and servo thread period dependent following error if you use any I term.
(even a small amount I will eventually force the feedback position to equal the commanded position during a long slew)

(see the pid.N.error-previous-target patch workaround)

I would much rather see the _current_ commanded position and the velocity, acceleration,and jerk be available
for the next servo period segment, so for higher performance machines, the hardware can do the
extrapolation correctly.

andypugh wrote:

It seems wasteful to use the 7i76 only for the spindle control channels.

It is, although I need at least one stepper channel too for the Z-axis. Selling the 7i76 and using a small board with some custom electronics (which I need anyway) makes more sense; there are better ways to spend the euros than an 7i76 which is used for 5%. On the other hand the 7i76 is not an expensive board (at least not when considering the total amount of money thrown in the machine by the time it is 80% finished) and it is built very well, so the real gain is not that much. Not sure what to do with the 7i76 yet.

The 7i77 Analogue outputs will control the VFD speed nicely, and the IO can switch the fwd/reverse.
However, it might be less trouble to keep your existing interface to the spindle and run that off of some of the 7i77 GPIO. You only get 1kHz PDM (using the software pwmgen in the servo thread) but it will work.

I am sure the 7i77 analog outputs will control the VFD nicely, but I rather keep the VFD electrically isolated from the rest as it is by far the noisiest component in the entire system and I hate electrical gremlins. 1kHz or 2kHz PDM rate on a regular I/O is more than sufficient for a spindle with a time constant in the seconds range.

As an aside, my milling machine runs an encoder counter in the servo thread for my mpg.

With the average ca. 100ppr encoder wheel you must be superman to generate more pulses per seconds than servothread ticks.

But what about the servos? Just use velocity mode and don't bother?

PCW wrote:

I would vote for velocity mode, especially if the drive has a high resolution absolute encoder...

The encoders on the servo motors are 2048ppr (512 lines) incremental encoders, but I also see U,V,W (hall-sensor) signals toggling in the setup software so the drive at least knows the absolute position in 60-degree increments. 2048ppr is not exactly high resolution, but not bad either. If I can keep low-speed positioning accuracy to within +/- 5 pulses I am happy.

OK, velocity mode it is.

Is velocity mode also the best choice for the Y-axis? That's two servos driving the same gantry. The gantry is a fairly massive piece of epoxy concrete mounted on preloaded linear rails, and it doesn't rack much. So even at fraction of a millimeter scale these two servos can fight each other. I don't know if this could be a real problem, or that it is more a theoretical issue.

(even a small amount I will eventually force the feedback position to equal the commanded position during a long slew)
(see the pid.N.error-previous-target patch workaround)

Never thought about it and there is not much about it in the documentation, but it is indeed a bit odd.
On the other hand it makes more sense to tell the motion hardware where to go next than to tell where it should be currently. It is more a 'how to calculate following error' issue imho.

(BTW: what does LinuxCNC do with axis.N.motor-pos-fb besides showing it in the DRO and calculate following error?)

I would much rather see the _current_ commanded position and the velocity, acceleration,and jerk be available
for the next servo period segment, so for higher performance machines, the hardware can do the
extrapolation correctly.

If the motor-pos-cmd as is given now is 'next', then 'current' is as easy as adding an extra pipeline stage, just like pid.N does.
Having access to velocity, acceleration and eventually jerk (a little impractical since +inf/-inf is possible too) which correlates to motor-position-cmd would be nice though.

Sure you can get the current position by another pipeline stage (as the PID patch does)
But its needlessly complex. Providing current position and forward differences for extrapolation to the
next waypoint would be much cleaner.

I think your post also explains why I had a small but fairly constant speed-dependant following error when toying around with linear scale feedback on my current stepper-driven mill (with steppers in velocity mode). Still, I don't think that giving the position where the axis should be next servoperiod is such a bad thing; knowledge of the future is powerful information.

What are the side effects of choosing a higher servo thread frequency than 1kHz, besides processing power required? That would bring the various pipeline stages closer together in time and reduce phase shifts caused by latency. No idea if my machine-under-construction can be classified as 'high speed', but 2x400W servos capable of delivering 3 times their nominal torque to 'flimsy' 16mm ballscrews with little inertia should be able to push that 130kg gantry+Z-axis around with some serious speed and acceleration.

As I see it now with my limited knowledge the worst that can happen is that it does not provide any benefits at all; 1kHz is already a lot higher than mechanical bandwidth.


I also searched the forum, but could not figure out what LinuxCNC actually does with motor-pos-fb besides calculate a following error and display it on the DRO. Is this all it does, or is the information also used by the trajectory planner to increase path following accuracy?