PID and slow changes

Discuss tuning PID coefficients to maximize system efficiency.
Post Reply
Danimal39
Posts: 7
Joined: Mon Oct 25, 2010 9:35 am
Bot?: No

PID and slow changes

Post by Danimal39 » Wed May 11, 2011 9:41 am

Perhaps not the best title, so I'll try to explain the best I can. So, we have a 13BBL fermenter with 5BBL of beer in our fermenter right now. We are lagering and want to crash the beer slowly, something like 5F/day. When we did our calibration batch with the default PID settings, we had trouble stopping the crashing where the beer would get much colder/day than we wanted. We'd get about -1F every 2-3 hours, and when we hit our setpoint, the ECC would close off the glycol, but due to the temperatures on the tank itself, the beer would continue to cool.

We also want to be able to keep our fermentation temps stable during primary fermentation and cold conditioning. The only thing we've changed so far is the sample and output periods to 120 seconds. Question is, what should we be trying to change to get our temps crashing slowly? We need a consistent 5F/day, so ~-1F every 5 hours would be ideal. Our PID settings are at default, BTW, and works well with keeping a stable temp during fermentation. Thanks!

Danny Wang - Overlord/Head Brewer
CAUTION: Brewing Company - Denver, CO
970.315.BREW

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

Re: PID and slow changes

Post by ECC » Fri May 13, 2011 12:23 pm

Overshoot! Or rather undershoot in your case. Common problem, caused by a PID that needs to be tuned. I quoted a reply from this thread, since some of it is applicable. I need a little more info. How much are you undershooting? Does the temp settle back to the setpoint after the undershoot, and if so, how long does that take?
ECC wrote: 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.

Danimal39
Posts: 7
Joined: Mon Oct 25, 2010 9:35 am
Bot?: No

Re: PID and slow changes

Post by Danimal39 » Sat May 14, 2011 8:59 am

So we're over(under)shooting by 3-4F, and yes, the temp does go back up after the undershoot, and since it's such a large amount of liquid, it took about 15 hours to get back to where it needed to be. Example - on one of our states we have the temp going from 66-61F after diacetyl rest. I went to 61F in about 8 hours, then the temp went all the way down to 56F before it started going back up. It took 15 hours to get to 56F, and another 15 to get back up to 61F. And thanks for the reference from the other thread, I'm wrapping my head around it still. :)

I'll see what I can do with a screenshot of the undershoot. We should start to crash in a couple of days. I'm thinking I'll start by adjusting my sample period? Since the temp changes so slowly, my thought would be to turn up the periods so that I'm not picking up the small changes, like the .1F changes. And then, try bringing up the P and I gains? Thanks for you help!

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

Re: PID and slow changes

Post by ECC » Sun May 15, 2011 8:02 pm

One more question.. When it undershoots, does the BCS turn the glycol pumps off as (reasonably) soon as it hits the setpoint, or do they keep running?

If its the former, we'll look more into better PID coefficents to make it turn off before it hits the setpoint, due to system lag. If its the latter, its probably caused by too long of a PID cycle time (my recommendation here is 60sec, and set Imax to 50 for a good starting point to reduce windup).

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest