Question on Cascade Control

I am creating a control system which has a temperature control in it. Most of my experience has been in controlling servo motors in very fast (2KHz+) hybrid
torque / position loops, so the relatively slow TC in the temperature system is making me question the best approach.
The oil loop consists of a pump (which can add a disturbace energy), an input manifold (heat loss disturbance), the load actuator (more loss), a return manifold (loss), an electric heater, a heat exchanger, and back to the pump reservoir.
I have thermocouples at the input manifold, the return manifold, the heater core, and the heater output. The actual state variable I wish to control is the temperature going into the actuator, which here is best obtained by the thermocouple on the input manifold immediately before the actuator.
However, my actual point of control is a couple feet away at the heater, which is a lag and a loss or two away from the primary point we want to keep under control.
I'm worried that if I close a PID loop on the input thermocouple, I'll be dancing the heater around all day trying to accomodate for the inherent lags and disturbances in the system.
From what little I know about Cascade Control, this seems a likely candidate. However, from what examples I've seen, there would be an outer PID loop based on my overall desired setpoint and the input thermocouple.
The inner loop is the heater loop which would either close on the heater core temperature or the heater outlet temperature (or perhaps a weighted average of these).
What's kinda throwing me is that if the outer loop measured variable reaches the setpoint, the PID output will go to zero (in a primarily P setup) or would stop integrating (in a primarily I setup). Nowhere in any examples (and I apologize for using the web as a reference library instead of going out and getting the actual books I need) does anyone discuss that the outer loop should be primarily integral in nature (unless I just don't get it).
In other words, if I set up a PID loop for the outer loop, is the goal to "slowly" tweek the inner (heater) loop "a little higher" or "a little lower" and try to stop integrating on a setpoint command to the inner loop when the outer loop is satisfied. I guess I'm envisioning the outer loop having its hand on the thermostat in the living room. He's asking for more or less heat but the inner loop is the faster control who tries to accommodate that request.
So in the presence of a common disturbance offset (let's say a 10 degree loss through a manifold), the outer loop would end up setting on a request for 210 degrees out of the inner loop to satisfy an outer loop 200 degree setpoint. Or am I lost here?
[note... I'm coding this well in advance of the hardware being constructed, so I have no actual measurements on flow times, lags, etc. I have "good guesses", but the task right now is just to get a framework of code in place prior to HW integration]
Thanks in advance to anyone who can nudge me towards the right direction!
Regards,
Dan
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
DanG2015 wrote:

In general, the outer loop in a cascade system is concerned with precision, while the inner loop is concerned with speed. This implies a necessity of having an integral term in the outer loop (since the only concern of the integral term is achieving zero average error, in the long term), while the inner loop has little use for an integral operation and the whole system may actually be more stable if the inner loop does not integrate error. Besides, if the inner loop setpoint is not achieving the exact needed output, the outer loop's integrator will correct the inner loop setpoint to make up for the long term output error, driving the outer loop error to zero, in spite of an inner loop offset.
Likewise, the outer loop must apply its precision by monitoring the final result, while the inner loop achieves speed by measuring some process variable very close (in response delay terms) to the plant (the device that alters the system under output control).
If the outer loop holds to a fixed setpoint, the proportional and derivative actions do not need to respond to error and rate of change of error, but only to process and rate of change of process. This allows a slow and smooth response to an occasional outer loop setpoint change.
In contrast, the inner loop is driven, constantly by its setpoint, as well as by its process measurement, so its proportional term needs to respond to both these changes by being based on error. In most cases, the inner loop derivative action can be based strictly on process rate of change (not error rate of change), since the outer loop usually reacts to much slower changes than the inner process. By eliminating the derivative effect on inner setpoint changes you will improve the noise immunity of the outer loop. and only have a single derivative effect (at most ) in the cascade. If these two approaches in cascade achieve acceptable accuracy and stability but still do not keep up with fast disturbances, then you get into the realm of feed forward. That is, you try to measure disturbances, as directly as possible, and add (or multiply) to the PID output, a predicted effect (based on a model) of the disturbance on the required controller output. Depending on the disturbance effect measured, the best place to apply it may be either the outer loop, or the inner loop.
A very simple feed forward for the inner loop is a factor times the setpoint from the outer loop. In other words, there may be a very predictable steady state relationship between the setpoint value and the output value eventually arrived at by the inner loop controller that will achieve that setpoint. It is, in effect, a predicted integral term that has none of the phase delay of the automatic integral response.
--
John Popelish

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
I really can't improve on that answer.
Walter.

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Walter Driedger wrote:

I might have added that all generalizations are wrong, but that doesn't mean they are not useful.
I await a DCS system (or other industrial PID controller) that does away with all the choices about what the gain and derivative are based on and just has controllers with two gain and derivative terms, one pair based on setpoint and one pair based on process variable. Then I wouldn't have to pick one of the other, but just optimize the setpoint and feedback responses, individually. It would simplify the pile of generalities I just waded through and make the last paragraph obsolete.
There is money to be made on nuances like this.
--
John Popelish

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

Thanks for the replies, they provide some good insight.
One area that still confuses me is the use of "vanilla" PID controls in such cascaded systems. While a good analysis of the process variables surely makes sense, much of PID tuning is generally just "getting the coefficients correct" to keep the process under control.
One thing you usually count on is that the setpoint and measured variable are "the same", meaning both are temperature or a motor position.
With cascade control and generic PID loops, I see troubles... the inner loop would measure, say temperature at a controllable point (in my case, a heater somewhat remote from the primary outer loop measurement point). Thus, it expects a temperature setpoint and controls a local temperature.
Now the outer loop in this case is also controlling temperature. Its setpoint is temperature and its measurement is temperature.
However, the output of the outer loop PID controller ends up not being a dimensionless input into a (heater, servo amp, etc.), it is actually a temperature setpoint into the inner loop.
Hence, isn't it a requirement in these cases that you utilize a PID loop that has strict controls on integrator and output limits?
For example, a somewhat generic PID controller that has, say, normalized -1 to +1 control outputs (or in HW, -10V to +10V, or 4 to 20mA) doesn't quite form a setpoint. Meaning that the inner loop expects to see, say, 70F to 200F as a setpoint cmd, so if the outer PID (when scaled) has the equivalent of -200F to 200F range, everything below 70F is just confusing for the inner loop.
In this case, limiting the output of the outer PID to a low of 70 and a high of 200 makes sense, but then the integrator would also need to be limited to prevent windup far outside the output limits.
So in conclusion, is cascade control usually done in such a manner where one doesn't just string together a series of generic PID loops, but instead uses something more specialized and targeted towards cascade control?
Thanks for the info,
Dan
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
DanG2015 wrote:

Sorry. I don't understand what you are trying to get me to understand by this paragraph. Much PID tuning is rather aimless, except to not have the process completely out of control. The problem is that many people do not clearly think about their aims before tuning loops and also are weak as to how to achieve various aims by tuning.

Yes. They should be both measured with the same units.

Yes.
Yes.
No outputs are dimension less in the real world. Just because the controller output is labeled in % instead of some real world unit, does not mean that some real world unit doesn't apply. They are just standardized to percent of an unknown range of some real world variable, by convention.
So an output that controls a valve is labeled as percent (of valve position), but that is just a stand in for what is actually happening which is some physical driving force that perturbs the system, such as a flow of steam, hot water, etc. In a cascade system, there is no real world driving force controlled by the outer loop. The only thing there is to control is the goal of another loop. So the real units of the outer loop controller is percent of the range of the setpoint of the inner loop.

This is a good idea for any pid controller.

The outer loop output scaling should be exactly the range of the setpoint on the inner loop, not some arbitrary range. So if that is what you are saying, we agree.

Again, limiting integral windup is important for any PID controller that performs integral action. You also need to perform back calculations that transition the outer loop from manual to automatic operation without bumping the setpoint f the inner loop. This usually involves setting the integrator term to balance the other two terms to produce an output that matches the last value set manually.
The inner loop is usually handled a bit differently. When it is transitioned from manual operation to cascade, its last process value is put into its setpoint by propagating that value back to the outer loop controller to set its output to this value by the integral initialization described in the previous paragraph.
If the inner loop is transitioned from automatic (fixed setpoint) to cascade, it is the current automatic setpoint that is usually propagated back to the output of the outer loop controller.

The coordination features are an important part of a smoothly operating cascade system that has all the normal operator intervention possibilities and handles saturation events as gracefully as possible.
--
John Popelish

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Dan,
Other than the initialization require to provided bumpless transfer, anti-reset windup, etc. there is no difference between inner and outer cascade controller and single loop controllers. A typical situation is a level / flow cascade. The inner, flow, loop is no different from any other flow loop. The function of the controller is to hold the flow to setpoint. The fact that the setpoint changes slowly in response to an external situation is normal for any controller. It is important that the setpoint not change too rapidly for the loop to follow.
The outer, level, controller is also no different than any other. It has the advantage of having a linearized valve as its end device. This makes it easier for the control by making the loop behave more like an ideal, linear situation. The normal, linear, controller is thus even better suited than before so long as the inner loop is not so slow as to defeat the work of the outer loop.
From the above discussion it is clear that the only special requirement is that the inner loop is faster than the outer.
Walter.

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

When P-only control is used, there has to be a manually-adjustable bias added to the controller output. This bias ensures that the P-action applies in a region centred on the target steady-state output value (which is not necessarily zero). The control loop will only have precisely zero steady-state error when this bias is manually adjusted (reset) to trim out the residual steady-state error (which is why in history the bias adjustment is called Manual-Reset).
Integral action substitutes this Manual-Reset bias with an automatically adjusted bias (which is why in history it is also called Automatic-Reset).
Kelvin B. Hales Kelvin Hales Associates Limited Consulting Control Engineers Web: www.khace.com
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

Polytechforum.com is a website by engineers for engineers. It is not affiliated with any of manufacturers or vendors discussed here. All logos and trade names are the property of their respective owners.