The Cascade Control Architecture - controlguru post

On Fri, 06 Jul 2007 20:38:20 +0000, Doug Cooper wrote:


Au contraire, mon ami!  "It is important to understand that neither
strategy benefits nor detracts from set point tracking performance."

In your cascade control* example the improvement in disturbance
rejection is a direct consequence of being able to increase the reaction
speed of the loop.  You can do this because measuring the flow allows
you to wrap that part of the system with a fast, robust loop.  This fast
loop, in turn, gives you the ability to tune the whole loop for faster
response while maintaining robustness in the face of plant variations,
nonlinearities, and all those other nasty things that we must work
around.

If you put on your rose-colored glasses and pretend that the system is
linear, time-invariant, and has all discrete states, then the additional
sensor lets you shove the poles farther into the left-half plane.  Doing
so decreases the system's sensitivity to low- and medium-frequency
disturbances at the same time that it increases it's ability to track
low- and medium-frequency setpoint changes (the plant will act like a
low-pass filter, giving the system an intrinsic ability to reject really
fast disturbances, as well as an intrinsic tendency to resist all
attempts to speed it up beyond a certain point).

In fact, both the disturbance rejection and the tracking ability are
tightly bound to the system sensitivity: if we keep those rose-colored
glasses on the disturbance rejection is the plant transfer function (the
tank level process transfer function, in your example) numerator over
the system sensitivity, and the error between the setpoint and the final
process variable is simply one over the system sensitivity.  With your
loop as shown, you _cannot_ improve the disturbance rejection without
also improving the set point tracking.

In the case of disturbance feed-forward this is not the case -- there (I
assume this is what you're thinking, at least) you measure the
disturbance outside the loop, and feed in a signal to null out the
effect of the disturbance.  Of course, if your system is predictable
enough to use disturbance feed forward on it, you can also feed the
setpoint forward if you really need to track it well.

I have to admit that I only skimmed the article to make sure that I knew
where you were coming from, so you may well have clarified this point
there -- but in your post here you certainly mis-state it.

Otherwise it looks like a good article, at least to the extent that I
can tell from just skimming it.

* "Nested loops" would be a much better term, IMHO.

--
Tim Wescott
Control systems and communications consulting
http://www.wescottdesign.com

Need to learn how to apply control theory in your embedded system?
"Applied Control Theory for Embedded Systems" by Tim Wescott
Elsevier/Newnes, http://www.wescottdesign.com/actfes/actfes.html

Indeed, a proper cascade (nested loops) can:
- improve the rejection of disturbances that hit the inner secondary
measured process variable,
- speed up the outer primary loop to permit an improved set point
response,
- even temper nonlinearities associated with the inner secondary loop to
the benefit of the outer primary loop.

I am working on a series of articles that compare/contrast cascade with
feed forward and that focus got me off track.

Thanks for the catch. I will have the article updated in the next few
days.

Doug
http://www.controlguru.com/

That was a really good article. The example was also excellent. If and
when I become a Prof one day, I will have to use a similar example to
show the benefits of nested loop control.

As a side note, in many mechanical systems it is possible to utilize
feedforward to improve tracking control. For example, many mechanical
system can be modeled as mass-spring-damper systems:

M*q_dot_dot + C*q_dot + K*q = u(t)

All feedforward is, is a control that mimics the plant dynamics in
order to "cancel" them out. For example, if I had a feedfoward +
feedback (PD feedback) controller of the form:

u(t) = M*q_dot_dot_desired - Kp(q - q_desired) - Kd(q_dot -
q_dot_desired)

then the resultant dynamics would be

M*q_dot_dot + C*q_dot + K*q = M*q_dot_dot_desired - Kp(q - q_desired)
- Kd(q_dot - q_dot_desired)

and provided q approx = q_desired (and q_dot_dot ~= q_dot_dot_desired,
q_dot ~= q_dot_desired) the above equation simplifies too

(C + Kd)*q_dot + (K + Kp)*q = Kp*q_desired + Kd*q_dot_desired

The only reason I mention this is because in some fields such as
robotics, feedforward control is used with great success because of
the very deterministic properties of the plant, that being the robot.
I have successfully implemented many nonlinear feedforward + feedback
(in the form of PD, PID, PI, Lead-Lag, H2 etc feedback) controllers on
both rigid and flexible mechanical systems (mostly robotic
manipulators).

I also feel inclined to mention something Peter Nachtwey posted a link
too : http://www.convolve.com/   These guys seem to have a "fancy"
feedfoward controller that is basically a convolution of the control
and the output. I have not had much time to read up on it... perhaps
Tim or Peter could give me a brief tutorial on what it is. From what I
have read, it does sound interesting though. Although I have some
doubts as to their claim of "input shaping does not effect the
stability of the closed loop system in any way"... anytime you add
dynamics in the form of feedforward or feedback you are effecting the
stability of the closed loop. You may be making the CL MORE stable,
but your changing it none the less. The plant has its own eigenvlaues,
the control has its own eigenvalues and the closed loop is the
combination. If you has some more control in the form of feedforward,
you are again adding some eigenvalues (poles) which will effect the CL
system in some way.

James Forbes

On Fri, 13 Jul 2007 14:45:22 +0000, James Forbes wrote:


What it looks like is a little bit of real value wrapped in a big oily
sheet of hype.

What they're doing is running your command through a filter before it gets
applied to the system, so that any resonances in the system get
preemtively damped out.  If you know enough about how the system responds
you can do this fairly easily.  The hard part is knowing enough about the
system.  It sounds like they're doing something fancy to kill a range of
frequencies in the input -- it'd be interesting to see what they think
they're doing.

If they are truly implementing the block diagrams they show then they
_aren't_ changing the stability of the system, for good or ill.  Because
they are changing the command to the system, not the system itself, they
cannot change it's stability.

What they _could_ do, and don't mention, is excite a hard limit cycle in
an otherwise well-behaved system.  This would be a bad thing.  Another
thing that they don't cover (and which I'm not sure they attempt to
address at all) is that a nonlinear system is going to respond in a
qualitatively different way to different inputs.  If they are sticking a
_linear_ filter in front of a system then its ability to smooth out the
rough patches may be severely constrained.

--
Tim Wescott
Control systems and communications consulting
http://www.wescottdesign.com

Need to learn how to apply control theory in your embedded system?
"Applied Control Theory for Embedded Systems" by Tim Wescott
Elsevier/Newnes, http://www.wescottdesign.com/actfes/actfes.html