Talk:Proportional–integral–derivative controller/Archive 1

Archive 1

Proportional control

Proportional - To handle the present, the error is multiplied by a (negative) constant P (for "proportional"), and added to (subtracting error from) the controlled quantity. P is only valid in the band over which a controller's output is proportional to the error of the system. For example, for a heater, a controller with a proportional band of 10 °C and a setpoint of 20 °C would have an output of 100% at 10 °C, 50% at 15 °C and 10% at 19 °C. Note that when the error is zero, a proportional controller's output is zero

This means that when the process variable maches the set point there is no out put from the controller i want to know that if gives 0% out put at when the process variable achieve the set pont position then it will make a rapid change after some time and again begain to decrease the temprature acording to the process lag

And for pressure loop is it same the proportional band is 100 psi and the set point is 200psi what u think is it possible that when 200 psi achieved it closes the valve 100% then wht will be the correct table for it

   INPUT(PSI)              OUTPUT(%)
      200                     0%
      150                    50%
      100                   100%

plese clear my concept about this confusion.And its only about proportional controler. I am at initial state learning process your guidence will be very knowledgeful for me.you can also mail me at my email address

Thanks REHAN RIAZ rehanriaz.tech@gmail.com

This page is borked. I tried cleaning it up down to 'Theory', standardizing, etc etc.

Cascade

I couldn't come up with a good example of cascading PID. I was thinking of a waste wood fed steam boiler, with one PID loop internal to the feed auger VFD + steam pressure and a second PID loop of an external loop controller with a sensor on the stack temperature, but then couldn't figure out how you would feed the output of the second controller into the first if it was already a loop with its own input. What is cascading PID?

Input > Controller > Output=Input > Controller > Output??? Why would you want to do that? Someone clarify?

GarrettSocling 21:07, 10 May 2006 (UTC)

(Answer) In a cascading structure, the controller output of the outer loop is used as the set-point of the inner loop. With y1=plant output used for inner loop, y2=plant output used for outer loop, u1=plant input, r1=set-point of inner loop and r2=set-point of outer loop, the outer controller uses r2-y2 as input (it tries to bring this quantity to 0) and generates u2; the inner controller takes it as set-point r1=u2, using u2-y1 as input (it tries to bring this quantity to 0) and generates u1 which is fed to the plant (for the sake of simplicity, we assume our controllers act on the error between the set-point and the measured plant output). Cascading is used typically when your inner loop is faster than the outer loop: you improve the performance of the inner part by adding a controller to make it more linear, less sensitive to disturbances, etc.; then you design the outer loop by considering the inner loop to be a simple system. For instance, in a car, the inner loop could control the wheel direction with an electrical motor, and the outer loop could control the trajectory of the car on the road. Basically, cascading is a trick to have more parameters to tune and to split the design when a simple PID isn't enough.

Mausy5043 09:17, 18 October 2006 (UTC): The example I like to use is that of a large tank filled with liquid and a jacket used to heat it up. The temperarature of the tank's content is controlled (master loop) by regulating the temperature in the jacket (slave loop).

The other key application of cascade is to allow an intermediate common path to the secondary loop from several influences besides just the influence captured by the primary loop. This allows several loops to target a common secondary setpoint. An example is steam boiler drum level control being influenced by feedwater flow as well as outlet steam pressure.--Billymac00 16:54, 28 August 2006 (UTC)

Cascade PID control is used widely in the water industry. A good example is controlling a common inlet channel level that feeds multiple filter vessels. the output of a P or PI loop on the inlet channel level is the setpoint to each filter vessel outlet flow PID controller. As a filter is taken offline (or gets blocked) the resulting change in common filter inlet channel level creates a change in setpoint to the remaining on-line filters thereby creating a self compensating system. --Darran12 11:00, 13 August 2007 (UTC)

Theory

Mausy5043 09:39, 18 October 2006 (UTC): I don't understand the first two paragraphs of this chapter:

  The PID loop adds positive corrections, removing error from the process's controllable variable (its input). 

  Differing terms are used in the process control industry: The "process variable" is also called the "process's input" 
  or "controller's output." The process's output is also called the "measurement" or "controller's input."

What we're trying to say here is that the PID loop has an input (e.g. from a measurement device) and an output (e.g. to a controlling device such as a valve or motor). Could someone please simplify these two paragraphs?

Undefined Parameters

Oh my. It's great to have a Loop Tuning section, but it remains kind of useless, because none of the parameters are defined -- T_r, T_d, even P. Somewhere in the article, those parameters should appear in an equation describing the PID response. Something like action = P * error + T_d * d(error)/dt + ... I don't know how it's conventionally stated, so I won't guess. But whoever put in the otherwise good description of the Ziegler-Nichols method would know. Spiel496 18:43, 12 June 2006 (UTC)

Representative HMI Interface

Here is a sample PID interface screen:

PID Interface

The interface should summarize key parameters such as gains, output clamps, direction of action (direct/reverse), setpoint and input and output values.--Billymac00 18:34, 6 August 2006 (UTC)

Confusion of names

The names given to different quantities aren't used in a consistent way. For instance, it is said that the measurement is also called process variable, but later there are input process variables, and one can manipulate some other process variable. And the PID loop is sometimes used for the controller itself; actually, the loop includes the process. It's likely that this confusion also exists in the literature (and perhaps even among a few engineers), but the result is that the article is difficult to understand for someone who doesn't know control. I think we should agree on some simple and explicit terms (e.g. measurement for the process output, controlled value for its input, and desired value for the set-point), use them consistently, and have a separate section where we mention all the other terms the reader may find in books and papers. Engelec 10:21, 18 October 2006 (UTC)

This entire long article needs to be edited by one person to ensure consistency in names, avoid repetition, etc. Encyclops 15:34, 18 October 2006 (UTC)

PID Loop Example diagram

Thanks, whoever recently added the PID loop example diagram, but I think it may be incorrect. It appears to be some variation on a parallel PID control algorithm; however, every control text I have, plus a recent traning course I went on show all three terms (P,I,D) acting on the error for a parallel PID algorithm. In the given diagram, the P and I terms act on the error, and the D term acts acts on the process variable( / measurement / plant output). While I appreciate that in some circumstances, there may be performance advantages to doing it this way, it doesn't appear to be the norm. Additionally, the first paragraph describes a PID controller acting on '...the rate of change of the error signal...' and not '...the rate of change of the plant output...'. The diagram and text should tell the same story. Many industrial PID controllers don't use the parallel algorithm anyway, they use the non-interacting or interacting algorithm. Dave t uk 16:08, 24 October 2006 (UTC)

This diagram is not uncommon, but I agree it's unfortunate that it doesn't match the text; there should be at least a caption. Pure parallel algorithms give large control signals when the set-point isn't smooth enough; and filtering the set-point is equivalent to not having a pure parallel algorithm. BTW, which difference do you see between parallel and non-interacting algorithms? There are certainly multiple definitions of both, but with the ones given in the article, one can assume they are the same. Engelec 22:16, 24 October 2006 (UTC)

For Standard/Non-interacting, I have Kc(e + (1/Ti)*integral(e)dt + Td(de/dt))

For Interacting, I have Kc(e + (1/Ti)*integral(e)dt) * (1 + Td*de/dt)

For Parallel, I have Kc*e + (1/Ti)*integral(e)dt + Td(de/dt)

The difference between the parallel and non-interacting algorithm is that with a non-interacting, the Kc term acts on all 3 terms, with parallel, it is independent. It means that with a parallel algorithm, lowering the Kc alters the output phase angle and could destabilise the system. Changing Kc on a non-interacting algorithm only alters the magnitude, hence it is prefered over parallel in many cases.Dave t uk 15:43, 25 October 2006 (UTC)

In that case, for the parallel implementation, Ti and Td include gains and don't correspond to times anymore (with dimensional analysis, comparison with the proportional term shows that there is a problem). I'd rather write Kp e + Ki integral e dt + Kd de/dt (or Kc instead of Kp). But this doesn't correspond to the article where non-interacting = parallel. Engelec 16:34, 25 October 2006 (UTC)

I just uploaded a new diagram I made and replaced the old one. Is this better? -- SilverStar 06:56, 25 October 2006 (UTC)

Yes, it's very nice and clear. I wouldn't use t' for the integration variable, though, because ' has already different meanings in control (τ would be fine if it's possible). And integration should begin at 0 instead of -inf (or some arbitrary time instant, but it would be needlessly confusing). Engelec 10:21, 25 October 2006 (UTC)

Thanks. I've uploaded a corrected version. The original integration formula was from the article, so it may need to be corrected as well. SilverStar_talk 10:37, 25 October 2006 (UTC)

That is an improvement, but the three blocks labeled "P", "I" and "D" have no meaning. Normally, a block has some effect on the signal, as with the block labeled "Process". I suggest putting the formulas inside blocks, along with P, I, D labels. Spiel496 06:29, 26 October 2006 (UTC)

Ok, new image on page. --SilverStar_talk 09:27, 26 October 2006 (UTC)

"following with dimensional analysis"

Is the reasoning that Kd = Dt and follows from dimensional analysis valid (I'm not denying the conclusion, just the stated reasoning)? Dimensional analysis can only show that a certain relationship is possible, it can't actually prove equality. At the very least, dimensional analysis would allow for an arbitrary unitless constant term to be multiplied on either side of the equation.

--SilverStar 07:26, 25 October 2006 (UTC)

Need to restart (almost) from zero

The article has accumulated so many errors and inaccuracies it becomes impossible to manage (just to enumerate a few: sign confusion (PID coefficients are usually positive), interacting mentionned before being defined, wrong definition for the "interacting form" (the parts connected in series are not the same as those of the parallel version), confusion between unstability and oscillations (a system can be unstable and not oscillate, and a nonlinear system can have stable oscillations), meaningless statements (e.g. filter applied to a complex frequency-domain system), etc.). I'd suggest to have a small, clean article on what PID controllers are in their academic version (parallel, controller input = error = setpoint - process output, controller output = process input) with a minimum amount of redundancy with control theory; maybe a section about why it isn't implemented like that; and a separate article on what's found in the industry, jargon, etc. (i.e. everything a beginner shouldn't read before understanding the basics). Engelec 10:52, 25 October 2006 (UTC)

I agree on your assessment, though I lean towards pruning and repair. There's too much "another way to look at it..." stuff. And, there should be a law against parentheses in article intros. I'll do what I can to fix stuff, but if someone can pull off a major rewrite, more power to him. The part where I feel most confident contributing is the Loop Tuning, which is also a mess, referring to variables mentioned nowhere else. Spiel496 16:35, 26 October 2006 (UTC)

I'd missed this one: the discrete-time version is wrong. Of course, you can implement a PID with three independent coeffients in discrete time (that's how they're done in digital devices like microcontrollers or FPGA). Equation $\mathrm {Output} _{n+1}=\mathrm {Output} _{n}+K_{p}\,e_{n}+K_{d}\,(e_{n}-e_{n-1})$ becomes, when using q as the forward-shift operator (see z transform), u(k) for controller output and e(k) for error: u(k) (q-1) = Kp e(k) + Kd (q-1)/q e(k) or u(k)/e(k) = Kp / (q-1) + Kd / q; in other words, a kind of PI controller where Kp is the integral gain and Kd the proportional gain. To get the correct equation, start with u(k)/e(k) = Kp + Ki q/(q-1) + Kd (q-1)/q; then u(k) q (q-1) = (Kp q (q-1) + Ki q^2 + Kd (q-1)^2) e(k), and finally, with the article notations,

$\mathrm {Output} _{n}=\mathrm {Output} _{n-1}+(K_{p}+K_{i}+K_{d})\,e_{n}-(K_{p}+2K_{d})\,e_{n-1}+K_{d}\,e_{n-2}$

Engelec 00:20, 27 October 2006 (UTC)

Changed. Engelec 10:20, 7 February 2007 (UTC)

Is it worth the trouble to fix changes by 129.241.206.68 ("by adding a integration of the average error to the process input" in the I term description)? The previous version wasn't better... Eventually, I'll probably remove all that's wrong, reducing significantly the size of the article. Engelec 15:14, 2 February 2007 (UTC)

I like what Engelec has been doing. Along the same lines as removing the "proportional band" stuff, I suggest we choose just one form for the math. Specifically, do we want

$\mathrm {Output(t)} =K_{p}{e(t)}+K_{i}\int _{0}^{t}{e(\tau )}\,{d\tau }+K_{d}{\frac {de}{dt}}$

---or---

$\mathrm {Output(t)} =K_{p}\left(\,{e(t)}+K_{ip}\int _{0}^{t}{e(\tau )}\,{d\tau }+K_{dp}{\frac {de}{dt}}\right)$

In practice, I prefer the second form, but with $K_{ip}$ and $K_{dp}$ replaced with ${\frac {1}{T_{i}}}$ and $T_{d}$, respectively. However, for an encyclopedia article, the first form is probably a less confusing way to introduce the subject. And it matches the figure. Spiel496 04:42, 10 February 2007 (UTC)

Okay, so Crinoid has made a lot of changes, mostly good. Unfortunately, we now have three forms of the main equation in rapid succession, none of which is strictly consistent with the top figure or the section on tuning: Kp+Ti+Td vs. Kp(1+Ti+Td) vs K+Ki+Kd. The display of these different forms is not interesting. Let's just pick one form. I vote for Kp(1+Ti+Td). Are there any objections to this form? It would mean fixing the figure. Spiel496 03:34, 16 February 2007 (UTC)

Feedback controller

Feedback controller redirects to this page, obviously PID is not the only feedback compensator ZyMOS

I've changed it to control theory. Engelec 01:13, 7 February 2007 (UTC)

"Traditional" or not

I consider myself an expert in this subject :) So I did a lot of changes to the article. Here are some thoughts.

