"PID"-ish HLT Control

Homebrew Talk - Beer, Wine, Mead, & Cider Brewing Discussion Forum

Help Support Homebrew Talk - Beer, Wine, Mead, & Cider Brewing Discussion Forum:

This site may earn a commission from merchant affiliate links, including eBay, Amazon, and others.

luke_l

Member
Joined
Mar 25, 2012
Messages
22
Reaction score
3
I am building an e-herms brewery similar to Kal's design. I have made a lot of changes, but I like his workflow and am emulating that. Being the geek that I am (and I suppose most people who spend time in the Automated Brewing Forum are), I am not satisfied with using an off the shelf PID. Instead, I have custom ordered a laser engraved metal keypad from China, and a large GLCD. I am using a spark core to control it, as I will eventually set it up so I can load my recipes from the web to have the mash temp/time preset, as well as hop addition reminders, etc.

I have seen many varying opinions on programming the temperature hold for the HLT. Many people have fooled around with existing PID libraries with varying levels of success. Others have written much simpler pieces of code, and that is the path I am planning on taking. Just curious what others have done? I think that with a large volume of water (10 gallons for 5 gallon batches, and 20 gallons for 10 gallon batches) that decreasing the duty cycle of the element as it approaches setpoint should be sufficient to avoid an overshoot. Here is my pseudo code I have written (but not tested). Anyone see any reason this won't work fairly well?
Code:
tempWindow = 5;
min = 30;
if (delta>tempWindow)
   output = 100;
else if (delta<=0)
   output = 0;
else 
   output = (delta*(100-min)/tempWindow)+min; //can probably be refactored, this is for readibility
tempWindow is the number of degrees below setpoint where duty cycle will be varied
delta is the setpoint-actual
min is the minimum duty cycle (so if set to 30, then when the temp approaches the setpoint, it will approach 30)

I will be recirculating the water in the HLT with a pump, and measuring the temp as it exits the HLT like in Kal's design which should prevent any stratification. And my duty cycle will be switching the SSR on/off based on a 5-10 second window.

I think that with some tweaking of my duty cycle window, minimum duty cycle, and my temperature window, I should be able to achieve a decent ramp-up time and hold temps fairly well with minimal overshoot.\

Thoughts?
 
Looks kind of like a PI algorithm to me, except the I part disappears when the setpoint is exceeded, and the I isn't actually integrated, but rather precalculated. Might work well for this application.

Brew on :mug:
 
Kind of what I figured. I started reading how PID works, but then my eyes glazed over... I'm smart enough to understand it, just too lazy to try :cross:

I figure that since it's not linear as it approaches the setpoint it should be ok. It's a matter of finding the correct "min" so that it will react quick enough. I figure with 5500w at 30% duty cycle into 20 gallons will (very roughly) heat 0.3degrees (C)/minute. I also assume that there will be very little "inertial" heating after the element turns off (I'm sure there's a better term than that, but I'm a computer geek not a thermodynamics expert). I think it will work.

Moving across the country in 2 weeks, but then I will finish smashing this all together and see how it works :rockin:
 
I've played around with this as well. When using a normal PID algorithm I found that I will always overshoot due to integral windup. So I created a piece wise model where if you are 5 or more degrees below the setpoint the output is on 100%. If you are above the setpoint then the output off. If you are within the 5 degree window then I use a PI algorithm. I have found this to work quite well. For large temperature increases it will still ramp as quick as possible, and it pretty much eliminates overshoot.
 
PID control is absolutely not necessary for HLT and is just a pain to get set up.
You could probably go even simpler and say 0% if larger or equal to setpoint, 30% if less than 1 deg below setpoint and 100% otherwise.
 
Well, I guess some goofing around is in order. As soon as I move I will set up my HLT and try a few different chunks of code. Glad to hear others don't think I'm out to lunch, and I can move on to coding more "fun" aspects of my project
 
Take a look at the MLT thread where we used an arduino and modified the PID library. Obviously your application is different, but will run into many of the same issues.

https://www.homebrewtalk.com/showthread.php?t=519779

Regardless of the control algo, one of the biggest issues is temperature lag primarily from stratification but also from measurement. It takes a lot of flow/mixing to reduce stratification which should be easier in the HLT since it does not have the MLT compaction issues from excessive flowrates. At slow flowrates (~0.5gpm) in the MLT, the time between turning on the heating element and seeing the temperature start to rise (MLT discharge) was measured in minutes, not seconds. That kind of delay causes issues for a traditional PID control if you also want a fast responding system with minimal overshoot. You may see a similar issue with your algo as well.

Our control logic had some feed forward + PID which was good to maintain less than 2deg overshoot for step changes and much tighter while just holding temp. I started moving to a model based approach tuned to my setup since I can be brewing in 40F ambient or 80F ambient conditions with 5 to 20gal batch sizes and I don't want to have to retune or settle for poor performance. That is still in the works and probably won't make furthur progress until the winter.

Other than that, I would recommend switching the ssr at the fastest rate your HW reasonably allows to minimize local over-heating (exaggerated example: for 50% load, rather than being on for 5 seconds and off for 5 seconds per cycle it would be on for 1/60th of a second and off for 1/60). I prefer zero cross SSR's to minimize noise, but others have used random fire ones without issue.

If your interested in the sourcecode I have, I can send it to you for ref.
 
Back
Top