In this article we will review how to implement a ControlLogix PID Controller using the Studio 5000 IDE. Full disclosure, we are going to be taking a practical application approach, therefore, you won’t be needing a PhD in Control Theory in order to follow along!

Before we can dive right into the implementation and configurations necessary to implement a ControlLogix PID controller, I think it will be prudent to review some key concepts regarding closed loop feedback, specifically what PID feedback control is, and what constraints or inherent issues that you are likely to encounter when implementing any real-world PID process.

## So What Is PID?

As an introduction to PID control, we recommend you give this article a read to start with. PID control is by far the most common feedback control algorithm used in industry today. Different types of processes, having different dynamic (time-dependent) behaviors require different levels of proportional, integral and derivative controller action to achieve stability and robust response.

To explain PID in its entirety we are going to have to dive a little bit deeper into some of the mathematics involved. Just like any control algorithm with any complexity, the mathematical foundations will prove paramount to our overall understanding. So let’s get started!

The term PID stands for **P**roportional, **I**ntegral, **D**erivative and the complete mathematical algorithm can be broken down into these three constituent parts, namely, the P-term, the I-term and the D-term. There are two different ways we can implement a ControlLogix PID Controller in the Studio 5000 IDE.

The first is using what’s called the ** Dependent Form **equation and the second is the

**equation. The formulas below represent these two equations and the P-term, I-term, and D-term’s respectively.**

*Independent Form*The Rockwell variant of these classic PID equations is as follows:

Where, *u= Controller Output, e = error (PV-SP, or SP-PV), Kp = Proportional Gain, Ki = Integral Gain, Kd = Derivative Gain, Kc = Controller Gain and t = Time*.

Looks scary right! Sure it does, however, throughout this article we will try to break it down so the sight of it won’t make you cringe…recall that we did promise you weren’t going to need a PhD in Control Theory to understand PID!

On a side note, if you are interested in a more in-depth look into PID and closed loop feedback systems I do highly recommend these two texts, Feedback Control of Dynamic Systems and Control Systems Engineering. Both are excellent resources, however, one word of warning they do get pretty heavy into the theory behind closed loop feedback and control.

As the programmer implementing a ControlLogix PID Controller you have a choice between one of these two competing algorithms as can be seen in the image below. Later I will explain why I prefer the *Dependent Form * algorithm over the *Independent Form *algorithm.

## Understanding Proportional, Integral and Derivative Action

It’s important to note, that any PID controller can be implemented using 1, 2 or all 3 of these components, meaning, a PID controller can be implemented as a P-only controller, a P+I controller or a full P+I+D controller. Let’s take a closer look at these 3 individual controller actions by watching the video below and continuing in this article!

### Proportional Controller Action

To explain proportional control, let’s imagine we have a liquid-level control system for a vessel, where the position of a level sensing float directly sets the stem position of a control valve. As liquid level rises, the valve opens up proportionally.

While this is a crude example, this proportional control system would in fact help regulate the level of the liquid inside the process vessel. If an operator wanted to change the setpoint value of this level control system, he or she would have to adjust the coupling between the float and valve stem for more or less distance between the two.

#### Direct Acting vs. Reverse Acting Proportional Control

We can describe any controller as either *Direct Acting *or *Reverse Acting. *Lets define both:

**Direct Acting Controller:** A direct acting controller is one where as your PV (process variable – variable to be controlled) increases the corresponding output (controlled variable or CV in a ControlLogix PID controller) also increases.

**Reverse Acting Controller:** A reverse acting controller is one where as your PV (process variable – variable to be controlled) increases the corresponding output (controlled variable or CV in a ControlLogix PID controller) decreases.

Now that we have an understanding of what a direct and reverse acting controllers are, what do you think our crude level control system above is, Direct or Reverse acting? If you said *Direct Acting*, you are 100% correct! While this is one example of a direct acting process it should be noted that most industrial process are in fact *Reverse Acting.*

When implementing a ControlLogix PID Controller you will specify whether it is a *Direct Acting or a Reverse Acting Controller.*

#### Why P-Only Controllers Are Not Suitable For Most Industrial Process?

To explain this I am going to refer to the mathematics because I think it will become very clear! If we look at only the P-term in our full PID mathematical algorithm above it would look like this:

Can you see why this is an issue??? The problem with P-only control is that there is no way to completely eliminate the error in the system. What do I mean? What is going to happen to the output when the error = 0?

Exactly, it is going to be multiplied by the Pgain value Kp and the corresponding output, *u(t)*, will also be 0. Furthermore, if Kp could be set for an infinite gain value we would be doing no better than an ON/OFF (or Bang-Bang) type control getting a typical saw-tooth type trend.

Therefore, we must set the gain somewhere between zero and infinity in order for this algorithm to function any better than ON/OFF control. How much gain a controller needs depends on the process and all the other instruments in the control loop.

For example, if the gain is set too high, there will be oscillations as the PV converges on a new setpoint value.

If the gain is set too low, the process response will be stable under steady-state conditions, but “sluggish” to changes in setpoint.

This overshoot and undershoot are generally undesirable. The controller should be able to respond in such a way that the process variable is made equal to the setpoint as quickly as the process dynamics will allow with no substantial overshoot or undershoot. But of course for reasons just discussed, this is nearly impossible with just proportional control alone.

### Integral (Reset) Controller Action

In a ControlLogix PID Controller the integral component is being executed by a digital integration algorithm. What are we doing when we integrate something in mathematics?

The integration symbol tells us the controller will accumulate (“sum”) multiple products of error (*e*) over tiny slices of time (*dt*). Therefore, we can simplify our *Dependent Form* P+I controller equation as,

The ControlLogix PID Controller literally multiplies error by time (for very short segments of time, *dt*) and continuously adds up all those products to contribute to the output signal which then drives the control valve (or other final control element).

The integral time constant (*Ti*) is a value set by the technologist or field engineer configuring the controller, proportioning this cumulative action to make it more or less aggressive over time.

### Summarizing P+I Controller Action

A P+I controller is the most commonly implemented controller in industrial processes today.

- Proportional action is defined by the error telling the output
to move.*how far* - Integral action is defined by the error telling the output
to move.*how fast*

Over time, a larger and larger quantity accumulates in the integral mechanism (or register) of the controller because an error persists over time. This accumulated value adds to the controller’s output, driving the final control element (i.e., valve) further open or closed in order to completely eliminate the error.

Integral action ceaselessly works to eliminate any offset between PV (process variable) and SP (setpoint). You can think of integral action as being how “impatient” the controller is, with integral action constantly ramping the output as far as it needs to go in order to eliminate error.

Just as too much proportional gain will cause a process control system to oscillate, too much integral action (i.e., an integral time constant that is too short) will also cause oscillation.

If the integration happens at too fast a rate, the controller’s output will “saturate” either high or low before the process variable can make it back to the setpoint.

## Derivative (Rate) Controller Action

The final element of P+I+D control is the “D” term, which stands for derivative. Simply put, derivative is the expression of a variable’s rate-of-change with respect to another variable. Finding the derivative of a function (differentiation) is the inverse operation of integration (anti-derivative).

With integration, we calculate the accumulated value of some variable’s product with time and it is fundamentally a multiplicative operation. With derivative action, we calculate the ratio of a variable’s change per unit of time, therefore, it always involves division.

A controller with derivative (or rate) action looks at how fast the process variable changes per unit of time, and takes action proportional to that rate of change. Contrast that to integral (reset) action, which represents the “impatience” of the controller, derivative (rate) action represents the “cautious” side of the controller.

If the process variable (PV) starts to change at a high rate of speed, the job of derivative action is to move the final control element (FCE) in such a direction as to counteract the rapid change, and thereby moderate the speed at which the process variable changes.

In simple terms, derivative action works to limit how fast the error can change. What this will do is make the controller “cautious” with regard to rapid changes in the process variable.

If the process variable is headed toward the setpoint value at a rapid rate, the derivative term of the equation will diminish the output signal (“put the brakes on”), thus tempering the controller’s response and slowing the process variable’s approach toward the setpoint.

### A Word Of Caution When Using Derivative Action

Derivative action can be intimidating, as it should be used with caution. Since it acts on rates of change, derivative action will “go crazy” if it sees substantial noise in the PV signal. Even small amounts of noise possess extremely large rates of change owing to the relatively high frequency of noise compared to the timescale of physical process changes.

Derivative action is useful for controlling processes dominated by large lag times. The presence of derivative controller action in a PID controller generally means the P and I terms may be adjusted more aggressively than before, since D will act to limit overshoot.