A lot of confusion in this article arises from the PID's long history. The first implementations were interacting and did not permit the setting of individual gains.

The purely parallel model with separate tunable gains for each part is mostly a mathematical model and can't really be used except in simulators and control engineering education. (Real implementations are digital anyway and most systems include premade PID blocks.)

That's why I think this article should mostly describe the "traditional" model and mathematics that include terms like integral TIME. One interesting fact about using integral TIME is that the integrator element's contribution cannot be made zero with a finite value of Ti. This is a feature of most industrial PID's.

Another interesting fact is that not all non-interacting controllers can be realized in the interacting form. The limiting factor is that Ti must be greater than or equal to 4*Td. If that is satisfied, the parameters can be transformed between the two forms.

This has implications when one tunes a PID with some method and has to input it to a controller that uses the interacting form. The parameters are not even close to being the same value when moving to the other implementation.

Some comments about the interacting/non-interacting (I'll just use I and NI :) forms are also confused. The difference is that the I form is

G = K * ( 1 + Integrator / Ti ) * ( 1+ Derivator * Td )

This is in effect a PD controller(with P gain 1) in series with a (parallel) PI controller.

The parameters of I and NI forms are not interchangeable!

Oh, the point? :-) One MUST know what is the implementation one is working on. The different forms should be properly introduced if they are mentioned at all.

Perhaps another page would be a solution, like... "implementations and extensions to the PID algorithm"? ;)

Crinoid 08:02, 16 February 2007 (UTC)

(Tip of the day: use the Show Preview button.) I don't think a separate page on "implementations and extensions" would really stand on its own. That's what sections are for. I'd like to see one form used for most of the article. Then in an implementation section we could have the interacting form and digital implementations. Spiel496 14:44, 16 February 2007 (UTC)

Okay Crinoid, if you're an expert, we welcome your ideas on how to fix the article. But as I said earlier, your formulas are inconsistent with other parts of the article. I liked where you were going, but unless you have a plan to finish what you started, I think it's time to revert your changes so the article is at least self-consistent. Spiel496 06:56, 24 February 2007 (UTC)

ZN tuning

Should the tuning parts be omitted from this article as well? I think it should be shortened considerably. Ziegler-Nichols tuning rules are given way too much emphasis. The ZN rules are anyway designed for rejection of load disturbances and if used for tuning for step responses, they give too much overshoot (too much sensitivity). Better methods exist.

If PID control is sufficient for the system, even a poorly tuned PID (a stable loop of course) gives results. I remember hearing an estimate that 70% of PID controllers in the industry operate on default settings, and probably the rest just have the "auto-tune" function run once :-)

Crinoid 08:17, 16 February 2007 (UTC)

I think a tuning section is appropriate -- a less rambling one, anyway. With regards to the Ziegler-Nichols method, I don't know what you mean by "way too much emphasis". It's described using three sentences and a 4x4 table. Spiel496 14:52, 16 February 2007 (UTC)

Proportional band and I control

Boring Friday at work, it seems ;)

About the proportional band, to clarify. It's known that a P controller gives zero output if the error is zero. Thus, no process variable value that requires non-zero input can be reached.

But, if a P controller is used with a bias value (output = K*e + bias), there is one process variable value that can be reached exactly, and that is of course the output corresponding to the bias input.

This is a very powerful control method - first determine the input value that gives the desired output. Then on top of this, implement a P controller with the proportional band set to some reasonable value around the desired output. (Adjusting the bias value is also called reset action.)

The clever thing about PI control is that the integrator part in effect keeps re-setting the bias value for the P controller! So all (reachable) output values can be exactly reached.

Crinoid 08:31, 16 February 2007 (UTC)

Parameter nomenclature

"A controller setting of 100% proportional band means that a 100% change of the error signal (setpoint – process variable) will result in 100% change of the output" is another way to say that the proportional term is proportional. The rate "measured in proportional band/minute" was certainly domain-specific. Unless someone older than me can provide better explanations, I'd suggest to remove this section. Engelec 22:43, 21 February 2007 (UTC)

I second the motion. I can't make any sense out of that prose. Spiel496 04:42, 22 February 2007 (UTC)

Ok, done. Engelec 15:14, 26 February 2007 (UTC)

Example System

I was thinking in the "Theory" section (would "PID formula" be better name?) the P, I, and D terms could be better described in terms of a tangible example. A good example would be an automobile cruise control, because many people are familiar with both human- and PID-control of car speed. The P term could be described, along with the limitations of P-only controller. Then the motivation for the I term is to remove steady-state error. Then the D term kind of mimics what a person does -- back off on the accelerator if you are rapidly approaching the target speed. Spiel496 06:46, 24 February 2007 (UTC)

Don't be mad...

So I have had the last three night shifts to work on the intro to this article. While I am not an expert I am a process operator so I have some experience. I attempted to explain the basic theory and define PID so that someone new to the concept could at least understand it. I ran it by several of my coworkers and they felt my edit was much easier to comprehend than what existed prior. That being said, no hard feelings if it needs to be reverted or so forth. I am going to leave the math and loop tuning to the experts. MDSNYDER 13:51, 5 May 2007 (UTC)

Major overhaul

Expert? I've got a PhD Chemical Engineering and 4 years in controller design and implementation, but please judge by the work, not the credentials. I've made minor edits to the intro, major edits to "Controller Basics" and merged the next two (redundant) sections.

With respect to nomenclature and alternative PID forms. Fact is, there is so much variety in common use. It sucks, but there it is. Myself and another guy in the office use different nomenclature. That said, I don't think it is helpful to have all of the alternatives inline in the text because it's just too confusing. I've created a new section "Alternative nomenclature and PID structures" that will contain all of that, keeping the main article consistent and clean. Only got half way so far: we've all got to eat :)

Please post feedback. Even positive feedback is appreciated ;). I'd like to know if I'm on the right track with this. Dhatfield 11:43, 27 July 2007 (UTC)

I like what you've done. I would just like to reiterate my opinion that we should choose between

$u(t)=K_{p}{e(t)}+K_{i}\int _{0}^{t}{e(\tau )}\,{d\tau }+K_{d}{\frac {de}{dt}}$

