Cascade Control

A simple control system drawn in block diagram form looks like this:

Information from the measuring device (e.g. transmitter) goes to the controller, then to the final control device (e.g. control valve), influencing the process which is sensed again by the measuring device.

The controller’s task is to inject the proper amount of negative feedback such that the process variable stabilizes over time. This flow of information is collectively referred to as a feedback control loop.

To cascade controllers means to connect the output signal of one controller to the setpoint of another controller, with each controller sensing a different aspect of the same process.

The first controller (called the primary, or master ) essentially “gives orders” to the second controller (called the secondary or slave) via a remote setpoint signal.

Thus, a cascade control system consists of two feedback control loops, one nested inside the other:

A very common example of cascade control is a valve positioner, which receives a command signal from a regular process controller, and in turn works to ensure the valve stem position precisely matches that command signal.

The control valve’s stem position is the process variable (PV) for the positioner, just as the command signal is the positioner’s setpoint (SP). Valve positioners therefore act as “slave” controllers to “master” process controllers controlling pressure, temperature, flow, or some other process variable.

The purpose of cascade control is to achieve greater stability of the primary process variable by regulating a secondary process variable in accordance with the needs of the first.

An essential requirement of cascaded control is that the secondary process variable be faster-responding (i.e. shorter lag and dead times) than the primary process variable.

An analogy for understanding cascade control is that of delegation in a work environment. If a supervisor delegates some task to a subordinate, and that subordinate performs the task without further need of guidance or assistance from the supervisor, the supervisor’s job is made easier.

The subordinate takes care of all the little details that would otherwise burden the supervisor if the supervisor had no one to delegate to.

This analogy also makes it clear why the secondary process variable must be faster-responding than the primary process variable: the supervisor-subordinate management structure fails to work if the supervisor does not maintain focus on long-term goals (i.e. longer-term than the completion time of the tasks given to subordinates).

If a supervisor focuses on achieving goals that are shorter-term than the time required for subordinates to complete their assignments, the supervisor will inevitably call for “course changes” that are too quick for the subordinates to execute.

This will lead to the subordinates “lagging” behind the supervisor’s orders, to the detriment of everyone’s satisfaction.

Example :

An example of cascade control applied to a real industrial process is shown here, for a dryer system where heated air is used to evaporate water from a granular solid.

The primary process variable is the outlet air exiting the dryer, which should be maintained at a high enough temperature to ensure water will not remain in the upper layers of the solid material.

This outlet temperature is fairly slow to react, as the solid material mass creates a large lag time:

There are several parameters influencing the temperature of the outlet air other than the moisture content of the drying material. These include air flow, ambient air temperature, and variations in steam temperature.

Each one of these variables is a load on the process variable we are trying to control (outlet air temperature). If any of these parameters were to suddenly change, the effect would be slow to register at the outlet temperature even though there would be immediate impact at the bottom of the dryer where the heated air enters.

Correspondingly, the control system would be slow to correct for any of these changing loads.

We may better compensate for these loads by installing a second temperature transmitter at the inlet duct of the dryer, with its own controller to adjust steam flow at the command of the primary controller:

Now, if any of the loads related to incoming air flow or temperature vary, the secondary controller (TC-1b) will immediately sense the change in dryer inlet temperature and compensate by adjusting steam flow through the heat exchanger.

Thus, the “slave” control loop (1b) helps stabilize the “master” control loop (1a) by reacting to load changes long before any effect might manifest at the dryer outlet.

A helpful way to think of this is to consider the slave controller as shielding the master controller from the loads previously mentioned (incoming air flow, ambient temperature, and steam temperature).

Of course, these variables still act as loads to the slave controller, as it must continuously adjust the steam valve to compensate for changes in air flow, ambient air temperature, and steam temperature.

However, so long as the slave controller does a good job of stabilizing the air temperature entering the dryer, the master controller will never “see” the effects of those load changes.

Responsibility for incoming air temperature has been delegated to the slave controller, and as a result the master controller is conveniently isolated from the loads impacting that loop.

To re-emphasize an important point, one of the non-negotiable requirements for cascade control is that the secondary (slave) loop must be faster-responding than the primary (master) loop.

Cascade control cannot function if this speed relationship is reversed. Temperature controller TC-1b is able to be a slave to controller TC-1a because the natural response time of the temperature at the dryer’s bottom is much shorter than at the dryer’s top with respect to any changes in steam valve position.

Important Points :

A necessary step in implementing cascade control is to ensure the secondary (“slave”) controller is well-tuned before any attempt is made to tune the primary (“master”) controller.

Just a moment’s thought is all that is needed to understand why this precedence in tuning must be: it is a simple matter of dependence.

The slave controller does not depend on good tuning in the master controller in order to control the slave loop. If the master controller were placed in manual (effectively turning off its automatic response), the slave controller would simply control to a constant setpoint.

However, the master controller most definitely depends on the slave controller being well-tuned in order to fulfill the master’s “expectations.” If the slave controller were placed in manual mode, the master controller would not be able to exert any control over its process variable whatsoever.

Clearly then, the slave controller’s response is essential to the master controller being able to control its process variable, therefore the slave controller should be tuned first when initially commissioning or optimizing a cascade control system.

Just like supervisory control systems where a process controller receives a “remote” setpoint signal from some other system, the secondary (“slave”) controller in a cascade system typically has three different operating modes:

• Manual mode: Controller takes no automatic action. Output value set by human operator.

• Automatic mode: Controller automatically adjusts its output to try to keep PV = SP. Setpoint value set “locally” by human operator.

• Cascade mode: Controller automatically adjusts its output to try to keep PV = SP. Setpoint value set “remotely” by primary (master) controller.

This means it is possible to defeat a cascade control system by placing the secondary controller in the wrong mode (automatic) just as it is possible to defeat any control system by placing the controller in manual mode. If a controller is “slaved” to another controller, it must be left in cascade mode in order for the control strategy to function as designed.

Also Read : Feedback Control Principle