Troubled by rigorous theory vs. "seat of your pants" control

[Chris Carlen]

Greetings:

You might want to first look at my posting "Estimating servo loop
bandwidth and sampling rate" to understand where I am coming from with
this post.

I have been slowly piecing together bits of understanding about the
subject of feedback control systems not having yet engaged in a formall
study of the subject. Most of what I know was gleaned from the "Art of
Electronics", and I am now attempting to apply it to the planning of a
new project. Trouble is, a computer programmer that I work with sees
things differently, and also has somewhat more experience than I. But I
think he has little theoretical understanding. I keep talking about
closed-loop bandwidth, and sampling rates needed (for DSP based servo
control) to avoid incurring undesirable added phase margins to both him
and a mechanical engineer who needs the final product. The programmer's
response is: "you can study control theory all day, but in the field
nobody ever uses that stuff. They just use heuristic algorithms to set
parameters, and that's it..." They seem to think I am speaking greek
when I talk in classical control theory language.

Trouble is, I think this guy has most of his experience with process
control in industrial environments with several Hz maximum system BW.

A summary of my understanding of feedback controls pertaining to
continuous time systems is as follows:

The "plant" (thing to control) has some transfer function Hp(s). We
have a reference signal source (command voltage) Vi, and some sensor of
the controlled parameter of the plant Vo. An error voltage Ve is
produced from Vi-Vo, and the result must pass though a "loop
compensation network" of some to-be-determined transfer function Hc(s)
in order to produce a stable loop when closed.

The choice of Hc(s) can be boiled down to this: make the open loop
transfer function Hc(s)*Hp(s) pass through unity gain with a slope of -6
dB/octave, and have a decent phase margin at the unity gain frequency of
say 45 degrees to preferrably 60 degrees or more.

Once a suitable Hc(s) is devised, the loop can be closed and the
resulting system will have a response given by:

H_closed_loop(s) = Vo/Vi = (Hc Hp)/(1 + Hc Hp)

The whole trick is choosing Hc(s), the loop compensation network. Often
this may take the form of a "PID" controller, though this sometimes is
not the best solution.

The only difference between this continuous time system and a discretely
sampled system, is that the sampling operation injects a constant time
delay which translates into some phase shift at the open-loop unity gain
frequency. Make sure this reduced phase margin is still within
acceptable bounds by a suitable choice of oversampling, and the only
difference between the performance of the continuous and discrete
systems will be a little more overshoot and ringing in the discrete case.

Am I on track here folks?

If so, then my problem amounts to simply that my computer programmer
thinks that the system bandwidth (or the maximum frequency component
that the system must respond to) is what sets the sampling
rate--directly. Well, accounting for Nyquist, of course. So he'd think
that to get 106Hz valve movement, about 220Hz sampling rate will suffice.

Whereas I think that the sampling rate is to be set by a determination
of the maximum *closed-loop system bandwidth* which is based on a
determination of the maximum phase shift (tracking error) that can be
tolerated at the maximum frequency of the command voltage Vi. The
system BW is likely to be considerably higher than the Vi upper
frequency range, and then the sampling frequency must be much higher
than that in order to not compromise phase margin.

Now how to get the computer programmer and mechanical engineer to
understand all this?

Thanks for input.


--
_____________________
Christopher R. Carlen
crobc@earthlink.net
Suse 8.1 Linux 2.4.19

 

[Tim Wescott]

Chris Carlen wrote:

Greetings:

You might want to first look at my posting "Estimating servo loop
bandwidth and sampling rate" to understand where I am coming from with
this post.

I have been slowly piecing together bits of understanding about the
subject of feedback control systems not having yet engaged in a formall
study of the subject. Most of what I know was gleaned from the "Art of
Electronics", and I am now attempting to apply it to the planning of a
new project. Trouble is, a computer programmer that I work with sees
things differently, and also has somewhat more experience than I. But I
think he has little theoretical understanding. I keep talking about
closed-loop bandwidth, and sampling rates needed (for DSP based servo
control) to avoid incurring undesirable added phase margins to both him
and a mechanical engineer who needs the final product. The programmer's
response is: "you can study control theory all day, but in the field
nobody ever uses that stuff. They just use heuristic algorithms to set
parameters, and that's it..." They seem to think I am speaking greek
when I talk in classical control theory language.

Trouble is, I think this guy has most of his experience with process
control in industrial environments with several Hz maximum system BW.

A summary of my understanding of feedback controls pertaining to
continuous time systems is as follows:

The "plant" (thing to control) has some transfer function Hp(s). We
have a reference signal source (command voltage) Vi, and some sensor of
the controlled parameter of the plant Vo. An error voltage Ve is
produced from Vi-Vo, and the result must pass though a "loop
compensation network" of some to-be-determined transfer function Hc(s)
in order to produce a stable loop when closed.

The choice of Hc(s) can be boiled down to this: make the open loop
transfer function Hc(s)*Hp(s) pass through unity gain with a slope of -6
dB/octave, and have a decent phase margin at the unity gain frequency of
say 45 degrees to preferrably 60 degrees or more.

Once a suitable Hc(s) is devised, the loop can be closed and the
resulting system will have a response given by:

H_closed_loop(s) = Vo/Vi = (Hc Hp)/(1 + Hc Hp)

The whole trick is choosing Hc(s), the loop compensation network. Often
this may take the form of a "PID" controller, though this sometimes is
not the best solution.

The only difference between this continuous time system and a discretely
sampled system, is that the sampling operation injects a constant time
delay which translates into some phase shift at the open-loop unity gain
frequency. Make sure this reduced phase margin is still within
acceptable bounds by a suitable choice of oversampling, and the only
difference between the performance of the continuous and discrete
systems will be a little more overshoot and ringing in the discrete case.

Am I on track here folks?

If so, then my problem amounts to simply that my computer programmer
thinks that the system bandwidth (or the maximum frequency component
that the system must respond to) is what sets the sampling
rate--directly. Well, accounting for Nyquist, of course. So he'd think
that to get 106Hz valve movement, about 220Hz sampling rate will suffice.

Whereas I think that the sampling rate is to be set by a determination
of the maximum *closed-loop system bandwidth* which is based on a
determination of the maximum phase shift (tracking error) that can be
tolerated at the maximum frequency of the command voltage Vi. The
system BW is likely to be considerably higher than the Vi upper
frequency range, and then the sampling frequency must be much higher
than that in order to not compromise phase margin.

Now how to get the computer programmer and mechanical engineer to
understand all this?

Thanks for input.

Your software engineer's head is stuck someplace that the seat of his
pants is often close to. It could just be that he simply doesn't
understand what "3dB bandwidth" refers to.