---or---

$u(t)=K_{p}\left(\,{e(t)}+T_{i}\int _{0}^{t}{e(\tau )}\,{d\tau }+T_{d}{\frac {de}{dt}}\right)$

I have a problem with the current form:

$u(t)=K_{p}{e(t)}+T_{i}\int _{0}^{t}{e(\tau )}\,{d\tau }+T_{d}{\frac {de}{dt}}$

because it would mean that $T_{i}$ and $T_{d}$ don't necessarily have units of time. (For example, if e is speed error and u is accelerator pedal position). Most descriptions of the Ziegler-Nichols tuning method assume the second form, and it screws people up if they try to use it on a system that is expressed in the third way. Spiel496 12:37, 27 July 2007 (UTC)

Spiel496, your second equation is incorrect! It should be as follows,

$u(t)=K_{p}\left(\,{e(t)}+{\frac {1}{T_{i}}}\int _{0}^{t}{e(\tau )}\,{d\tau }+T_{d}{\frac {d}{dt}}e(t)\right)$

It should be noted that,

$K_{i}={\dfrac {K_{p}}{T_{i}}}$

and

$K_{d}={K_{p}}\cdot {T_{d}}$

Hence,

$u(t)=K_{p}{e(t)}+K_{i}\int _{0}^{t}{e(\tau )}\,{d\tau }+K_{d}{\frac {d}{dt}}e(t)$

Bsodmike (talk) 18:39, 31 August 2009 (UTC)

Agreed. I happen to prefer the first form because it looks neat and clean.Dhatfield 15:34, 27 July 2007 (UTC)

Corrected the form of the equations as suggested, added a note to alternative nomenclature that the standard form is indeed the standard. Still to do in future: Clean up description of integral and derivative actions. Remove the section on implementation? (is it relevant beyond historical interest?), or maybe move it into a section called 'history'. Add nomenclature and/or glossary. This field is rife with MV = OP = CV, PV = MV (yes, it's amazing, but true). At least SP is just SP. Add something about error-squared PID and alternatives to PID (fuzzy, MPC) and when and where they are more applicable (maybe). Didn't you know I was only doing all this cleanup so that I could clutter the article up again? :)

I really like the tuning section, but I feel that we could create much better impact with some graphs (eg. stable vs unstable, slow vs fast). Have to figure out how to upload pngs first. Dhatfield 16:59, 27 July 2007 (UTC)

Editing / cleanup mostly done. Dhatfield 21:07, 27 July 2007 (UTC)

Uploading PNGs is pretty easy, the file upload wizard on the left bar will let you do it, but you must choose a wiki compatible licence, (Creative Commons(CC) or Public domain or GNU Free Doc. Lic. (GDFL)) Once uploaded you can add your images in as per Wikipedia Images. Does anyone have a nice image of the inverted pendulum experiment? Thats always good for an impact in control. User A1 02:47, 28 July 2007 (UTC)

Thanks

I have not seen this implemented and I don't know what it means: "# setpoint weighting Setpoint weighting uses different multipliers for the error depending on which element of the controller it is used in. The error in the integral term must be the true control error to avoid steady-state control errors. This affects the controller's setpoint response. These parameters do not affect the response to load disturbances and measurement noise." Can anyone clarify? For now I'll just leave it alone.

To have smoother responses to setpoint changes, some people (e.g. KJ Åström) suggest to reduce or totally discard the proportional path from setpoint to control signal. Many concepts would become clearer with graphics. Engelec 13:37, 14 August 2007 (UTC)

I've removed the "{{Expert-portal|Technology|October 2006}}" tag. If you revert (which I will understand completely) please give guidelines for further improvement. Thanks. --Dhatfield 08:43, 30 July 2007 (UTC)

Limiting the integral history

In the "Alternative Nomenclature..." section there is the statement:

“ it is possible to modify the integral to such that it does not "record" all historical values of the error signal. There are many possible schemes for performing such modification, such as windowing the signal or applying a decay term to the integral value itself. ”

I'll be blunt: I consider this technique to be based on a misunderstanding about what the integral term does. Yes, it does remember that big error from long ago, but the overshoot of the loop since then has canceled out that error. The integral output settles to exactly what it is supposed to be. The infinite memory of the integral term just freaks out some some engineers, and their response is to make modifications like those described in the quote. But the mathematics doesn't point to any benefit. That's my personal belief, anyway. I'd love to excise this section, or present it as "a common misguided technique" but it would be completely original research at this point. Does anyone have a control systems text book that speaks to this? Spiel496 05:42, 15 September 2007 (UTC)

I agree with you. I think we can say it's misguided, or not mathematically sound, or remove it, or move it to a section about things to be avoided, as long as nobody provides any reference. Also mathematically the integral starts at t = 0 isn't really relevant. Engelec 13:40, 17 September 2007 (UTC)

I don't have a text-book to hand, but there are clear practical problems with what is called "integral wind-up". In response to Spiel496, 'the overshoot of the loop' is precisely what we try to avoid. If a furnace takes 50 minutes to heat by 1000 deg C (say, from ambient to a fixed setpoint just above 1000 deg C) then when it reaches setpoint, you do not want it to overshoot while something like 0.5 * 50 * 1000 = 25,000 degree-minutes of integral wind-up are "unwound". That, without integral wind-up prevention, would render the system useless in practice. --Nigelj 16:40, 17 September 2007 (UTC)

ARW (anti-reset windup) is a perfectly valid, documented improvement of the basic PID or PI controller, already mentionned in the article. I object to such as windowing the signal or applying a decay term to the integral value itself: with windowing the signal, I understand that the I term would be proportional to $\int _{t-a}^{t}{e(\tau )}\,{d\tau }$ with some constant $a$, and by applying a decay term to the integral value itself that its frequency response would be bounded at null frequency. That's not how ARW works. Engelec 17:12, 17 September 2007 (UTC)

I agree integral windup is a real problem. It arises when the Process Variable is unable to respond linearly to the Manipulated Variable. In Nigelj's example, when the furnace is way below the 1000 C set point, the heater may be saturated at 100W, while the PID loop is requesting something absurd, like 500kW. It would indeed make sense to prevent the Integral from remembering that frustrating period from its past. Does it make sense then to restrict the "clever modifications of the integral" to the section on windup? Even there I don't see the wisdom in "Limiting the time period over which the integral error is calculated", but the other three techniques sound legit. Spiel496 04:28, 18 September 2007 (UTC)

Since we all agree, I've been bold and removed it. Engelec 21:23, 18 September 2007 (UTC)

What use e for error?

