Thermostats hard on keezer?

[AussieBrewerInColorado]

Evanos, hope you got your answer because this has gone way off topic!

 

[motobrewer]

So many accusations...

what accusations? You are the only one making them, starting off with blasting catt.

I figured as much after a few posts. It is unfortunate you don't exhibit the same zeal regarding cat22's post as you do mine, especially after initially appearing to validate his approach.

I don't disagree with cat's method. works for him. isn't that what matters?

"after a few posts"? I agreed with you right after your response to my original post. then you started blabbing about free lunches, tetrinanry effects, other random garbage you don't seem to understand.

Your "deadband" is 0. Does that even count as a "band"?

I'm not saying that's the way I'm doing it.

Lets be clear, my controller is NOT being controlled by the min on timer. The fridge is on for at least 5 minutes, as is shown by my data.

Those most likely have proper reset, error, and exception handling. A home baked board running freeware, or worse a PC with an MS product without all the crapware disabled, running my code with only minimal testing, validation, and fail-safing, is what I was referring to. I would have thought that would be fairly obvious, since I talked about coding my own loop.

lol! ok, i thought you were talking about a normal hobbyists board, not a ball of solder with a USB drive with your app shoved into the middle. You're right, when people talk about custom-welded brew rigs, i should just assume they are really put together with a soldering iron.

You are getting really nit-picky here. Do I need some more /'s next time? I stated that a "PID controller" or even "PID" has become a generic term for a controller using a PID control loop, usually along with other control mechanisms as well. I also apologized, and said I should have been more specific. And, I also stated it was meant to be a joke about being to anal about temps, which I thought would have been caught the first time.

i don't really care what you were joking about, you talked about controlling a fridge with a PID and I said that's not possible directly. that is all i said.

I am sure he can fairly quickly think of a few ways to process the output to control overshoot in a fridge. I know I did.

when??

From what I have read, PIDs are good for controlling overshoot, especially when tuned for a given system. Valves are continuous, but the flow is not linear, that is why there are parameters to account for this. It may be possible to take advantage of those to control a fridge, although an intermediate circuit may be needed, and yes, it would not be linear (or is it continuous?). It has to turn something on and off at some point based on a linear (continuous?) signal. It would control overshoot, better than using a straight temp differential approach, while using a PID controller, which is all I ever claimed.

PID's can be tuned for many various applications; fast response, minimum oscillations about the setpoint, as low as zero overshoot, etc. obviously, there are tradeoffs.

i've already talked about how some people take a PI and send it to a state selection box, then send it to a staged output. very hard to tune and not very reliable

I was just using the names for the control options available on many PID based controllers. They are usually marketing terms to some extent, and usually have other methods under the hood. I am not certain.

I am not sure you CAN buy a "PID on a chip", but why wouldn't you be able to. Seems like a reasonable thing to fill a chip up with a PID's magic smoke, and sell it. Any software or microcode (and that is not just software for microcontrollers), can be burned into the chip.

auto-tune is a method of turning the gain constants of a PID loop real-time in order to dial in error. PIDs are available on chips, you can buy various companies implementation of a PID on a chip.

I don't have DAQ capability, so do not have hard evidence. I have only used my ferm chamber for ale temps, so no comparable data to yours anyway. It may only cycle once a day when ambient is near the SP. I need to get my other controller wired up for my "new to me" and free keezer, after I get a new PTC start relay for it (casualty of excessive cycling from running empty, no doubt). Just using a standard fridge for serving now.

so, you have absolutely no evidence about anything you're saying. awesome.

You are using time based control whenever the min on time is in play. There is a name for that method, but I can't think of it.

uh, no i'm not. my controller is always on or off longer than the safety min timers. edit (i missed a word): well, yeah i'm using "time based control" whenever the timers is in play - so is everyone. but, it's never in play. glancing at my data i thought it might be, taking a harder look at it shows it's not.

If you read my previous post, I suggested that you might get acceptable temp control, no freezing, and less cycling, by damping the sensor. The amount of damping is limited, in your case, by the hysteresis caused by your keezer's thermal inertia, for lack of a better term. Something close to the same thermal response as the bottles of your beer that you are worried about freezing would be a good starting point. What would it hurt? You would know in a couple of hours where it is headed.

I'm already getting acceptable temp control, and an acceptable level of cycling. Until someone comes on and says their freezer only cycles once a day (with actual evidence) and a "realized" deadband of less than 2F, i'm pretty content with what I have.

i threw my controller together last minute, just wanting to get my fridge running. turns out, it works really well. So I haven't messed with it.

If I don't specify everything (with caveats), you seem to call me out for generalizing or not including some piece of minutia, including in this post.

when?!? you came on here with things you half understand, proven with zero data. then you instantly railed on cat for sharing something that works really well for him. then railed on me because i don't wanna freeze my bottles.

not sure when my next lager will be, but I'll be sure to control to the thermowell sensor and record data.

 

[motobrewer]

I thought Johnson communications was a subsidiary of Johnson Controls. I checked, and it is not.

nope. and, for clarification, I didn't mean to say that to throw it around, i just wanted to clarify what I meant by "our controllers"

 

[evanos]

Evanos, hope you got your answer because this has gone way off topic!

What I've gleaned and will probably try is this:

Buy a chest freezer.

Buy a digital controller a la http://www.northernbrewer.com/brewi...on-controls-a419-digital-temp-controller.html

Set the operating range to 2-4 degrees F.

Place probe in jug of water.

Put beer in fridge.

The end.

 

[cwi]

For a cheap controller ($25) that only requires some basic DIY, you can check out the ebay aquarium controller threads. They are dual-stage and can also simultaneously control a heater. Handy for times when ambient is lower than your set point. Not sure if that would be useful in Tucson or not. Maybe for fermenting ales in the winter.

 

[djsethall]

What I've gleaned and will probably try is this:

Buy a chest freezer.

Buy a digital controller a la http://www.northernbrewer.com/brewi...on-controls-a419-digital-temp-controller.html

Set the operating range to 2-4 degrees F.

Place probe in jug of water.

Put beer in fridge.

The end.

Love the answer. Simple

 

[Yuri_Rage]

Please stop bickering. Had the OP read the entire thread, he would be thoroughly confused and/or exhausted. It appears he gave up on your arguing quite a few posts back.

I tired of reading the argument, but you seem to be after lab precision when the OP only wants to keep some kegs cold for serving. If you want to discuss fine temperature control for yeast culturing or fermentation, please start a thread of your own.

 

[AussieBrewerInColorado]

here here Yuri.

 

[evanos]

Please stop bickering. Had the OP read the entire thread, he would be thoroughly confused and/or exhausted. It appears he gave up on your arguing quite a few posts back.

I tired of reading the argument, but you seem to be after lab precision when the OP only wants to keep some kegs cold for serving. If you want to discuss fine temperature control for yeast culturing or fermentation, please start a thread of your own.

Well, I actually read the entire argument during my Soil Fertility class (yeah, it's that boring). I've just tried to pick out what makes sense as I'm not going to be setting up an entire digital brewery, and I'm not an engineer/physicist/probrewer/etc. But, the info is interesting for sure.

 

[cwi]

There is always unsubscribe.

I was, and still am, advocating the simple and easy hands off approach to using a controller. The set and forget approach that doesn't require a bunch of tinkering.

I will be posting at least once more, just for kicks. The hanging curve balls that keep appearing in front of me are too tempting.

 

[cwi]

what accusations? You are the only one making them, starting off with blasting catt.

You might want to go back and read the thread again, in sequence. Catt22 "blasted" ME first, then you followed by stroking him with "Catt speaks the truth" and "Catt is dead on".

I don't disagree with cat's method. works for him. isn't that what matters?

Except that he foists it as the BEST method FOR OTHERS, and AS A FACT based on his "testing". Along with telling anyone who disagrees with him that they don't know what they are talking, and that science doesn't prove anything. Manually adjusting temps on a daily basis is not what people expect from a ferm temp controller.

"after a few posts"? I agreed with you right after your response to my original post. then you started blabbing about free lunches, tetrinanry effects, other random garbage you don't seem to understand.

If you look back, in the same post, you agreed that controlling to the vessel was better, then a few sentences later you disagree.

Quote:
Originally Posted by cwi
Your "deadband" is 0. Does that even count as a "band"?

I'm not saying that's the way I'm doing it.

note, my control strategy is just "on at >41F, off at <41F". i have a 2 minute "min/on min off" restriction on that output.

41-41= 0 ?????

Lets be clear, my controller is NOT being controlled by the min on timer. The fridge is on for at least 5 minutes, as is shown by my data.

QFT

You're right, the freezer seems to be held on at some instances by the min timer I selected. Most times it runs longer than 2 minutes tho.

??????

Try using your strategy for ferming at ale temps, or in colder ambient temps, and see how many "min on time" events occur.

lol! ok, i thought you were talking about a normal hobbyists board, not a ball of solder with a USB drive with your app shoved into the middle.

I wasn't worried about soldering issues so much as kernel, library, and processor interaction errors causing it to lock up. I would think those issues would come to mind. Apparently, only balls and shoving thumb drives in places is what comes to yours.

You're right, when people talk about custom-welded brew rigs, i should just assume they are really put together with a soldering iron.

I will have to try welding the next time I need to attach a ball grid array package to a PCB. Sounds much sturdier. Thanks for the tip.

i don't really care what you were joking about, you talked about controlling a fridge with a PID and I said that's not possible directly. that is all i said.

I was talking about a controller with PID, and other capabilities, and you know it, or should have. But, I guess if that is the best thing you've got, you have to milk it for all its worth. I would think that there is one available that has enough parameters to do what I proposed. Regardless, maybe you should tell it to these guys, or file a complaint with IEEE for a bogus paper.

http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=5069255

i've already talked about how some people take a PI and send it to a state selection box, then send it to a staged output. very hard to tune and not very reliable

See above. You "lol'd" about using a PID, I said it could work, then you said it couldn't be done, I said it could, more "lol'ing", and now you are telling me it can be done????

PIDs are available on chips, you can buy various companies implementation of a PID on a chip.

I thought I said that already. Here is why I said it. QFT

(seems like you think a "PID" is a chip you buy)

May have even been an "lol" about me in there somewhere as well.

so, you have absolutely no evidence about anything you're saying. awesome.

I don't need to try every possible configuration gathering reams of data to understand thermodynamic principles, and make some intelligent choices. Some thought experiments give me more than enough info for my needs.

I don't cold crash with other vessels in the same chamber like you do, especially in a chest freezer with kegs on a constant pressure CO2 source (overcarbing risk). You may not have significant temp drops in the other vessels, but I don't want to bother finding out. Just doesn't seem worth the risk, and something would suffer in the trade-off. Crashing faster seems to lead to better clearing anyway.

Quote:
Originally Posted by cwi
You are using time based control whenever the min on time is in play. There is a name for that method, but I can't think of it.

(original text in post)
uh, no i'm not. my controller is always on or off longer than the safety min timers.
(revised post)
uh, no i'm not. my controller is always on or off longer than the safety min timers. edit (i missed a word): well, yeah i'm using "time based control" whenever the timers is in play - so is everyone. but, it's never in play. glancing at my data i thought it might be, taking a harder look at it shows it's not.

Did you forget about this:
QFT

You're right, the freezer seems to be held on at some instances by the min timer I selected. Most times it runs longer than 2 minutes tho.

Or this:
The data points are there for at least 6, in 2 days, single "on time" samples, but your sample rate is 2 min., so they could be up to 4 min.

Or even know this:
Standard controllers don't have a "min on" setting, because it isn't available, at least not on my ebay controllers. So, "so is everyone" is not correct. Min on time is not part of a standard home fridges control system, which is why it may not be on many aux controllers. The "on time" is only a concern as it relates to cycle frequency, which is usually kept in check by by the "temp differential" or "dead band" which is fixed for stock and adjustable for most aux controllers. This is to reduce general cycling freq, not specifically to guarantee a min on time for immediate compressor protection.

Your off timer is shorter than industry standards. The off timer activation has only been avoided by luck. Open the lid right after a cycle, and the timer will activate, which is what it should do. It's just not a long enough protection delay, at least according to compressor cycle delays I have found.

I verified what I already knew, that starting a compressor after a short delay (short cycling) is the prime reason for ASD, due to high pressure at start up potentially locking the compressor. Suggested delays are 5 minutes or more, but dependent on the system. I found nothing about a short run time causing problems, other than being related to frequent cycling which is bad due to general start up wear. Compressor total run time is less important than total start cycles over the life of a fridge.

I'm already getting acceptable temp control, and an acceptable level of cycling. Until someone comes on and says their freezer only cycles once a day (with actual evidence) and a "realized" deadband of less than 2F, i'm pretty content with what I have.

Cycling freqs are personal preference, as I have stated. If you don't want to improve them, keep everything the same. Don't ask for ways your system can be improved, even in jest, and you won't get any suggestions.

Quote:
Originally Posted by cwi
If I don't specify everything (with caveats), you seem to call me out for generalizing or not including some piece of minutia, including in this post.

when?!? you came on here with things you half understand, proven with zero data.

Really? After all the backtracking you have had to do after finding out the truth after the fact, I am the one that only half understands things.
What have I said that wasn't true, regardless of whether I fully understand it. Even though I mostly do, and have the schooling and ability to quickly learn what I don't. It seems like it is you who only half understand, or less, the workings of a compressor or fridge control system, as shown by your off time and on time settings. Practical control system knowledge seems a little lacking as well.

I don't need a bunch of data, especially if I use it like you do and make statements contrary to what the data shows. (Remember the whole 2 minute on timer you keep flip flopping about, it's in the data)

then you instantly railed on cat for sharing something that works really well for him. then railed on me because i don't wanna freeze my bottles.

Again, if you go back, it was Catt22 who "railed" and "blasted" ME first. A post which you then "totally" agreed with ("Catt is dead on" remember?). I only questioned your method initially because you mis-stated what you were actually doing- the whole ramping vs. fermenting issue along with the freezing bottles. Then you questioned my logic, and the fun began.

not sure when my next lager will be, but I'll be sure to control to the thermowell sensor and record data.

Taped to the side of the fermenter and insulated is the currently accepted best fit placement.

Using Cat22's method for your next ale is what I want to see data on. Don't forget to add a column for the manual adjustment intervals. Sounds like fun.

 

[motobrewer]

blah blah blah, i'm sick of this meaningless argument

again....i didn't say i was doing what i mentioned. my controller has a setpoint only. i'm not gonna quote every meaningless thing you say. good lord, and you say that I am "calling you out for generalizing"!

you have no data to back up anything you're saying. until you do, come back on. your "thought experiments" are meaningless cause it doesn't seem like you have a clue. fuzzy logic...lol...

Fact: my controller keeps a 2F deadband and cycles 3-4 minutes an hour (took some 30 second data last night - it's over 3 minutes). Come up with a strategy that beats it or stop talking.

jeeze, i originally though "hey, this guy has some good points". Now i just realize you know enough about this stuff to self-claim yourself as an "expert" and like to hear yourself talk. throw around "engineering" words you don't understand so it makes you seem smart.

whatever man. come back with the last word, people like you usually do, but i'm out. an engineer that "doesn't need data", eh? we call those guys "sales reps".

hahaha! fuzzy logic, autotune! that'll let me control a staged output! classic.

 

[cwi]

your "thought experiments" are meaningless cause it doesn't seem like you have a clue. fuzzy logic...lol...

It's you that doesn't seem to "have a clue" about the very system you are talking about controlling. "on time" safety- all that control param is doing in your application is simulating damping the sensor when the temp drops below bounds <2 min after an "on" event. That param is good for that, and preventing chatter that would destroy the controller itself. The freezer has its own "min OFF time" called ASD, and it may only be the PTC start relay depending on its age. Maybe it's you who should "get a clue" about what you are talking about.

Fact: my controller keeps a 2F deadband and cycles 3-4 minutes an hour (took some 30 second data last night - it's over 3 minutes). Come up with a strategy that beats it or stop talking.

I have always stated that internal air temp swings don't matter to me. As well as that using the fastest response sensor; as close as possible to the freezer evap coils; with the smallest temp diff allowed by the controller; and shortest cycle delay; will give the best AIR temps.

FACT: the compressor would die an early death. Short cycling protection (within the controller) of some sort is advised to prevent chatter, especially if a 0 temp diff is allowed by the controller. It will keep the controller from destroying its own relays.

Your strategy is not far off from this, so its a good thing your controller has min "on time", as well of "min off". Most don't.

For finished beer, I would rather protect the compressor a bit by damping the sensor, and not have to worry about temp swings (of other beer) or large cycling freq increases when an out of bounds keg is added; and have suggested a method for doing that.
I would hope that proper sensor placement for fermenting (ales at least) is apparent by now.

jeeze, i originally though "hey, this guy has some good points". Now i just realize you know enough about this stuff to self-claim yourself as an "expert" and like to hear yourself talk. throw around "engineering" words you don't understand so it makes you seem smart.

At first, I couldn't figure out if you were the disgruntled old technician type, who hates the engineers with all their "theory" talkity-talk; or a green engineer with limited real world experience and knowledge, who thinks he knows more than everyone. They have similar attitudes, especially when they get caught being wrong about something.

Here is an engineering term for you- indirect control. Do you "have a clue"?

your "thought experiments" are meaningless
an engineer that "doesn't need data", eh?

An engineer that designs by actual experimental elimination is the best kind? That gets expensive, and takes too long. I will stick with my "thought experiments". I used that method to pick a control strategy that does not need a bunch of data to be collected to know how to tune it for each change of conditions.

hahaha! fuzzy logic, autotune! that'll let me control a staged output! classic.

You still milking that? I guess its the best thing you have. The various adj params on PID controllers can be used to get different behaviors out of them. Some PID controllers even revert to different modes when params are set to specific values.

Did you bother to use your IEEE membership to read that paper, which is SPECIFICALLY about PID loop control of home fridges?

Is this where I am supposed to "lol"?
"A PID controller isn't something you can buy on a chip, lol!.... oh wait, yes it is" - that one was pure gold. One of my favorite backtracks, of many, you had to do.

 

[motobrewer]

It's you that doesn't seem to "have a clue" about the very system you are talking about controlling. "on time" safety- all that control param is doing in your application is simulating damping the sensor when the temp drops below bounds <2 min after an "on" event. That param is good for that, and preventing chatter that would destroy the controller itself.

what? exactly what "chatter" is going to destroy the controller? or are you talking about the relay? or compressor??

Is this where I am supposed to "lol"?
"A PID controller isn't something you can buy on a chip, lol!.... oh wait, yes it is" - that one was pure gold. One of my favorite backtracks, of many, you had to do.

you can "lol" all you want. What I meant to say was, "A PID controller isn't JUST something you buy." I missed a word, but it should have been obvious to anyone who knows anything about PID. I don't care enough or have the time to go over every post with a fine-tooth comb. The fact that you still think "various parameters" on PIDs can allow it to directly control a multi-state output shows a fundamental lack of knowledge of what it actually is.

I did a test, taking 30 second data. One I controlled to air temp, and the other I controlled to a probe immersed in a small glass of water, set on my compressor hump. Again, my control strategy is just "On >41, Off<41".

All temps are in F. On-to-On time is the time between the start of one "on" event and the start of the next "on" event. Compressor "on" time and on-to-on time has an error range of +/- 30sec, since i'm trending 30 second intervals.


Air temp Control-

Air Temp Variance: 38.74 - 41.12 (deadband of 2.38F)
Water temp variance: 39.53 - 39.74 (deadband of 0.21F)
Compressor On Time: 4 minutes
On-to-On Time: 38 minutes
Cycles per day: 37.89
Comp Daily Runtime: 151.5 minutes per day


Water Temp Control-

Air Temp Variance: 37.49 - 42.27 (deadband of 4.78F)
Water temp variance: 40.29 - 40.98 (deadband of 0.69F)
Compressor On Time: 7.5 minutes
On-to-On Time: 70 minutes
Cycles per day: 20.57
Comp Daily Runtime: 154.3 minutes per day


So, having the probe in Air provides much tighter control and slightly overall less runtime, but almost twice the cycles. I'm surprised on how small the deadband is for water temp control, i thought it would finish much lower than 40.29F, however this is just a small glass of water. I imagine putting it in a carboy would have a bigger swing. So, back to my post (after being corrected), I said controlling to thermowell is more accurate, but provides a bigger swing. Hm, seems accurate to me. Then there was an argument, about what I don't know or care anymore, I'm certainly not going to go back and read all that garbage.

Note that the water temp never goes above 41F, this is probably just a display or rounding thing with our controllers. The sensor probably did send >41F, but our controller didn't display it for whatever reason. You gotta realize that our system is designed for things with very large time constants, so data visualization at this level isn't dead-nuts accurate. Why? One, because it's not needed for large building control, and two, if it were implemented and used on a wide scale, it would build up a very large database very quickly. The behind-the-scenes controller will certainly use more real-time and accurate information, it's just not passed to the visualization piece.

fermenting ale? I'm in wisconsin....my basement never really gets above 65F. I have ales in my heat chamber right now.

 

[Monster Mash]

Here is my 2 cents, having the probe in the air or in liquid "makes no difference" for storing kegs of beer. Either way, if you set it to 38 degrees the beer will be 38 degrees, even if you opened it constantly. If it mattered the food in your refrigerator would spoil because the temp controller isn't submerged. You can open and close your fridge 10 times a day and it doesn't hurt anything, freezers are better because they hold in the cold when you open them. This should not even be an argument, if you want to submerge it go ahead. If you don't then don't.

Fermentation...

It is best NOT to put the probe in the fermenter, it tried it and the thermal capacity of my fermenter made my fridge run too long and got too cold before the fermenting beer could reach the right temp and then it kept cooling below the set temp because the ambient air around it was 38 degrees.

By hanging the probe in the air the ambient temp of the air around the fermenter stays +/- 4 degrees of the set temp, due to the thermal capacity of the fermenting beer it does not change. I use a digital thermometer insulated to the side of the fermenter to monitor temps.

 

[cwi]

Here is my 2 cents, having the probe in the air or in liquid "makes no difference" for storing kegs of beer. Either way, if you set it to 38 degrees the beer will be 38 degrees, even if you opened it constantly. If it mattered the food in your refrigerator would spoil because the temp controller isn't submerged. You can open and close your fridge 10 times a day and it doesn't hurt anything, freezers are better because they hold in the cold when you open them. This should not even be an argument, if you want to submerge it go ahead. If you don't then don't.

Fermentation...

It is best NOT to put the probe in the fermenter, it tried it and the thermal capacity of my fermenter made my fridge run too long and got too cold before the fermenting beer could reach the right temp and then it kept cooling below the set temp because the ambient air around it was 38 degrees.

By hanging the probe in the air the ambient temp of the air around the fermenter stays +/- 4 degrees of the set temp, due to the thermal capacity of the fermenting beer it does not change. I use a digital thermometer insulated to the side of the fermenter to monitor temps.

For serving, it isn't that simple when varying sized containers are involved, especially if the probe is in/on the largest vessel. It can be made worse if there isn't a fan circulating air. For serving, air will give you the best temp control, but at the cost of increasing compressor cycling.
What motobrewer's data shows is that by probing the liquid, cycling can be reduced for a modest increase in temp variance.

Your comments on fermenting temp control make very little sense. The ferm'ing beer is generating heat, so the chamber air temp would have to be adjusted (offset) to account for this. The heat changes (decreases) over time, so the chamber air temps (offset) would have to be also. YOU are the controller in this loop. All the temp controller is doing is maintaining your offset, that would have to be adjusted by manually looking at the thermo on the ferm vessel.

Air has very little thermal mass, so temp overshoot of the liquid due to the air/freezer thermal inertia is minimal. There are other issues with convection within the vessel, as well as sensor lag in the thermowell. Placing the probe ON the outside of the ferm vessel, and then lightly insulating it, is the currently accepted method. This allows some influence on the probe of the chamber air, which reduces overshoot.

You may not have the appropriate controller, or did not have it adjusted correctly. If you want to put the probe in/on the fermenter, or in liquid for serving, you would need to have a controller that allows adjustment of the temp differential (on/off temp range) to 1F or so, since that is what the temp swing of the probed liquid will be guaranteed to be at a minimum.

 

[cwi]

what? exactly what "chatter" is going to destroy the controller? or are you talking about the relay? or compressor??

Both are possible. With a 0 dead band and no min on/off time, the solenoids in the unit could chatter. There may be some additional threshold logic in the controller to account for the transition, but min on/off time may be the only prevention. The compressor has its own short cycling circuitry, but some types of ASD would still allow chatter to reach the compressor. The appliance engineers love to minimize part counts, and build to normal use warranty claim periods only.

you can "lol" all you want. What I meant to say was, "A PID controller isn't JUST something you buy." I missed a word, but it should have been obvious to anyone who knows anything about PID. I don't care enough or have the time to go over every post with a fine-tooth comb. The fact that you still think "various parameters" on PIDs can allow it to directly control a multi-state output shows a fundamental lack of knowledge of what it actually is.

Funny you are now saying that what you said should have been obvious, because that all started when I jokingly talked about temp control overkill by using a PID (instead of "PID controller"), and you got all bent about it. Then ridiculed me by saying I must think a PID is some chip you can buy (which I knew you could), even after I said I was talking about a PID controller, which should have been obvious to start with.

On top of that, I posted a link to an IEEE paper about using PID control for home fridges systems. There are PID controllers that have overshoot damping capability even for on/off based systems, which may or may not be limited to some schoolboy textbook definition of what 3 block PID control is.

So, having the probe in Air provides much tighter control and slightly overall less runtime, but almost twice the cycles.

While the variance is smaller with air, there is the "offset" from the setpoint that has to be adjusted for.

Air temp Control-
Air Temp Variance: 38.74 - 41.12 (deadband of 2.38F)
Water temp variance: 39.53 - 39.74 (deadband of 0.21F)

Temp Offset = setpoint temp - actual temp = ~2F or ~1F or ~1.6F depending on how you want to deal with resolution. That offset will change based on ambient (i.e. garage) temps and also different desired temps, hence one of the major disadvantages of indirect control.

I'm surprised on how small the deadband is for water temp control, i thought it would finish much lower than 40.29F, however this is just a small glass of water. I imagine putting it in a carboy would have a bigger swing.

In general, with the probe on the carboy, the carboy will have a lower swing than the smaller glass of water. A glass of water in that same chamber at the same time will have a larger swing than the carboy. It is a function of relative thermal masses, but there are convection/conduction issues within larger vessels that can affect variance as well. Which is why the currently accepted best practice is to tape the probe to the vessel, then lightly insulate. It even simulates corrects overshoot somewhat by simulating the probe changing its response curve (or a dual probe strategy) on the cooling cycle, due to the partial influence of below setpoint air.
The sensor can be damped to minimize cycling or minimize temp swing in the smallest container, or somewhere in between. If freezing of bottles is the only concern, a container much larger than a bottle should be able to be used. Only testing can determine how much larger, and ambient (garage) temp changes may affect the size that can be used- indirect control again.

So, back to my post (after being corrected), I said controlling to thermowell is more accurate, but provides a bigger swing. Hm, seems accurate to me. Then there was an argument, about what I don't know or care anymore, I'm certainly not going to go back and read all that garbage.

I always stated that finished beer could be controlled to a tighter variance with air than probed directly, but it would come at a cost of frequent compressor cycling, and would require human intervention for offset calculations to account for the avg temps. For garages, this would only need to be adjusted a couple or three times a year for temperate regions, but almost daily for hot areas with wide garage temp swings.

Also, with common controllers most people set the temp diff to 4-5F when the probe is in the air to prevent excessive cycling, and down to 1F for water damped probes to control swing. 1F in air would be a serious cycling issue for a keezer in a hot garage.
The bigger temp swing was about fermenting and probe placement, which got muddied by your crash cooling vs. lagering vs. fermenting a lager, and collateral freezing bottle constraint confusion.
I also mentioned several times about indirect control having issues with changing external conditions. As well as that placing the probe in/on a jug water should give you adequate temp control without freezing, and fewer compressor cycles. You seemed happy with your cycling. It seemed high to me. Its your compressor. You have since done some testing, and whether .5F, or even more, is worth the reduced cycling is a decision that is up to you.

Note that the water temp never goes above 41F, this is probably just a display or rounding thing with our controllers. The sensor probably did send >41F, but our controller didn't display it for whatever reason.

That could also be some hidden anti-chatter logic in action.

fermenting ale? I'm in wisconsin....my basement never really gets above 65F. I have ales in my heat chamber right now.

During high krausen, ales in ferm chambers (avg. chest freezer size) can be 6-10F hotter than avg chamber air temps. Your ferm chamber is a much more interesting system to examine for probe placement, because it seems very close to the dead spot (worst case scenario) for indirect control. With the sensor in air, set to anything above 65, the ferm temp could theoretically vary a great amount based on ferm heat and external heat loss interactions. Same goes for chiller based ferm chambers with ambient near ferm temps.

 

[cwi]

I did a test, taking 30 second data. One I controlled to air temp, and the other I controlled to a probe immersed in a small glass of water, set on my compressor hump. Again, my control strategy is just "On >41, Off<41".

All temps are in F. On-to-On time is the time between the start of one "on" event and the start of the next "on" event. Compressor "on" time and on-to-on time has an error range of +/- 30sec, since i'm trending 30 second intervals.


Air temp Control-

Air Temp Variance: 38.74 - 41.12 (deadband of 2.38F)
Water temp variance: 39.53 - 39.74 (deadband of 0.21F)
Compressor On Time: 4 minutes
On-to-On Time: 38 minutes
Cycles per day: 37.89
Comp Daily Runtime: 151.5 minutes per day


Water Temp Control-

Air Temp Variance: 37.49 - 42.27 (deadband of 4.78F)
Water temp variance: 40.29 - 40.98 (deadband of 0.69F)
Compressor On Time: 7.5 minutes
On-to-On Time: 70 minutes
Cycles per day: 20.57
Comp Daily Runtime: 154.3 minutes per day

Are you sure there isn't a built in differential, .5F or so, in the controller?
Is the ~.75F overshoot caused completely by the thermal inertia of the de-energized freezer?
At what temperature does the controller say it is de-energizing the controller?
Originally I thought the only way your 0 temp diff was running longer than the min on time was from a lagging sensor reading shooting past 41F, but your controller logs don't show that.

 

[motobrewer]

Are you sure there isn't a built in differential, .5F or so, in the controller?
Is the ~.75F overshoot caused completely by the thermal inertia of the de-energized freezer?
At what temperature does the controller say it is de-energizing the controller?
Originally I thought the only way your 0 temp diff was running longer than the min on time was from a lagging sensor reading shooting past 41F, but your controller logs don't show that.

I'm sure.
Yes.
Anything less than 41F
I know.

Funny you are now saying that what you said should have been obvious, because that all started when I jokingly talked about temp control overkill by using a PID (instead of "PID controller"), and you got all bent about it. Then ridiculed me by saying I must think a PID is some chip you can buy (which I knew you could), even after I said I was talking about a PID controller, which should have been obvious to start with.

On top of that, I posted a link to an IEEE paper about using PID control for home fridges systems. There are PID controllers that have overshoot damping capability even for on/off based systems, which may or may not be limited to some schoolboy textbook definition of what 3 block PID control is.

Yeah, I got "all bent" alright. I believe my exact words were, "You can't control a staged output by a PID LOOP". Which, you can't. There are things inside commercial "PID controllers" which post-process the "PID loop" output into something that can control a staged output.

Every "PID" has "overshoot damping capability"! You seem to think "preventing overshoot" is all a PID does.

Listen, I'm done arguing about your lack of knowledge on PIDs. You'll keep talking about it I'm sure, but I'm done.

 

[djsethall]

Jesus, motobrewer and cwi. You two are almost a disgrace to this forum. The OP had a simple question and you two have completely hijacked his simple question thread. You two either need to duke it out in the ring or get together and work out your frustrations with each other (grudge sex?). Either way, you both need to just go do your own thing and stop arguing over finite points. I sounds like a pissing match. My fermenter's bigger than yours, My dad can beat up your dad. Get off the playground and take your energy elsewhere, like go brew or something. In my eyes, you are both wrong and it has nothing to do with closed loops or PID controllers.

 

[cwi]

Are you sure there isn't a built in differential, .5F or so, in the controller?

I'm sure.

The data seems odd- 40.98F? There is some conditioning of the sensor output being done.

[/CODE]62675]Is the ~.75F overshoot caused completely by the thermal inertia of the de-energized freezer?

Yes.

So the freezer is being turned off at 49.97F?

At what temperature does the controller say it is de-energizing the controller?

Anything less than 41F

It energizes before it even makes it 41F (40.98F), according to your data summary. The temp at cutoff logged by the controller is what then- 40.97F?

Originally I thought the only way your 0 temp diff was running longer than the min on time was from a lagging sensor reading shooting past 41F, but your controller logs don't show that.

I know.

Your original logs did have enough info so I was assuming that sensor lag is how your 0 temp diff was not causing issues. Your current data summary says the sensor NEVER goes above 41F (40.98F), so there has to be some anti-chatter unless the sensor stays at 41F exactly (or 40.98F?), until the controller de-energizes the freezer.
So, according to the data, not settings, the controller is de-energizing the freezer at 40.99F (or 40.97F)?
Unless it is, your controller appears to have some sort of anti-chatter logic. Anti-chatter logic generally functions exactly like a temp differential, because it works better than time based anti-chatter.

Yeah, I got "all bent" alright. I believe my exact words were, "You can't control a staged output by a PID LOOP". Which, you can't. There are things inside commercial "PID controllers" which post-process the "PID loop" output into something that can control a staged output.

By that point, I had already stated I was talking about a PID controller with the additional functionality that every commercial PID controller on the market has built in. I was NEVER talking about some idealized 3 block PID loop, that was you. I had stated that if the correct params and tunings were available, a PID controller could be forced to control an on/off system while accounting for overshoot. You kept saying that it was impossible, and that I was stupid. Now you seem to be trying to reverse your original position, while making it seem like I took your original position.

Every "PID" has "overshoot damping capability"! You seem to think "preventing overshoot" is all a PID does.

Either you are purposely trying to leave out critical parts of what I write, or you don't read very thoroughly. I wrote, "There are PID controllers that have overshoot damping capability even for on/off based systems. Something which you (originally) said was impossible , and I (always) said was easily done, even if the PID controller being used didn't allow for it, by using simple software, or simple circuits.

Listen, I'm done arguing about your lack of knowledge on PIDs. You'll keep talking about it I'm sure, but I'm done.

Your knowledge of PIDs seems limited to a block diagram in a book.
I still find it hard to believe that you think there is no way to control overshoot for an on/off compressor based system with a commercially available PID controller, or if you think it is possible, why you don't admit you originally stated otherwise. It is in the thread, anyway.
There are models available that can do it. It can even be easily done with additional circuits or software to post process a straight proportional PID output, or maybe even run two PID controllers in series.

 

[cwi]

Jesus, motobrewer and cwi. You two are almost a disgrace to this forum. The OP had a simple question and you two have completely hijacked his simple question thread. You two either need to duke it out in the ring or get together and work out your frustrations with each other (grudge sex?). Either way, you both need to just go do your own thing and stop arguing over finite points. I sounds like a pissing match. My fermenter's bigger than yours, My dad can beat up your dad. Get off the playground and take your energy elsewhere, like go brew or something. In my eyes, you are both wrong and it has nothing to do with closed loops or PID controllers.

djsethall, no need to bring religion into this as well.

I believe if you look at the experiment that Motobrewer just did, it is directly related to the OP's question regarding compressor cycling using controllers and how to mitigate it through sensor damping and placement.

As always, there is the unsubscribe button. Which you may have to use since you were probably automatically subscribed when you added to the noise in this thread.

 

[motobrewer]

Either you are purposely trying to leave out critical parts of what I write, or you don't read very thoroughly. I wrote, "There are PID controllers that have overshoot damping capability even for on/off based systems. Something which you (originally) said was impossible , and I (always) said was easily done, even if the PID controller being used didn't allow for it, by using simple software, or simple circuits.

"overshoot in on/off control"...

are you saying it's possible to maintain one solid temperature with an on/off compressor? with absolutely no variance?

in on/off control, there is always a deadband. i never said it was impossible, in fact, i told you exactly how to do it.

your knowledge of PID's seem to be what you've read on the internet this past week.

 

[cwi]

"overshoot in on/off control"...

Where does that quote even come from? I can't find it, and the previous thing like that I stated was

There are PID controllers that have overshoot damping capability even for on/off based systems, which may or may not be limited to some schoolboy textbook definition of what 3 block PID control is.

are you saying it's possible to maintain one solid temperature with an on/off compressor? with absolutely no variance?

I have never stated that, and it would be impossible even with a variable speed compressor. There has to be variance for a single sensor control system to even function. I originally stated that overshoot (of the deadband/differential), which is the main disadvantage of damping sensor response (probe on vessel), can be minimized, even though it is already minimal due to large thermal mass differences, with a PID controller, which it can.

in on/off control, there is always a deadband.

There will be a dead band in any real system. For a single sensor feedback system, there is guaranteed to be a dead band, even theoretically. It is the size of the variance, and compensation that matters. For a typical keezer controller, overshoot compensation is not possible. For a single sensor system, a PID controller, or a historical data based system, can compensate for overshoot.

i never said it was impossible, in fact, i told you exactly how to do it.

I explained how to do it, while you were still saying it wasn't possible. Then you finally admitted a PID controller could be used to reduce overshoot in a compressor based system. Prior to that you were calling me stupid for even thinking a PID controller could be used to control a compressor. I gave enough hints for the type of circuit that could do it to see if you really knew what you were talking about, or if you had to go ask your cubemate everything. Determining velocity (or acceleration) towards the setpoint isn't that difficult (even easier in code), and that is all a PID controller would need for overshoot compensation for an on/off slow response keezer type system.

your knowledge of PID's seem to be what you've read on the internet this past week.

I learned about PIDs long ago, and control systems even longer. This is pretty basic stuff. The only reading I did was the IEEE paper summary about controlling a fridge with a PID controller. That was only after you said I was wrong, and that it was not possible, when I knew it was entirely possible, and there were commercially available controllers that could do it.

Your knowledge seems to be limited to what a book and professor told you, and maybe a cubemate. What do you do when the solution isn't in a book? You don't even seem to know how your own controller functions, or how to apply it to a keezer. Beyond what a tech would know, anyway.

 

[djsethall]

Holy crap, you guys are still having your "i know more" contest? Listen, and listen well. A freezer has a thermostat in it that turns on when it gets too warm and off when it gets cold. Pretty frickin simple. A PID is merely going to do the same darn thing as the thermostat. No you will never have it dead set at a certain temp. Use a PID in place of the thermostat and go on with your merry life. In order to avoid duty cycling your compressor to death, use the ASD function. Or set it to turn on at a temp say 40 degrees and off at say 35 degrees. Simple question, simple answer. BTW, my knowledge comes from actually building and installing a walk in 12 tap beer cooler that keeps beer at a frosty 35f. The compressor /evaporator comes on at 37 to avoid excessive duty cycle. Done.

 

[motobrewer]

I explained how to do it, while you were still saying it wasn't possible. Then you finally admitted a PID controller could be used to reduce overshoot in a compressor based system.

no you didn't. I did. You explanation was, specifically, auto-tune and fuzzy logic.

Your knowledge seems to be limited to what a book and professor told you, and maybe a cubemate. What do you do when the solution isn't in a book? You don't even seem to know how your own controller functions, or how to apply it to a keezer. Beyond what a tech would know, anyway.

lol! I came back on here simply to present more data. you seem to have a serious "I have to seem like I know more than you" issue. Seems like I'm not the only one thinking that either. I said it before, got sucked in one last time, but again - I'm done arguing about your lack of knowledge about PIDs.

Once again, i'm sure you'll get the last word in. Guys like you always do.

Listen, and listen well.

 

[MarsingRedneck]

I have the inkbird. They just hauled off my kegerator today and brought another one out. I think I was the one that screwed it up. The last couple of days, it would run but not get cold. When I went in and checked it yesterday it was at 74 degrees and the fridge was srunning. So with my new refrigerator, if I understand correctly, from reading the thread, I set it for 1 degree difference and max out the time for the compressor to kick on? That would be 10 minutes in my case. (I'm making a Czech Pilsner)