_My_ seat-of-the-pants estimation is that unless you have something
really wacky going on you want to sample between 5 and 20 times the
closed-loop bandwidth. You can make something buzz at 100 Hz when you
sample it at 200Hz, but you have to have the Worlds Easiest Plant if you
want to close the loop at "100Hz" with a 200Hz sampling rate (note the
quotes -- it's probably only theoretically possible, if that).

You really ought to post this to sci.engineering.control. That group
has lots of folks who understand these issues, and it's not nearly
active enough!

Check my website -- I've got a few closed-loop tutorials there. They're
mostly written for the software engineer who's transitioning into
closed-loop control, but you may be able to glean something useful out
of it (and you can show him the published one with the sampling rate
rule of thumb).

--

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

 

[Terry Given]

"Chris Carlen" <crobc@BOGUS_FIELD.earthlink.net> wrote in message
news:c79o7h01aio@news3.newsguy.com...

Greetings:

You might want to first look at my posting "Estimating servo loop
bandwidth and sampling rate" to understand where I am coming from with
this post.

I have been slowly piecing together bits of understanding about the
subject of feedback control systems not having yet engaged in a formall
study of the subject. Most of what I know was gleaned from the "Art of
Electronics", and I am now attempting to apply it to the planning of a
new project. Trouble is, a computer programmer that I work with sees
things differently, and also has somewhat more experience than I. But I
think he has little theoretical understanding. I keep talking about
closed-loop bandwidth, and sampling rates needed (for DSP based servo
control) to avoid incurring undesirable added phase margins to both him
and a mechanical engineer who needs the final product. The programmer's
response is: "you can study control theory all day, but in the field
nobody ever uses that stuff. They just use heuristic algorithms to set
parameters, and that's it..." They seem to think I am speaking greek
when I talk in classical control theory language.

Trouble is, I think this guy has most of his experience with process
control in industrial environments with several Hz maximum system BW.

A summary of my understanding of feedback controls pertaining to
continuous time systems is as follows:

The "plant" (thing to control) has some transfer function Hp(s). We
have a reference signal source (command voltage) Vi, and some sensor of
the controlled parameter of the plant Vo. An error voltage Ve is
produced from Vi-Vo, and the result must pass though a "loop
compensation network" of some to-be-determined transfer function Hc(s)
in order to produce a stable loop when closed.

The choice of Hc(s) can be boiled down to this: make the open loop
transfer function Hc(s)*Hp(s) pass through unity gain with a slope of -6
dB/octave, and have a decent phase margin at the unity gain frequency of
say 45 degrees to preferrably 60 degrees or more.

Once a suitable Hc(s) is devised, the loop can be closed and the
resulting system will have a response given by:

H_closed_loop(s) = Vo/Vi = (Hc Hp)/(1 + Hc Hp)

The whole trick is choosing Hc(s), the loop compensation network. Often
this may take the form of a "PID" controller, though this sometimes is
not the best solution.

The only difference between this continuous time system and a discretely
sampled system, is that the sampling operation injects a constant time
delay which translates into some phase shift at the open-loop unity gain
frequency. Make sure this reduced phase margin is still within
acceptable bounds by a suitable choice of oversampling, and the only
difference between the performance of the continuous and discrete
systems will be a little more overshoot and ringing in the discrete case.

Am I on track here folks?

If so, then my problem amounts to simply that my computer programmer
thinks that the system bandwidth (or the maximum frequency component
that the system must respond to) is what sets the sampling
rate--directly. Well, accounting for Nyquist, of course. So he'd think
that to get 106Hz valve movement, about 220Hz sampling rate will suffice.

Whereas I think that the sampling rate is to be set by a determination
of the maximum *closed-loop system bandwidth* which is based on a
determination of the maximum phase shift (tracking error) that can be
tolerated at the maximum frequency of the command voltage Vi. The
system BW is likely to be considerably higher than the Vi upper
frequency range, and then the sampling frequency must be much higher
than that in order to not compromise phase margin.

Now how to get the computer programmer and mechanical engineer to
understand all this?

Thanks for input.
Christopher R. Carlen

Hi Chris,

from a purely theoretical perspective, the programmer considers himself
correct. Which he is not - you are on the right track, and his approach
would probably be an expensive disaster. Firstly, using the spectral knee of
the valve rise time to determine required bandwidth is excellent - you are
right on the money here.

Secondly, think a bit about the nyquist rate - any frequency above it gets
aliased, ie becomes uncontrollable. Setting your nyquist rate to be 4%
higher than the nominal valve frequency doesnt give you a hell of a lot of
design margin. What if its 50 rise-degrees?!

The digital controller behaviour will have a fundamental delay of one
sampling period. Anything that happens after you have sampled your ADC is
"invisible" until the next sample time. Depending on your application, that
can cause problems.

the method used to design your controller will have a huge impact. If you
plan on designing an "analogue" controller then (say) transforming into the
z-domain for implementation, then the type of transformation you use is
important - a bilinear transform controller can have a much lower sample
rate than a backward-difference transform controller, which needs around 20x
sample rate to function effectively. There are a wide variety of tricks for
solving this problem, but sampling faster is the easiest one. An all digital
design can easily incorporate this delay [IIRC augment your state variables
with a new variable, which is the delayed state eg v=u(n-1)].


If you design for Wo*Ts < 1 where Wo = 2pi*106Hz = 666Hz (ie Ts < 1.5ms) you
can make it work, if you design your controller carefully. If you design for
Wo*Ts << 1 (ie Ts < 150us) then crude methods like the backward-difference
transform will work fine.

cheers
Terry

 

[Terry Given]

"Chris Carlen" <crobc@BOGUS_FIELD.earthlink.net> wrote in message
news:c79o7h01aio@news3.newsguy.com...

Greetings:

You might want to first look at my posting "Estimating servo loop
bandwidth and sampling rate" to understand where I am coming from with
this post.

I have been slowly piecing together bits of understanding about the
subject of feedback control systems not having yet engaged in a formall
study of the subject. Most of what I know was gleaned from the "Art of
Electronics", and I am now attempting to apply it to the planning of a
new project. Trouble is, a computer programmer that I work with sees
things differently, and also has somewhat more experience than I. But I
think he has little theoretical understanding. I keep talking about
closed-loop bandwidth, and sampling rates needed (for DSP based servo
control) to avoid incurring undesirable added phase margins to both him
and a mechanical engineer who needs the final product. The programmer's
response is: "you can study control theory all day, but in the field
nobody ever uses that stuff. They just use heuristic algorithms to set
parameters, and that's it..." They seem to think I am speaking greek
when I talk in classical control theory language.

Trouble is, I think this guy has most of his experience with process
control in industrial environments with several Hz maximum system BW.

lots of studies have been done on the effect of automated control in
industry. They all end up saying about the same thing - 1/3 of all
controllers improve processes, 1/3 have no net effect, and 1/3 make the
process substantially worse. And the reasons are always the same - badly
tuned controllers (this has fueled the demand for self-tuning controllers, a
jolly good trick). I have watched plenty of guys tune motor controller PID
loops in industry, and they ALL do it "empirically" ie by making it up as
they go along, often for no apparent reason (usually based on what has
worked before).

A summary of my understanding of feedback controls pertaining to
continuous time systems is as follows:

[snip]
jolly good.

The only difference between this continuous time system and a discretely
sampled system, is that the sampling operation injects a constant time
delay which translates into some phase shift at the open-loop unity gain
frequency. Make sure this reduced phase margin is still within
acceptable bounds by a suitable choice of oversampling, and the only
difference between the performance of the continuous and discrete
systems will be a little more overshoot and ringing in the discrete case.

Am I on track here folks?

yep. Actually phase errors can often be compensated out quite easily in
digital controllers.

If so, then my problem amounts to simply that my computer programmer
thinks that the system bandwidth (or the maximum frequency component
that the system must respond to) is what sets the sampling
rate--directly. Well, accounting for Nyquist, of course. So he'd think
that to get 106Hz valve movement, about 220Hz sampling rate will suffice.

a computer programmer would. probably because he didnt think about the
problem carefully.....

Whereas I think that the sampling rate is to be set by a determination
of the maximum *closed-loop system bandwidth* which is based on a
determination of the maximum phase shift (tracking error) that can be
tolerated at the maximum frequency of the command voltage Vi. The
system BW is likely to be considerably higher than the Vi upper
frequency range, and then the sampling frequency must be much higher
than that in order to not compromise phase margin.

....which you did. the closed loop bandwidth is ultimately governed by the
references/disturbances you wish to track/correct. In a "regulator" the
reference doesnt change (small-signal value is zero), so the known load
behaviour (ie disturbance) is used to specify the required bandwidth, often
indirectly (eg maximum overshoot & undershoot etc). In the case of a
controller, the reference (ie setpoint) can and does vary, so EITHER the
reference or disturbance behaviour can be used to specify the required BW.

the degradation in phase margin depends entirely on your implementation
(including of course sample frequency), but yes.

Now how to get the computer programmer and mechanical engineer to
understand all this?

thats the fun bit. My tolerance argument alone should convince the
mechanical engineer, if hes any good. IME programmers arent swayed by
mathematical proofs, arguments etc. Be in charge, then just make him do it
your way. Actually, the tolerance, read as butt-covering argument, is
probably the best one all round. As long as you dont get too out of control,
extra sample rate wont hurt.

Thanks for input.
_____________________
Christopher R. Carlen

 

[Robert Baer]

Tim Wescott wrote:

Chris Carlen wrote:
Greetings:

You might want to first look at my posting "Estimating servo loop
bandwidth and sampling rate" to understand where I am coming from with
this post.

I have been slowly piecing together bits of understanding about the
subject of feedback control systems not having yet engaged in a formall
study of the subject. Most of what I know was gleaned from the "Art of
Electronics", and I am now attempting to apply it to the planning of a
new project. Trouble is, a computer programmer that I work with sees
things differently, and also has somewhat more experience than I. But I
think he has little theoretical understanding. I keep talking about
closed-loop bandwidth, and sampling rates needed (for DSP based servo
control) to avoid incurring undesirable added phase margins to both him
and a mechanical engineer who needs the final product. The programmer's
response is: "you can study control theory all day, but in the field
nobody ever uses that stuff. They just use heuristic algorithms to set
parameters, and that's it..." They seem to think I am speaking greek
when I talk in classical control theory language.

Trouble is, I think this guy has most of his experience with process
control in industrial environments with several Hz maximum system BW.

A summary of my understanding of feedback controls pertaining to
continuous time systems is as follows:

The "plant" (thing to control) has some transfer function Hp(s). We
have a reference signal source (command voltage) Vi, and some sensor of
the controlled parameter of the plant Vo. An error voltage Ve is
produced from Vi-Vo, and the result must pass though a "loop
compensation network" of some to-be-determined transfer function Hc(s)
in order to produce a stable loop when closed.

The choice of Hc(s) can be boiled down to this: make the open loop
transfer function Hc(s)*Hp(s) pass through unity gain with a slope of -6
dB/octave, and have a decent phase margin at the unity gain frequency of
say 45 degrees to preferrably 60 degrees or more.

Once a suitable Hc(s) is devised, the loop can be closed and the
resulting system will have a response given by:

H_closed_loop(s) = Vo/Vi = (Hc Hp)/(1 + Hc Hp)

The whole trick is choosing Hc(s), the loop compensation network. Often
this may take the form of a "PID" controller, though this sometimes is
not the best solution.

The only difference between this continuous time system and a discretely
sampled system, is that the sampling operation injects a constant time
delay which translates into some phase shift at the open-loop unity gain
frequency. Make sure this reduced phase margin is still within
acceptable bounds by a suitable choice of oversampling, and the only
difference between the performance of the continuous and discrete
systems will be a little more overshoot and ringing in the discrete case.

Am I on track here folks?

If so, then my problem amounts to simply that my computer programmer
thinks that the system bandwidth (or the maximum frequency component
that the system must respond to) is what sets the sampling
rate--directly. Well, accounting for Nyquist, of course. So he'd think
that to get 106Hz valve movement, about 220Hz sampling rate will suffice.

Whereas I think that the sampling rate is to be set by a determination
of the maximum *closed-loop system bandwidth* which is based on a
determination of the maximum phase shift (tracking error) that can be
tolerated at the maximum frequency of the command voltage Vi. The
system BW is likely to be considerably higher than the Vi upper
frequency range, and then the sampling frequency must be much higher
than that in order to not compromise phase margin.

Now how to get the computer programmer and mechanical engineer to
understand all this?

Thanks for input.



Your software engineer's head is stuck someplace that the seat of his
pants is often close to. It could just be that he simply doesn't
understand what "3dB bandwidth" refers to.

_My_ seat-of-the-pants estimation is that unless you have something
really wacky going on you want to sample between 5 and 20 times the
closed-loop bandwidth. You can make something buzz at 100 Hz when you
sample it at 200Hz, but you have to have the Worlds Easiest Plant if you
want to close the loop at "100Hz" with a 200Hz sampling rate (note the
quotes -- it's probably only theoretically possible, if that).

You really ought to post this to sci.engineering.control. That group
has lots of folks who understand these issues, and it's not nearly
active enough!

Check my website -- I've got a few closed-loop tutorials there. They're
mostly written for the software engineer who's transitioning into
closed-loop control, but you may be able to glean something useful out
of it (and you can show him the published one with the sampling rate
rule of thumb).

--

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Mr Wescott is (indirectly) referring to the Nyquist criteria.
The 5 times to 20 times criteria is a good place to start.
Just imagine that a 2 times (ie the "100Hz" loop sampled at 200Hz)
will result in an indeterminite phase delay of 180 degrees - or zero
degrees (metastable).

 

[Mike]

On Tue, 04 May 2004 20:49:05 -0700, Chris Carlen wrote:

The only difference between this continuous time system and a discretely
sampled system, is that the sampling operation injects a constant time
delay which translates into some phase shift at the open-loop unity gain
frequency.

Nope, and nope.

-- Mike --

 

[Ken Smith]

In article <c79o7h01aio@news3.newsguy.com>,
Chris Carlen <crobc@BOGUS_FIELD.earthlink.net> wrote:
[...]

Am I on track here folks?
Sounds right to me and I studied control systems.

The only real problem was with the 6db slope. It is nice but not
something that needs to be true.

If so, then my problem amounts to simply that my computer programmer
thinks that the system bandwidth (or the maximum frequency component
that the system must respond to) is what sets the sampling
rate--directly. Well, accounting for Nyquist, of course. So he'd think
that to get 106Hz valve movement, about 220Hz sampling rate will suffice.

Your programmer is obviously a moron. Get a new one. If you can't get a
new one try one of these arguments:

If we assume that there is some broadband disturbance injected at the
input of the plant. The conponents of that disturbance that are above the
loop closure frequency will still cause the output of the plant to vary.
This will be sampled in the converter and, if it is above Nyquist, will be
aliased. This aliased signal will cause the loop to servo out an error
that is not there. The result is an increase in the in band noise of the
system.

If you have a lowish number of bits in the ADC and the signal has some
noise in it, you can use the averaging effect of oversampling to prevent
cogging in the output.

Now how to get the computer programmer and mechanical engineer to
understand all this?

Perhaps you can't.
--
--
kensmith@rahul.net forging knowledge

 

[Chris Carlen]

Mike wrote:

On Tue, 04 May 2004 20:49:05 -0700, Chris Carlen wrote:


The only difference between this continuous time system and a discretely
sampled system, is that the sampling operation injects a constant time
delay which translates into some phase shift at the open-loop unity gain
frequency.


Nope, and nope.

-- Mike --

Mike,

Thanks for the input.

Your position is so far outnumbered three to one, with two of those
having substantial documented experience in the field.

If you would like me to learn something from your statement, please
provide some detailed explanation, and I will be happy to read it with
an open mind.

Good day!


--
____________________________________
Christopher R. Carlen
Principal Laser/Optical Technologist
Sandia National Laboratories CA USA
crcarle@sandia.gov

 

[Scott Stephens]

Tim Wescott wrote:

_My_ seat-of-the-pants estimation is that unless you have something
really wacky going on you want to sample between 5 and 20 times the
closed-loop bandwidth.

Have you seen any papers that analyze sampling with a frequency that has
been mixed with a pseudo-random phase offset (noise)?

Lets say you sample at X 2, but use a random phase dither. Some systems
might not have so much gain that coherent instabilities will build up.
And the increased noise would help the system, if it happened to be
sticky or have hysteresis.

Of course it would probably worsen power consumption, heat and wear. But
in some systems (DVD lasers), it doesn't matter.

--
Scott

**********************************

DIY Piezo-Gyro, PCB Drill Bot & More Soon!

http://home.comcast.net/~scottxs/

**********************************

 

[Tim Wescott]

Terry Given wrote:

-- snip --

the method used to design your controller will have a huge impact. If you
plan on designing an "analogue" controller then (say) transforming into the
z-domain for implementation, then the type of transformation you use is
important - a bilinear transform controller can have a much lower sample
rate than a backward-difference transform controller, which needs around 20x
sample rate to function effectively. There are a wide variety of tricks for
solving this problem, but sampling faster is the easiest one. An all digital
design can easily incorporate this delay [IIRC augment your state variables
with a new variable, which is the delayed state eg v=u(n-1)].

The only time I'd advocate transforming an analog controller into the
z-domain would be if you're replacing it with a digital controller
that's supposed to do _exactly_ the same thing. The closest I've ever
come to this is to write a digital control algorithm with the same
filters as the analog controller it was replacing, then tune it up
empirically based on the plant's frequency response as seen by the software.

Generally I model the plant in continuous-time then (if it's a linear
plant, which is a big if) I make an exact z-domain model of it and
design my control system -- but I still end up tuning it with empirical
data at the end, if I want to get good performance. Even a nonlinear
plant can sometimes be handled this way, by linearizing the
continuous-time system around the "typical" operating point, and
transforming _that_ exactly.

If you design for Wo*Ts < 1 where Wo = 2pi*106Hz = 666Hz (ie Ts < 1.5ms) you
can make it work, if you design your controller carefully. If you design for
Wo*Ts << 1 (ie Ts < 150us) then crude methods like the backward-difference
transform will work fine.

In general making the sampling rate faster will make the design job
easier, and require higher precision in all your filters. If you can
spend the money on a fast machine that has the capacity for 32-bit
computation then go collect your bonus. If you need to squeeze pennies
out of the controller (which I suspect will happen eventually if this is
an automotive application) then you should sample as slowly as you can
get away with (which is where my feed-forward or even adaptive
feed-forward suggestion came from).

cheers
Terry

--

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

 

[Tim Wescott]

Chris Carlen wrote:

Mike wrote:

On Tue, 04 May 2004 20:49:05 -0700, Chris Carlen wrote:


The only difference between this continuous time system and a
discretely sampled system, is that the sampling operation injects a
constant time delay which translates into some phase shift at the
open-loop unity gain frequency.



Nope, and nope.
-- Mike --



Mike,

Thanks for the input.

Your position is so far outnumbered three to one, with two of those
having substantial documented experience in the field.

If you would like me to learn something from your statement, please
provide some detailed explanation, and I will be happy to read it with
an open mind.

Good day!

The sampling process also creates frequency aliasing, so sampling at
your suggested 28kHz would bring a 29kHz signal down to 1000Hz at your
software, which may cause you trouble. Also, the time delay isn't
really "constant"; the ADC reading contains new information about
_everything_ that happened since the last one, so it has content that
ranges from Ts to "RIGHT NOW".

I've never been satisfied with trying to think of sampled-time systems
in continuous-time terms -- this is why I much prefer to bring
everything into the sampled-time domain as soon as possible and deal
with it there. This still leaves you with making sure that you're
getting good performance _between_ the samples, but with a rational
sampling rate that usually just happens and all you need to do is verify
this fact.

--

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

 

[Chris Carlen]

Ken Smith wrote:

In article <c79o7h01aio@news3.newsguy.com>,
Chris Carlen <crobc@BOGUS_FIELD.earthlink.net> wrote:
[...]

Am I on track here folks?

Sounds right to me and I studied control systems.

The only real problem was with the 6db slope. It is nice but not
something that needs to be true.



If so, then my problem amounts to simply that my computer programmer
thinks that the system bandwidth (or the maximum frequency component
that the system must respond to) is what sets the sampling
rate--directly. Well, accounting for Nyquist, of course. So he'd think
that to get 106Hz valve movement, about 220Hz sampling rate will suffice.


Your programmer is obviously a moron. Get a new one.

It's not that simple. The folks I am working for, one of them is a
world-renouned engine researcher in a department of other world-renouned
researchers. The programmer is much more experienced than I am in
software, and has spent many years in this department and earned the
respect of these high level researchers, even if he may happen to be
less knowledgeable than I am about the mathematical specifics of control
theory. I have every intention to treat these folks with utmost
respect, and so this is somewhat of a delicate situation.

I think and I hope it may be simply a case of speaking different
languages. The folks I work with are very good at what they do. The
programmer does all of our high speed data acquisition, engine control
(not feedback control) and lab status monitoring and control (on/off)
type stuff. He makes very good stuff, and also works with industry on
engine research related software including real-time stuff.

Trouble is, neither the programmer nor my mechanical engineer speak the
language of "bandwidth" etc. typical of us control and electronics folks.

I just explained my position to a fellow electronic technologist with
much less theoretical background, and he understood perfectly!

This is a language problem. Hopefully with some patient explanation, as
I just did with a fellow technologist, they will get it.

If you can't get a
new one try one of these arguments:

If we assume that there is some broadband disturbance injected at the
input of the plant. The conponents of that disturbance that are above the
loop closure frequency will still cause the output of the plant to vary.
This will be sampled in the converter and, if it is above Nyquist, will be
aliased. This aliased signal will cause the loop to servo out an error
that is not there. The result is an increase in the in band noise of the
system.

If you have a lowish number of bits in the ADC and the signal has some
noise in it, you can use the averaging effect of oversampling to prevent
cogging in the output.

Now how to get the computer programmer and mechanical engineer to
understand all this?


Perhaps you can't.

Thanks for the reply.


Good day!


--
____________________________________
Christopher R. Carlen
Principal Laser/Optical Technologist
Sandia National Laboratories CA USA
crcarle@sandia.gov

 

[Mike]

On Wed, 05 May 2004 08:04:36 -0700, Chris Carlen wrote:

Mike wrote:
On Tue, 04 May 2004 20:49:05 -0700, Chris Carlen wrote:


The only difference between this continuous time system and a discretely
sampled system, is that the sampling operation injects a constant time
delay which translates into some phase shift at the open-loop unity gain
frequency.


Nope, and nope.

-- Mike --


Mike,

Thanks for the input.

Your position is so far outnumbered three to one, with two of those
having substantial documented experience in the field.

If you would like me to learn something from your statement, please
provide some detailed explanation, and I will be happy to read it with
an open mind.

That seems unlikely.

"Anyone who claims to be a human being who values freedom and democracy,
and who does nothing to abandon Windows, is a hypocrite."
-- Chris Carlen

Not exactly what would be expected from someone with an open mind.

As far as being outnumbered goes, science isn't a democracy, and we don't
take votes on the facts.

Perhaps you'd care to show (mathematically, of course) where the delay
comes from. If you have an open mind, I suspect you'll be enlightened.

-- Mike --

 

[Mike]

On Wed, 05 May 2004 15:12:49 GMT, Scott Stephens wrote:

Tim Wescott wrote:

_My_ seat-of-the-pants estimation is that unless you have something
really wacky going on you want to sample between 5 and 20 times the
closed-loop bandwidth.

Have you seen any papers that analyze sampling with a frequency that has
been mixed with a pseudo-random phase offset (noise)?

You'd be hard-pressed to find a sampling clock that isn't noisy - it's just
a question of where and how much. This was the subject of an article in EE
Times a few weeks ago, by someone from Analog Devices. There have been
various papers on the topic, and it's becoming a more serious issue as
clock and bit-counts climb, and attracting more interest of researchers.

-- Mike --

 

[Peter O. Brackett]

Chris:

[snip]
The programmer's
response is: "you can study control theory all day, but in the field
nobody ever uses that stuff. They just use heuristic algorithms to set
parameters, and that's it..." They seem to think I am speaking greek
when I talk in classical control theory language.
[snip]
:
:
[snip]

Now how to get the computer programmer and mechanical engineer to
understand all this?
--
_____________________
Christopher R. Carlen
[snip]

Heh, heh... Don't listen to that bull...

In my 30+ year professional career, I have designed many analog, sampled
data digital and mixed mode multi-loop control systems and I can assure you
that I always made good use of all of the control theory I learned at school
and beyond. [Subsequently had shipped thousands of units of well in excess
of $4BB gross revenue all working in the field.]

*You* may be a little inexperienced now, but you are on the right track...
just perservere my friend.

Regarding your last comment about *convincing* the programmer and the
mechanic, I am reminded of the old cliche...

"Never wrestle in the mud with pigs, you will just get dirty, and the pigs
like it!"

--
Peter
Indialantic By-the-Sea, FL

 

[Joel Kolstad]

The programmer's
response is: "you can study control theory all day, but in the field
nobody ever uses that stuff. They just use heuristic algorithms to set
parameters, and that's it..." They seem to think I am speaking greek
when I talk in classical control theory language.

The guy has a point; in my experience it's far more likely to come across
problems where something like a PID loop or some 'heuristic' based
controller will solve the problem. However, if you know classical control
theory and can properly apply it, you'll be able to make noticeably more
money solving problems where such approaches fail miserably. In fact, it
seems as though control systems is one of the areas where consultants who
know what they're doing never run out of clients whose own employees failed
to make the system work due to assuming that all systems can be controlled
with simple algorithms.

See Jim Thompson's post a week or so ago about getting a company to pay
through the nose for a control systems fix!

 

[Scott Stephens]

Mike wrote:

You'd be hard-pressed to find a sampling clock that isn't noisy - it's just
a question of where and how much.

No doubt, and if you're trying to demodulate QAM, the phase noise
matters. But in this case, the idea is deliberately inject a wideband
noise to prevent instability and perhaps mechanical stiction.

--
Scott

**********************************

DIY Piezo-Gyro, PCB Drill Bot & More Soon!

http://home.comcast.net/~scottxs/

**********************************

 

[Chris Carlen]

Mike wrote:

On Wed, 05 May 2004 08:04:36 -0700, Chris Carlen wrote:


Mike wrote:

On Tue, 04 May 2004 20:49:05 -0700, Chris Carlen wrote:



The only difference between this continuous time system and a discretely
sampled system, is that the sampling operation injects a constant time
delay which translates into some phase shift at the open-loop unity gain
frequency.


Nope, and nope.

-- Mike --


Mike,

Thanks for the input.

Your position is so far outnumbered three to one, with two of those
having substantial documented experience in the field.

If you would like me to learn something from your statement, please
provide some detailed explanation, and I will be happy to read it with
an open mind.


That seems unlikely.

"Anyone who claims to be a human being who values freedom and democracy,
and who does nothing to abandon Windows, is a hypocrite."
-- Chris Carlen

I was anticipating this. I expected that you were resenting my past
comments, and that your motivations for your comments weren't to engage
in an honest discussion but simply to spite me.

The quote to which you responded:

"A common Linux mantra is that everyone should have freedom and choice,
unless their free choice is not Linux. In that case they should be insulted,
castigated, abused, criticized, punished, assailed, excoriated, chastised,
penalized, and pilloried.

Your comments, repudiating the humanity of others simply because they
disagree with you, exceed even that low standard, and would better be
addressed to an alt.hate newsgroup.

I can't think of anyone who truly values humanity, freedom, or democracy,
who would agree with you that any of those things are predicated or
dependent on something as utterly insignificant as someone's choice of
operating system.

-- Mike --"

It was clear at that point that you had taken my hyperbole way too
seriously.

I commented after that:

"Oops. It seems I was a bit heavy handed with that one. I shouldn't
respond to such issues early in the morning.

Good day!"

But perhaps you didn't read that, so I will repeat in a simpler
translation here that I hope you can give a fair consideration:

I was wrong. I was engaging in an emotional outburst. Sorry about that.

There, in plain public view, I have admitted my wrongness. I hope at
this point you can consider forgiving my earlier harsh comments. I also
hope that you can open your mind to the possibility that I was simply
falling prey to my own humanity, and that I am not really hateful of
anyone. Listen, if Microsoft weren't a criminal monopoly, I would be
completely willing to respect folks' choices to use it. At this point,
I don't respect their choices, but I do have sympathy for the situations
which lead them to choose to use Windows unwisely, which is usually the
need to make a living. And I don't think they are really hippocrites,
but rather unfortunate victims of a sick industry in the grips of a
truly evil monopolist. I don't even hate Bill Gates, just think he's a
greedy fool.

You see, being critical of someone doesn't require hating them.

Not exactly what would be expected from someone with an open mind.

You can take it at face value, or see something here that isn't, all
according to your own intentions. I will understand if you choose to
continue to resent me. But I have admitted my wrongness in an effort to
reestablish an atmosphere of good will. If you aren't interested in
reciprocating, then so be it. I will wish you well nonetheless, but
refrain from further consideration of any of your postings.

As far as being outnumbered goes, science isn't a democracy, and we don't
take votes on the facts.

Perhaps you'd care to show (mathematically, of course) where the delay
comes from. If you have an open mind, I suspect you'll be enlightened.

-- Mike --

It was your assertion that my understanding was incorrect, so I believe
the burden of making that case is in your hands.


Good day!


--
_____________________
Christopher R. Carlen
crobc@earthlink.net
Suse 8.1 Linux 2.4.19

 

[Terry Given]

"Tim Wescott" <tim@wescottnospamdesign.com> wrote in message
news:109i3cibrv4brb9@corp.supernews.com...

Terry Given wrote:

-- snip --

the method used to design your controller will have a huge impact. If
you
plan on designing an "analogue" controller then (say) transforming into
the
z-domain for implementation, then the type of transformation you use is
important - a bilinear transform controller can have a much lower sample
rate than a backward-difference transform controller, which needs around
20x
sample rate to function effectively. There are a wide variety of tricks
for
solving this problem, but sampling faster is the easiest one. An all
digital
design can easily incorporate this delay [IIRC augment your state
variables
with a new variable, which is the delayed state eg v=u(n-1)].

The only time I'd advocate transforming an analog controller into the
z-domain would be if you're replacing it with a digital controller
that's supposed to do _exactly_ the same thing. The closest I've ever
come to this is to write a digital control algorithm with the same
filters as the analog controller it was replacing, then tune it up
empirically based on the plant's frequency response as seen by the
software.

Alas, in practice the former gets done a lot. Its definitely the hard way
though.

Generally I model the plant in continuous-time then (if it's a linear
plant, which is a big if) I make an exact z-domain model of it and
design my control system -- but I still end up tuning it with empirical
data at the end, if I want to get good performance. Even a nonlinear
plant can sometimes be handled this way, by linearizing the
continuous-time system around the "typical" operating point, and
transforming _that_ exactly.

yep analyses are never exact, everything is non-linear to some extent
(usually in the way that causes the most problems and of course
everything varies. But when it comes to simple PID controllers, in many
cases it is not too hard to directly calculate the Kp, Ki and Kd gains
required for a given crossover frequency and phase+gain margins, giving you
a good basis for "fiddling"

If you design for Wo*Ts < 1 where Wo = 2pi*106Hz = 666Hz (ie Ts < 1.5ms)
you
can make it work, if you design your controller carefully. If you design
for
Wo*Ts << 1 (ie Ts < 150us) then crude methods like the
backward-difference
transform will work fine.

In general making the sampling rate faster will make the design job
easier, and require higher precision in all your filters. If you can
spend the money on a fast machine that has the capacity for 32-bit
computation then go collect your bonus. If you need to squeeze pennies
out of the controller (which I suspect will happen eventually if this is
an automotive application) then you should sample as slowly as you can
get away with (which is where my feed-forward or even adaptive
feed-forward suggestion came from).

yes. many companies have gotten in the crap by sampling too fast, either
because of the required filter resolution (well spotted!) or computational
overhead.

cheers
Terry

 

[Terry Given]

"Joel Kolstad" <JKolstad71HatesSpam@Yahoo.Com> wrote in message
news:c7bd6o$kkn$1@news.oregonstate.edu...

The programmer's
response is: "you can study control theory all day, but in the field
nobody ever uses that stuff. They just use heuristic algorithms to set
parameters, and that's it..." They seem to think I am speaking greek
when I talk in classical control theory language.

The guy has a point; in my experience it's far more likely to come across
problems where something like a PID loop or some 'heuristic' based
controller will solve the problem. However, if you know classical control
theory and can properly apply it, you'll be able to make noticeably more
money solving problems where such approaches fail miserably. In fact, it
seems as though control systems is one of the areas where consultants who
know what they're doing never run out of clients whose own employees
failed
to make the system work due to assuming that all systems can be controlled
with simple algorithms.

See Jim Thompson's post a week or so ago about getting a company to pay
through the nose for a control systems fix!

I went to a seminar on motor control by Prof. Joachim Holz a fair few years
back. During the inevitable group discussion at lunchtime, many people
(myself included) asked how to analytically tune a PID controller. We ranged
from fairly junior (me) to quite senior engineers, and the interesting thing
we had in common was that NOBODY at our firms ever analytically tuned PID
controllers, even though they were our stock in trade (we all were involved
in motor control). Prof. Holz was amazed at our ignorance, and in about
5mins flat (using a placemat not a napkin showed us all how easy it is to
do - that was a turning point for me wrt control systems. It took me a few
hours to figure it out for per-unitised control systems, but it still works.
Nice to be able to choose Fcross and damping factor, then directly calculate
gains.