Talk:Proportional–integral–derivative controller

message: 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)
thread_title: Removed this comment from the article itself

message: 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)
replies: text: 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)
thread_title:  No definition of "Process Gain" 

message: 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)
thread_title:  Kessler's Symmetric optimum principle 

message: 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)
thread_title:  Helmsman example picture 

message: 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)
replies: text: 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)
replies: text: 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)
replies: text: 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)

text: 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)
replies: text: 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)
replies: text: 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)

text: 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)
replies: text: 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)
replies: text: 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)
replies: text: 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  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)
replies: text: 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)

text: 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)
replies: text: Looks good. Q Science (talk) 18:22, 2 April 2012 (UTC)
thread_title:  proportional versus integral 

message: 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)
replies: text: 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)
thread_title: Velocity Form Pseudocode

message: 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)
thread_title: Archived old discussions

message: 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. 
# 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.
# 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.
# 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.
# 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. 
# 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.
# 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)
thread_title:  Pseudocode reset 

message: 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)
thread_title:  Integral windup 

message: 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)
replies: text: I found O'Dwyer and have added it to the Further reading section. ~Kvng (talk) 14:00, 14 August 2017 (UTC)
thread_title:  Alternative nomenclature 

message: 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)
replies: text: 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)
replies: text:  +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)
thread_title:  Replacing the integral function by a model based part 

message: Last paragraph about "variable voltages" seems totally unrelated.
Can somebody please check?
Thanks!
Itto Ogami (talk) 05:49, 2 June 2013 (UTC)
replies: text: 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)
thread_title:  History and applications 

message: 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)
thread_title:  Image showing effect of changing Kp is incorrect 

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

message: 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)
replies: text: 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)
replies: text: 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)
replies: text: 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)
replies: text: 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)
replies: text: 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)
thread_title:  Derivative control 

message: 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)
replies: text: 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)
replies: text: 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)
replies: text:  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)
replies: text: 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)
replies: text:  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)
thread_title:  Integral windup 

message: 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)
replies: text: 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)
replies: text: 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)
replies: text: 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)
thread_title:  Gradient controller 

message: 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)
replies: text: 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)
thread_title:  Feedback control variable always zero. 

message: Hello fellow Wikipedians,
I have just added archive links to  on PID controller. Please take a moment to review my edit. If necessary, add  after the link to keep me from modifying it. Alternatively, you can add  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 ).
Cheers.—cyberbot IITalk to my owner:Online 17:30, 22 March 2016 (UTC)
thread_title:  External links modified 

message: 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)
replies: text: 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)
thread_title:  Too much maths at the beginning 

message: 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)
replies: text: 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)

text: 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)

text: 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)
replies: text: 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)

text: 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)
thread_title:  Comments from IP 

message: 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)
replies: text: 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)
replies: text: 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)
replies: text: 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)
thread_title:  Pseudocode still waiting 

message: 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)
replies: text: appears to have taken care of this. ~Kvng (talk) 14:50, 7 August 2017 (UTC)
thread_title:  PSD in the lead 

message: 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)
thread_title:  'Increasing' the power output of the engine. 

message: 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)
thread_title:  Pseudocode 

message: "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  Does that help? ~Kvng (talk) 14:50, 22 February 2022 (UTC)
thread_title: Poor wording

message: 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)
thread_title:  Mathematical explanation of integral term is insufficient.