The Cascade Control Architecture - controlguru post

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 wrote in news:7smdnYJMPo_FoBLbnZ2dnUVZ snipped-for-privacy@web-ster.com:

Tom

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

innews:7smdnYJMPo_FoBLbnZ2dnUVZ snipped-for-privacy@web-ster.com:

Doug,

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 :

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

innews:7smdnYJMPo_FoBLbnZ2dnUVZ snipped-for-privacy@web-ster.com:

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.