Analog servos: torque mode, velocity mode, both?

OK, copied the question to a new topic and removed it here. Sorry for the inconvenience.

I tried setting up the Omron OMNUC-U / Yaskawa Sigma-I servo drive with 750W motor on the X axis in velocity mode.

I had little luck doing so. I could not get the velocity loop inside the drive stable. Motor either kept on vibrating and making hissing noises, or would not come to speed quickly when commanded to do so by LinuxCNC. I tried the entire spectrum of settings for 'mechanical rigidity', used the autotune function with those various 'mechanical rigidity' settings, and tried tuning the speed loop gain and integration time constant myself.

No luck. autotune makes a mess of it. Manual tuning was better. But even then: if i was able to jog the motor from within the drive configuration software without vibration and overshoot I saw in HALscope the output of a fullscale speed command during acceleration and deceleration, and a huge ferror that I was unable to tune away.

Tonight I tried torque mode. 3kHz servo thread, single PID controller using P,I,D, FF1 and FF2, pid.0.feedback-deriv connected to the velocity output of the 7i77 encoder, and pid.0.error-previous-target set to 1.
I had much more luck with that. Quiet motor, fairly decent response for a first tuning effort.

At 6000mm/min:


ferror is in millimeters. Lower speeds give lower peak-to-peak ferror.

It could use some more tuning effort, but the 'oscillations' in the image match the ballscrew pitch and when watching the rotating screw I can see that it is not perfectly straight (oh, the joys of Chinese goods). It seems the screw needs a varying torque during it's travel because of that. I have to fix that first before I can improve the tuning.

Question: did anybody notice similar speed loop behaviour with those Sigma-I/Omnuc-U drives? I still think I did something wrong somewhere; all that servo stuff is new for me and it seems that there are many of those Sigma-I/Omnuc-U drives in the field perfectly doing their job.

No, I tried to tune it in the system itself (but that is fairly low inertia too, although the friction of the preloaded ballscrew nuts and bearings do add some damping)

I guess I would _really_ try to find out why velocity mode does not work
it should be easier to tune and allow lower servo thread rates.

You do need to make sure that there are no input filters enabled on the velocity command.

If lLinuxCNC is controlling a velocity mode drive, the "tuning" is mostly setting FF1
properly and finding how much P is still stable. (D should not be needed)

FF1 will be ~1.0 if the units are normalized by setting the analog out scale to machine units/sec at 10V

I did some Googling on the velocity mode issues, but no luck so far.
Also, when the servo runs in velocity mode there is not that much to tune:



In simple velocity mode without auto-this, auto-that there is only a command scale, loop gain and loop integration constant to tune.
The 'machine rigidity' factor pre-selects a pair of loop gain/integration constants and autotuning works from there. No magic behind that.

There are 'maximum acceleration' settings, which are disabled. And there is a torque command filter that also works when the velocity loop is closed internally. Played around a little with it, but unless set for really low bandwidth it does not make a huge difference so I reset it to factory default.

When using velocity mode I had a P around 30 and an FF1 of 1.0, all other parameters set to zero. Played around a bit with them, but too unstable or too slow depended on the loop settings in the drive. Verified that by jogging the motor under control of the SigmaWin software.

I still suspect I am missing something somewhere, but what? There must be thousands of units in the field working just fine...

I am beginning to suspect that I am not missing anything and that the builtin speed loop is not that great at all if one desires both a fairly high bandwidth and accuracy.

Omron/Yaskawa provided a mode where the drive can be fed with both velocity and torque information through two separate analog inputs. I am beginning to suspect that they had a reason to do so.

From the manual:


Very similar to what I see when using the drive in velocity mode. The area between the solid and dotted line in the bottom graph is following error...


Now, everybody here who has more than 2 hours of servo tuning experience says 'use velocity mode if you can'. It would not be wise to ignore that.
But being someone with less than 2 hours of servo tuning experience I do not see the problems of torque mode yet.

What I see is:
- The drive uses a 7,5kHz PWM frequency to control the IGBT's, so updating motor current (torque) with more than 3-4kHz makes little sense.
- Computer runs a 3kHz servo thread easily. I got a realtime error once at 5kHz, but I was running two WinXP VirtualBox VM's at the same time.
- I doubt that the drives' internal 'servo thread' for the speed loop runs much faster than 3kHz; drive model year is 1994 so the design is more than 20 years old. We considered a 2-4MIPS 16-bit embedded processor state of the art back then.
- Given the low mechanical bandwidth a 3kHz servo thread plus MESA 7i77 analog hardware plus hm2 encoder velocity estimator fed by a 8192 counts/rev encoder doesn't seem to consume enough phase margin to only make low bandwidth loops possible.
- I agree that an inner velocity loop and outer position loop should be easier to tune; that smells a lot like PIV control and being able to tune using variables like 'damping' and 'bandwidth' has advantages and can take the guesswork out a bit. But my first stab at tuning the loop using P,I,D,FF1 and FF2 coeffs seems not bad at all, and I would not classify the tuning effort until now as 'hard'. But on the other hand I have not yet disturbed the loop by pushing an endmill through steel.

Can someone educate me a little in this?

Sounds like the drive really needs torque feedforward
Fanuc drives of similar vintage have this and many other workarounds
for their relatively slow (4 or 8 KHz) sample rate.

So in your drives case it looks like LinuxCNCs PID is smarter
(or at least more configurable) than the drives...

I don't have a lot of experience tuning servos but I have tuned (tried to anyway) a torque mode setup. The system I was tuning did not have as high of encoder resolutions as it appears you are using. But if you have not seen it I had a fairly long thread on this newsgroup that may show some of the potential pitfalls of using torque mode in a marginal system. While I was able to achieve acceptable performance I think the system could have been stiffer with faster response if I had used these drives position mode with encoder feedback to a 7i85s running the step gens in velocity mode, rather than the 7i77/torque mode that I used (these drives did not offer analog velocity mode). I tuned another machine with similar drives and the 7i85s setup, it was much simpler to tune.

Here is a link to that thread.
linuxcnc.org/index.php/english/forum/10-...-servo-tuning-advice

There are a lot of hal scope screen shots in the thread (It looks like some of the pictures on the first couple pages have been lost) A quick look back reminded me of one torque mode gotcha. The discussion in this thread uncovered a possible bug with how following errors is calculated. This doesn't seem to affect velocity mode tuning like it does in torque mode. I think a fix/patch was made to compensate, but I don't remember how much difference it made (or how much I messed with it). I was kind of sick of messing with it at that point

I think I will stay with torque mode for now and move control to LinuxCNC.
Not many other options; the drives only accept analog voltages for both torque and velocity, and the velocity loop seems to perform not too well.

I'll see how far I get using the standard LinuxCNC PID component. If tuning proves to be too hard I could make a PIV component (or nest two PID controllers; there is not much more to PIV than an inner velocity loop and outer position loop), which should make tuning torque mode servos easier.

I have seen the ferror discussion, and I actually used the advice given by PCW to start tuning. Anyway: PID position error with pid.N.error-previous-target set to 1 is the important variable and ferror is not. ferror is used for checking but not much more it seems. And with higher servo thread rates the values move closer together anyway. The one servothread cycle delay would produce an extra 'virtual' 0,17mm ferror at rapid speeds and less than 0,01mm at 'finish milling' speeds. That is acceptable.