Cascade, Scan Time, PID Tuning

Otto Muller-Girard, PE
Omg@frontiernet.net

A: It is a good idea to slow down the scan time for slow moving controllers. When the reset is more than five minutes, in many cases the controller does not need to run every second or even every 10 seconds. A common rule of thumb is that the scan time for a controller should be at least 10 times faster than the reset in minutes/repeat or rate in minutes. In my experience, the scan time almost never has to be more than 30 times faster than the reset.

You have a choice to adjust the scan time or the PV filter time. When the scan time is in a 10:30 ratio to the reset, then the PV filter time can be kept in a more typical range.

For example, if the reset is 10 minutes/repeat, then 30 times faster translates to a 20- second scan time as the maximum, and 10 times faster equates to a 1-minute scan time as a minimum.

Jim Becker
james.becker@bayer.com

A: Scan should be fast enough to capture pertinent information…
If too long, dead time will be increased and loop performance will degrade; you will have to detune the loop because dead time appears now longer. If too short, it is useless… and requires too much time from the CPU.

As a rule of thumb, for control loops tuned to reject disturbances, scan time should be around one-tenth of dead time. That being said, if the loop is tuned sluggishly, there is no need to use fast scan time.

Michel Ruel, P.Eng.
AMichel.Ruel@bba.ca

A: Increasing scan rate may improve stability; it won't hurt. It all depends on the time constants. Detuning will always reduce quality of control. And if dead time dominates the control loop, you must detune to improve stability.

Be careful to tune the process, not the valve.

The old rule of thumb said that when you used sampled data you had to sample five or ten times faster than the loop time constant to "keep in touch" with the situation. Lengthening out of sample rate can be a bad thing, but there is no magic number. We fear what is called "aliasing," where sampling time was some integral fraction of the sampled process time constant, and the data seen was in serious error, as the samples would see the peaks or valleys of cycles and not show the real response for a while and then drift between the peaks and valleys and present a very confused image of the process dynamics. The cure is to sample frequently enough.

Back to master/slave loops. Forgive me if this is elementary for you, but I want to go back to the basics for fear we could be thinking of different things.

I once worked in a plant where the internal temperature of jacketed kettles had to be closely controlled. Any change in the source of heating or cooling (steam and cold water) would affect the kettle temperature, and the system would never settle down. The slave loop has the duty of quickly stabilizing the source of heat or cooling and insulating the slow master controller from the faster upsets. It is usually far faster than the master loop (tens of seconds versus tens of minutes) and should be tuned for fast response. The master (vessel temperature) controller output signal, is used as the set point for the secondary, (jacket inlet temperature) loop. The sampling rate for the master controller has to be frequent enough to maintain good control.

"Detuning" in my world means reducing gain and lengthening reset time (integral) to decrease response. The penalty is obviously sluggish response and poor control. But the charts or display might look nice.

Some time ago while developing the ISA Standard 75.25 on control valve response, I worked up a computer simulation of a simple level control loop using a less-than-perfect control valve, while subjecting the loop to a forced upset. For each valve I made a number of runs, starting with the controller set at a low gain and then increased the controller to a high gain. Integrated error was computed for each run. This was repeated for another less perfect valve and so on.

The 3D plot of process error plotted against valve response and controller gain was very interesting. The difference in total error for the perfect valve versus the less than perfect valve was huge. For each valve, the minimum in the error curve showed where the controller gain was optimum for the loop for that valve. These error minimums varied a great deal. The increased error resulted from the requirement to reduce controller gain to stop cycling. A few percent difference in valve precision had a much greater impact on the quality of control than you might expect. This required a patient computer.

Cullen Langford
CullenL@aol.com

A: Sampling in control systems takes a whole book and at least one semester at the university. 

However that will not give you a useful answer to your current needs, so let me start by saying that "scan rate" is not and should not be a tuning parameter, except in the cases where you are using an analyzer that provides a result every given sampled time. And from your question that doesn't seem to be your case.

Second, dead time is the worst enemy of a control loop, and sampling increases the dead time by half of the sample time.

There are fast loops and slow loops. The fast ones, such as liquid flow or liquid pressure control, can have a combined dead time and lag time of about 1 to 2 seconds, so a sample time of 1 or more seconds can make the loop dead time dominant, and that will impose a severe limitation to the controller gain and therefore to its performance. On top of that the controller timing modes (Integral, Derivative, Filters) are undesirably affected by the sampling time.