Joint vel-cmd for torque PID loop and linear encoder PID

Patch was pushed to 2.7 and master branch github.com/LinuxCNC/linuxcnc/pull/467/co...e215d95a80a6f1d413ac

As for feedback-deriv, it's only useful for torque PID loops as it uses D term, and allows you to make the torque output less noisy, but I've got a strange issues when I connected it for the Z axis. Maybe someone faced it too, and it was left unconnected. Still it works perfectly for X and Y axes.

Well it looks like I need to try some alternatives to using torque drive with linear scales, because of position mismatch of two PID's during homing (causes massive jerk after finding index pulse and a following error) and reset of linear scale PID's integral error doesn't allow you to continue work after switching drives off.
I found that it could be possible to use velocity control servo and linear scale position PID only, leaving servo position loop unused. If I understood correctly linear scale PID will generate velocity command directly to the servo drive and it should be OK for the backlash present in system, because velocity control is done inside servo and it doesn't matter from where the velocity command has come. Still some manuals insist on two position loops. And the resolution of scale is lower than rotary encoder's one, what may be a big problem.

My previous attempts of tuning this servo in velocity mode were a bit unsuccessful, but now I found that it have torque feed-forward function which may help with tuning. I need help with setting it up in HAL, because I don't understand what I need to use as a torque feed-forward reference.
Here is block diagram for that from manual:


Also I found that my drives have speed/torque input reference time constant of 47 microsecond which gives cut off frequency of 3386 Hz (1/(2*pi*0.000047)) and that means that it shouldn't give any difference if I run servo thread faster than that. Now it's running on 6.67 kHz. Possibly internal torque loop is much faster than 3.3 kHz. Please correct me if I'm wrong.

PCW, could you please look into this?

What problems do you have with plain old velocity mode?

I would expect that inertial compensation (torque feed forward)
would be something that can be done in the drive

I couldn't get it stable and prevent drifting, possibly because of lack of experience So I switched to torque mode.
Drives do have some load inertia parameter with Kg.cm^2 values for setup, but for now I don't have any means to read this value from drive.
Anyway I want to try it again and get better results than with current torque mode and manual says that torque feed-forward reduces positioning time for velocity mode.
My main question is what will be the consequences of using only one PID from linear scale for positioning with velocity mode drive. Motors have 2500 ppr encoders, and final resolution is 2000 and 4000 counts per 1 mm. Scales are 1000 counts per 1 mm. Or maybe there some ways to avoid problems with two position PIDs.

A velocity mode drive should only drift when the PID control is disabled. If the drives are enabled at any time when Linuxcnc is not controlling them (machine off F2) then they can and will drift. The drives should ONLY ever be enabled when Linuxcnc is in Machine On. If Linuxcnc is not in control of the drive enable, it is a dangerous situation that needs to be corrected. If you are having drifting with Linuxcnc in Machine On and a non zero P value, then something is wrong.

Thanks Todd, I know that this shouldn't happen under nornal conditions.

Well I read some articles that tell about PIV control, feedforwards and dual loop feedback, and found this image:

They say that PIV control may perform better due to nested loops that work on different bandwidth, than a single PID loop. Article for that image says that it will be ok to close the position loop on the linear scale and add velocity/acceleration feedforwards for stiffer positioning, as they allow to make movements before error adds up.
I see that in case of LinuxCNC the FF1 term of position PID is the velocity feedforward and it will be better to connect joint-vel-cmd to command-deriv pin to remove the delay, and newly introduced pin for acceleration command can be used as torque feedforward. How I should connect it to DAC and what scaling I have to use for it?

When you are using your drives in velocity command mode, the velocity loop is closed in the drive. If you want to use them in torque command mode, then you will need to close that loop in Linuxcnc. It is difficult to process the servo-thread fast enough in Linuxcnc to get really good results for a torque command. It is almost always better to let the servo drive handle that. But if you insist, you can set up a cascaded dual PID loop in Linuxcnc. The first is an ordinary PID position command loop. that outputs a velocity command to the 2nd PID loop and that is the velocity loop it inputs the velocity command (connected where the position command normally would go) and outputs the torque command that goes to the drives analog input. I have 1 machine setup this way, and I know that I've posted the config files on this forum before. A quick search should be able to dig the example files up. I did this machine this way because the drives I was using only accepted a torque command. If I could have used a velocity command I would have. I was also able to make it work with a single PID loop but it was much more difficult to tune and wasn't quite as stiff.

I've already done that for my machine, results are on a first page (shortcut - single PID did better). Servo is running 6.67 kHz, this is more than enough for torque mode. I could've leave it as is, but I'm using linear scales in addition to rotary encoder, and facing some problems which force me to choose some different ways to control the system. Drives support torque feed-forward for velocity mode, and I want to use it.