Yet another Arduino Based Brewing controller

Australia & New Zealand Homebrewing Forum

Help Support Australia & New Zealand Homebrewing Forum:

This site may earn a commission from merchant affiliate links, including eBay, Amazon, and others.
Well during the test-run (and brew) yesterday, it came into range OK (+/- 1.25C) on a ~60 litres HLT, 4500w element.

Now this is getting to target temperature without me having to fiddle with it, I will reduce this OK-zone down to +/- 0.75C of target. There was a little bit of quaffing involved in the brew-afternoon, so I wasn't paying the kind of attention a proper test might have warranted, thus I don't know exactly how long it took to reach proper temperature, or if it ever went over.

One thing I noticed, is that when I turn the knob left, the numbers go up (and vice-versa). i think before I hacked the encoder library to reverse this, but a subsequent update has reversed it back again.

Do you get this Wiggman?

Maybe just swapping the encoder data wires will swap it around. I will test this theory.
 
Swapping the wires does indeed correct this issue. 100% of the time I've managed to connect them in the wrong polarity.
Good idea about narrowing the range, by memory it would change to green within 2°C which in my opinion is probably too soon given the lagging temp of the mash. I haven't done a brew in a few weeks but to date have never encountered overshoot nor quite hit target temp with my original settings. I've had some personal matters lately which has kept me away from home and brewing so I haven't had a chance to play around with it. I've got some ingredients for a Scottish 80/- ready to go so I'll tweak the PID values again provided my computer lets me - which has also been on holidays.
 
Have you guys seen the YF-21 flow meter? Check out ebay.

Some specs:
1/2 male threads on each end (BSP parallel)
Polyamide body, rated to 150°C
POM impeller (for hall effect sensor), rated to 120°C
Pulse width output, 5-24VDC, 1-30lpm

would be cool to do pump flow control. Essentially PWM on the sensor and output.
 
What sort of boards are you guys using, and approx how much memory (flash?) is being used by the program?
 
Cool. Do you know how much memory is being used by the PID program? Anything else on top?

I'm thinking of a slightly bigger board for a 2 x PID with a few extra functions, driving two displays (not sure why) for my brewery (again, not sure why) but looking an doing a predictive controller for fridge control - which the Nano should do excellently.

Main thing in I'm not sure about the voltage range needed for everything I want to drive. 5V arduinos with decent flash memory seem to be limited. I'm thinking some buffer would be good before writing to a USB for example, to get history on fermentation and brews.
 
Adr_0 said:
Have you guys seen the YF-21 flow meter? Check out ebay.

Some specs:
1/2 male threads on each end (BSP parallel)
Polyamide body, rated to 150°C
POM impeller (for hall effect sensor), rated to 120°C
Pulse width output, 5-24VDC, 1-30lpm

would be cool to do pump flow control. Essentially PWM on the sensor and output.
I've just ordered these for my kegbot setup, ~$4.50 a pop from aliexpress
 
Moad said:
I've just ordered these for my kegbot setup, ~$4.50 a pop from aliexpress
So ignore this post, didn't realise what the Kegbot is for...
 
Adr_0 said:
Cool. Do you know how much memory is being used by the PID program? Anything else on top?

I'm thinking of a slightly bigger board for a 2 x PID with a few extra functions, driving two displays (not sure why) for my brewery (again, not sure why) but looking an doing a predictive controller for fridge control - which the Nano should do excellently.

Main thing in I'm not sure about the voltage range needed for everything I want to drive. 5V arduinos with decent flash memory seem to be limited. I'm thinking some buffer would be good before writing to a USB for example, to get history on fermentation and brews.
I don't really remember how much "ROM" the PID library takes, maybe a couple of KiB, IIRC.
I don't think it uses any more RAM than the few variables it takes, so 6x (or so) doubles, thus < 64 bytes / PID loop.

Since you want to drive two of them, you'll need to ensure your displays have the CS (chip/cable select) PIN available.
Some of the (very) cheap ones do not, and thus you can't switch between them on the bus. Of course I'm assuming you're talking about using the same displays I did.

Alot of the memory footprint was used up by the GUI. I guess we could re-write these to be a bit more frugal Although I already did one pass at this, removing things I didn't need - like passing the button colours as parameters, etc. Probably a lot of the code could by encapsulated and re-used, like for example handling the rotation of the knob when "this" control is focused. Currently it's a big & ugly state-transition mashup.

One additional thing I'd like to add, is to have the PID parameters settable in the GUI (saving to EEPROM).
 
Mr Wibble said:
I don't really remember how much "ROM" the PID library takes, maybe a couple of KiB, IIRC.
I don't think it uses any more RAM than the few variables it takes, so 6x (or so) doubles, thus < 64 bytes / PID loop.

Since you want to drive two of them, you'll need to ensure your displays have the CS (chip/cable select) PIN available.
Some of the (very) cheap ones do not, and thus you can't switch between them on the bus. Of course I'm assuming you're talking about using the same displays I did.

Alot of the memory footprint was used up by the GUI. I guess we could re-write these to be a bit more frugal Although I already did one pass at this, removing things I didn't need - like passing the button colours as parameters, etc. Probably a lot of the code could by encapsulated and re-used, like for example handling the rotation of the knob when "this" control is focused. Currently it's a big & ugly state-transition mashup.

One additional thing I'd like to add, is to have the PID parameters settable in the GUI (saving to EEPROM).
Cool, sounds good. Looks like there is 10-12kb of code, and as you said, a few doubles.

I was going to go for 4 line serial displays if I could. One for program/mode/step info, and one for monitoring/control.

There are a few EEPROM functions, eg write, update, read. You could write initial values, then update as the parameters changed.

You should be able to pull up a new screen with a loop against a button press or the pot to change the parameters. Include the 'lcd.begin', 'lcd.setcursor (0,0)' for first row, first column, then 'lcd.print("P: " + pidp), then maybe a 2 second delay then EEPROM.update(1,pidp).

Your PID then has to replace any P, I, D references with EEPROM.read(1).

Not sure how you use the pot to change the values - but within this, put some of the above code as a starting point.
 
With a POTentiometer you wire it to an analogue input line.
Performing an analogRead() against that pin will give you a number 0-1023.
This can then be mapped to whatever you like.

So about the 4-line LCD. I'm not trying to talk you out of it or anything, but ...

I've used a bunch of 2-lines, and 4-line character LCDs with Arduino. They work well, mostly (very cheap ones can be a bit dodgey).
But the refresh speed is slow, leading to blurring on fast-updating characters.

The little colour pixel-based LCDs I used with this project are just as simple to use, maybe cost a few extra dollars (say $7 instead of $4).
If you decide later you'd like to plot a graph of Heat Vs Time - well you can.

In terms of programming complexity, they're about the same.
 
That's awesome.

Good points about the display... I guess since I'm leaning towards serial (using only one DO rather than 5-6) I would need to do all of the calculations, then update every 1-5s - and I'd have no choice but to update the whole screen. I know it's a bit backwards, but if I can get a couple of screens in the 71x29mm range, that will be an easy fit into my current box and I'll have a fair bit of free space for other things.

Thanks for the tips. I'm not sure that I really want to be getting into this, afterall my current setup works fine - the only catch being a drop in pump speed/flow when the element kicks in. I'm sure that's from a drop in voltage, and could possibly sort it out with some sort of regulation, but it would also be nice to put in a flow setpoint and have that maintained. Flow control would also be a nice application for PI control too, if one were so inclined...
 
[SIZE=10pt]Hi this post has abruptly stopped I have reading it with great interest and have slowly been acquiring the required parts.[/SIZE]
[SIZE=10pt]Hope there is more to come.[/SIZE]
 
mrcopierman said:
[SIZE=10pt]Hi this post has abruptly stopped I have reading it with great interest and have slowly been acquiring the required parts.[/SIZE]
[SIZE=10pt]Hope there is more to come.[/SIZE]
There's not really anything much to tell currently...

I'm still using my box. The updated PID parameters seem to be working well.

My little power supply failed the other day, I just swapped in a new one (I always buy a couple since they're so cheap).
This is the first time I've had one fail though - I don't want to give the impression that they're dodgey.

I'm still thinking about making a Arduino-Mega based version, but haven't done anything more than think about it (and acquire parts).
 
cool i will post my build when i get all my components good to hear all is working well.
 
Incidentally I'm whacking together an Arduino data logging predictive on/off temperature controller, primarily for in-wort temperature control where you an get a fairly big lag.

I just need to decide if the DS18B20 is good enough at >0.06°C resolution or I need an RTD. I'm thinking if I have a 'ramp' and 'modulate' mode I can hit the temperature bang on, then modulate +/-0.2°C. The main thing is the ds18b20 might have trouble picking up rate-of-change in 0.1 to 0.2 range...
 
Adr_0 said:
I just need to decide if the DS18B20 is good enough at >0.06°C resolution or I need an RTD. I'm thinking if I have a 'ramp' and 'modulate' mode I can hit the temperature bang on, then modulate +/-0.2°C. The main thing is the ds18b20 might have trouble picking up rate-of-change in 0.1 to 0.2 range...
Another aspect of the DS18B20s is that they take about 1.5 seconds (IIRC) to do the full-precision read too.
So if you need fast iterations you have to work something out. I guess temperature in a Hx/Pot isn't going to change much over a second.
 
can this be ported to an "Uno" ??
as i have a couple lying round and size isnt an issue on my enclosure>
 
koshari said:
can this be ported to an "Uno" ??
as i have a couple lying round and size isnt an issue on my enclosure>
Absolutely.
For all intents and purposes, and Uno is the same as a Nano.
It does need to be the version with 2k RAM and 32k of ROM[1] though.
Some older Uno's are based on different (lower spec) CPU systems with less ROM.

[1] It's not really ROM, since one can store a program in it. But once running, it's ROM to the program.
 
nice, and the pinouts have equivalents in both platforms?

i picked up an encoder but haven't checked it out yet, hope its compatable for this library/code.
 
Back
Top