| Topic: |
Science > Physics |
| User: |
"Gregory L. Hansen" |
| Date: |
05 Feb 2004 08:58:16 AM |
| Object: |
CuPID Controller |
We're changing the DAQ software a little to turn the PID controllers into
CuPID controllers. That is, output with terms proportional to the cube of
the error, the error, the integral of the error, and the differential of
the error. I don't know if CuPID is a standard term, but it seems like a
logical term, I like it. I also don't know if it will help much, but
we're making some other changes, and as long as we're mucking around in
there, this one is almost trivial to add. I wanted the extra term to give
a more aggressive correction when we stray far from the set-point. It can
always be set to zero.
Is there any guidance, something analogous to the Ziegler-Nichols method,
for setting run parameters on such a four-term controller?
--
"I'm giving you the chance to look fate in those pretty eyes of hers
and say, 'Step off, *****. This is my party and you're not invited.'"
-- Chris Shugart, _Testosterone Magazine_
.
|
|
| User: "Tony" |
|
| Title: Re: CuPID Controller |
06 Feb 2004 10:31:10 AM |
|
|
(Gregory L. Hansen) wrote in message news:<bvtlm8$ha0$1@hood.uits.indiana.edu>...
We're changing the DAQ software a little to turn the PID controllers into
CuPID controllers. That is, output with terms proportional to the cube of
the error, the error, the integral of the error, and the differential of
the error. I don't know if CuPID is a standard term, but it seems like a
logical term, I like it. I also don't know if it will help much, but
we're making some other changes, and as long as we're mucking around in
there, this one is almost trivial to add. I wanted the extra term to give
a more aggressive correction when we stray far from the set-point. It can
always be set to zero.
Is there any guidance, something analogous to the Ziegler-Nichols method,
for setting run parameters on such a four-term controller?
Seems easy enough to do empirically. Just feed the correction
algorithm a sine wave and see what the output is. Scale
for your control out and see if you stay in reasonable bounds.
Cheers,
Tony.
.
|
|
|
| User: "Gregory L. Hansen" |
|
| Title: Re: CuPID Controller |
06 Feb 2004 11:03:59 AM |
|
|
In article <bd9a613.0402060831.a7d496c@posting.google.com>,
Tony <bjlapen@hotmail.com> wrote:
glhansen@steel.ucs.indiana.edu (Gregory L. Hansen) wrote in message
news:<bvtlm8$ha0$1@hood.uits.indiana.edu>...
We're changing the DAQ software a little to turn the PID controllers into
CuPID controllers. That is, output with terms proportional to the cube of
the error, the error, the integral of the error, and the differential of
the error. I don't know if CuPID is a standard term, but it seems like a
logical term, I like it. I also don't know if it will help much, but
we're making some other changes, and as long as we're mucking around in
there, this one is almost trivial to add. I wanted the extra term to give
a more aggressive correction when we stray far from the set-point. It can
always be set to zero.
Is there any guidance, something analogous to the Ziegler-Nichols method,
for setting run parameters on such a four-term controller?
Seems easy enough to do empirically. Just feed the correction
algorithm a sine wave and see what the output is. Scale
for your control out and see if you stay in reasonable bounds.
An interesting idea. Our DAQ can do high-low and a random input for
calibrations, but I know sine waves have a special place in the engineer's
heart. I wonder if that would be a useful thing to add.
--
"Don't try to teach a pig how to sing. You'll waste your time and annoy
the pig."
.
|
|
|
| User: "Tony" |
|
| Title: Re: CuPID Controller |
07 Feb 2004 07:21:09 AM |
|
|
(Gregory L. Hansen) wrote in message news:<c00hdv$g77$1@hood.uits.indiana.edu>...
In article <bd9a613.0402060831.a7d496c@posting.google.com>,
Tony <bjlapen@hotmail.com> wrote:
<snip stuff we already read>
Seems easy enough to do empirically. Just feed the correction
algorithm a sine wave and see what the output is. Scale
for your control out and see if you stay in reasonable bounds.
An interesting idea. Our DAQ can do high-low and a random input for
calibrations, but I know sine waves have a special place in the engineer's
heart. I wonder if that would be a useful thing to add.
As you no doubt found out, your random input into the integral and
differential portions make a mess of your output. There is nothing
magic about a sine wave, but it does have a nice smoothly changing
derivative. This helps exerscise the entire algorithm without any
sharp dislocations in the differential. And, of course, sine waves
are easy to come by. You could simply hook up a signal generator to
your DAC. Since you mentioned that you are changing the software,
I thought maybe you just code up a sine function that replaces the
DAC output as the numerical source data for the rest of the algorithm.
This way, you can do the whole job on your computer, and you don't
need to scrounge a signal generator.
* Indiana.edu, Huh?, grab an undergrad, and assign the critter the
* task of building a signal generator out of parts obtainable at
* the local Radio Shack! That should do it.
* Say Hello to the Oracle for me.
http://cgi.cs.indiana.edu/~oracle/index.cgi
Cheers,
Tony
.
|
|
|
| User: "Gregory L. Hansen" |
|
| Title: Re: CuPID Controller |
07 Feb 2004 07:47:51 AM |
|
|
In article <bd9a613.0402070521.6f066e80@posting.google.com>,
Tony <bjlapen@hotmail.com> wrote:
glhansen@steel.ucs.indiana.edu (Gregory L. Hansen) wrote in message
news:<c00hdv$g77$1@hood.uits.indiana.edu>...
In article <bd9a613.0402060831.a7d496c@posting.google.com>,
Tony <bjlapen@hotmail.com> wrote:
<snip stuff we already read>
Seems easy enough to do empirically. Just feed the correction
algorithm a sine wave and see what the output is. Scale
for your control out and see if you stay in reasonable bounds.
An interesting idea. Our DAQ can do high-low and a random input for
calibrations, but I know sine waves have a special place in the engineer's
heart. I wonder if that would be a useful thing to add.
As you no doubt found out, your random input into the integral and
differential portions make a mess of your output. There is nothing
magic about a sine wave, but it does have a nice smoothly changing
derivative. This helps exerscise the entire algorithm without any
sharp dislocations in the differential. And, of course, sine waves
are easy to come by. You could simply hook up a signal generator to
your DAC. Since you mentioned that you are changing the software,
I thought maybe you just code up a sine function that replaces the
DAC output as the numerical source data for the rest of the algorithm.
This way, you can do the whole job on your computer, and you don't
need to scrounge a signal generator.
In practice, I've just been running and comparing sets of run parameters.
The problem is trying to make a 10e-4 measurement on a 60 nW signal. It
can just take a long time to collect that much data, and so an empirical
walk through parameter space can take a while. I keep hoping I'll find
some way to look at the error signal, transform it, and then know which
parameter to tweak, and by how much.
* Indiana.edu, Huh?, grab an undergrad, and assign the critter the
* task of building a signal generator out of parts obtainable at
* the local Radio Shack! That should do it.
* Say Hello to the Oracle for me.
http://cgi.cs.indiana.edu/~oracle/index.cgi
I'm a long way from Indiana. I'm at NIST in Maryland, haven't been to
Bloomington in years. But I sure as heck like Bloomington better than
Gaithersburg. Well, Gaithersburg has some good points, but mainly where
the people aren't.
--
"And don't skimp on the mayonnaise!"
.
|
|
|
| User: "Tony" |
|
| Title: Re: CuPID Controller |
09 Feb 2004 05:53:45 AM |
|
|
(Gregory L. Hansen) wrote in message news:<c02qa7$7v1$1@hood.uits.indiana.edu>...
In article <bd9a613.0402070521.6f066e80@posting.google.com>,
Tony <bjlapen@hotmail.com> wrote:
<snip stuff we already read>
As you no doubt found out, your random input into the integral and
differential portions make a mess of your output. There is nothing
magic about a sine wave, but it does have a nice smoothly changing
derivative. This helps exerscise the entire algorithm without any
sharp dislocations in the differential. And, of course, sine waves
are easy to come by. You could simply hook up a signal generator to
your DAC. Since you mentioned that you are changing the software,
I thought maybe you just code up a sine function that replaces the
DAC output as the numerical source data for the rest of the algorithm.
This way, you can do the whole job on your computer, and you don't
need to scrounge a signal generator.
In practice, I've just been running and comparing sets of run parameters.
The problem is trying to make a 10e-4 measurement on a 60 nW signal. It
can just take a long time to collect that much data, and so an empirical
walk through parameter space can take a while. I keep hoping I'll find
some way to look at the error signal, transform it, and then know which
parameter to tweak, and by how much.
* Indiana.edu, Huh?, grab an undergrad, and assign the critter the
* task of building a signal generator out of parts obtainable at
* the local Radio Shack! That should do it.
* Say Hello to the Oracle for me.
http://cgi.cs.indiana.edu/~oracle/index.cgi
I'm a long way from Indiana. I'm at NIST in Maryland, haven't been to
Bloomington in years. But I sure as heck like Bloomington better than
Gaithersburg. Well, Gaithersburg has some good points, but mainly where
the people aren't.
OK, I see what you are up to now. A magical transform would be nice,
but I don't know much control theory, so I can't tell you what is
possible and what is not. Personally, I hate PID (Think, Is there a
Harder way?), and I am amazed it is still around.
PID harkens back to the days of analog computing, when solving a
numerical equation electronically was impossible. BUT! You could
do calculus! A resistor = Proportional, a capacitor = Intergral, etc.
A wonderfull theory of control systems grew up around PID, not because
it was great, but because it was what we had, and we did need a
mathematical description. Now PID lives on as a digital simulation
of an analog process in which the lack of numerical calculations are
a huge deficiency.
*sigh*
[Don't bother flaming me for the above, The PID vs. Fuzzy war]
[raged for a decade, already been done.]
You proposed an X^3 term, so when the process gets off it's
setpoint, it gets a big correction to slam it back fast.
As long as you are hacking the algorithm, how about a simple
polynomial.
Y = a + bX + cX^2 + ...
where Y is the *correction* to the control signal, not the
control signal itself.
a should in all likelyhood be 0, as you are calculating the
correction, not the signal.
That leaves b and c, your proportional and one (or more) higher
order parameter to tweak. Of course, you can always add in
the I and D terms if they have specific value in your case.
When you are at the setpoint, the correction is 0; as you drift,
the correction goes increasingly higher order.
You have some time delay due to measurements constraints, so
your only worry is not to overdo the corrections.
For simulations, all you really need to know is how the output
of the process varies with the control signal. Is it first
order, second order, etc. To handle the time delay, you feed in
your control signal to your simulation algorithm n times, before
calculating a new correction. The larger value of n corresponds
to a longer time delay. This way, you can rip through parameter
space in an instant. If you want to do a simulation, let me
know, and we can whip something up.
Cheers,
Tony.
.
|
|
|
|
|
|
|
|
|
Related Articles |
|
|