Hi, I think that when using e for the error is somewhat not suitable notation as when learning this coupled with being introduced to laplace transforms at uni. I was under the understanding that this was some expenisional term which as when using laplace occurs a lot so for someone learning this topic it would be easier to note this as E or ε. I do see now that this was denoted as error but still confused me.

I know this may seem perdantic but i feel this is a nessessury change to make the topic (which is great by the way) better.

Thanks Andy (Study Chemical Engineering) —Preceding unsigned comment added by 138.38.152.11 (talk) 12:22, 20 November 2007 (UTC)

Pseudocode

I don't feel that the second block of code in PID_controller#Pseudocode adds much to the article. The content is virtually identical to the first block, except for the absence of the constant dt. Do many others feel this level of implementation detail is warranted? Spiel496 (talk) 22:56, 27 March 2008 (UTC)

I'm with you. Normally I tend towards being inclusive, but this level of detail is beyond 'encyclopeadic' and doesn't add enough. At the risk of discouraging Shriramrs31, I believe it should be reverted. To Shriramrs31 - please give motivation for the addition of the Z-transform. Dhatfield (talk) 14:31, 2 April 2008 (UTC)

It didn't add anything but confusion. The first block of code already was based on the Z transform, and much cleaner; I've grouped Ki*dt and Kd/dt to suggest they can be precomputed outside the loop. "Successive subtraction" didn't mean much. The range of values for dt was totally arbitrary. I've removed all that. Engelec (talk) 00:21, 3 April 2008 (UTC)

Hello guys. I was trying to implement the first pseudo code block in a FPGA. I had to use lots of resources for division and felt that dt calculation can be removed by executing the loop every dt, so that addition and subtraction, functions as integration and division over the period of dt. in FPGAs its easier to use the timer (even in nanoseconds for faster loops), so just by executing the loop on the expiry of timer and by modifying the first pseudo code, i reduced resources and speeded up the whole loop. I felt it might be useful for others, who wants to reduce Floating Point Arithmetic and Logic resources. So, the second pseudo code, differs in reducing the division and implements dt by executing the loop in frequency based on dt. Shriramrs31 (talk) 11:56, 3 April 2008 (UTC)

You mean you actually imagine that someone doing hardware design would use resources to divide by a constant in a loop? This kind of obvious optimization should not be used to complicate explanatory pseudocode. Dicklyon (talk) 15:12, 3 April 2008 (UTC)

Well, apparently someone did. Then they learned :) BTW, nice work in other areas of optics, signal processing, etc. Could you maybe help out optical flow - it's pretty dire. Dhatfield (talk) 08:01, 4 April 2008 (UTC)

I know, I was making fun of that someone. As to optical flow, I'll take a look; I have passing familiarity with that through various friends. Dicklyon (talk) 04:53, 5 April 2008 (UTC)

Hi, well for my application, i has to choose different sets of PID constants according to varying commands from an outside interface. So i could not assume the value of KP,KI and KD as constants. This is one of my first contributions to wikipedia and I am not very much aware of all this thorough review involved. I am glad about this and happy to learn things from experts like you. I will try my best in further contributions. Thanks a lot guys :) Shriramrs31 (talk) 12:06, 4 April 2008 (UTC)

Welcome to Wikipedia. Dhatfield (talk) 21:59, 4 April 2008 (UTC)

But 1/t can still be a constant, can't it? Or just update coefficients when they change, not every time around the loop. Whatever the strategy, we don't need pseudocode for it. Dicklyon (talk) 04:44, 5 April 2008 (UTC)

The pseudocode section as it stands is very helpful...it almost solely describes the PID conecpt in less than 30 seconds...and is alot easier to understand than a bunch of mathematics. Thanks to whoever put it there :) — Preceding unsigned comment added by 12.73.190.141 (talk) 15:16, 31 January 2012 (UTC)

Loop Tuning Initial Estimates Table

I am trying to add a table of manual loop tuning initial estimates.
The table is useful information for people practically trying to tune a control valve.
This table is relevant to the manual tuning of control valves and thus appropriately placed.
The source article is a hard copy of a single page document issued by Exxon as a starting point for tuning control valves.
The units presented in the table are in SI.
Proportional - dimensionless (-)
Integral - seconds (s)
Derivative - seconds (s)

Is the reference note all that is required to keep the table in place? How do I reference a single page hard copy? Are there philosophical objections to its inclusion based on the fact it is for practical rather than theoretical application?

I will revert the document to include the table once again. But if undoing the change could you please respond here. —Preceding unsigned comment added by 203.47.182.117 (talk) 06:39, 11 June 2008 (UTC)

Here are the problems I see with the table:

• The coefficients "P", "I" and "D" are not defined elsewhere in the article. OK, they are, but not with those names. It's been a chore to make the nomenclature self-consistent, so the understandable reaction by many editors is just to delete new material if it doesn't follow the conventions used in the rest of the article.
• The formatting is confusing. "Units" appears to be one of the "Loop Type" entries.
• The systems at Exxon are too narrow an application. For example, a temperature control loop could have a timescale of 10 milliseconds and another might be 2 hours, depending on the size of the system.

69.111.133.13 (talk) 17:47, 11 June 2008 (UTC)

Counter-Arguments...

Those coefficients are used elsewhere in the article. So it is consistent with labels used elsewhere.

The formatting may be confusing, but I have tried to edit the format numerous times to fit in with what appears to be the standard. Wouldn't a better way be to help fix the formatting than just deleting the table?

I think the systems at Exxon cover a very diverse range of control applications. In fact I would go so far as to suggest there probably isn't another company with as diverse a range of control applications.

The table also provides a starting point for slow and fast temperature controllers to allow for just that wide disparity in differences that you use in your example.

Finally these initial estimates are starting values for manual tuning only not the final values. The other table listed under the "manual tuning" segment would then be used as a guide to modify these values.

BUT given people seem determined not to include this table I will refrain from reintroducing it once again. —Preceding unsigned comment added by 203.47.182.117 (talk) 08:13, 13 June 2008 (UTC)

