Evanos, hope you got your answer because this has gone way off topic!
So many accusations...
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'm not saying that's the way I'm doing it.Your "deadband" is 0. Does that even count as a "band"?
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.
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 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.
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.
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.
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.
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.
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.
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.
I thought Johnson communications was a subsidiary of Johnson Controls. I checked, and it is not.
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.
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.
what accusations? You are the only one making them, starting off with blasting catt.
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.
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.
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.
??????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.
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.
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'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
PIDs are available on chips, you can buy various companies implementation of a PID on a chip.
May have even been an "lol" about me in there somewhere as well.(seems like you think a "PID" is a chip you buy)
so, you have absolutely no evidence about anything you're saying. awesome.
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.
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.
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.
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.
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.
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.
your "thought experiments" are meaningless
an engineer that "doesn't need data", eh?
hahaha! fuzzy logic, autotune! that'll let me control a staged output! classic.
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.
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.
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.
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.what? exactly what "chatter" is going to destroy the controller? or are you talking about the relay? or compressor??
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.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.
While the variance is smaller with air, there is the "offset" from the setpoint that has to be adjusted for.So, having the probe in Air provides much tighter control and slightly overall less runtime, but almost twice the cycles.
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.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)
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.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.
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.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.
That could also be some hidden anti-chatter logic in action.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.
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.fermenting ale? I'm in wisconsin....my basement never really gets above 65F. I have ales in my heat chamber right now.
Are you sure there isn't a built in differential, .5F or so, in the controller?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.
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.
The data seems odd- 40.98F? There is some conditioning of the sensor output being done.I'm sure.Are you sure there isn't a built in differential, .5F or so, in the controller?
So the freezer is being turned off at 49.97F?Yes.[/CODE]62675]Is the ~.75F overshoot caused completely by the thermal inertia of the de-energized freezer?
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?Anything less than 41FAt what temperature does the controller say it is de-energizing the controller?
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.I know.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.
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.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.
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.Every "PID" has "overshoot damping capability"! You seem to think "preventing overshoot" is all a PID does.
Your knowledge of PIDs seems limited to a block diagram in a book.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, no need to bring religion into this as well.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.
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.
Where does that quote even come from? I can't find it, and the previous thing like that I stated was"overshoot in on/off control"...
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.
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.are you saying it's possible to maintain one solid temperature with an on/off compressor? with absolutely no variance?
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.in on/off control, there is always a deadband.
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.i never said it was impossible, in fact, i told you exactly how to do it.
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 of PID's seem to be what you've read on the internet this past week.
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.
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.
Listen, and listen well.
Enter your email address to join: