Talk:Proportional–integral–derivative controller

Removed this comment from the article itself

With all due respect, we have a reason to question this PID definition, because it perpetuates a mistake in PID control, especially with respect to the Integral term. The mistake can be Illustrated as follows:

1) Even though there is zero error, the Integral term will cause an output action. (Not desired)

With due respect, if the integral term is producing an output... the result is that there is NO zero error, so the integral will have a value to continue until zero error is reached. cuye.

2) The Integral is based upon previous errors which are no longer relevant. (Not desired)

Proportional control can produce zero error if the controller is comparing the input to the output and through negative feedback and driving the Error to zero.

Not really. Proportional control needs an error signal because if the error is zero, the output is zero. The real situation is that if -for example- the controlled motor load changes, we need a different error to ensure that the control power changes.

The correct PID term:

D term: Add changes (differentiation) to the steady-state INPUT to be combined in the summing Junction.

I term: Add changes (differentiation) to the negative (negative feedback) of the steady-state OUTPUT to be combined in the summing Junction.

Integration is differentiation when combined across (around) negative feedback. The output is connected to the zeroed-offset summing Junction with a very high gain and negative polarity (inverting).

Contribution:

P term: is the desired OUTPUT divided by the desired INPUT OR the ratio of the signal fed the summing Junction by the OUTPUT divided by the signal fed the summing Junction by the INPUT. When the negative OUTPUT of the parameter to control is summed with the INPUT (setpoint) The OUTPUT will satisfy the desired setpoint. {gain and offset errors are mostly insignificant in todays designs, otherwise can be handled separately, certainly do not want output based on previous, unrelated errors as described below}

I term: Integration slows down the output response as it approaches the correct/desired value. Useful to dissipate stored energy that would produce an overshoot.

D term, Differentiation speeds up the output response to an input so the output approaches the correct value sooner. — Preceding unsigned comment added by 80.192.162.104 (talk) 03:19, 25 December 2016 (UTC)

No definition of "Process Gain"

The term "process gain" is used in the "Droop" section ("... droop is proportional to process gain ..."). Process gain is not defined anywhere in the article, and the term is not used anywhere else in the article. It's difficult or impossible to determine precisely what it means. — Preceding unsigned comment added by 174.31.179.148 (talk) 13:28, 21 October 2013 (UTC)

Process gain is discussed in PID controller#First with dead time model. It is first mentioned in PID controller#Steady-state error. We should try to fix this forward reference. ~Kvng (talk) 15:31, 6 March 2021 (UTC)

Kessler's Symmetric optimum principle

No mention of Kessler's tuning method of using two zeros of a PID controller to cancel out the dominant poles in a n-th order PT1 system? no absolutely wrong

Kessler's symmetrical optimum method does seem to be a significant ommision. I see a lot of references to a 1958 paper. ~Kvng (talk) 15:31, 6 March 2021 (UTC)

Basing Derivative and Proportional Action on PV sign

Shouldn't the sign on the d/dt PV terms be negative for these alternative forms? If error is SV-PV, then when switching to d PV based derivitive term changes sign. When using the Ti, Td form, these variables are positive, so shouldn't the sign on the PV based derivitive term be negative? --CaveMole (talk) 10:40, 10 January 2012 (UTC)

I think CaveMole is right. Has anyone else thought this through? Spiel496 (talk) 22:15, 10 January 2012 (UTC)

I looked at this a few days ago and reverted a change. These alternate forms use different constants. The new constants are not defined in the article. If there were I assume we'd see inverting signs there to accomplish the required sign reversal. Inverting the sign in the constants and simplifies the equations. But without definitions for the new constants, it does lead to questions. --Kvng (talk) 19:41, 12 January 2012 (UTC)

The equations given use the same symbols - so the sign must be changed. The constants are usually positive, so they can't include a sign.

Besides the sign problem, I see also some concern with the arguments to support the changes. Going from proportional to error to proportional to measured value does not change anything in how the controller reacts with a constant setpoint, so the tuning (Ki,Kp,Kd) should not change at all. The change in going from error to measured value however changes the reaction to a change in setpoint - in a way similar to a simple form of control-feed-forward. A simple (linear model) form of control-feed-forward would ad parts proportional to the setpoint and the time derivative of the setpoint.--Ulrich67 (talk) 20:22, 23 March 2014 (UTC)

Helmsman example picture

Forgive my very low level comment after your constructive sections, but the black & white picture of the guy in shorts steering a boat is very inelegant with respect to the topic. Is it really necessary? It doesn't really make a difference and it doesn't even carry the message quoted: "PID theory developed by observing the action of helmsmen". — Preceding unsigned comment added by Raggot (talk • contribs) 16:09, 7 February 2012 (UTC)

- I thought the picture and accompanying text expliaining it was the most accessible part of the entire article. The rest reads like a math textbook. 198.58.148.127 (talk) 08:01, 19 January 2016 (UTC)

proportional versus integral

I came to Wikipedia to confirm my understanding of PID controllers, and now a bit later I've come to understand that the main article is wrong.

www.cds.caltech.edu/~murray/courses/cds101/fa02/caltech/astrom-ch6.pdf

The article HERE says that for the "P" the CHANGE in output is proportional to the error. If integrate on both sides, the output is proportional to the integral of the error. This is what the I term is supposed to do.

A property of a P control system (Or a PID where the I and D constants are set to zero) is that when there is a disturbance, there will be a constant error. The way things are described here the error would always be regulated towards zero.

To create a final error that is zero the "evolution" of controllers added the "I" term to PD controllers to have the error converge on zero..... Rewolff (talk) 11:11, 23 March 2012 (UTC)

You are right, it is not a "change". Please see if the new text is better. Q Science (talk) 17:18, 23 March 2012 (UTC)

In the general case, the proportional term is one of three terms; when the measured value is at setpoint, the proportional term is zero. It might be useful to distinguish the proportional part as only part of the control variable output. --Wtshymanski (talk) 17:56, 23 March 2012 (UTC)

Is it not enough that the article says "The proportional, integral, and derivative terms are summed to calculate the output of the PID controller"? Spiel496 (talk) 18:01, 23 March 2012 (UTC)

The new definition is good. Your changes to the droop section aren't quite right. A properly biased pure proportional controller can settle at its target value. This is discussed in the last sentence of the droop section. I have revised to never say never. --Kvng (talk) 17:25, 25 March 2012 (UTC)

I don't agree. Normally, the bias is considered as the value of the integral term at t-zero, the reset value. As a result, when there is a bias it is no longer a "pure proportional controller". Therefore, the previous text was correct. Q Science (talk) 18:10, 25 March 2012 (UTC)

I think that is unnecessarily pedantic. $P_{\mathrm {out} }=K_{p}\,{e(t)}+c$ is still the description of "a" pure proportional controller. Every pure propotional controller will settle without droop at some setpoint. For example, even with no heat output at SP, a temperature controller will settle without droop at the chamber's external ambient temperature. Suppose it is a heat/cool system and 0 V represents full cooling? Then there may be a negative temperature that represents a no-droop point. But, as I say, this is all too pedantic. The 'never say never' version is more true, simply because anyone can think of two or three exceptions if we say 'never'. --Nigelj (talk) 19:02, 25 March 2012 (UTC)

Nigelj and I have the same objection. The article describes a bias on the setpoint. You can also get undrooped behavior by biasing the output as he describes. Can we restore my edits? --Kvng (talk) 21:10, 25 March 2012 (UTC)

Do you have a reference that suggests that a constant is part of a proportional controller? I was not able to find one. Q Science (talk) 21:21, 25 March 2012 (UTC)

The constant is built into the system being controlled - the constant is defined by what the system does when control input to it is 0. I don't have a reference handy. --Kvng (talk) 03:45, 26 March 2012 (UTC)

I'm just trying to use examples on a talk page to explain something to an editor who seems to have little practical understanding of the subject. I think more to the point here, is does Q Science (talk · contribs) have a reference for the material they restored with this edit, per WP:BURDEN, which is part of WP:V, which is core policy? The previous text left many realistic options open, Q Science's version is very definite, saying what "will never" happen, and what "there will always be" (emph added). These are very narrow statements and cannot be allowed to stand without a universally acceptable reference that uses exactly as strong language. (Jeez, it's a nuisance having to be so pedantic, but if that is what the other editor prefers...) --Nigelj (talk) 11:08, 26 March 2012 (UTC)

So now you want me to prove a negative? Your argument is equivalent to the observation that since even a stopped clock is right twice a day it is wrong to say that a stopped clock does not tell time. To convince me, all you have to do is to find one good text book to support your position. Q Science (talk) 16:17, 26 March 2012 (UTC)

So, we ended up with something correct but clumsy. I have reworked the Droop paragraph. I removed what I beleived to be an oversimplified droop formula. I moved the droop exception to note. Linked to Biasing and note that bias can be to setpoint or output. Let me know if you like it. --Kvng (talk) 04:28, 1 April 2012 (UTC)

Looks good. Q Science (talk) 18:22, 2 April 2012 (UTC)

Domain of error in integral term

I am totally baffled as to what this tau thing is. I thought the integral term summed the error over a duration, in which case it would be e(t), right? -Keith (Hypergeek14)^Talk 15:41, 9 May 2012 (UTC)

My math courses were decades ago, don't trust my description unthinkingly. I think the idea is that the function is defined at some time t - and the integration needs a "running variable" that runs from 0 to t to evaluate the integral part of the term. t and tau are both time, but used differently. --Wtshymanski (talk) 16:00, 9 May 2012 (UTC)

I am also confused. It appears to me that there should be a "t" where the tau is. I don't want to make the change myself, because I'm not absolutely sure I'm right. It would be nice if someone more knowledgeable either changed the equation or add some explanation of the term tau. My thanks to the kind soul who makes the changes. --User:rben13 —Preceding undated comment added 11:46, 24 July 2012 (UTC)

The short answer is "It's calculus". I know calculus, but I'm not great at explaining it. In lieu of a good explanation, here's a similar example. The following things are all equal:

$\int _{0}^{t}{\tau ^{2}}\,{d\tau }=\int _{0}^{t}{\alpha ^{2}}\,{d\alpha }=\int _{0}^{t}{K^{2}}\,{dK}={\frac {t^{3}}{3}}$

Notice that the variable of integration $\tau$, $\alpha$, or $K$ doesn't really matter. It's like your choice of loop counter in a "for" loop; i works, but so do j, k and count. The only thing you cannot use is a variable that is defined outside the loop. Similarly, you can't integrate over $t$ because it is already being used to designate the present time. If this makes someone say "Ah ha! Now I get it!" please advise on what can be said in the article. I added a line to the article defining $\tau$ but I'm not sure what else we can do. Spiel496 (talk) 19:37, 24 July 2012 (UTC)

Velocity Form Pseudocode

Is it worthwhile putting up pseudocode for the velocity form (that can avoid integral windup)? Is this correct? I believe it's in a style consistent with the existing pseudocode. It's based on the formulae at http://controlstation.brightegg.com/page/150-integral-reset-windup-jacketing-logic-and-the-velocity-pi-form and http://lorien.ncl.ac.uk/ming/digicont/digimath/dpid1.htm

previous_error = setpoint - process_feedback
previous_derivative = 0
previous_output = 0
start:
  wait(dt)
  error = setpoint - process_feedback
  derivative = (error - previous_error)/dt
  second_derivative = (derivative - previous_derivative)/dt
  output = previous_output + (Kp*derivative*dt) + (Ki*error*dt) + (Kd*second_derivative*dt)
  previous_error = error
  previous_derivative = derivative
  previous_output = output
  goto start

D.keenan (talk) 15:33, 20 October 2012 (UTC)

That may be flirting with WP:HOWTO. Also we already have multiple representations for the filter. I think we need fewer, not more. -—Kvng 14:04, 23 October 2012 (UTC)

The code in the aritcle is wrong. Here the error is "implicitly" summed is the output. So Kp becomes a kind of integral gain. For instance, if you choose Kp=0.5, Ki=0 and Kd=0, you see that the output will converge to the setpoint with a null error which is possible only if Ki is non null. — Preceding unsigned comment added by Jlpons (talk • contribs) 06:09, 30 October 2021 (UTC)

Archived old discussions

Old discussions not active in months or years have been archived; reviewing the archive may be of interst in explaining how the article got to where it is now. --Wtshymanski (talk) 20:47, 9 May 2012 (UTC)

Pseudocode reset

I have reset the pseudocode example to a combination of an old version from January 2010, combined with a version that I found in a CodeProject example, itself lifted from this article in 2009. I know that the use of a reference that itself references this article is normally very dubious, but in my defence I would say that the benefit of the CodeProject source is that it has been thoroughly tested in the actual code that follows, as well as by various commentators. I know that that is not much, but I also couldn't easily find a better online source of PID pseudocode.

The changes that this edit have effectively made are as follows.

1. I removed the remark that this is "in its 'ideal, parallel' form". It may be, but neither I nor the reference were clear as to what that would amount to. This has commentary on the matter, but I can't tell how what we have relates to what that author is talking about. Per WP:NOR I tried to err on the safe side by removing this assertion.
2. I went back to initialising the derivative value to zero rather than to 'setpoint - process_feedback'. The difference here will be that, should the loop be started in the presence of a large error, my version would initiate a large derivative kick - on the first iteration only. I think this is a reasonable loss of performance for the sake of clarity in the example: this is simple explanatory pseudocode, not production code. WP:NOTHOWTO.
3. I moved 'wait(dt)' back to the bottom of the loop, rather than being the first thing. This move may have been made to make even better capital out of the derivative initialisation cleverness above, but really, a loop that begins by doing nothing makes you wonder what's going on. The principle of least astonishment.
4. I removed a line 'process_feedback = process_feedback + output' entirely. That seems to be a crude attempt at modelling the actual controlled process in the pseudocode too.
5. I renamed 'process_feedback' to 'measured_value' and explained it's relationship to 'PV' in some explanatory text that I added underneath too. I think that is the clearest possible name.
6. I removed all the brackets from multiplication terms that would naturally be executed first anyway. Even if the rules of precedence are not clear to the reader, the lack of typographic spacing should help them see what is meant better than all those unnecessary characters, I think.

--Nigelj (talk) 18:38, 4 November 2012 (UTC)

Integral windup

I removed the bullet point about "Limiting the time period over which the integral error is calculated" in the Integral windup section. There was a discussion on this point some months back. My reasons are the same now: Taking this action replaces the integrator with a low-pass filter; the benefit of infinite gain at zero frequency is lost. It's possible that this limitation is implemented by some engineers, but it sounds like a sloppy solution, and the references don't back it up. Spiel496 (talk) 22:11, 6 November 2012 (UTC)

See Talk:PID_controller/Archive_1#Limiting_the_integral_history. Spiel496 (talk) 22:15, 6 November 2012 (UTC)

Alternative nomenclature

This section is entirely unreferenced. I have marked it as such. It doesn't appear to be essential. An editor has recently called into question its accuracy. Unless a reference is provided, I propose to delete the whole section. -—Kvng 16:15, 8 December 2012 (UTC)

---

I suggest Astrom' PID Controllers Theory, Design and Tunning (1995, not sure if there is a newer edition) and, **much** more relevant and concise about this particular topic is O'Dwyer's Handbook of PI and PID Controller 3rd edition (2009).

In fact, O'Dwyer's chapter 2 is entirely about different forms for PID controllers. Even the same form receives different nomenclatures, depending who you cite, the best example is the Ideal or Standard form. Signed: Dr.AnonymousCoward 189.101.208.60 (talk) 18:55, 20 February 2014 (UTC)

I found O'Dwyer and have added it to the Further reading section. ~Kvng (talk) 14:00, 14 August 2017 (UTC)

Replacing the integral function by a model based part

As noted by User:Ywaz here, the section about the "model based part" is somewhat cryptic. I can't really follow it either, but it sounds like it might be valuable information. Anybody want to take a crack at it? Spiel496 (talk) 21:35, 19 March 2013 (UTC)

This part seems so be the same as feed forward, already described further down under improvements.--91.3.23.131 (talk) 16:31, 18 March 2014 (UTC)

+1 this seem to be a kind of feed forward - not exactly the same as under improvements, and with a different example. So the two parts should go together and need a reference. There is the more general problem that the 2 sections "Modifications to the PID algorithm" and "Improvements" are rather closely related. Most changes are made to improve regulation. --Ulrich67 (talk) 17:51, 20 March 2014 (UTC)

History and applications

Last paragraph about "variable voltages" seems totally unrelated. Can somebody please check? Thanks!

Itto Ogami (talk) 05:49, 2 June 2013 (UTC)

I agree. If the paragraph is kept, I suggest moving it to the "Discrete implementation" section. In a digital implementation, one must choose a way to convert the calculated PV into an analog signal; the paragraph in question talks about those methods. Spiel496 (talk) 20:33, 2 June 2013 (UTC)

Image showing effect of changing Kp is incorrect

The image in the Proportional term section is incorrect. The image shows the Kp = 0.5 having a shorter rise time compared to Kp = 1 and Kp = 2. It also incorrectly implies that a larger proportional gain will result in a longer settling time. Simple simulations in Simulink show that this is not the case. — Preceding unsigned comment added by Cypus28 (talk • contribs) 23:45, 26 December 2013 (UTC)

Mention

The PID controller article is mentioned here. -- Jreferee (talk) 00:52, 20 January 2014 (UTC)

Derivative control

We need a better description of derivative control in the water faucet example. The purpose of derivative control is to moderate the controller and prevent it from overshooting the target. ~KvnG 15:03, 23 January 2014 (UTC)

Yes, I wrote that, and it's been worrying me ever since. It's not right. The purpose of derivative action is to apply a correction which is proportionate to the rate of change of the error. If the error is increasing rapidly, then a proportionally large correction is applied. Similarly if the error is reducing rapidly. I'm trying to think how to apply this in a one-sentence example to controlling the temperature of a tub of water as it fills. --Nigelj (talk) 20:16, 23 January 2014 (UTC)

I don't think you can use this example to demonstrate the value of the derivative term - the temperature of the water in the tub just can't change that fast. The example was previously about controlling the temperature of the water as it came out of the tap. You could demonstrate a derivative as avioding scalding in that scenario. ~KvnG 20:47, 23 January 2014 (UTC)

Ah. Got it! Water temperature control is the wrong "order" of system for PID. It can't overshoot! My maths is rusty, but I think that we need a 2nd order system to require and justify PID control. When heating an oven, if you switch off the heat, the temperature continues to rise. When you switch on the heat, nothing apparently happens in the first few seconds. That's a 2nd order system (or is it 3rd? I'm rusty as I say). With the present example, if you turn off the hot then (apart from the water actually in flight) the temperature cannot continue to rise, and so PID control is unnecessary. Previously, when talking about the water as it came out of the tap, the example described a 1st order system with a built-in pure time delay. That was even worse, as that's an n-order system where n is off near infinity, and so it is technically uncontrollable by a PID controller. We need to write a new example, using a good old PID oven or kiln, or perhaps a position control system of something heavy like a gun turret on a tank, but I don't like guns. --Nigelj (talk) 21:19, 23 January 2014 (UTC)

Making up our own examples here risks WP:OR. Why don't we find a reference that already has a nice example? ~KvnG 15:06, 26 January 2014 (UTC)

The water example is a little tricky as here the system gain is changing with the amount of water already in the container. A first order system may not oscillate, but this sample may, if effects like speed of measurement or the length of pipe from the valve to the container (which acts as a dead time) are included. However the current explanation is wrong for the proportional part, and not very clear for the derivative and integral part. "not heating quickly enough" is more like proportional and derivative part togehter. A pure derivative would be something like "also consider the rate of temperature change: adding more hot water if the temperature is falling, and less on rising temperature".--Ulrich67 (talk) 17:05, 24 March 2014 (UTC)

 Done. I have finally got around to rewriting the PID controller#Control loop basics section. I have based it on the control of a robot arm. I hope people approve. --Nigelj (talk) 20:53, 18 November 2015 (UTC)

Integral windup

In the list of methods to deal with Integral windup, can anyone explain the meaning of the statement "Adjusting the integral accumulator to produce meaningful process outputs"? If so, then we can expand the sentence so that it says something informative. As it stands, it hinges on the word "meaningful" which could be interpreted a lot of ways. Spiel496 (talk) 19:15, 21 February 2014 (UTC)

I added that. Perhaps "feasible" would be more proper. The preceding text of "Preventing the integral term from accumulating above or below pre-determined bounds" is fundamentally different--It limits some of the excesses of integral windup, but does not completely solve the problem. Rather than constrain the integral term to pre-determined bounds, the bounds on the integral term are dynamically adapted to constrain the *process output* to pre-determined limits. The pre-determined bound on the integral term method is implemented in several popular 3d-printer PID algorithms, (https://github.com/kliment/Sprinter/blob/master/Sprinter/heater.cpp#L656 https://github.com/ErikZalm/Marlin/blob/Marlin_v1/Marlin/temperature.cpp#L439 https://github.com/Traumflug/Teacup_Firmware/blob/master/heater.c#L313 and https://github.com/repetier/Repetier-Firmware/blob/master/src/ArduinoAVR/Repetier/Extruder.cpp#L127 ) but this method does not fully eliminate integral windup like modern PID controllers. The cite attached to the preceeding entry, http://www.controlguru.com/2008/021008.html , does not support bounding the *integral term*, but details the "back-calculation" of an appropriate integral term that would correspond to the a feasibly bounded *process output*. I added text to include an entry matching Douglas Cooper's terms. Drf5n (talk) 16:50, 27 February 2014 (UTC)

Thanks. My interpretation of the "back-calculating" is Figure 10.8 of this book chapter. Am I correct about that, or is this yet another anti-windup technique? Spiel496 (talk) 17:20, 27 February 2014 (UTC)

Your book chapter ref points to the wiki page. If you mean page 315 of http://www.cds.caltech.edu/~murray/books/AM08/pdf/am06-pid_16Sep06.pdf , then yes. Drf5n (talk) 18:36, 27 February 2014 (UTC)

Oops, how did I screw that up? Yes, that's the pdf I was trying to point to. Spiel496 (talk) 17:36, 28 February 2014 (UTC)

The Back calculating and the extra feedback loop from the book should be essentially the same (except possible small delay of feedback). The extra loop may be even implemented in analog technique, not just digital. --Ulrich67 (talk) 18:35, 23 March 2014 (UTC)

Gradient controller

I would like to have a link in this article to the gradient controller, because the gradient controller comes without the typical disadvantages of the PI controller. Any suggestion where and how to do that? A comparison between PI controller and gradient controller (both in time discrete version) can be found on the page http://i-r-p.de/gradient.htm — Preceding unsigned comment added by 85.212.89.129 (talk) 18:03, 11 August 2014 (UTC)

That would be easy to do if there were a Gradient controller article. I'm not sure that gradient controller is notable enough to warrant an article - I'm not finding any independent references on it. ~KvnG 14:06, 14 August 2014 (UTC)

Since the person at that link is claiming that he developed and named the gradient controller, then it is not notable. Also, it is highly likely that a PID controller will accomplish the same result, or better. Robert - Northern VA (talk) 15:47, 15 August 2014 (UTC)

Yes, I have developed the gradient controller, and I am currently preparing a publication in a technical magazine. I will tell you as soon as this is done. You might easily take my comparison between PI controller and gradient controller and change the PI into a PID controller: you will then see that the quality difference between gradient controller and PID controller is the same, the gradient controller is much better. In the chosen example with a big distortion at the input of an integrating system, the additional D part of the controller is a neglectible improvement. — Preceding unsigned comment added by 85.212.64.17 (talk) 13:08, 16 August 2014 (UTC)

Feedback control variable always zero.

According to the equation for u(t), if the controller is actually working and the process is stable, and the error e(t) is zero, then u(t) will become zero. This is clearly not very sensible. If the cruise control is working properly, it doesn't mean that the throttle position is zero. If the central heating is working properly, it doesn't mean that the gas is off.Lathamibird (talk) 08:34, 8 September 2014 (UTC)

That would be correct from the formula, if it wasn't for the integral term. If the error between t=0 and now has been non-zero, then so will u(t) now. This is also correct in practice. For every control system, there is a value of the controller output that is the default or initial value. For the rudder angle this may be 0, as it can go + or minus. For the throttle, it may be 50% (which this formula does not handle as it is). After that, a PID system is an 'error-driven' system, so that there have to be errors, or there will be no action. In a long-term steady state, the integral term will gradually make the error approach zero. In all other cases, there will always be a residual error, which is driving the control output. For example, for a linearly ramping setpoint, the error will be finite and constant. --Nigelj (talk) 17:32, 8 September 2014 (UTC)

Would it be fair to say that this equation (discrete time implementation) is only valid if the I gain constant is non-zero? I was surprised to notice that testing the "P only" behavior of this implementation led to u[k] = u[k-1] + Kp(error[k] - error[k-1]), which results in a constant (not proportional) output when the error does not change. This is not at all what I needed or expected. Was there a statement in that section that should have alerted me to this strange behavior? Jrquant (talk) 17:48, 9 August 2023 (UTC)

Droop

Optimotowiki deleted the section describing droop. The edit comment says "Droop in control theory means something entirely different than what was originally written. This section should be deleted for clarity." I am not clear what was wrong with deleted droop description and am inclined to restore it. Kvng (talk) 14:42, 1 April 2015 (UTC)

What the droop section was referring to is most commonly called steady state error (SSE). The statements made concerning the relationship between proportional gain and what should have been called SSE were correct. Additionally, all of the previous discussions on this page concerning "droop" are valid if all parties are in fact referring to SSE.

Droop refers to a control scheme utilized in several industries wherein the error is automatically biased at the summing junction before the controller transfer function according to some pre-defined droop curve. It is used extensively in the electric power industry for speed control of prime movers and reactive power control of generators connected to the grid.

Though the original terminology used in the "droop" section may make sense from a layman's point of view, it is confusing and potentially harmful professionally for those intending to use the wikipedia page as an educational reference. Referring to steady state error as droop will cause an electrical or controls engineer to audibly groan.

Unfortunately, a cursory google search revealed a number of industrial websites that utilize the droop terminology. Note that these websites were found mainly in industries concerned with process control, which is telling. Neither offset nor droop is technically correct, as it ignores the fundamental mathematics, which state quite explicitly that there is a non-zero steady state error with pure proportional control. We should call it what it is, not make up new words that confuse the issue.Optimotowiki (talk) 18:12, 1 April 2015 (UTC)

How about we restore what you deleted and then replace all "droop" occurrences with "steady state error". --Kvng (talk) 23:29, 1 April 2015 (UTC)

Now almost a year after this discussion, I discover a dead intra-page link in History and applications, linking to the Droop section:

it was insufficient for dealing with a steady disturbance, notably a stiff gale (due to droop), which required adding the integral term

For now, I've simply deleted the parenthetical remark, since the remark makes no sense without knowing what steady state error (or droop or whatever you prefer) means, and that term is not explained. I'm noting this on the talk page though, since I'm not a big fan of removing the information. Preferably, there would be a section on steady state error so it can link to that. I'm not in the mood for writing that section, hence the deletion. Digital Brains (talk) 17:56, 25 February 2016 (UTC)

I think actually the better solution was to implement Kvng's proposal and tweak the deleted text to use SSE instead of droop, so I did that instead. There was one sentence on SSE added since, where previously the Droop section was; I removed that. It was on the border of incorrect anyway (as it says now, there are regulation systems with just P action and no SSE). Silly of me not to think of the obvious solution right away. Digital Brains (talk) 18:30, 25 February 2016 (UTC)

External links modified

Hello fellow Wikipedians,

I have just added archive links to 2 external links on PID controller. Please take a moment to review my edit. If necessary, add {{cbignore}} after the link to keep me from modifying it. Alternatively, you can add {{nobots|deny=InternetArchiveBot}} to keep me off the page altogether. I made the following changes:

• Added archive http://web.archive.org/web/20110608080946/http://ieeexplore.ieee.org/iel5/37/24267/01104827.pdf?arnumber=1104827 to http://ieeexplore.ieee.org/iel5/37/24267/01104827.pdf?arnumber=1104827
• Attempted to fix sourcing for //www.tcnj.edu/~rgraham/PID-tuning.html

When you have finished reviewing my changes, please set the checked parameter below to true or failed to let others know (documentation at {{Sourcecheck}}).

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 18 January 2022).

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—^{cyberbot II}_{Talk to my owner:Online} 17:30, 22 March 2016 (UTC)

Too much maths at the beginning

It really saddens me that this article begins by launching directly into complex maths.

To this retired Electrons Engineer, it indicates that the authors don't understand their subject and are too keen on showing off.

As Einstein said "If you can't explain it to a six year old, you don't understand it yourself".

I really wish that Wikipedia has a "No Maths until page two" policy.

It would greatly assist in making Wikipedia more accessible, as well as eliminating many of the pompous academics who infest this place Gutta Percha (talk)

It's only one equation, and the text makes perfect sense if you don't even glance at it. I don't know how to talk about proportionality, integration and derivatives without mentioning mathematics. Pompous, eh? --Nigelj (talk) 19:50, 17 December 2016 (UTC)

By NOT being able to talk without math you have no insite into how it works are its meaning to the real world. — Preceding unsigned comment added by 64.134.217.6 (talk) 15:28, 26 December 2016 (UTC)

^^^^^^

Agree that the maths section up front is unwieldy and detracts from the overall article. The definitions of K_p/i/d aren't well explained and the section itself is a dupe of the Controller Theory section below. Not sure how someone coming here to understand more about PID control (read: most readers) would find this part very useful.

As an example, a simpler and more concise explanation of PID theory than any section of this wiki page is found here: https://www.ni.com/en-us/innovations/white-papers/06/pid-theory-explained.html. But from a pragmatic standpoint, I'll be the first to admit that for an article that's 20 years old and has close to 1,000 edits, the idea of making this simpler and not more complex is probably a non-starter.

Dmccarty2 (talk) 17:40, 3 January 2022 (UTC)

Comments from IP

With all due respect, this PID definition is wrong, it perpetuates a very common mistake in PID control, especially with respect to the Integral term. The mistake can be Illustrated as follows:

1) Even though there is zero error, the Integral term will cause an output action. (Not desired)

2) The Integral is based upon previous errors, which are no longer relevant. (Not desired)

The correct PID solution is Proportional control can produce zero error ... if the controller is comparing the input to the output and through negative feedback and driving the Error to zero.

The correct PID term:

D term: Add changes (differentiation) to the steady-state INPUT to be combined in the summing Junction.

I term: Add changes (differentiation) to the negative (negative feedback) of the steady-state OUTPUT to be combined in the summing Junction. Integration is differentiation when combined across (around) negative feedback The output is connected to the zeroed-offset summing Junction with a very high gain and negative polarity (inverting).

Contribution:

P term: is the desired OUTPUT divided by the desired INPUT OR the ratio of the signal fed the summing Junction by the OUTPUT divided by the signal fed the summing Junction by the INPUT. When the negative OUTPUT of the parameter to control is summed with the INPUT (setpoint) The OUTPUT will satisfy the desired setpoint. {gain and offset errors are mostly insignificant in todays designs, otherwise can be handled separately, certainly do not want output based on previous, unrelated errors as described below}

I term: Integration slows down the output response as it approaches the correct/desired value. Useful to dissipate stored energy that would produce an overshoot.

D term, Differentiation speeds up the output response to an input so the output approaches the correct value sooner. Thank You -

If you disagree, that's ok, but this needs to be resolved, it has created a lot of pain for many people who blindly followed this teachings.

Thank You — Preceding unsigned comment added by 100.47.124.115 (talk • contribs) 00:49, 26 December 2016 (UTC)

You seem to be describing an op-amp-based circuit that implements pretty nearly the equations in the article. But you also have some differences, like making the D term differentiate the input rather than the error. I suspect that would not work as well; do you have a source we can cite for your version? Dicklyon (talk) 16:07, 26 December 2016 (UTC)

Totally agree with above, one of the problems is references are too highly regarded by Wiki. The vast majority of the PID references are by people who never had to create an actual controller ... Like the person who said "it is all about the equations", thus having no insite. We have designed over 150 products, that used PID, more than 45,000 major controllers in common use. Here is what PID is:

PID are the elements needed to control real world processes.

P is chosen to scale the process sensor to the processor actuator to reach the desired result. It also overcome gain reducing physical drag (friction) or electrical resistance.

"I" is chosen to absorb (dampen) the system's stored energy like from physical momentum or electrical capacitor/inductor . Therefore "I" prevents overshooting the desired output.

D is used to overcome energy robbing components like physical absorbing mass or electrical inductor/capacitors. Therefore D improves (speeds up) the system response time to achieve the desired output.

All theses OTHER interpretations are just wordsmith, twilding equations and expressions in to nonsense. They the keep quoting and referencing each other for years now. This has caused countless engineers and technicians to produce designs that kinda work, but require patches to get by. Please set Wiki, right! — Preceding unsigned comment added by 64.134.217.6 (talk) 15:24, 26 December 2016 (UTC)

We could describe it in such terms if you pointed us at a reliable source that does so. Dicklyon (talk) 16:07, 26 December 2016 (UTC)

Well Dicklyon, how would WiKi handle this?

Turns out majority of everything Googled Supports everything currently described by Wiki on this topic. But a quick check of my fellow Engineers verify that my 50 years of PID engineering follows what I wrote above.

The Wiki described PID is problematic, tremendously error-prone and difficult procedure that is adopted by the academians, and engineer so unfortunate to have been influenced by them.

So to your good question, what makes me a "reliable" source?

Maybe my 75 + US patents - (hundreds worldwide,  my four industry awards for a commercially successful products, or the fact that you can walk through hundreds of manufacturing plants in the US and see my products everywhere ... would suggest I'm worth talking to if not maybe a little "reliable".
 What do you think?  — Preceding unsigned comment added by 64.134.217.6 (talk) 18:45, 26 December 2016 (UTC) 

I'm sure you're a smart guy with a lot of knowledge to contribute; I have about 60 issued US patents myself, and some experience in this space, but when I edit wikipedia, especially when changing the work of others, I try to back up the new info with a published source or two. So far, I don't quite even understand what you're saying is wrong with the present treatment. Does your version have different equations? Can you show us? Dicklyon (talk) 20:54, 31 December 2016 (UTC)

What about this diagram? More like what you'd like to see, using feedback integrator for the deriviative path? Or this op-amp circuit? Dicklyon (talk) 21:00, 31 December 2016 (UTC)

Pseudocode still waiting

I know you've tweaked the Pseudocode a number of times (and it's only a Pseudocode). However, I believe there is problem with using the wait(dt) command. wait, pause, delay, all mean the same thing depending the language structure used your actual code - it to stop the code running for a period of time. Therefore, the current code will wait for a period of dt (to which has not been declared anywhere in the current code).

I believe you are using dt (delta time) as the length of time taken between each loop cycle - dt = start loop - end of code loop - then rest time count for next loop. In theory, what you have currently got (if you say that 'dt' is how long it takes between readings) is doubling the length of time between loop by adding delta_time to wait(dt) - wait for as long as it took to do the loop in the first place. very counter productive. A better suggestion (similarly suggested over on Ardunio and in the 'PID Ardunio Library' creators blog by Brett:- http://brettbeauregard.com/blog/2011/04/improving-the-beginners-pid-introduction/) is to do this...

previous_error = 0
integral = 0 
loop_time = 0
loop:
  begin_time = now
  error = setpoint - measured_value
  integral = integral + error*dt
  derivative = (error - previous_error)/dt
  output = Kp*error + Ki*integral + Kd*derivative
  previous_error = error
  loop_time = now
  dt = loop_time - begin_time
goto loop

Again this pseudocode nothing complicated and doesn't lean towards anyone structural format. So what does this do (besides what you are trying to achieve. begin_time = now means set the time to now (you can define this in your actual code to be in seconds, milliseconds or whatever time factor). loop_time checks the time again once the loop has completed its operation, then the loop goes back to the start as per usual. dt now becomes the time difference in the cycle and can be used back within the PID algorithm. what do you think? -- BrBarry (talk) 03:45, 11 April 2017 (UTC)

No, that's lame. The point is not to measure how long the code takes, but rather to run it every sample time, spaced dt. The wait(dt) clearly means that; the code execution is assumed to be instantaneous, and there are delays of dt between executions. The program takes dt as an argument. Where it says "waits until dt seconds have passed since start", it means to start dt later than the last time. Dicklyon (talk) 04:05, 11 April 2017 (UTC)

Maybe I'm missing something something but shouldn't line 9 from the pseudo code be "output = previous_output + Kp*error + Ki*integral + Kd*derivative"? If you don't take previous_output into account the output will keep bouncing up and down and never reach a steady state. Klaas1978 (talk) 15:23, 30 April 2017 (UTC)

No, in a real system error, integral and derivative will be fairly similar this time to last time around the loop and so the output will proceed reasonably. What you suggest would add another level of integration, I think. --Nigelj (talk) 15:31, 30 April 2017 (UTC)

PSD in the lead

This in the lead....

For discrete-time systems, the term PSD (proportional–summation–difference) is often used.[1]

Is confusing. Is it saying that PSD is not always called this, and what is PSD anyway, and how does it relate to this topic, and if it does relate then it should be in the main text and the lead should summarize if PSD is so well known that this is necessary. Suggest removal. Dougsim (talk) 14:21, 4 August 2017 (UTC)

Dougsim appears to have taken care of this. ~Kvng (talk) 14:50, 7 August 2017 (UTC)

Yes, thanks for the note, I was going to post here. There was no objection, so I went ahead. It should be noted that this article is getting a lot of hits, so it is important. I am just going to do some more work tidying up the historical narrative, which is a bit cryptic, as I think that is very pertinent to the subject, rather than of academic interest. There has been a lot of good stuff added by contributors recently at the end of article, so we have to make the first part attractive. Dougsim (talk) 15:40, 7 August 2017 (UTC)

'Increasing' the power output of the engine.

At the end of the second paragraph, the word "increasing" in the text "...increasing the power output of the engine" should be changed to "modulating". It's not just strictly increasing the power; that would be too easy. If that were the case, the cruise control would just floor it when the car came to a hill. 162.207.203.26 (talk) 01:28, 1 November 2020 (UTC)

You are right. Excessive flooring is inhibited by virtue of the three PID terms, which prevent excessive power application, but applies that power which is necessary to optimise the power correction. So it is modulating, but in the lead where some readers are new to control concepts, for this example increasing is clearer. Dougsim (talk)

s.t. Ti+Kp/Ki,Td=Kd/Kp?

Near end of article, what does "s.t." mean in "s.t. Ti+Kp/Ki,Td=Kd/Kp"? I looked "s.t." up. Apparently all that is Google doesn't know what it means either... 162.207.203.26 (talk) 04:23, 1 November 2020 (UTC)

"s.t." means "such that". It is often denoted as a : or | instead.

https://mathworld.wolfram.com/SuchThat.html

https://math.stackexchange.com/questions/934108/what-does-s-t-mean Jrquant (talk) 17:11, 9 August 2023 (UTC)

Pseudocode

We needs some help reviewing a disputed line in this code:

derivative := (error − previous_error) / dt

or

derivative := (error − previous_error) × dt

With the former, an editor has observed

(dt) appears to need to be equal to, or greater than one. I don't think it is in proper SI "seconds". It is probably an integer, like "samples" or "milliseconds". Assuming dt is in seconds and using dt=1.0/1000.0 gives extremely large derivative values which are many orders of magnitude larger than "proportional" or "integral".

The latter seems to work but it doesn't look right to other editors. ~Kvng (talk) 13:26, 3 April 2021 (UTC)

I changed the pseudo code to be in coherence with the discrete implementation above (commonly used). This code (using $u_{0}$=0) is equivalent to a basic one witch evaluates the PID equation using BD and summation except if you want to change Kp,Ki or Kd dynamically. Note that Kp Ki and Kd are supposed to be constant independent of time. Changing gain dynamically makes them function of time and change the behavior of a standard PID.

(The last person didn't sign, I'm someone else)

I think it's reasonable for the layman (as referenced in the sentence preceding the pseudocode) to assume that the algorithm would react naturally to small timesteps. It took me 3 days of troubleshooting before I stumbled across this talk page and figured out what was wrong. That being said, it would be strange for the code to assume something like that about its implementation. As a half measure, I added a note to the top of the Pseudocode section that alerts the reader of this edge case and lists a few potential solutions/workarounds. This leaves the pseudocode unaltered, doesn't add much bloat to the page (if any), and still alerts readers to the potential shortcomings of the pseudocode. That being said, wouldn't this mismatch also affect the integral component? Jmortiger (talk) 20:12, 19 December 2022 (UTC)

On top of this issue, I was confused about the first presented pseudocode. As mentioned above, they list the derivative as :derivative := (error − previous_error) / dt . However, looking at both the following pseudocode and the preceding discrete formula, this appears to be incorrect. If I'm not mistaken (which I very well may be), the pseudocode would need to store not just the prior error, but the one before that, and the derivative would look more like this derivative := (error - 2 * previous_error + error_before_last) / dt I haven't done any rigorous testing for this myself (yet), but am I right here? The following pseudocode defines the 3 terms as

(Kp + Ki*dt + Kd/dt) * error[0]

(-Kp - 2*Kd/dt) * error[1]

(Kd/dt) * error[2]

This directly shows that the derivative is related to the error before last, but the first pseudocode doesn't even store it. Plus, the (-Kp - 2*Kd/dt) * error[1] matches with the assumed - 2 * previous_error. The discrete formula also seems to corroborate this. Am I missing something? (Sorry for any mistakes, first time) Jmortiger (talk) 20:12, 19 December 2022 (UTC)

Poor wording

"Using proportional control alone will result in an error between the setpoint and the actual process value because it requires an error to generate the proportional response. If there is no error, there is no corrective response" - this is almost back-to-front causality. If there is no error, you don't NEED a corrective response.

I changed the last sentence to The controller cannot adjust the system unless there is an error present. Does that help? ~Kvng (talk) 14:50, 22 February 2022 (UTC)

Mathematical explanation of integral term is insufficient.

In this article, the integral term is calculated using a definite integral between 0 and t, and uses the letter tau in place of t. It doesn't seem to follow any common uses of tau (as denoted on its Wikipedia article).

From Controller theory, Integral term: "The integral in a PID controller is the sum of the instantaneous error over time and gives the accumulated offset that should have been corrected previously." The definite integral between the beginning of measurement (0) and current time t of e(t), read as a function e that equals the value of error at time t, should calculate to the area between curve e(t) and axis t, which is equal to the sum of all error values, if my understand of definite integrals is correct. If it is, then why does the notation use tau instead of t? If I'm incorrect, then the use of tau needs elaboration, both for understanding the fundamental operation and to make the function practically applicable.

It'd also be nice to have some elaboration on exactly what '0' is supposed to mean. 2A02:AA7:460A:9E83:F435:2745:26C4:3A80 (talk) 12:19, 7 September 2022 (UTC)