203.47.182.117, a few comments to get you started (I'm assuming you are new around here). First, you are congratulated for being bold. If you plan to continue editing, here are some tips:

1. Create an account - it increases you credibility by a factor of roughly 10 bazillion (I'm only serious about the create an account part).
2. Sign your posts on the talk page. It is considered unprofessional, or even rude, not to.
3. Think carefully before reverting the edits of a registered user with a long presence on the edit history or (especially) talk pages. Considering what you need to learn about WP:NOTABILITY, WP:WIKIPEDIA and WP:SPIDER and that fact that he probably already knows these things, be patient mostly replaces WP:BE BOLD in practice.
4. I apologise if your first edit on Wikipedia has been a frustrating experience and if I sound like a boring old fart. I hope that you will come back and help us and go through the (sometimes painful) learning curve from newbie to experienced editor. We all went through it and I have found it a great learning experience. Dhatfield (talk) 09:21, 13 June 2008 (UTC)

My objectives were the lack of a stated source, and the units. The derivative and integral terms can't have the same units. Even the proportional term being dimensionless has some other assumption built into it, since the "Process" input and output are not generally in the same units, and since the process can have any gain. So the numbers seem be quite mysterious and meaningless. If a source we presented, we could try to see what's behind them, and maybe help find a way to explain. No objection a table per se, though. Dicklyon (talk) 14:58, 13 June 2008 (UTC)

I'm afraid I don't think a manual loop tuning table from a proprietary source will meet the copyright or notability requirements, but I've become sensitive to the fact that newcomers may view high standards for accuracy and referencing as hostile. We have a prospective new (apparently very competent) contributor who made a new page at PI controller rather than integrate his content here. I have discussed it on the Talk:PI_controller page, but I fear I came across as hostile. How to solve the eternal problem that being edited is not a fun experience? I don't know. Dhatfield (talk) 09:35, 19 June 2008 (UTC)

Notwithstanding the valid point that the table was proprietary and problems with units, wikipedia was my preferred initial point of contact with this subject and I found the table helpful from a practical standpoint in tuning a simulation. Is it possible to resurrect the table with clear caveats? I've actually dug the source up again from the history as it was so useful. GivePeasAChance (talk) 06:17, 13 August 2009 (UTC)

I'll wade in here. I would recommend finding a paper in a peer reviewed journal that provides loop tuning estimates, or methods of estimation for various common applications. However direct tuning values are simply "rules of thumb" and may not mean the same thing to all engineers. Quoting direct values with minimal information on either the system or the interpretation of that system may not be helpful (imagine level control on a viscous solution, versus a very invisicid one, what is "fast" or "slow" are we talking seconds, hours or days. A furnace's PID values could be orders of magnitude different if you were using a lab scale furnace versus an industrial scale furnace. It depends upon the inertia of the system during heating and cooling, which in turn depends upon temperature of operation, geometery etc etc. Level control depends upon how tight your control needs to be, noise in instrumentation and all sorts of stuff. User A1 (talk) 09:59, 13 August 2009 (UTC)

Pseudocode II

Regarding recent edits to the Pseudocode, with the removal of dt. In order for a loop of this nature to funciton, it would have to be driven such that the loop executes every dt units of time *as well as* incorporating the units of time into the tuning parameters. This is not consistent with the rest of the article, as the tuning parameter is now not just system dependant, but also dependent upon your loop's update time period.

Examples:

• "The magnitude of the contribution of the derivative term to the overall control action is termed the derivative gain, Kd" -- this would not *quite* be true under the new Pseudocode.
• "Defining $u(t)$ as the controller output, the final form of the PID algorithm is:

$\mathrm {u(t)} =\mathrm {MV(t)} =K_{p}{e(t)}+K_{i}\int _{0}^{t}{e(\tau )}\,{d\tau }+K_{d}{\frac {de}{dt}}$

and the tuning parameters are" -- this form does not match the new pseudocode either. User A1 (talk) 11:01, 14 October 2008 (UTC)

I changed it such that the integral and the derivative are explicit; perhaps this will make it more clear and people will be less likely to mess it up? Dicklyon (talk) 15:44, 14 October 2008 (UTC)

Now it's ok, but remember that this type of struct is ideal PID, change "Here is a simple software loop that implements the PID algorithm:" to "Here is a simple software loop that implements a Digital Ideal PID algorithm:" —Preceding unsigned comment added by 189.19.196.155 (talk) 16:20, 14 October 2008 (UTC)

Use of bold

Bold has been used since the article began in August 2006. Dicklyon (talk), I don't know why you think this is no longer appropriate. I think it made the article easier to read. Please put it back. Robert - Northern VA (talk) 20:08, 30 October 2008 (UTC)

Manual tuning

On Oct 14 [1], the article was modified to indicate that the I term controls the long term offset and that D controls the rise time (as described in the article). This agrees with what was in the article Jan 2008 [2]. For some reason Dicklyon (talk) removed this edit. I don't understand why. Robert - Northern VA (talk) 20:23, 30 October 2008 (UTC)

You're right -- it used to say that D eliminates offset, which is incorrect. I don't know why I didn't notice it before. One place I would dispute the current wording, though, is the claim that excessive D leads to excessive response and overshoot. I could believe that too much D would amplify noise and thus lead to instability, but elsewhere the article says D reduces overshoot, so that's confusing at best. The other issue I have is that P, I and D are undefined in the article's nomenclature; they should be Kp, Ki and Kd. Spiel496 (talk) 22:12, 30 October 2008 (UTC)

Modifications to the PID algorithm

Old modifications:

This's proportional only! :

• Setpoint weighting – Setpoint weighting uses different multiplier for the proportional error (only!!! derivative and integral don't use this!), this help reducing steady-state error from proportional controller. The error in the integral and derivative term don't change. This affects the controller's setpoint response (ok that's for proportional). These parameters do not affect the response to load disturbances and measurement noise (derivative and integral responses could be removed from here?).

Dead Bands:

• Integral dead band:

 if(absolute(error) <= dead_band) then:      integral_sum don't change
 else:      integral_sum = integral_sum + error

• Proportional dead band:

 if(absolute(proportional_error) <= dead_band) then:      proportional term = 0
 else:      proportional term = proportional_error * proportional gain

• Derivative dead band:

 if(absolute(derivative value) <= dead_band) then:      derivative term = 0
 else:      derivative term = derivative value * derivative gain

---

New modifications, Derivative modifications:

• Derivative of the input signal - In this case derivative is calculated from input signal not from error, a change on setpoint don't change the derivative control.

• Lowpass filter on derivative - With a lowpass filter after derivative control high frequency created by derivative control are cutted, allowing a smooth response from derivative control.

Integral modifications:

• anti windup?! - a saturation output should: reduce integral term on upper saturation, increase integral term on lower saturation, proportional to error value. (inverse error sum)

   integral_sum = integral_sum - error_value 

or proportional to saturation value. (anti windup sum showed on books)

   integral_sum = integral_sum - (pre saturation output filter - saturated output)   

saturation filter function:

   if(value>max) then: output = max
   elseif(value<min) then: output = min
   else output = value

---

Others modifications, i didn't found the name but are used:

Conditional integral sum

• Derivative input signal invert error on integral

if absolute(derivative_value) > pre_determined_value then: integral = integral - error

• Limit integral error value or saturated integral error, it's near ramp error but don't work with a time function or low pass filter of setpoint. This work with error value

if (error > x) then: integral_error=x else if (error < y) then: integral_error=y else: integral_error=error integral_sum = integral_sum + integral_error

Terminology

The following associations were recently added

• proportional term (sometimes called gain)
• integral term (sometimes called reset)
• derivative term (sometimes called rate)

I don't know where these come from and I suggest removing them unless a reference is provided. Q Science (talk) 15:22, 5 January 2009 (UTC)

It's possible that a reader of the article has experience only in operating a PID, but would like to learn more about the meaning of the knobs he's been turning. If one of those knobs had been labeled "reset", then providing these associations in the article would help connect the article's content with his past experience. On the other hand, it could lead to confusion if we don't get it right. At least one site [3] has reset defined as 1/integral. Spiel496 (talk) 16:08, 5 January 2009 (UTC)

Not sure if it is still of interest. The following is the base were I start my explanations from:

• $u=K_{p}\left(\,{e(t)}+{\frac {1}{T_{i}}}\int _{0}^{t}{e(\tau )}\,{d\tau }+T_{d}{\frac {d}{dt}}e(t)\right)$

This is called the (ideal) additive form of a PID-Controller (I think the explanation doesn't hold for the multiplicative form but not sure). These associations afaik come from the following:

• reset (time) $T_{i}$ is the time an I-Controller (without P part!) needs to produce the same output (control signal u) as the PI-Controller at time 0 for a step input
• rate (time) $T_{d}$ is the time a P-Controller needs to produce the same output as a PD-Controller at time 0 for a ramp as input

I learned this in a lecture. Second one I'm not 100% sure. But I'm sure this can be found in most of the basic control theory books. But I could name only German ones (e.g. Taschenbuch der Regelungstechnik). I can't explain why it is reset and rate (time) but these are the German translations of these words. TFTD (talk) 11:39, 22 October 2009 (UTC)

Thanks. I questioned this because in analog circuit implementations, reset (being a verb) clears the capacitor used to store (accumulate) the integral value, but does not refer to the value itself (that would require a noun). As far as panel labels go, it would make sense to have a knob to change the RC-time constant ($1/T_{i}$) and a separate reset button to clear the capacitor. Q Science (talk) 20:59, 22 October 2009 (UTC)

Error in the formula of the derivative term?

I think it should be:

$D_{\mathrm {out} }=K_{d}{\frac {de(t)}{dt}}$

(unsigned comment by 89.133.22.172)

The formula currently reads:

$D_{\mathrm {out} }=K_{d}{\frac {de}{dt}}$

which has the identical meaning. Spiel496 (talk) 14:34, 6 February 2009 (UTC)

Excel spreedsheet

user:User A1, I thought the excel spreadsheet was pretty cool. It even allows random noise to be added. I assume that you deleted it because it broke one of the wikipedia rules, but isn't there some way that it can be added? Robert - Northern VA (talk) 07:08, 10 February 2009 (UTC)

From WP:EL,

1. Links to blogs, personal web pages and most fansites, except those written by a recognized authority (this exception is meant to be very limited; as a minimum standard, recognized authorities always meet Wikipedia's notability criteria for biographies).

A short piece of scilab or matlab psuedocode would be more appropriate for this task. Furthermore, there are technical issues with their method.

1. They should use a higher order integration, rather than Euler, or at least confim that changing the step size has minimal effect on algorithmic convergence, particularly in the presence of "noise". Euler method has issues of its own.
2. There is no notion of "system". The transfer function of the system that they are controlling is effectively 1, which is completely non-physical.
3. Finally, the idea of "noise" is not quite right either, as noise in processes usually significantly outweighs noise in the control device itself, so the "noise" being added is not system fluctation, but fluctuation in the actuator position.

In total, these issues, as well as the WP:EL guidelines prompted me to remove the article, as it is a non-authoritarian source. User A1 (talk) 10:36, 10 February 2009 (UTC)

I hope that this response is not to terse or blunt, please feel free to contribute to the article, and of course any article, in any way you see fit!. User A1 (talk) 11:52, 10 February 2009 (UTC)

Excellent points.

1. I haven't read anything on how different forms (orders) of integration will effect the system. It seems that, for many systems, the extra time delay could cause oscillations, but for others, it would really help. Perhaps a section on this would make an important addition to the article.
2. The examples (plots) already in the article appear to assume linear systems with no noise. The existing article does not even have a link to transfer function.
3. With a simple linear system, I don't think it matters where the noise is added.

So, I guess the spreadsheet implements what the article describes, but the article actually needs to be expanded a bit. I originally thought it was just the WP:EL guidelines. Specifically, personal web site and rich media. Robert - Northern VA (talk) 17:59, 10 February 2009 (UTC)

Converting continuous-time controllers to discrete-time controllers is indeed an important topic which should be mentionned; not relevant here for simulation, but for implementation. If your system has a rational transfer function (such as 1, which isn't very interesting as User A1 said), you can compute an exact step response by converting the closed-loop transfer function from Laplace transform to z transform assuming a zero-order hold, either by hand or with matrix exponential. The resulting discrete-time state-space model is easily simulated iteratively. Engelec (talk) 20:21, 12 February 2009 (UTC)

the Kp plot is incorrect

the Kp plot is incorrect —Preceding unsigned comment added by 192.158.61.142 (talk) 21:00, 8 June 2009 (UTC)

In what way? The caption says that Ki=1 and Kd=1 for all 3 curves and that only Kp changes between the curves. Robert - Northern VA (talk) 16:25, 20 July 2009 (UTC)

It doesn't look incorrect to me either, but giving numerical values for the three PID parameters and nothing more is misleading. The closed-loop response depends on the process as well... Engelec (talk) 19:32, 21 July 2009 (UTC)

It looks wrong to me aswell! When looking at the graph it seems that increasing Kp will decrease the overshoot and settling time. The rise time is correctly decreased! When you increase Kp it will increase overshoot and setteling time and that is not what the figure shows, this is also described further down in the "Manual Tuning" section. —Preceding unsigned comment added by 80.254.148.43 (talk) 12:57, 29 January 2010 (UTC)

To make the plots, the contributor (Skorkmaz) had to assume some example process, and we don't know its characteristics. Perhaps that process is really atypical. For instance, if the process has no high frequency poles, then there won't be any onset of ringing as Kp is increased. The question is, what process characteristics would serve as a good example? I think we'd want to have one pole much lower than the desired closed loop response -- that would mimic the situation in thermal control where the process acts almost like an integrator. Then another pole just above the loop response, in order to make things ring if the gain is set too high. Maybe we'd need two up there to demonstrate the benefit of the derivative term. Does anyone have more specific suggestions? Spiel496 (talk) 19:33, 29 January 2010 (UTC)

I'm not an expert, but trying to learn PID. It seems to me that the graph for demonstrating Kp should show a "typical" example where a large Kp causes more overshoot, and a small Kp causes less overshoot. While there may be atypical processes as Spiel above indicates, the purpose of an introductory article should be to demonstrate the basic principles using a typical process as a basis. I think that exchanging the curves for Kp=0.5 and Kp=2 would be more illustrative to a beginner. Or have I missed the point completely? —Preceding unsigned comment added by 67.169.6.121 (talk) 17:24, 3 March 2011 (UTC)

Improved Ziegler-Nichols method

Should there be reference to the improved Ziegler-Nichols method? I think it wasn't much just modified equations for the Ki and Kd. I'm not an expert so I won't make an edit. We just used it a lot more often in my undergrad degree.

Further I seem to remember another manual technique for tuning that was more involved than that mentioned and converged to an optimen quicker. There was an actual process to go through and you tended to get the "correct" result in two or three iternations after starting with Ziegler-nichols method's. —Preceding unsigned comment added by 119.224.62.103 (talk) 03:18, 20 July 2009 (UTC)

Phelan IPD controller

Is there an article on this?

http://users.erols.com/jyavins/servo.html —Preceding unsigned comment added by 71.167.65.207 (talk) 02:11, 15 September 2009 (UTC)

Tuning

There's also IMC tuning (internal model control)...Matlab toolbox has this option--Billymac00 (talk) 04:45, 3 February 2010 (UTC)

Honeywell Thermostats

Had a phone conversation this morning, Tuesday May 11th, 2010, with Honeywell's technical support line at 1-800-468-1502. Representative from Honeywell claimed that what the industry calls PID, _THEY_ call either "Adaptive Intelligent Response" (A.I.R.) or "Smart Response". Also, it's included in every programmable thermostat they sell. Yea, I know, this trivia doesn't fit inside the PID Controller article, but I figured I'd toss it out there in case SOMEONE knows a relevant place to put it.
LP-mn (talk) 15:03, 11 May 2010 (UTC)

Its known as "self tuning PID" control. Its a well established branch of theory (and even practice). PID tuning software says this section, but I don't think it is necessary (or useful) to refer to a specific product. User A1 (talk)

MV - The water valve position?

I disagree this is unnecessary complication. It is necessary, because saying that the water valve position is the MV is incorrect. We go to the equation in the article MV=P(e)+I(e)+D(e), and let's for the time being ignore the I and D terms. So we have MV=P(e), which from the aritcle is MV=K_p*e(t). Now we say the MV is the absolute valve position. So let's say we want to set the water temp to 35 degrees, and we have the hot water valve open at say 15%, and the water temp in the water bath is indeed 35 degrees. So e(t)=0. So this would mean at 35 degrees MV, which is the absolute water valve position and has a value of 15% opening at 35 degrees, is zero. 15% opening on the hot water valve equals a MV of zero. Now we want to change the water temp to 55 degrees, so obviously we need to turn the water valve to open more. However if we use the definition that MV=K_p*e(t) then when the water temp is indeed 55 degrees, e(t) is zero and MV has to be zero again according to MV=K_p*e(t). If MV is the absolute water valve position that means the water valve is also only opening at 15% for a water temp of 55 degrees. This doesn't make sense.

What MV is how much corrective action we apply. We have error in the system, we apply more corrective action. The effect of the corrective action is that it changes something in the system. So in the water valve example, the corrective action is turning the valve, not the absolute position of the valve itself. 122.57.201.57 (talk) 13:36, 27 June 2010 (UTC)

First you say, "let's for the time being ignore the I and D terms", then you go on to complain that there is no integral action to fix the droop in your water temp example. You are changing MV to ΔMV, which changes the order of the system, to create some kind of automatic integral action. Please read Control system#Linear control, and this article, where all this is explained. Better still, find a WP:RS on control theory that backs up your position. While you do so, unfortunately you have reverted the article to have erroneous statements. Have a look at WP:BRD to see why re-instating your version before discussion was wrong. --Nigelj (talk) 14:04, 27 June 2010 (UTC)

Nigelj is correct. Without an integral term, the error term is never zero at steady state. I have changed it back. Q Science (talk) 17:01, 27 June 2010 (UTC)

Block Diagram, correct classification?

The block diagram shown in the corner is of a style commonly used in control theory, and I believe it comes from diagrams describing analog computers and some electronic signal processing (or at least, the same style of diagram turns up in those places). However, the name "Block Diagram", is used by many disciplines to mean many things, it gets used in control theory to mean this specific type of diagram where the arrows represent signal flow and the blocks represent processing stages, also with the summing junctions and the Sigma symbol in the junction. I can't find a wikipedia page specifically describing the type of block diagram used by control theory, nor can I find a precise name to distinguish this type of diagram from the more generic concept. In partial answer to my own question, there's a category on commons Category:Control_theory_block_diagrams which probably should have a companion wiki page Control theory block diagram and maybe also related to Function block diagram but not exactly.

I can't guarantee that the diagram in the article adheres to a set of industry standards. But it appears to me to be an example of a Function block diagram. The summing junctions are just blocks like the others, only they happen to be round. Spiel496 (talk) 05:12, 9 December 2010 (UTC)

PID Controller Theory problems

The plots in this section are essentially meaningless, since there is no explanation for how PV is related to u(t). Certainly, the generation of the plots required some relation between these terms, and without it explicitly defined, the reader is left confused. Whoever made those plots should fill in the details. —Preceding unsigned comment added by 84.108.63.99 (talk) 05:32, 28 April 2011 (UTC)

From Talk:PID controller/Comments

Hello,

For the Proportional Term, I think it's wrong in the graph of "Change of response for varying Kp". The black curve with smaller oscillation should have a smaller proportional gain Kp. The red curve with bigger oscillation should have a bigger proportional gain Kp. But in the graph, it seems wrong way round. So by my understanding, the black curve should have Kp=0.5 and the red curve should have Kp=2. Am I right?

Many Thanks,

Li

Li, see Bmike210's response below. If you're unsure about this, I would recommend that you setup a simple SIMULINK model and observe the effects of a step-input to the model of a DC motor (or any other plant of your choice). Modelling the DC motor in SIMULINK is quite simple (if you understand the basics), and if not, it is widely detailed online. Give me a shout if you need a hand :) Cheers, Mike ~ Bsodmike (talk) 18:23, 31 August 2009 (UTC)

---

The page has it correct. A higher proportional gain will increase response time. Notice how the black curve approaches the command at a faster rate then the others.

On the other hand the red curve, with the smallest gain out of the 3, has the slowest response and thus the largest overshoot.

Bmike210 (talk) 17:28, 6 September 2008 (UTC)