Showing posts with label behavious. Show all posts

Integral (Reset) Windup, Jacketing Logic and the Velocity PI Form

A valve cannot open more than all the way. A pump cannot go slower than stopped. Yet an improperly programmed control algorithm can issue such commands.

Herein lies the problem of integral windup (also referred to as reset windup or integral saturation). It is a problem that has been around for decades and was solved long ago. We discuss why it occurs and how to prevent it to help those who choose to write their own control algorithm.

The PI Algorithm
To increase our comfort level with the idea that different vendors cast the same PI algorithm in different forms, we choose the independent, continuous, position PI form for this discussion:

Where:
CO = controller output signal (the wire out)
CObias = controller bias or null value
e(t) = current controller error, defined as SP - PV
SP = set point
PV = measured process variable (the wire in)
Kc = proportional gain, a tuning parameter
Ki = integral gain, a tuning parameter

Note that Kc is the same parameter in both the dependent and independent forms, though it is more typically called controller gain in the dependent form.

Every procedure and observation we have previously discussed about PI controllers applies to both forms. Both even use the same tuning correlations. To tune Ki, we compute Kc and Ti for the dependent form and then divide (Ki = Kc/Ti).

Integral (Reset) Windup
Our previous discussion of integral action noted that integration is a continual summing. As shown below, integration of error means that we continually sum controller error up to the present time.

The integral sum starts accumulating when the controller is first put in automatic and continues to change as long as controller error exists.
If an error is large enough and/or persists long enough, it is mathematically possible for the integral term to grow very large (either positive or negative):

This large integral, when combined with the other terms in the equation, can produce a CO value that causes the final control element (FCE) to saturate. That is, the CO drives the FCE (e.g. valve, pump, compressor) to its physical limit of fully open/on/maximum or fully closed/off/minimum.

And if this extreme value is still not sufficient to eliminate the error, the simple mathematics of the controller algorithm, if not jacketed with protective logic, permits the integral term to continue growing.

If the integral term grows unchecked, the equation above can command the valve, pump or compressor to move to 110%, then 120% and more. Clearly, however, when an an FCE reaches its full 100% value, these last commands have no physical meaning and consequently, no impact on the process.

Control is Lost
Once we cross over to a "no physical meaning" computation, the controller has lost the ability to regulate the process.

When the computed CO exceeds the physical capabilities of the FCE because the integral term has reached a large positive or negative value, the controller is suffering from windup. Because windup is associated with the integral term, it is often referred to as integral windup or reset windup.

To prevent windup from occurring, modern controllers are protected by either:
▪ Employing extra "jacketing logic" in the software to halt integration when the CO reaches a maximum or minimum value.
▪ Recasting the controller into a discrete velocity form that, by its very formulation, naturally avoids windup.
Both alternatives offer benefits but possess some fairly subtle drawbacks that we discuss below.

Visualizing Windup
To better visualize the problem of windup and the benefit of anti-windup protection, consider the plot from our heat exchanger process below (click for a large view).
To the left is the performance of a PI controller with no windup protection. To the right is the performance of the same controller protected by an anti-windup strategy.
For both controllers, the set point is stepped from 200 °C up to 215 °C and back again. As shown in the lower trace on the plot, the controller moves the CO to 0%, closing the valve completely, yet this is not sufficient to move the PV up to the new set point.

To the left in the plot, the impact of windup is a degraded controller performance. When the set point is stepped back to its original value of 200 °C , the windup condition causes a delay in the CO action. This in turn causes a delay in the PV response.

To the right in the plot, anti-windup protection permits the CO, and thus PV, to respond promptly to the command to return to the original SP value of 200 °C.

More Details on Windup
The plot below (click for large view) offers more detail. As labeled on the plot:

1) To the left for the Controller with Wind-up case, the SP is stepped up to 215 °C. The valve closes completely but is not able to move the PV all the way to the high set point value. Integration is a summing of controller error, and since error persists, the integration term grows very large.
The sustained error permits the controller to windup (saturate). While it is not obvious from the plot, the PI algorithm is computing values for CO that ask the valve to be open -5%, -8% and more. The control algorithm is just simple math with no ability to recognize that a valve cannot be open to a negative value.
Note that the chart shows the CO signal bottoming out at 0% while the controller algorithm is computing negative CO values. This misleading information is one reason why windup can be difficult to diagnose as the root cause of a problem from visual inspection of process data trend plots.

2) When the SP is stepped back to 200 °C, it seems as if the CO does not move at first. In reality, the control algorithm started moving the CO when the SP changed, but the values remain in the physically meaningless range of negative numbers.
So while the valve remains fully closed at 0%, the integral sum is accumulating controller errors of opposite sign. As time passes, the integral term shrinks or "unwinds" as the running sum of errors balance out.
3) When the integral sum of errors shrinks enough, it no longer dominates the CO computation. The CO signal returns from the physically meaningless world of negative values. The valve can finally move in response.
4) To the right in the plot above, the controller is protected from windup. As a result, when the set point is stepped back to 200 °C, the CO immediately reacts with a change that is proportional to the size of the SP change. The PV moves quickly in response to the CO actions as it tracks the SP back to 200 °C.

◊ Solution 1: Jacketing Logic on the Position Algorithm
The PI controller at the top of this article is called the position form because the computed CO is a specific intermediate value between full on/open/maximum and closed/off/minimum. The continuous PI algorithm is specifying the actual position (e.g., 27% open, 64% of maximum) that the final control element (FCE) should assume.

● Simple Logic Creates Additional Problems
It is not enough to have logic that simply limits or clips the CO if it reaches a maximum (COmax) or minimum (COmin) value because this does nothing to check the growth of the integral sum of errors term.
I
n fact, such simple logic was used in the "control with windup" plots just discussed. The CO seems stuck at 0% and we are unaware that the algorithm is actually computing negative valve positions as described in item 1 above.

● Anti-Windup Logic Outline
When we switch from manual mode to automatic, we assume that we have initialized the controller using a bumpless transfer procedure. That is, at switchover, the integral sum of error is set to zero, the SP is set equal to the current PV, and the controller bias is set equal to the current CO (implying that COmin < CObias < COmax).

Thus, there is nothing to cause CO to immediately change and "bump" our process at switchover.

One approach to creating anti-windup jacketing logic is to artificially manipulate the integral sum of error itself. With our controller properly initialized, the approach is to flip the algorithm around and back-calculate a value for the integral sum of error that will provide a desired controller output value (COdesired), or:

Note that COdesired can be different in different situations. For example,
▪ We do not want tuning parameter adjustments to cause sudden CO movements that bump our process. So if tuning values have changed, COdesired is the value of CO from the previous loop calculation cycle.
▪ If the PI controller computes CO values that are above COmax or below COmin, then we must be concerned about windup and COdesired is set equal to the limiting COmax or COmin value.

The anti-windup logic followed at every loop sample time, T, is thus:

1) If tuning parameters have changed since the last loop calculation cycle, then COdesired = current CO. Back calculate the integral sum of error so CO remains unchanged from the previous sample time. This prevents sudden CO bumps due to tuning changes.

2) Update SP and PV for this loop calculation cycle.
3) compute:

4) If CO > COmax or if CO < COmin, then the anti-windup (integral desaturation) logic of step 5 is required. Otherwise, proceed to step 6.

5) If CO > COmax, then CO = COdesired = COmax. if CO < COmin, then CO = COdesired = COmin. Back calculate the integral sum of error using our selected COdesired and save it for use in the next control loop calculation cycle.

6) Implement CO

◊ Solution 2 - Use the Velocity (Discrete) Controller Form
Rather than computing a CO signal indicating a specific position for our final control element, an alternative is to compute a signal that specifies a change, ∆CO, from current position for the FCE. As explained below, this is called the velocity or discrete controller form.

We employ the dependent algorithm for this presentation, but the derivation that follows can be applied in an analogous fashion to the independent PI form. To derive the discrete velocity form, we must first write the continuous, position form of the PI controller to include the independent variable on the controller output, showing it properly as CO(t) to reflect that it changes with time:

Please note that this controller is identical to all dependent PI forms as presented in other articles. The only difference is we are being more mathematically precise in our expression of CO(t).

● Deriving the Discrete Velocity Form
The first step in deriving the discrete form is to take the time derivative of the continuous form. In physics, the time derivative (rate of change) of a position is a velocity. This is why the final form of the PI controller we derive is often called the velocity form.

Taking the derivative of the continuous PI controller above with respect to time yields:

Since CObias is a constant and the derivative of a constant is zero, then:

Removing this term from the equation results in:

If we assume discrete or finite difference approximations for the continuous derivatives, then the controller becomes:

where ei is the current controller error, ei-1 is the controller error at the previous sample time, T, and ∆ei = ei - ei-1.
Recognizing that loop sample time is T = ∆t, then the PI controller becomes:

Rearranging, we arrive at the discrete velocity form of the PI controller:

● Reason for Anti-Windup Protection
Discrete velocity algorithms compute a ∆CO that signals the FCE to move a specific distance and direction from its current position. As we can see from the PI controller form above, the computation does not keep track of the current FCE position, nor does it mathematically accumulate any integral sums.

In a sense, the accumulation of integration is stored in the final control element itself. If a long series of ∆CO moves are all positive, for example, the valve, pump or compressor will move toward its maximum value. And once the FCE reaches its maximum limit, any ∆CO commands to move further will have no impact because, as stated in the first sentences of this article, a valve cannot open more than all the way and a pump cannot go slower than stopped. It is the physical nature of the FCE itself that provides protection from over-accumulation (i.e., windup).

As long as the CO never reaches COmax or COmin, the continuous position and discrete velocity forms of the PI controller provide identical performance. A properly jacketed continuous position PI controller will also provide windup protection equal to the discrete velocity form. Implicit in these statements is that sample time,T, is reasonably fast and that T and the tuning values (Kc and Ti) are the same when comparing implementations.

● Concerns with Discrete Velocity PID
Unfortunately, the usefulness of the discrete velocity form is limited because the method suffers problems when derivative action is included. We find that we must take the derivative of a derivative, yielding a second derivative. A second derivative applied to data that contains even modest noise can produce nonsense results.

Some vendors implement this form anyway and include a signal filter and additional logic sequences to address the problem. Thus, even with the anti-windup benefits of a discrete velocity algorithm, we find the need to jacket the algorithm with protective logic.

Tuesday, 22 March 2011 // Labels: action, basics, behavious, Heat Exchanger, integral, pid, tuning // 1 comments //

Interacting Tuning Parameters

Many process control practitioners tune by "intuition," fiddling their way to final tuning by a combination of experience and trial-and-error.

Some are quite good at approaching process control as art. Since they are the ones who define "best" performance based on the goals of production, the capabilities of the process, the impact on down stream units, and the desires of management, it can be difficult to challenge any claims of success.

To explore the pitfalls of a trial and error approach and reinforce that there is science to controller tuning, we consider the common dependent, ideal form of the PI controller:

Where:
CO = controller output
e(t) = controller error = set point - process variable = SP - PV
Kc = controller gain, a tuning parameter
Ti = reset time, a tuning parameter

For this form, controller activity or aggressiveness increases as Kc increases and as Ti decreases (Ti is in the denominator, so smaller values increase the weighting on the integral action term, thus increasing controller activity).

Since Kc and Ti individually can make a controller more or less aggressive in its response, the two tuning parameters interact with each other. If current controller performance is not what we desire, it is not always clear which value to raise or lower, or by how much.

Example of Interaction Confusion
To illustrate, consider a case where we seek to balance a fairly rapid response to a set point change (a short rise time) against a small overshoot. While every process application is different, we choose to call the response plot below our desired or base case performance.

Now consider the two response plots below. These were made using the identical process and controller to that above. The only difference between the base case response above and plot A and plot B below is that different Kc and Ti tuning values were used in each one.

And now the question: what tuning adjustments are required to restore the desired base case performance above starting from each plot below? Or alternatively: how has the tuning been changed from base case performance to produce these different behaviors?

There are no tricks in this question. The "process" is a simple linear second order system with modest dead time. Controller output is not hitting any limits. The scales on the plot are identical. Everything is as it seems, except PI controller tuning is different in each case.

Study the plots for a moment before reading ahead and see if you can figure it out. Each plot has a very different answer.

Some Hints
Before we reveal the answer, here is a hint. One plot has been made more active or aggressive in its response by doubling Kc while keeping Ti constant at the original base case value.

The other cuts Ti in half (remember, decreasing Ti makes this PI form more active) while keeping Kc at the base case value:

So we have:
• Base case = Kc and Ti
• Plot A or B = 2Kc and Ti
• Other Plot B or A = Kc and Ti/2

Still not sure? Here is a final hint: remember from our previous discussions that proportional action is largely responsible for the first movements in a response. We also discussed that integral action tends to increase the oscillatory or cycling behavior in the PV.

It is not easy to know the answer, even with these huge hints, and that is the point of this article.

The Answer
Below is a complete tuning map with the base case performance from our challenge problem in the center. The plot shows how performance changes as Kc and Ti are doubled and halved from the base case for the dependent, ideal PI controller form.

Starting from the center and moving up on the map from the base case performance brings us to plot B. As indicated on the tuning map axis, this direction increases (doubles) controller gain, Kc, thus making the controller more active or aggressive. Moving down on the map from the base case decreases (halves) Kc, making the controller more sluggish in its response.

Moving left on the map from the base case brings us to plot A. As indicated on the tuning map axis, this direction decreases reset time (cuts it in half), again making the controller more active or aggressive. Moving right on the map from the base case increases (doubles) reset time, making the controller more sluggish in its response.

It is clear from the tuning map that the controller is more active or aggressive in its response when Kc increases and Ti decreases, and more sluggish or conservative when Kc decreases and Ti increases.

Building on this observation, it is not surprising that the upper left most plot (2Kc and Ti/2) shows the most active controller response, and the lower right most plot (Kc/2 and 2Ti) is the most conservative or sluggish response.

Back to the question. With what we now know, the answer:
• Base case = Kc and Ti
• Plot B = 2Kc and Ti
• Plot A = Kc and Ti/2

Interacting Parameters Makes Tuning Problematic

The PI controller has only two tuning parameters, yet it produces very similar looking performance plots located in different places on a tuning map.

f our instincts lead us to believe that we are at plot A when we really are at plot B, then the corrective action we make based on this instinct will compound our problem rather than solve it. This is strong evidence that trial and error is not an efficient or appropriate approach to tuning.

When we consider a PID controller with three tuning parameters, the number of similar looking plots in what would be a three dimensional tuning map increases dramatically. Trial and error tuning becomes almost futile.

We have been exploring a step by step tuning recipe approach that produces desired results without the wasted time and off-spec product that results from trial and error tuning.

If we follow this industry-proven methodology, we will improve the safety and profitability of our operation.

Interesting Observation

Before leaving this subject, we make one more very useful observation from the tuning map. This will help build our intuition and may help one day when we are out in the plant.

The right most plot in the center row (Kc, 2Ti) of the tuning map above is reproduced below.

Notice how the PV shows a dip or brief oscillation on its way up to the set point? This is a classic indication that the proportional term is reasonable but the integral term is not getting enough weight in the calculation. For the PI form used in this article, that would mean that the reset time, Ti, is too large since it is in the denominator.

If we cover the right half of the "not enough integral action" plot, the response looks like it is going to settle out with some offset, as would be expected with a P-Only controller. When we consider the plot as a whole, we see that as enough time passes, the response completes. This is because the weak integral action finally accumulates enough weight in the calculation to move the PV up to set point.

This "oscillates on the way" pattern is a useful marker for diagnosing a lack of sufficient integral action.

// Labels: action, basics, behavious, Control, control loop, Controllers, tuning // 0 comments //

The P-Only Control Algorithm

The simplest algorithm in the PID family is a proportional or P-Only controller. Like all automatic controllers, it repeats a measurement-computation-action procedure at every loop sample time, T, following the logic flow shown in the block diagram below (click for large view):

Starting at the far right of the control loop block diagram above:

A sensor measures and transmits the current value of the process variable, PV, back to the controller (the 'controller wire in')
Controller error at current time t is computed as set point minus measured process variable, or e(t) = SP - PV
The controller uses this e(t) in a control algorithm to compute a new controller output signal, CO
The CO signal is sent to the final control element (e.g. valve, pump, heater, fan) causing it to change (the 'controller wire out')
The change in the final control element (FCE) causes a change in a manipulated variable
The change in the manipulated variable (e.g. flow rate of liquid or gas) causes a change in the PV

The goal of the controller is to make e(t) = 0 in spite of unplanned and unmeasured disturbances. Since e(t) = SP - PV, this is the same as saying a controller seeks to make PV = SP.

The P-Only Algorithm
The P-Only controller computes a CO action every loop sample time T as:

CO = CObias Kc∙e(t)

Where:
CObias = controller bias or null value
Kc = controller gain, a tuning parameter
e(t) = controller error = SP - PV
SP = set point
PV = measured process variable

Design Level of Operation
Real processes display a nonlinear behavior, which means their apparent process gain, time constant and/or dead time changes as operating level changes and as major disturbances change. Since controller design and tuning is based on these Kp, Tp and Өp values, controllers should be designed and tuned for a pre-defined level of operation.

When designing a cruise control system for a car, for example, would it make sense for us to perform bump tests to generate dynamic data when the car is traveling twice the normal speed limit while going down hill on a windy day? Of course not.

Bump test data should be collected as close as practical to the design PV when the disturbances are quiet and near their typical values. Thus, the design level of operation for a cruise control system is when the car is traveling at highway speed on flat ground on a calm day.

Definition: the design level of operation (DLO) is where we expect the SP and PV will be during normal operation while the important disturbances are quiet and at their expected or typical values.

Understanding Controller Bias
Let's suppose the P-Only control algorithm shown above is used for cruise control in an automobile and CO is the throttle signal adjusting the flow of fuel to the engine.

Let's also suppose that the speed SP is 70 and the measured PV is also 70 (units can be mph or kph depending on where you live in the world). Since PV = SP, then e(t) = 0 and the algorithm reduces to:

CO = CObias Kc∙(0) = CObias

