Effect of discretization on feedback controllers

Boris Lau wrote:

Lots of things.  A discrete-time controller is a different animal than a
continuous-time one, because you're sampling the input and because
you're introducing delay both as part of the sampling process and
because of any processing that you do.  In general, if you sample fast
enough then the difference between a discrete-time controller and a
continuous-time one will be smaller than the other differences between
theory and practice in your system, and can be ignored.  This effect may
or may not occur after you have spent more money than you can afford on
computing hardware.


Just as with a continuous-time controller, yes.


They'll be different for each property and controller -- and they'll
change depending on your sampling rate as well.  This is why I generally
prefer to characterize my system in the continuous-time domain then do
my design in the discrete-time domain.  Many experienced people are
uncomfortable with this approach however, so you'll see a lot of designs
that start with a continuous-time controller then approximate it in
discrete time.

--

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

Do you need to implement control loops in software?
"Applied Control Theory for Embedded Systems" gives you just what it says.
See details at http://www.wescottdesign.com/actfes/actfes.html

Tim Wescott wrote:

yes, but is there a bound on the error, or any other thing I can say?


I see. Well, this seems to be the case here, since the controller works
alright and I'd like to keep on using it.

 > They'll be different for each property and controller -- and they'll
 > change depending on your sampling rate as well.

By the way, I've found this in another thread:

Sam wrote regarding "Re: Digital implementation of a control design":
 > If your controllers bandwidth is much greater than the relative
 > bandwidth of the system you are controlling then your continuous time
 > design will do fine. Another way of saying this is if your sampling
 > frequency is high enough (meaning much faster than the fastest
 > dynamics of your process--more than 10 times) then you will come very
 > close to the desired continuous time design.  Also, remember that eigC
 > = exp(eigC*Ts)
 > Where eigC is the continuous time eigenvalues of your system (the one
 > you designed) and Ts is the Sampling Interval (1/Fs or 1/sampling
 > frequency).

This sounds like a general rule when taking a continuous controller into
discrete time, or doesn't this apply to my case?

Thanks again,

Boris

Boris Lau wrote:

It requires that the sample rate be much higher than might otherwise be
needed. If that doesn't increase the cost or the response time of the
necessary filters out of bounds, then it applies.

Jerry
--
Engineering is the art of making what you want from things you can get.
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯

Boris Lau wrote:

There are some fairly good hand-waving arguments that you can use if you
want to do approximations.  Mostly, you can take the delay effect of the
zero-order-hold on the output DAC and check to see if it's phase shift
is going to cause grief to your loop -- if not, you're probably in business.

It's this hand-waving that makes me prefer to design directly in the
digital domain, but to each their own...


It's general, yes, and I use it all the time.  From a practical
perspective it's a good starting point, but for _really_ precise control
you want to exceed the 10x factor, perhaps even bumping it up to 100x if
you can.  You can do better than this rule of thumb by evaluating the
system as a continuous-time one with a one-half or one sample pure delay
in it, and see if you're going to get decent performance.

 From a theoretical standpoint it's all still hand-waving to some extent
-- what's the fastest dynamic in your process, after all?  Just about
any real process has an effectively infinite number of dynamics, so the
real quote should be "the fastest important dynamic".  Once you insert
that qualifier in there, you're back to hand-waving.

--

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

Do you need to implement control loops in software?
"Applied Control Theory for Embedded Systems" gives you just what it says.
See details at http://www.wescottdesign.com/actfes/actfes.html

I want to learing from it.
www.ningbo-electric.com

There are two things that happen.
1. As mentioned above, the sample intervals can have a big affect on
the response.
2. The feed back is not linear.  Digital sampling turns a linear ramp
into little stair steps.  The finer the feedback resolution the closer
the feedback will represent a linear ramp.


I agree that every system is different but there are general
procedures that will allow you to tune a system and determine if it is
stable.  Tuning the s-domain is easy because it is easy to calculate
the gains symbolically.  In the digital domain the gains are affected
by the sample interval.  Assume all the closed loop poles are going to
be at -10 in the s domain.  One can calculate the location in the z
domain, exp(-10*T).  The digital controller gains will approach those
calculated for the analog controller as the sample interval approaches
0.  The digital controller gains will be less than the analog
controller as the sample interval increases.  One can verify this by
writing a program to tune a controller by placing the closed loop
poles at a specific location in the z domain.  Use Ackermann's method
to do this.  If the pole locations are kept constant but the sample
interval is varied you will see what I mean.

From this you would think the idea is to minimize the sample interval
but there are problems with that too.  As the sample time approaches
0, the ability to calculate accurate derivatives goes down UNLESS the
resolution is also made finer by a proportional amount. The control
output will change in quantized jumps proportional to the ratio of
feed back resolution to the sample interval if only a derivative gain
is used.  If a second derivative is used the control output will
change in quantized steps proportional the the resolution/T^2.

There is hope, we can design an observer to estimate and smooth the
state feedback and remove most of the stair step quantizing.
Since we are assuming we have the plant model from system
identification, we can use this model to design the observer.

Peter Nachtwey