Spindle orient PID tuning [re-solved, yay]

I think it's in revs:

# ---Encoder feedback signals/setup---
setp [HMOT](CARD0).encoder.00.counter-mode       0
setp [HMOT](CARD0).encoder.00.filter             1
setp [HMOT](CARD0).encoder.00.index-invert       0
setp [HMOT](CARD0).encoder.00.index-mask         0
setp [HMOT](CARD0).encoder.00.index-mask-invert  0
setp [HMOT](CARD0).encoder.00.scale              [SPINDLE_0]ENCODER_SCALE

net  spindle-revs                       <=   [HMOT](CARD0).encoder.00.position
net  spindle-vel-fb-rps                 <=   [HMOT](CARD0).encoder.00.velocity
net  spindle-vel-fb-rpm                 <=   [HMOT](CARD0).encoder.00.velocity-rpm
net  spindle-index-enable               <=>  [HMOT](CARD0).encoder.00.index-enable

I looked at the inverse-deadband thing you mentioned and that's a non-standard component, right?  I'd have to install it (somehow) before using it - not sure how to do that.

Same thing for lincurve.  I read up on the comp - looks useful - and I get how to create the x/y lookup chart, but I'm hazy on how to connect that chart a PID P-gain function.  Forum searching reveals some useful lincurve examples for an anolog spindle speed correction, but I've not found anything for other applications.

-Ralph

(I'm back to fiddling with orient while I'm waiting on a reply to the carousel thing)

Here's what I've got in the test HAL:

#setp pid.o.Pgain                        2000   #[TUNE]P
setp pid.o.Igain                        0   #[TUNE]I
setp pid.o.Dgain                        250   #[TUNE]D
setp pid.o.bias                         0   #[TUNE]BIAS
setp pid.o.FF0                          0   #[TUNE]FF0
setp pid.o.FF1                          0   #[TUNE]FF1
setp pid.o.FF2                          0   #[TUNE]FF2
setp pid.o.deadband                     0.005   #[TUNE]DEADBAND
setp pid.o.maxoutput                    210   #[TUNE]MAX_OUTPUT
setp pid.o.error-previous-target        true
setp orient.0.tolerance                 0.8

setp lincurve.0.x-val-00 0
setp lincurve.0.y-val-00 0
setp lincurve.0.x-val-01 0
setp lincurve.0.y-val-01 0
setp lincurve.0.x-val-02 0
setp lincurve.0.y-val-02 0
setp lincurve.0.x-val-03 0
setp lincurve.0.y-val-03 0
setp lincurve.0.x-val-04 0
setp lincurve.0.y-val-04 0

net orient-lincurve-in                  <=  pid.o.error
net orient-lincurve-in                  =>  lincurve.0.in
net orient-lincurve-out                 <=  lincurve.0.out
net orient-lincurve-out                 =>  pid.o.Pgain

Obiously I've set the lincurve pairs to 0 as this was a cut-paste from a thread on spindle pwm control. 

Suggested starting pair values based on the earlier 'moderately close' orient behavior with P=2000?

Your patience is remarkable, BTW.

So lincurve addition didn't throw any errors and I started running/tuning orient.

M19 kept timing out... and I noticed something strange in halshow.

orient.0.poserr always winds up way off - which, presumably, is why it times out with an error.  But poserr looks funny, like a scaling issue or something.  The spindle is getting close and the PID is twitching/hunting, but poserr is reporting almost a full turn off.

What would cause the orient poserr to be almost a full turn off, yet the PID thinks the target is close enough to be wagging +/- just a little?

 

Thank you Andy - the scaling put me on the right track.

Adjusted the lincurve & deadband and it's no longer wagging dramatically.  Still twitching a bit, but with the earlier lincurve values divided by 360, deadband = 0.003, and tolerance = 0.2 it's achieving 'is-oriented' within a second or two.

I copied the basic scheme from this thread:

forum.linuxcnc.org/10-advanced-configura...le-lock-brake#225912

with the thought that having an electronic spindle/orient 'brake' would be useful.

It's decision time - do I abandon the 'brake' function, or do I try to tune the remaining wiggle out down to a few counts?

Any suggestions on getting more of the wiggle out?

While not back to square 1, orient is starting to aggravate me.

It's not repeatable.  I can run an M19 orient command four times in a row, and it doesn't respond the same way twice.  I set up a halscope to see if that helped make sense of what's happening.. but it isn't helping me understand the seemingly random responses.

I've got a simple little program to run the spindle for a couple seconds, stop it, then orient.  I'm giving it 3 seconds to orient before it throws an error.

Multiple tests with the same lincurve & deadband values result in wildly different results.  It usually orients the first or second time if I tweak an input value, but after that it's hopeless.  Or it will fail four times in a row... then it nails the orient in less than a second.

Adding a little (relatively) I-term seems to have helped, but it's not what I'd call reliable.

Multiple screen captures attached - all are with the same settings.  First one nailed it, remainder failed.
 

My take on this is discard lincurve and fix the orient component so it outputs
a followable motion command (add orient velocity and acceleration constraints)
That way the PID heavy lifting will be done by FF1 like a standard velocity mode
servo. Step command inputs and integral terms don't get along very well