If CObias is zero, then when set point equals measurement, the above equation says that the throttle signal, CO, is also zero. This makes no sense. Clearly if the car is traveling 70 kph, then some baseline flow of fuel is going to the engine.

This baseline value of the CO is called the bias or null value. In this example, CObias is the flow of fuel that, in manual mode, causes the car to travel the design speed of 70 kph when on flat ground on a calm day.

Definition: CObias is the value of the CO that, in manual mode, causes the PV to steady at the DLO while the major disturbances are quiet and at their normal or expected values.

A P-Only controller bias (sometimes called null value) is assigned a value as part of the controller design and remains fixed once the controller is put in automatic.

Controller Gain, Kc
The P-Only controller has the advantage of having only one adjustable or tuning parameter, Kc, that defines how active or aggressive the CO will move in response to changes in controller error, e(t).

For a given value of e(t) in the P-Only algorithm above, if Kc is small, then the amount added to CObias is small and the controller response will be slow or sluggish. If Kc is large, then the amount added to CObias is large and the controller response will be fast or aggressive.

Thus, Kc can be adjusted or tuned for each process to make the controller more or less active in its actions when measurement does not equal set point.

P-Only Controller Design
All controllers from the family of PID algorithms (P-Only, PI, PID) should be designed and tuned using our proven recipe:

Establish the design level of operation (the normal or expected values for set point and major disturbances).
Bump the process and collect controller output (CO) to process variable (PV) dynamic process data around this design level.
Approximate the process data behavior with a first order plus dead time (FOPDT) dynamic model.
Use the model parameters from step 3 in rules and correlations to complete the controller design and tuning.

The Internal Model Control (IMC) tuning correlations that work so well for PI and PID controllers cannot be derived for the simple P-Only controller form. The next best choice is to use the widely-published integral of time-weighted absolute error (ITAE) tuning correlation:

Moderate P-Only:

This correlation is useful in that it reliably yields a moderate Kc value. In fact, some practitioners find that the ITAE Kc value provides a response performance so predictably modest that they automatically start with an aggressive P-Only tuning, defined here as two and a half times the ITAE value:

Aggressive P-Only: Kc = 2.5 (Moderate Kc)

Reverse Acting, Direct Acting and Control Action
Time constant, Tp, and dead time, Өp, cannot affect the sign of Kc because they mark the passage of time and must always be positive. The above tuning correlation thus implies that Kc must always have the same sign as the process gain, Kp.

When CO increases on a process that has a positive Kp, the PV will increase in response. The process is direct acting. Given this CO to PV relationship, when in automatic mode (closed loop), if the PV starts drifting too high above set point, the controller must decrease CO to correct the error.

This "opposite to the problem" reaction is called negative feedback and forms the basis of stable control.

A process with a positive Kp is direct acting. With negative feedback, the controller must be reverse acting for stable control. Conversely, when Kp is negative (a reverse acting process), the controller must be direct acting for stable control.

Since Kp and Kc always have the same sign for a particular process and stable control requires negative feedback, then:

direct acting process (Kp and Kc positive) −› use a reverse acting controller
reverse acting process (Kp and Kc negative) −› use a direct acting controller

In most commercial controllers, a positive value of the Kc is always entered. The sign (or action) of the controller is then assigned by specifying that the controller is either reverse or direct acting to indicate a positive or negative Kc respectively.

If the wrong control action is entered, the controller will quickly drive the final control element (e.g., valve, pump, compressor) to full on/open or full off/closed and remain there until the proper control action entry is made.

Proportional Band
Some manufacturers use different forms for the same tuning parameter. The popular alternative to Kc found in the marketplace is proportional band, PB.

In many industry applications, both the CO and PV are expressed in units of percent. Given that a controller output signal ranges from a minimum (COmin) to maximum (COmax) value, then:

PB = (COmax - COmin)/Kc

When CO and PV have units of percent and both range from 0% to 100%, the much published conversion between controller gain and proportional band results:

PB = 100/Kc

Many case studies on this site assign engineering units to the measured PV because plant software has made the task of unit conversions straightforward. If this is true in your plant, take care when using these conversion formula.

Implementation Issues
Implementation of a P-Only controller is reasonably straightforward, but this simple algorithm exhibits a phenomenon called "offset." In most industrial applications, offset is considered an unacceptable weakness. We explore P-Only control, offset and other issues for the heat exchanger and the gravity drained tanks processes.

// Labels: basics, behavious, componenst, control loop, Controllers, Drives, dynamic, loop, non-linear, pid, proportional, Safety, variability // 0 comments //

Proportional Control - The Simplest PID Controller