A small amount of D in a PID controller lets us “get away” with using a bit more P and I action than we ordinarily could, resulting in a faster approach to the setpoint with minimal overshoot.

## Dead-time and Lag-time Explained

**Dead-time** is the time elapsed from the moment the process undergoes a change in its PV (process variable) to the moment the controller takes action. There can be many sources of dead-time that accumulate in a control loop, such as the dynamic response of the instrument, propagation delay in the transmission of signals, and delivery time of the manipulated variable to the process.

Dead-time is an undesirable element of the process, and unfortunately, unavoidable. Its effects, however, can be mitigated to a manageable value.

It should be noted that any loop that has a relatively large dead-time is at risk of losing control, and therefore requires a redesign or troubleshooting of the loop.

An ideal process has a dead-time of 0 seconds, hence a process engineer always endeavors to minimize dead-time in a real process. This time lag is usually modeled by a stepped time delay.

**Lag-time** is the time elapsed from the moment the controller takes action to the moment the process undergoes a change in its PV (process variable). This time lag, in its’ most common form, looks like a first order response (think of a capacitor charging and discharging) of the CV.

This time delay represents a processes inertial time response to a change.

We can simulate the effects of dead-time and lag-time in a ControlLogix PID Controller application by making use of the DEDT and LDLG instructions as follows. This allows us to very tightly model an actual process.

### Why I Prefer The Dependent Form PID Algorithm Over the Independent Form

As promised, I did say that I preferred to implement most ControlLogix PID controllers using the *Dependent Form *controller algorithm…here’s why! Let’s quickly review the complete PID controller forms now that we have an understanding of what each form is and the function of each constituent part, namely, the P+I+D terms.

Not so scary now right!!! When we look at these two forms a little more closely, particularly the K-terms we can see that the difference is that in the *Independent Form *they are “independent” gain values, namely, *Kp, Ki and Kd,* whereas in the *Dependent Form *algorithm there is only one “dependent” *Kc* value.

Because *Kc *term factors, as shown in the Dependent Form, it effectively becomes a scalar quantity, or multiplier of all three controller gains. This means that you only need to adjust one gain and you effectively tweak all three gains.

It should be noted that, *Kc = Pgain, Ti = Igain, and Td = Dgain *in a ControlLogix PID Controller implementation.

## Automatic Tuning Of A ControlLogix PID Controller

To start, I would like to look at the Auto-tuning feature available in a ControlLogix PID Controller, namely, the PID_Enhanced instruction. As you can see there is a parameter in the PIDE instruction that will accept an Auto-tuning tag in the controller.

Navigating to the “Autotune” tab of the PIDE instruction you can see that by “acquiring” the PIDE_Tune tag we can perform an “auto-tuning” procedure on this controller. The reason you have to explicitly acquire this tag is so that you can create just one PIDE_Tuning tag to service more than one ControlLogix PID Controller and then by pressing “Release Tag” it will be available to other controllers in your project.

What the auto-tuning procedure effectively does is perform a “bump-test” on the final control element (FCE) which could be a 4..20 mA proportional valve. You define the *Process Type, PV Change Limit and CV Step Size,* that your particular process can tolerate during an auto-tune test.

### A Word Of Warning Regarding Automatic Tuning

Let’s imagine you have a process that has been running in production for some time. Then one day out of the blue the process begins to run away and you have no idea why.

The practice of using the controller to automatically tune yourself out of a serious control problem like this can adverse affects if the root problem goes undiagnosed for any period of time. While a false sense of security ensues after the band-aid is applied and production is restored, the problem will almost certainly rear its ugly head again!

In fact, by continuing down this circular path of continual automatic tuning, the root cause could be lost entirely over time and failure of process components will surely follow (such as pumps, valves, tanks, pipes, instruments etc.) – or finally the controller can no longer be auto-tuned to restore control.

This is why root-cause analysis is absolutely imperative in these situations!

## Troubleshooting A ControlLogix PID Feedback Loop

It is highly recommended that you make use of the Studio 5000 trending functions when tuning or troubleshooting any kind of ControlLogix PID feedback loop. See our Studio 5000 Essentials video series to get you get going with some of these tools.

To setup a trend to monitor your feedback loop assign the following ControlLogix PID controller tags to your trend pens.

- SP (setpoint)
- PV (process variable)
- CV (control variable)

Once these are configured, you will be able to monitor the dynamic response curves of your physical process. Let’s take a look at some example response curves and through graphical analysis determine the tuning required to improve the feedback loop.

Based on the examples below, let’s answer the following questions:

- Whether this is an open-loop or closed-loop response?
- Whether the controller is (or needs to be)
*direct-acting*or*reverse-acting*? - Identify any problems with the controller PID tuning?
- Qualitatively identify the kind of PID tuning we will need for robust control.

#### PID Tuning Example #1

This is a closed-loop test, based on the fact the output signal responds dynamically to the changing process variable, as well as to the step-change in setpoint.

This is a reverse-acting controller: the output steps up when the setpoint steps up (implying the output would step down if the process variable stepped up).

There does not appear to be any field instrumentation problems revealed in this trend. A manual-mode (open-loop) test would be more informative in that regard, but it appears as though the process is very quick to respond with no discernible dead-time or other lags.

The controller tuning is clearly inappropriate for this process. Note the large offset between PV and SP (i.e. how the process variable never settles at the setpoint value, even though it’s clearly a fast-responding process).

This tells us the controller is configured only for proportional action, and this process needs integral! We can also tell this from the 180 degree phase shift between PV and output during the oscillations: this is the classic response of a reverse-acting proportional-only controller with excessive gain.

Aggressive integral action with a minimum of proportional gain should work very well in this process, which is probably a liquid flow-control process.

#### PID Tuning Example #2

This is a closed-loop test, based on the fact the output signal responds dynamically to the changing process variable, as well as to the step-change in setpoint.

This is a reverse-acting controller: the output steps up when the setpoint steps up (implying the output would step down if the process variable stepped up).

There does not appear to be any field instrumentation problems revealed in this trend. A manual-mode (open-loop) test would be more informative in that regard, but it appears as though the process is very quick to respond with no discernible dead time or other lags.

The controller tuning is too heavy on proportional action. We can tell this from the phase shift between PV and output during the oscillations, which is nearly 180 degree. Excessive integral action would shift the phase of the output wave further to the right (i.e. so that each peak of the output waveform coincided with the zero-crossing of the PV waveform, or very nearly).

The fact that the inverse peaks of the PV and output waves are very nearly aligned tells us that excessive gain (proportional action) is the culprit here. Another clue is the magnification of noise we see in the output trend compared to the PV trend – only proportional action or derivative action can cause this, and since we see no sign of excessive derivative action (e.g. output wave leading the PV wave), we can safely say the problem is too much gain.

The process response time (dead time, lag time) seems to be very short, which is a good thing for process control. We can tell, however, that this is an integrating process by the way it was able to achieve a new SP value with the old output value. This means it will exhibit some overshoot with SP changes if there is any integral action.

We may have to do most of the control through proportional action (albeit much less gain than we are using now!), with just enough integral action to handle load changes.

#### PID Tuning Example #3

This is a closed-loop test, based on the fact the output signal responds dynamically to the changing process variable, as well as to the step-change in setpoint.

This is a reverse-acting controller: the output steps up when the setpoint steps up (implying the output would step down if the process variable stepped up).

This process does exhibit some dead time as well as lag time, which explains the setpoint overshoot. A field check of the control element (valve) might be good to do, so see that it is not sticking and causing dead time.

The controller tuning actually looks pretty good here. The only problem is the slight overshoot of setpoint, which may or may not be significant depending on the specific process and the needs of operations personnel.

If this overshoot is deemed excessive, we might wish to turn down the proportional action (gain), based on the fact the PV and output waves seem to hit their respective peaks at nearly the same time (characteristic of proportional-dominant action).

Given the existence of dead-time and lag-time together, we must be careful not to use too much proportional action lest the loop will oscillate. Derivative action could be very useful in taming the effects of lag time.

## Final Words…

As you can see graphical analysis of the dynamic response of a feedback loop can reveal a tremendous amount of useful information and should be used as a troubleshooting tool by any field engineer or technologist.

I hope you enjoyed this article, and I do encourage you to become a member of our growing community of professional engineers, technicians and technologists, Register Here!

Also, check out our YouTube Channel to see some great videos…and don’t forget to like and subscribe to our channel! Lastly, if you run into any problems in your day-to-day engineering activities please be sure to check out our Live and Interactive PLC Forum!