PID Settings & Cycling Question

Discuss tuning PID coefficients to maximize system efficiency.
Post Reply
CJKogut
Posts: 14
Joined: Sat Feb 19, 2011 5:58 am
Bot?: No

PID Settings & Cycling Question

Post by CJKogut » Thu Mar 24, 2011 12:14 pm

If I set my sample period to 20, output period to 20, and Min output % to 50, then I should have a maximum cycle rate of 10 seconds on and 10 seconds off, right?

What effect would shortening the sample period have if the other settings are not changed?

User avatar
ECC
Posts: 676
Joined: Fri Sep 12, 2008 12:29 pm
Bot?: No
Contact:

Re: PID Settings & Cycling Question

Post by ECC » Thu Mar 24, 2011 2:25 pm

Changing Min output % will give you a minimum cycle rate of 10sec on 10sec off. If the PID (or duty cycle control) want less than 50%, the output will be off.

Shortening the sample period will affect how often the temperature is read, and hence update the pid output. So if the PID says it needs 60%, this will only change once every sample period. Shortening this affects system response time, but is separate from the output pulse width settings.

You can think of it in two steps. 1) Updated the desired output% (pid sample period). 2) Take desired output% and control outputs (output pulse width period, min/max settings)

CJKogut
Posts: 14
Joined: Sat Feb 19, 2011 5:58 am
Bot?: No

Re: PID Settings & Cycling Question

Post by CJKogut » Fri Mar 25, 2011 12:20 pm

Thanks. I think I've got it. When I said "maximum" I was referring to how fast my burner would try to cycle on and off. For example, if it is currently clicking on and off faster than the gas valve is designed to operate, and I wanted to set it so that the burner would operate for a MINIMUM of 10 seconds before shutting off, and then wait at least 10 seconds before being able to re-ignite, I believe that my settings originally posted should do the trick. Would you agree?

Sample Period 20, Output Period 20, Minimum Cycle 50%, Max Cycle 100%

User avatar
ECC
Posts: 676
Joined: Fri Sep 12, 2008 12:29 pm
Bot?: No
Contact:

Re: PID Settings & Cycling Question

Post by ECC » Sun Mar 27, 2011 7:33 pm

Yes, those settings will give you a minimum of 10s on, however it won't ensure you wait 10s until the next firing. For example, if the PID wants 90%, you get 18 seconds on and 2 off.

You may want to look into differential temperature control, with a (for example) 1 degree temperature swing.. This would give you a temperature deadband/hysteresis that would ensure you don't switch too fast.

CJKogut
Posts: 14
Joined: Sat Feb 19, 2011 5:58 am
Bot?: No

Re: PID Settings & Cycling Question

Post by CJKogut » Thu Mar 31, 2011 4:55 am

I tried a simple 2 degree differential before moving to PID. I had like a 6-8 degree overshoot. Perhaps I should mention that I am heating 100 gallons of water with a 300 plus KBTU burner, which makes an overshoot something that can take a while to correct, lol. I'm getting a bit over 3 degrees temperature rise per minute with my burner currently, and although I have the kettle whirlpooling slowly, it takes 1-2 minutes for the thermistor to get a stable, even reading. By that time, I get the overshoot. I may turn down the burner in the future, and I have yet to take multiple temperature readings in the tall kettle to see if there are striations.

I tried my new PID settings yesterday and the system seems to fire desirably, but I still got a 2.5 degree overshoot. I may adjust the settings a couple of more times, but this seems like a problem I'll be able to work with overall. I may find the 2.5 degrees just the right overshoot when I go to pre-heat the mash tun, and I may just make corrections with the heat exchanger.

User avatar
ECC
Posts: 676
Joined: Fri Sep 12, 2008 12:29 pm
Bot?: No
Contact:

Re: PID Settings & Cycling Question

Post by ECC » Mon Apr 04, 2011 1:56 pm

Now that's some serious fire power. Literally! :) Sounds like the PID just needs some tuning. My advice is to get to know your pid terms, and how they affect your system. The best way is to run a few water tests and open up the Datalog page and click on the PID Controller Display, which will give you data on all of the terms.
http://www.embeddedcontrolconcepts.com/ ... er_Display

Are you using the default gains, P=20 and I=0.5? I don't worry too much about D, as you'll see when you look at the terms as the system is running. The other notable setting is Imax, or the maximum cap on the integral term, defaulted to 100.

As you're ramping up, P will be king because the the error (difference between setpoint and actual temp) is high. With a gain set at 20, it will only start backing off when you get to an error of 5deg. 5deg*20=100%, 4deg*20=80%, etc.

Also, as you're ramping up, integral error will be maxed out at 100 (iMax) because its been a big error for a long time. With its gain (0.5*100) this gives you 50% of your output, and this is added to the pTerm above. So when you add together the pTerm and iTerm, it means that the PID output is going to be 100% until you're 2.5 deg below your setpoint. Then start backing off to 50% until you hit the setpoint, at which time the negative error will start reducing the iTerm over time.

From your description, and assuming you're starting with the default PID gains, here's what I would suggest:
  • Speed up your PID Sample Period. If your getting 3deg/min, 20sec seems pretty slow. Keep the Output Period the same, which will give you the switching characteristics that you want, but by speeding up the PID Sample Period you will get faster system response. Try 5sec and see how that works. You may want to do this first before trying to tune the gains, because this will affect how fast the integral term is reduced as soon as the setpoint is hit, and that may be one of the contributing factors to the overshoot.
  • Lower your P and I gains. Not sure which one would help best.. But you can think of it this way... Since you are seeing a 2.5 deg overshoot, it makes sense that you'd like to start backing off output when the temperature error is 2.5 degrees less than what it is today. All of these settings are interrelated, but my first instinct is to lower iTerm by reducing the iGain or iMax. In your situation, you might even be able to get by with setting iGain to zero and totally get rid of the iTerm all together. Particularly if you're not worried about long term error, i.e., you heat the water and transfer it out right away..
What would really help is a screenshot of the datalog with the following things traced: Temp, Temp Setpoint, and Output. And maybe a list of the pid terms as you approach the setpoint, hit the setpoint, and then overshoot. Or any subset of those, whatever you can grab.

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest