Spindle control woes

Thanks Andy, here are the values:

cnc@cnc:~$ halcmd show pin pid.s*
Component Pins:
Owner Type Dir Value Name
14 float IN 0 pid.s.Dgain
14 float IN 0.5 pid.s.FF0
14 float IN 0 pid.s.FF1
14 float IN 0 pid.s.FF2
14 float IN 0.05 pid.s.Igain
14 float IN 1.01 pid.s.Pgain
14 float IN 0 pid.s.bias
14 float IN 300 pid.s.command <== spindle-vel-cmd-rpm
14 float IN 0 pid.s.command-deriv
14 float IN 0 pid.s.deadband
14 s32 OUT 1292 pid.s.do-pid-calcs.time
14 bit IN TRUE pid.s.enable <== spindle-enable
14 float OUT 230.2671 pid.s.error
14 bit IN TRUE pid.s.error-previous-target
14 float IN 69.73286 pid.s.feedback <== spindle-vel-fb-rps
14 float IN -135.8156 pid.s.feedback-deriv
14 bit IN FALSE pid.s.index-enable <== spindle-index-enable
14 float IN 0 pid.s.maxcmdD
14 float IN 0 pid.s.maxcmdDD
14 float IN 0 pid.s.maxerror
14 float IN 0 pid.s.maxerrorD
14 float IN 0 pid.s.maxerrorI
14 float IN 0 pid.s.maxoutput
14 float OUT 873.2758 pid.s.output ==> spindle-output
14 bit OUT FALSE pid.s.saturated
14 s32 OUT 0 pid.s.saturated-count
14 float OUT 0 pid.s.saturated-s

cnc@cnc:~$

Sorry about the time taken to reply, I was testing your suggestion and I think we have had a degree of success.
In changing to spindle-vel-cmd-rps, the spindle sits at a very low RPM for about 4-5 minutes then ramps up VERY slowly (takes approximately 10 minutes to get to 400 RPM and around 30 mins to 1000 RPM) but, when it gets to the commanded speed, it does hold there and maintains the commanded speed, so I think your suggestion has worked.

I have checked with HAL meter using the hm2 encoder count and hm2 raw count, that each turn of the spindle gives 2062 pulses (10 turns and averaged) which seems an odd number compared to a similar typical encoder count of 2048. That small difference (14 pulses) is readily apparent to the naked eye when the spindle is moved by this amount so I am reasonably confident that this (odd) figure cannot be interpreted as 2048 PPR. This is a bit strange to me in its own right... Using this as a datum though, setting 2062 PPR in the encoder scale (ini file) gives 500 RPM at the motor when S1000 is commanded, which given the 1:2 motor/spindle gearing is correct. I still don't really understand the wierd ppr number, nor the fact that 2062 PPR measured with 1 turn of the spindle should equal half that amount at the motor (through the gearing) unless hm2 encoder count measures all 4 pulses but then linuxcnc only uses the A+/A- pulse for its RPS spindle calcs for example (half the pulse number)...

Now that it seems that the speed is being controlled in a closed loop fashion, I am a bit vexxed as to where to go next to to make the spindle accel and decel behave normally.

Thanks again for all the help Andy!
Cheers.

One thing to remember in spindle speed control PID loops is that most of the
control (of drives with a speed command) is open loop (via FF0)

That is, using no feedback at all (a PID loop with all parameters = 0 except FF0=1)
You have a open loop system where the PID input command is simply copied to the PID output

This should be quite close to being correct before P and I terms are added to close the loop

Thanks for the tips Peter and Andy.

I think I have it mostly sorted now. One issue was the scaling, the VFD is standard being controled by a 0 to +10VDC signal. The "potentiometer" input voltage into the 7i47s for spindle control voltage output (pwm control) is slightly above 10V (a little closer to 12V) so I had to include some scaling there. After much testing and checking the correct encoder count was 2000 pulses to achieve the correct RPM downstream of the motor/spindle gearing.
Acceleration is fine and closed loop speed hold is apparent.
I may just need to tweak the PID etc settings just a little.
The spindle is a little slow to correct an offspeed condition, it will move about 1 rpm/15 seconds to correct itself back to target. I know that the parameters are all related, but I would like to know which parameter controls the aggressiveness with which the loop corrects itself to get back on target. I understand the balance of the system and that too much of this will cause hunting, but I would just like to slightly tweak the appropriate gain/parameter to have a little more authority in the correction back to target speed.
The current Spindle section of the ini file is attached for reference.
Once again thanks.
It is now 5am and I'm heading to bed

We got there!
Andy and Peter, just personally wanted to say thank you to you both for your help and the generosity of your time for the giving of that help!
Kindest regards,
Marty.

andypugh wrote:

I would start with FF0 = 1.0, that should give you close to the right speed immediately.
Then just keep increasing the I-gain until you get the effect you want.
You might not need any P-gain at all. Start with it at zero.

When the I-gain is too high you will get speed oscillations. About half the value that oscillates is probably OK.

I am adding to this old thread in case it is useful to anyone searching for info on closed loop spindle control. I have tried closed loop control a few times over the years with LCNC and always had the same result. The problem is the accel time for the spindle drive allows the PID loop I parameter to wind up very high which always results in severe overshoot when starting the spindle. If the value of I is lowered to minimize the overshoot then the speed regulation degrades.

Well, I visited closed loop spindle again yesterday and found the holy grail to the problem of overshoot yet maintain a reasonably aggressive speed control using the "I" term in the PID loop. The answer is the PID pin "maxerrorI" !!! That limits the max output from the I term which supresses the overshoot (due to accel time of the spindle drive) yet still allows tight speed control.

I post this because I read everything I could find on closed loop spindle and never seen mention of using "maxerrorI" to surpress overshoot. Hopefully others will find this usefull.

George

PS For my bridgeport with VFD spindle, I have P=0, I=4, D=0, FF0=1, maxerrorI=7 All speeds are now within a couple rpm's and lock in fast with almost no overshoot.

So some 12 months later, I am now finishing my manual to cnc lathe conversion and ironically having similar issues to the previous ones regarding spindle control.
I have a 3 ph motor controlled by a vfd. there are three photo interrupters on a disk with 120 slots and one index slot which is mounted on the spindle itself.
There are a number of gears between the motor and the spindle, but again critically the feedback and rpm/rps velocity feed back to linuxcnc is based directly off the spindle itself.
So, my theory, is that to some degree, regardless of whatever gearing is going from the motor to the spindle, linuxcnc is getting actual spindle rpm feedback from the source (the spindle itself) and thus, if the loop is closed and the PID gains are correct, in theory the motor output should regulate per that spindle feedback to maintain the commanded rpm regardless of the gear train in the interim.
The analogy being that if a driver is in a car, he references the speedo which is connected to the actual back wheels (true speed). Thus the driver (PID closed loop controller) can maintain the actual desired speed (via the accelerator and actual speedo feedback) regardless (within reason) of what gear he is in.
I have this in the HAL (max motor RPM is 2500)
#setp hm2_7i76e.0.7i76.0.0.spinout-scalemax 2500
Whenever this is commented IN the spindle behaves, but there is no closed loop.
Whenever this is commented OUT with a view to let the PID loop command the required output to arrive at the commanded spindle RPM (where the encoder measurement is located) the motor simply goes to max RPM with no regard to spindle RPM/velocity pins. i.e. if S150 m3is commanded, the encoder (actual) spindle rpm will disregard this and go to max motor RPM regardless.
From Halmeter I can see that invariably the commanded RPM is 2500 and this does not moderate until the motor goes to max RPM, i.e. ignores feedback vs commanded RPM. I ahve also tried various mult2 components to ensure rps feedback is rpm and vice versa without any indication the spindle rpm is being commanded in any other way than open loop...
I have a 7i76e controlling this lathe, but so far no luck with spindle control even though the feedback is from the spindle itself.
Regarding the INI file and encoder scaling, one rotation is correct with the spindle position increasing or decreasing exactly one turn.
You will also notice from the HAL file I have reversed spindle encoder input a and b pins. This was to test whether the spindle command may have been given as a negative vs encoder feedback, but again no change.
Have tested G33.1 and the Z moves with the spindle, somewhat confirming that spindle encoder information is being read at least for position.

As this machine stared life as a manual lathe, I have two MPG's on the saddle, one for X, one for Z, with the view that the lathe can therefore be used fairly easily in a manual context as well. Excuse the added complexity in the HAL, as there is some code to enable spindle speed control via the potentiometer on the saddle and thus be true to the idea of being able to operated easily manually as well. After where we go here, this would likely need to be modified.

So, in summary, I am in a quandary as to how to get spindle RPM control even though the encoder is on the spindle itself and thus largely independent of any gearing between motor and spindle.

Would also like to know, is the spindle rpm/rps feedback obtained from a and b encoder phases (via encoder scaling), or from the index pulse (one ppr with smoothing filtering)?

Thanks again.

Have included the relevant files.

Regards,
Marty.