# PID math demystified, part 2

## You’ve see the equations, but have you thought about how those elements work together? Part 2: Adding integral and derivative to the mix.

05/13/2013

Last week we started with proportional. (Read Part 1) Now let’s look at the next part of the equation, the integral component:

The most striking (and scariest) part of this equation is the big integral sign in the middle. If you’ve had high school calculus, you think to yourself, “I’ve got this. Integrals don’t scare me. I just need to find the area under the curve from time zero to time t of the error function.”

But, this is the real world. What is time zero? How do I integrate an error function? The good news is that the real definition is much simpler than calculus. What the PID function does is take a portion of the error and adds it to a running total. This running total, sometimes called reset, is added to the output. Since reset increases or decreases a little at a time, it adjusts the output of the valve incrementally each scan.

For a PI controller, the two factors that we have covered so far are Kp and Ki, but if you look at the faceplate for most industrial systems, there is only one K (gain) that has no units, and a τi (integral time constant) designated as seconds or minutes per repeat. So, a little translation is required. Most industrial controllers don’t use the independent form of the equation shown above. Instead, they use the dependent form of the equation:

The K is typically the same as the proportional gain, Kp.  The factor τi determines how much of the error is going to be applied to the accumulated reset on each scan. So in the big mathy equation, Ki can essentially be replaced by the faceplate parameters:  K⁄τi.

What’s important to understand from this is that the gain that affects the proportional action of a controller also affects the integral action. But, the integral time constant τi only affects the integral action.

In pseudo code this would look like:

Error := Setpoint - ProcessValue;

Reset := Reset + K/tau_i * Error;

Output := K * Error + Reset;

The unit’s minutes per repeat for the integral time constant τi  comes from the fact that if the error stays constant, that is how long would it take for the integral accumulator to repeat the proportional change in output.

Note: Another way of specifying the integral tuning parameter is in seconds, and then it is the reciprocal of seconds per repeat. If the integral time constant is in seconds, the bigger the number, then the slower the response. If the integral is in seconds per repeat, the opposite is true.

Derivative

Now let’s look at derivative:

Again, this is another mathy looking equation with a simple explanation. The mathy definition first, the output will be changed by the derivative (or rate of change) of the error function. What this means is that the output will be affected by the change in error from one scan to another. Adding this to our pseudocode gives us:

Error := Setpoint - ProcessValue;

Reset := Reset + K/tau_i * Error;

Output := K * Error + Reset + ((PreError – Error) * K/tau_d));

PreError := Error;  //Save the error for the next scan

What is intended is for the output to change as soon as the process variable begins to move either toward or away from the setpoint. What results can be a very quick response to a change in error from one scan to another.

The intention of derivative action is to respond to changes as they begin to occur. For example, if a temperature is starting to rise, the valve will begin to open as soon as it sees the change instead of waiting for it to cross a setpoint. This can result in a very rapid response to a small change. This rapid response can become unstable if there is noise in the process variable or on a setpoint change. So, the derivative action is often filtered separately and is sometimes calculated on PV only to ignore setpoint changes.

Summary

So now we have reviewed the three components of the PID algorithm. One way they have been described is in terms of the flow of time. P depends on the present error, I on the accumulation of past errors, and D on the prediction of future errors based on current rate of change.

This post was written by Scott Hayes. Scott is a senior engineer at MAVERICK Technologies, a leading system integrator providing industrial automation, operational support, and control systems engineering services in the manufacturing and process industries. MAVERICK delivers expertise and consulting in a wide variety of areas including industrial automation controls, distributed control systems, manufacturing execution systems, operational strategy, and business process optimization. The company provides a full range of automation and controls services – ranging from PID controller tuning and HMI programming to serving as a main automation contractor. Additionally MAVERICK offers industrial and technical staffing services, placing on-site automation, instrumentation and controls engineers.

Anonymous , 05/17/13 08:16 AM:

In your reset and derivative pseudo code, you left out the sampling time. When these calculations are converted from continuous time to discrete (sampled) form, the sampling time appears explicitly when you have an integration or derivative step. Also, your derivative term has to use not the previous error, but the difference between the previous error and the current error. I think you need to fix this posting. And the error could be SP-PV, or PV-SP depending on the direction of action of the controller.
Scott , United States, 05/20/13 11:41 AM:

Anonymous, you’re right! The pseudo code for the derivative component should have been “Output := K * Error + Reset + ((PreError – Error) * K/tau_d));” I regret the typo. Leaving out the sampling time and the controller direction were, however, a little more intentional. I also didn’t cover some other things like scaling the PV and Output to engineering units, anti-reset windup, etc. I was trying to break the equation down into simple terms and using the code as illustration. But, again you are right and I should have at least mentioned the assumption that I made, that the code would execute only once each second. Thanks for input.
Chandan , MD, United States, 05/29/13 03:28 PM:

K*tau_d should be instead of K/tau_d ???
M , United States, 06/05/13 05:08 PM:

You have demistified Jack, because the maths of a controller are irrelevant if you cannot connect it to a plant model, IOW, you have to come up with the COMPLETE TRANSFER FUNCTION, which is not easy to find, and from there you MAY come up with the right settings.
NEIL , Non-US/Not Applicable, United Kingdom, 06/06/13 09:36 AM:

Very helpful content and will use to explain to some apprentices. Thanks
Anonymous , 06/07/13 07:35 AM:

Anonymous back again - I still don't think you have the derivative right. I believe it should be Output := K * Error + Reset + (K*Tau_D*(Error – PreError)/DeltaT). The Tau_D multiplies, rather than divides. And the de/dt derivative term converts in the simplest difference equation form to just (Error-PreError)/(DeltaT) where DeltaT is the sampling time for the calculation. Chandan's comment was correct on handling Tau_D. And a final point - you also left out the Bias term, which is the Output when the Error and integrated error terms are 0. It is usually computed when the PID is initialized on transition from Man to Auto.
M , United States, 06/10/13 06:31 PM:

These equations are only good if you know the transfer function of the process itself, which is not easy to establish. Then, it can be synthesized and a "best response", if it exists, found.