Spindle orient PID tuning [re-solved, yay]

More
14 May 2022 23:49 #242989 by andypugh

Seems like once in a while it'll get close (within a couple degrees), stop, then jump and hunt until orient times out and errors.

This sounds like it is sitting in a position such that the P-term isn't big enough to request 60rpm. Then eventually the I-term integrates enough to get to 60rpm, but then it takes too long for the I to integrate down again. (This is a phenomenon called "I term wind-up"

At this point it might well be worth trying the inverse deadband. 
Actually I would probably use a lincurve to give the same effect. 

Or, possibly first, I would set up a variable gain (again using lincurve). 

If the error is within the orient complete window, then the P-gain would be low. 
At each side of that, the P-gain would be set up so that the output is at least 60 rpm. (eg, at 2 degrees on the X the Y would be 30, for a PID output of 60 degrees, 20 at 3, 15 at 4 etc. 

Having typed all that, I have looked at the other post and see that your P gain is 2000. Is the feedback to the PID in degrees or in revs?


 

Please Log in or Create an account to join the conversation.

More
15 May 2022 01:35 #242995 by spumco
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

Please Log in or Create an account to join the conversation.

More
17 May 2022 00:04 #243117 by andypugh

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.

You would connect the pid.N.error output to the X of the lincurve, then take the Y out of the lincurve to control the P-gain of the PID. 

(This is, unfortunately, a little bit circular, you either have to accept a stale error into the lincurve or have the PID gain change a cycle too late, depending on whether the "addf" of the Lincurve is before or after the "addf" for the pid.)


 
The following user(s) said Thank You: spumco

Please Log in or Create an account to join the conversation.

More
21 May 2022 03:07 #243456 by spumco
(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.

Please Log in or Create an account to join the conversation.

More
21 May 2022 16:33 #243484 by andypugh
Something like

-5, 2000
-2, 10000
-1, 0
1, 0
2, 10000
5, 2000

To start with.
The following user(s) said Thank You: spumco

Please Log in or Create an account to join the conversation.

More
22 May 2022 03:11 #243529 by spumco
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?

 
Attachments:

Please Log in or Create an account to join the conversation.

More
22 May 2022 10:29 #243546 by andypugh
I think that there is a scaling issue, indeed. It's in the lincurve. The example I gave you was in degrees, but the pid loop is working in turns.

Divide all the X by 360, and also make the centre deadband smaller, as you have a 0.5 degree tolerance. ie make the +1 and -1 +0.2/360 and -0.2/360 so that the PID only goes quiet when the spindle is inside the window.
The following user(s) said Thank You: spumco

Please Log in or Create an account to join the conversation.

More
11 Jun 2022 15:06 #244939 by spumco
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?

Please Log in or Create an account to join the conversation.

More
11 Jun 2022 22:31 #244962 by spumco
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.
 

Please Log in or Create an account to join the conversation.

More
12 Jun 2022 02:06 #244969 by PCW
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

Please Log in or Create an account to join the conversation.

Time to create page: 0.120 seconds
Powered by Kunena Forum