PID Control - analog input, digital outputs

[VeeJay]

Will Integral error ever be zero? From what I see, it keeps adding and if my setpoint is set for a long period of time, output will sum up because of integral error and my PWM duty cycle which is directly dependent on output of PID will trigger a response. Would you think a proportional control will suffice in my system? Considering that my error will never be zero but within a deadband.

[nathand]

---

@VeeJay wrote:

Will Integral error ever be zero? From what I see, it keeps adding and if my setpoint is set for a long period of time, output will sum up because of integral error and my PWM duty cycle which is directly dependent on output of PID will trigger a response. Would you think a proportional control will suffice in my system? Considering that my error will never be zero but within a deadband.

---

Yes, it's possible for the integral value to be zero, but only by integrating out the error.  So, if you have some negative integrated error, you'll need a corresponding positive error (overshoot in the opposite direction) to cancel out the accumulated error.  I'm usually working with heater systems in which a small integral value is necessary to maintain temperature due to heat loss to the environment, but position control systems don't have this problem.  I don't know if proportional control alone will work for your system - you'll have to give it a try.  I appreciate your detailed explanation of your system (sounds rather complicated) but I can't make any educated guess at the system dynamics.

If you do try using integral control you'll want to start with a very small gain, which actually means using a large value for the integral time if you're using LabVIEW's PID toolkit.  The value is time in minutes, so a longer time means slower integral response, which is what you want.

The PID VI has a "reinitialize" input.  You can use this to clear the integrated error and reset the PID whenever you're within the deadband region.  You might also try running two separate control loops, one for the motor and the other for the valve, since you will probably want different tuning parameters for each one.  You will want to use a negative proportional gain for one and a positive gain for the other, so that they'll act inversely from each other.  This would also let you set separate output limits for the valve and motor.  If you know that you don't want to pulse the motor, you could use simple on-off control for the motor and PID for the valve.

[VeeJay]

Thanks for that detailed explanation! When you say two control loops, do you mean two parallel loops? I am intending using different control strategy for motor and valve. Value, it will be easier for PID but not for Motor because it is digitally triggered as opposed to analog.

Regarding negative/positive proportional gain, wouldn't error= SP-PV take care of the sign? Also, how does integral error get calculated? Is it (previous error+current error)/2)*loop time *Prop gain/Ti ?? What is the use of dt(s) in PID function?

And i saw that there is a reinitialize line in the PID functin. WIll try and implement that. I will be making my nth trial today and will post the clean vi for your thoughts. Thank you so much for guiding me. PID is very abstract if you havent dealt with it and implementing it in LabVIEW is more than a cup of tea. There aren't many resources out there explaining PWM PID control.

V

[nathand]

---

@VeeJay wrote:

Thanks for that detailed explanation! When you say two control loops, do you mean two parallel loops? I am intending using different control strategy for motor and valve. Value, it will be easier for PID but not for Motor because it is digitally triggered as opposed to analog.

Regarding negative/positive proportional gain, wouldn't error= SP-PV take care of the sign? Also, how does integral error get calculated? Is it (previous error+current error)/2)*loop time *Prop gain/Ti ?? What is the use of dt(s) in PID function?

---

I mean put the controllers in parallel, although you will probably want to put them inside the same LabVIEW while loop since they will both get the same process variable from the analog input.