he P-Only Control Algorithm
The simplest algorithm in the PID family is a proportional or P-Only controller. Like all automatic controllers, it repeats a measurement-computation-action procedure at every loop sample time, T, following the logic flow shown in the block diagram below (click for large view):

Starting at the far right of the control loop block diagram above:

A sensor measures and transmits the current value of the process variable, PV, back to the controller (the 'controller wire in')
Controller error at current time t is computed as set point minus measured process variable, or e(t) = SP - PV
The controller uses this e(t) in a control algorithm to compute a new controller output signal, CO
The CO signal is sent to the final control element (e.g. valve, pump, heater, fan) causing it to change (the 'controller wire out')
The change in the final control element (FCE) causes a change in a manipulated variable
The change in the manipulated variable (e.g. flow rate of liquid or gas) causes a change in the PV

Establish the design level of operation (the normal or expected values for set point and major disturbances).
Bump the process and collect controller output (CO) to process variable (PV) dynamic process data around this design level.
Approximate the process data behavior with a first order plus dead time (FOPDT) dynamic model.
Use the model parameters from step 3 in rules and correlations to complete the controller design and tuning.

direct acting process (Kp and Kc positive) −› use a reverse acting controller
reverse acting process (Kp and Kc negative) −› use a direct acting controller

// Labels: basics, behavious, componenst, Control, control loop, Controllers, Courses, Drives, dynamic, linear, loop, motors, non-linear, pid, proportional, Safety, variability // 1 comments //

Controller process architecture

A controller seeks to maintain the measured process variable (PV) at set point (SP) in spite of unplanned and unmeasured disturbances. Since e(t) = SP - PV, this is equivalent to saying that a controller seeks to maintain controller error, e(t), equal to zero.

A controller repeats a measurement-computation-action procedure at every loop sample time, T. Starting at the far right of the control loop block diagram above:

A sensor measures a temperature, pressure, concentration or other property of interest from our process.
The sensor signal is transmitted to the controller. The pathway from sensor to controller might include: a transducer, an amplifier, a scaling element, quantization, a signal filter, a multiplexer, and other operations that can add delay and change the size, sign, and/or units of the measurement.
After all electronic and digital operations, the result terminates at our controller as the "wire in" measured process variable (PV) signal.
This "wire in" process variable is subtracted from set point in the controller to compute error, e(t) = SP - PV, which is then used in an algorithm (examples here and here) to compute a controller output (CO) signal.
The computed CO signal is transmitted on the "wire out" from the controller on a path to the final control element (FCE).
Similar to the measurement path, the signal from the controller to FCE might include filtering, scaling, linearization, amplification, multiplexing, transducing and other operations that can add delay and change the size, sign, and/or units of our original CO signal.
After any electronic and digital operations, the signal reaches the valve, pump, compressor or other FCE, causing a change in the manipulated variable (a liquid or gas stream flow rate, for example).
The change in the manipulated variable causes a change in our temperature, pressure, concentration or other process property of interest, all with the goal of making e(t) = 0.

Design Based on CO to PV Dynamics
The steps of the controller design and tuning recipe include: bumping the CO signal to generate CO to PV dynamic process data, approximating this test data with a first order plus dead time (FOPDT) model, and then using the model parameters in rules and correlations to complete the controller design and tuning.

The recipe provides a proven basis for controller design and tuning that avoids wasteful and expensive trial-and-error experiments. But for success, controller design and tuning must be based on process data as the controller sees it.

The controller only knows about the state of the process from the PV signal arriving on the "wire in" after all operations in the signal path from the sensor. It can only impact the state of the process with the CO signal it sends on the "wire out" before any such operations are made in the path to the final control element.

As indicated in the diagram at the top of this article, the proper signals that describe our complete "process" from the controller's view is the "wire out" CO and the "wire in" PV.

Complete the Circuit
Sometimes we find ourselves unable to proceed with an orderly controller design and tuning. Perhaps our controller interface does not make it convenient to directly record process data. Maybe we find a vendor's documentation to be so poorly written as to be all but worthless. There are a host of complications that can hinder progress.

Being resourceful, we may be tempted to move the project forward by using portable instrumentation. It seems reasonable to collect, say, temperature in a vessel during a bump test by inserting a spare thermocouple into the liquid. Or maybe we feel we can be more precise by standing right at the valve and using a portable signal generator to bump the process rather than doing so from a remote control panel.

As shown below, such an approach cuts out or short circuits the complete control loop pathway. External or portable instrumentation will not be recording the actual CO or PV as the controller sees it, and the data will not be appropriate for controller design or tuning.

Every Item Counts
The illustration above is extreme in that it shows many items that are not included in the control loop. But please recognize that it can be problematic to leave out even a single step in the complete signal pathway.

A simple scaling element that multiplies the signal by a constant value, for example, may seem reasonably unimportant to the overall loop dynamics. But this alone can change the size and even the sign of Kp, thus having dramatic impact on best tuning and final controller performance.

From a controller's view, the complete loop goes from "wire out" to "wire in" as shown below.

Every item in the loop counts. Always use the complete CO to PV data for process control analysis, design and tuning.

Pay Attention to Units
As detailed in this related article, signals can appear in a control loop in electronic units (e.g., volts, mA), in engineering units (e.g. oC, Lb/hr), as percent of scale (e.g., 0% to 100%), or as discrete or digital counts (e.g. 0 to 4095 counts).

It is critical that we remain aware of the units of a signal when working with a particular instrument or device. All values entered and computations performed must be consistent with the form of the data at that point in the loop.

Beyond the theory and methods discussed in this e-book, such "accounting confusion" can be one of the biggest challenges for the process control practitioner.

// Labels: basics, behavious, componenst, Control, control loop, Courses, DESIGN, Drives, linear, loop, non-linear, pid, proportional, Safety // 0 comments //

Nonlinear Process Behavior & DEEISGN OF CONTROL.

Processes with streams comprised of gases, liquids, powders, slurries and melts tend to exhibit variations in behavior as operating level changes. This, in fact, is the very nature of a nonlinear process. For this reason, our recipe for controller design and tuning begins by specifying our design level of operation.

Controller Design and Tuning Recipe:

Establish the design level of operation (DLO), which is the normal or expected values for set point and major disturbances.
Bump the process and collect controller output (CO) to process variable (PV) dynamic process data around this design level.
Approximate the process data behavior with a first order plus dead time (FOPDT) dynamic model.
Use the model parameters from step 3 in rules and correlations to complete the controller design and tuning.

Nonlinear Behavior of the Gravity Drained Tanks
The dynamic behavior of the gravity drained tanks process is reasonably intuitive. Increase or decrease the inlet flow rate into the upper tank and the liquid level in the lower tank rises or falls in response.

One challenge this process presents is that its dynamic behavior is nonlinear. That is, the process gain, Kp; time constant, Tp; and/or dead time, Өp; changes as operating level changes. This is evident in the open loop response plot below.

As shown above, the CO is stepped in equal increments, yet the response behavior of the PV changes as the level in the tank rises. The consequence of nonlinear behavior is that a controller designed to give desirable performance at one operating level may not give desirable performance at another level.

Nonlinear Behavior of the Heat Exchanger
Nonlinear process behavior has important implications for controller design and tuning. Consider, for example, our heat exchanger process under PI control.

When tuned for a moderate response as shown in the first set point step from 140 °C to 155 °C in the plot below, the process variable (PV) responds in a manner consistent with our design goals. That is, the PV moves to the new set point (SP) reasonably quickly but does not overshoot the set point.

The consequence of a nonlinear process character is apparent as the set point steps continue to higher temperatures. In the third set point step from 170 °C to 185 °C, the same controller that had given a desired moderate performance now produces a PV response with a clear overshoot and some oscillation.

Such a change in performance with operating level may be tolerable in some applications and unacceptable in others. As we discuss in this article, "best" performance is something we judge for ourselves based on the goals of production, capabilities of the process, impact on down stream units and the desires of management

Nonlinear behavior should not catch us by surprise. It is something we can know about our process in advance. And this is why we should choose a design level of operation as a first step in our controller design and tuning procedure.

Step 1: Establish the Design Level of Operation (DLO)
Because, as shown in the examples above, processes have process gain, Kp; time constant, Tp; and/or dead time, Өp values that change as operating level changes, and these FOPDT model parameter values are used to complete the controller design and tuning procedure, it is important that dynamic process test data be collected at a pre-determined level of operation.

Defining this design level of operation (DLO) includes specifying where we expect the set point (SP) and measured process variable (PV) to be during normal operation, and the range of values the SP and PV might typically assume. This way we know where to explore the dynamic process behavior during controller design and tuning.

The DLO also considers our major disturbances (D). We should know the normal or typical values for our major disturbances. And we should be reasonably confident that the disturbances are quiet so we may proceed with a bump test to generate and record dynamic process data.

Step 2. Collect Dynamic Process Data Around the DLO
The next step in our recipe is to collect dynamic process data as near as practical to our design level of operation. We do this with a bump test, where we step or pulse the CO and collect data as the PV responds.

It is important to wait until the CO, PV and D have settled out and are as near to constant values as is possible for our particular operation before we start a bump test. The point of bumping a process is to learn about the cause and effect relationship between the CO and PV.