The reason for using one positive gain and one negative gain is that when lowering the device you'll want a positive error to cause a positive output, and when raising the device you'll want a negative error to cause a positive output (or perhaps it's swapped in your actual system).  You want the two controls to act opposite each other, not in the same direction.  Or, looking at it differently, a positive error should turn one system off and the other on; if both gains have the same sign then a positive error would turn both of them on.

The PID manual I mentioned earlier in this thread explains how the integral error is calculated.  I think you have it right, but check there if you need to be sure.  If you're writing your own PID, as with any numerical integration there are several ways to do it depending on how accurate and complicated you want it to be.

The dt(s) input is there because the integral and derivative terms both include time units, so for accurate results the PID needs to know what the time increment is.  If you run your loop at 1s and set the dt input to 1s, it runs in real time.  If you run your loop at 100ms but keep the dt at 1s, you'll get exactly the same sequence of outputs in 1/10th the time.  This is useful for simulation, where you want to see what the output will be using a model that runs faster than the real system.

[VeeJay]

Hi Nathan,

Currently,I am not using dt(s). you think I should include that? If I dont, what time does it take? I don't quite understand its use. If I have Ti for eg as 3 seconds (0.005 min) then, how is integral portion calculated? the integral equation requires a 't' and what is that valuve? i know that an intgral time of 3 seconds will work the system in a way to get it to target position within 3 seconds, but the output of PID doesnt refect that. THe errors slowly add up past 3 seconds until my output is 100% maybe 30 seconds later. Would you be able to rephrase your last explanation? THanks!

V

[nathand]

---

@VeeJay wrote:

i know that an intgral time of 3 seconds will work the system in a way to get it to target position within 3 seconds, 

---

This is completely incorrect.  The integral time is the time it takes for the integral response to equal the proportional response.  Let's say you are using proportional control alone, you have a setpoint of 5V, a process variable of 4.5V, proportional gain of 0.5, and that you have reached a steady state with a constant offset of 0.5V so your output is at 0.25V.  If you add in integral control with an integral time of 2 minutes, the output will slowly increase, and at 2 minutes the output will be 0.5V (0.25V from the proportional component + 0.25V from the integral component).  This situation of course assumes that there's no change in PV as the output increases which isn't generally the case, but it explains the idea behind integral time.

---

@VeeJay wrote:

Hi Nathan,

Currently,I am not using dt(s). you think I should include that? If I dont, what time does it take? I don't quite understand its use.

---

You probably don't need dt.  It is useful if you want to run the PID as though it was running at some rate different than the actual loop time.  Let's say you have a file of data from an experiment, recorded at one point per second, and you want to see what a PID loop would do if you fed the experimental data as the process variable.  However, there's no need for you to wait 1s between calculations, since all the data is already available.  So you would set dt to 1s, but run the code as fast as it can read data from the file.  The same idea applies if you have a software model of your system that can run faster than the real, physical system.  If you don't specify dt, it uses the actual time between calls to that instance of the PID vi.

---

@VeeJay wrote:

If I have Ti for eg as 3 seconds (0.005 min) then, how is integral portion calculated? the integral equation requires a 't' and what is that valuve?

---

The integrated error is not affected by the integral gain; the error always accumulates the same way, and then it is multiplied by the integral gain before being added to the output.  Going back to the example in the first paragraph of this post: let's say your loop rate is 6s.  Every loop cycle, the accumulated error increases by 0.5V * (6s/60s) = 0.05V.  Integral output = proportional gain / integral time * integrated error.  After the first loop cycle (6s), the integral output is 0.5 / 2 min * 0.05V = 0.0125.  After 10 loop cycles (1 minute) the accumulated error is equal to 0.5V.  After 20 loop cycles (120s = 2min), the integral output is 0.5 / 2 min * 1V = 0.25, demonstrating again that the integral time is the time necessary for the integral output to duplicate the proportional output.

[VeeJay]

Wow, that explanation blew my mind.... It is the perfect explanation I was expecting for.. Maybe you should teach a course on PID... I am so getting where I need to in my understanding. I hope you dont mind me asking so many questions.. This is a difficult topic to understand and especially if you have limited practical experience in PID.

So, I get now that the PID intergral portion matches the Proportional output within Integral time . I implemented in LaBvIEW and I understand that completely. Now, what is that trying to tell the system? I am trying to understand that. Assuming that PV does not reach the SP in your example, for 2 minutes, there has been no action. But, now we have PID output to be 0.25+0.25=0.5V. My SP and actuator are different correct? I am going to add this to my actuator, which already receives its input from SP, so we have here efffectively, SP+PID output to the actuator, but SP doesn't change. Is this correct way of understanding?

Step 1: SP->actuator : go to 5V

Step 2: PV doesnt go to 5V but 4.5V

Step 3: PID output tells actuator to go to 5+0.5=5.5V, but SP still is 5V.

and so on

So if a deadband is used, and we keep the system going, can the PID output keep accumulating such that it may go to infinity, if there are no bounds?

Thansk! 🙂

V

[nathand]

---

VeeJay wrote:

So, I get now that the PID intergral portion matches the Proportional output within Integral time . I implemented in LaBvIEW and I understand that completely. Now, what is that trying to tell the system? I am trying to understand that. Assuming that PV does not reach the SP in your example, for 2 minutes, there has been no action. But, now we have PID output to be 0.25+0.25=0.5V. My SP and actuator are different correct? I am going to add this to my actuator, which already receives its input from SP, so we have here efffectively, SP+PID output to the actuator, but SP doesn't change. Is this correct way of understanding?

Step 1: SP->actuator : go to 5V

Step 2: PV doesnt go to 5V but 4.5V

Step 3: PID output tells actuator to go to 5+0.5=5.5V, but SP still is 5V.

and so on

So if a deadband is used, and we keep the system going, can the PID output keep accumulating such that it may go to infinity, if there are no bounds?

---

You're not quite there yet.  If you don't mind my asking, where are you getting your ideas?  Have you looked at any of the examples supplied with LabVIEW, or a textbook on controls?  In most systems, setpoint is an input to the PID, and the only output to the actuator is the output from the PID.  If you already know what the output should be, you don't need a PID loop.  The exception is systems with some sort of feed-forward control that use the PID to do fine-tuning, but I don't think that's what you have, or want, here.  In your Step 1, how would you determine that you want the actuator to go to 5V?  With PID, it's the proportional gain that does that for you, approximately.  When the PID tuning is perfect, as the setpoint changes, the integral value accumulates to the point that when the error reaches zero the accumulated error times the integral gain is exactly the right amount to maintain the setpoint (at least in a system such as temperature control that requires a constant output).  In a position control system you might get a small amount of overshoot or undershoot as you cancel out any accumulated error.

If you use some sort of deadband, and the PID doesn't know about it, then yes, it is possible for the error to accumulate indefinitely.  This is one case of what is known as integral windup, and needs to be handled.  In my opinion the simplest way to do this with the LabVIEW PID is to set the reinitialize input to true whenever the process variable is within the deadband.

At some point you will also need to understand PID tuning - the process of finding appropriate gains to get good control of your system.  I cannot take the time to answer all of your questions on this subject, there are many resources available in libraries and the internet on the topic of PID tuning.  The typical place to start is with the Zeigler-Nichols method, either open-loop or closed-loop depending on your system.

[VeeJay]

Thanks Nathan! I guess I am over complicating things. I have read all these material over the last few days and it has propped up so many questions in my head. My mind is getting all these stupid ideas. That's all 🙂 I will read them again, maybe some repetition will trigger some better understanding. I have a solution in mind. I will implement it and post the vi. Maybe you can take a look at it. Thanks!

V

[RavensFan]

Nathan,

Thanks for the clear explanations on PID loops.  I think it gives a much clearer, practical understanding of the P I and D gains than any textbook or industry white paper or article I've ever seen.

I've seen that situation withe the integral windup.  I wonder why the PID algorhithms or the toolkit doesn't already do something to handle that situation automatically.  It seems to me that the integrated error should be automatically reset anytime the setpoint value changes.