With the process at steady state, we are starting with a clean slate. As the PV responds to the CO bumps, the dynamic cause and effect behavior is isolated and evident in the data. On a practical note, be sure the data capture routine is enabled before the initial bump is implemented so all relevant data is collected.

Two popular open loop (manual mode) methods are the step test and the doublet test.

For either method, the CO must be moved far enough and fast enough to force a response in the PV that dominates the measurement noise.

Also, our bump should move the PV both above and below the DLO during testing. With data from each side of the DLO, the model (step 3) will be able to average out the nonlinear effects as discussed above.

Step Test

To collect data that will "average out" to our design level of operation, we start the test at steady state with the PV on one side of (either above or below) the DLO. Then, as shown in the plot below, we step the CO so that the measured PV moves across to settle on the other side of the DLO.

We can either start high and step the CO down (as shown above), or start low and step the CO up. Both methods produce dynamic data of equal value for our design and tuning recipe.

Doublet Test

A doublet test, as shown below, is two CO pulses performed in rapid succession and in opposite direction. The second pulse is implemented as soon as the process has shown a clear response to the first pulse that dominates the noise in the PV. It is not necessary to wait for the process to respond to steady state for either pulse.

The doublet test offers attractive benefits, including that it starts from and quickly returns to the DLO, it produces data both above and below the design level to "average out" the nonlinear effects, and the PV always stays close to the DLO, thus minimizing off-spec production. Such data does require commercial PID loop tuning software for model fitting, however.

Step 3: Fit a FOPDT dynamic model to Process Data
In fitting a first order plus dead time (FOPDT) model, we approximate those essential features of the dynamic process behavior that are fundamental to control. We need not understand differential equations to appreciate the articles on on this site, but for completeness, the first order plus dead time (FOPDT) dynamic model has the form:

Where:
PV(t) = measured process variable as a function of time
CO(t - Өp) = controller output signal as a function of time and shifted by Өp
Өp = process dead time
t = time
When the FOPDT dynamic model is fit to process data, the results describe how PV will respond to a change in CO via the model parameters. In particular:

Process gain, Kp, describes the direction and how far PV will travel,
Time constant, Tp, states how fast PV moves after it begins its response,
Dead time, Өp, is the delay from when CO changes until when PV begins to respond.

An example study that compares dynamic process data from the heat exchanger with a FOPDT model prediction can be found here. Comparisons between data and model for the gravity drained tanks can be found here and here.

Step 4: Use the model parameters to complete the design and tuning
In step 4, the three FOPDT model parameters are used in correlations to compute controller tuning values. For example, the chart below lists internal model control (IMC) tuning correlations for the PI controller and dependent ideal PID controller, and dependent ideal PID with CO filter forms:

The closed loop time constant, Tc, in the IMC correlations is used to specify the desired speed or quickness of our controller in responding to a set point change or rejecting a disturbance. The closed loop time constant is computed:

aggressive performance: Tc is the larger of 0.1·Tp or 0.8·Өp
moderate performance: Tc is the larger of 1·Tp or 8·Өp
conservative performance: Tc is the larger of 10·Tp or 80·Өp

Use the Recipe - It is Best Practice
The FOPDT dynamic model of step 3 also provides us the information we need to decide other controller design issues, including:

Controller Action

Before implementing our controller, we must input the proper direction our controller should move to correct for growing errors. Some vendors use the term "reverse acting" and "direct acting." Others use terms like "up-up" and "up-down" (as CO goes up, then PV goes up or down). This specification is determined solely by the sign of the process gain, Kp.

Loop Sample Time, T

Process time constant, Tp, is the clock of a process. The size of Tp indicates the maximum desirable loop sample time. Best practice is to set loop sample time, T, at 10 times per time constant or faster (T ≤ 0.1Tp). Faster may provide modestly improved performance. Slower than five times per time constant leads to significantly degraded performance.

Dead Time Problems

As dead time grows greater than the process time constant (when Өp > Tp), controller performance can benefit from a model based dead time compensator such as the Smith predictor.

Model Based Control

If we choose to employ a Smith predictor, or perhaps a dynamic feed forward element, a multivariable decoupler, or any other model based controller, we need a dynamic model of the process to enter into the control computer. The FOPDT model from step 3 of the recipe is usually appropriate for this task.

// Labels: behavious, Control, DESIGN, dynamic, linear, non-linear, pid, proportional, tuning // 0 comments //

Instrumentation & Control

Integral (Reset) Windup, Jacketing Logic and the Velocity PI Form

Interacting Tuning Parameters

Proportional Control - The Simplest PID Controller

Controller process architecture

Nonlinear Process Behavior & DEEISGN OF CONTROL.

Followers

About Me

About This Blog

categories

Blog Archive