# Yet another Arduino Based Brewing controller



## mr_wibble

G'day,

Finally finished my brewing controller. 
It's designed to drive my HLT and HERMS-HX mash-tun.
There are many like it, but this one is mine.

It's based around an Arduino Nano. I wanted to push the nano as far as it would go. 
I couldn't quite get the kitchen sink in there, but it does everything on my list.

I like programming on the Arduino nano, because they're cheap, small, and I get a bit of a nostalgic joy - it's not a whole lot different to our old 32k Microbee that I used when I was a kid. Actually the killer-feature is those bloody screw-terminal boards - makes it so easy to attach sensors and daughter-boards.

So the main criteria were:
- Set and keep the HLT temperature (PID controlled)
- Set and maintain the mash heat-exchange temperature (PID controlled)
- Allow easy setting of HLT & mash temperatures
- Allow calibration of sensors
- Allow for a real-time delayed start of HLT heating (well, the whole system)
- Allow for the HLT and Mash to run independently
- A simple to use User Interface (UI/GUI).





The whole thing is housed in a splash-proof box (which was IP66 rated until I drilled a hole for the knob, and added audio-plug sockets for the temperature sensors).




I did have to make some compromises. I wanted some nice sockets on the bottom instead of those short leads. But the HLT heater is 20A, and 20A sockets do not come in a wide range. Maybe someone in the trade would know of something, but I don't. The short-leads are a cost effective solution. Much cheaper than a 20A HPM socket.

The Arduino libraries I used take up quite a bit of space, literally 99.7% of the Arduino is full. 

Using a rotary-encoder as the only user input device works well. Clicking (push down) or turning the knob is enough for all input. 
To change a value, the user rotates the knob to select the input field, clicks to go into edit-mode, rotates the knob until the desired value, then clicks a last time to go back.

I did (perhaps still do) have problems with the DS18B20 temperature sensors "locking" to the same reading. The symptoms of this is that the sensors never reports a new reading is ready, constantly reporting (say) 35.6C, meanwhile the PID using the value to heat your water way past the set-point. I read to fix this a 0.1uF capacitor right near the sensor helps, but my sensors are sealed in s.steel housings on a 3m cable. So I had to settle with a capacitor at their attachment points. Also watching for the lack of a sensor result, and re-requesting seems to fix it.

I wanted to add a little bluetooth module. This would allow the arduino to continually broadcast all the vital statistics (set temps, actual temps, mash-schedule, start-time, etc. etc.). Any sort of logging and monitoring app could read this data, and do what it wants - like plot temp Vs time graphs. But it's at the point where the additional 1.5k of RAM needed for the serial library is just too much. I had already re-factored the code several times to reduce it's memory footprint. I had to give up on this feature.

(I'll add some GUI photos in the next post)


----------



## mr_wibble

This is the over view screen. The flame-icon indicates the heater is currently on.
Things like delayed start, control-box overheating alarm, step-mash running are also showed here.



This is where i can set the HLT temperature, and a delayed start-time. Typically I set my HLT to start heating at 4:30am, so when I'm up at 5ish, she's right to go.
In the circuit is a battery-backed real-time clock, so the controller always knows what time it is.



The Mash screen allows the temperature to be set simply. If set to zero, the mash is considered to be off.
A 4-step mash programme can also be set. The fields are XX minutes at YY degrees, the user fills out as may fields as wanted, then click "Run".



The calibration allows small adjustments to the HLT and Mash sensor readings, and to set the time on the clock (theoretically only needing to be done once, and on battery changes).



Finally, a shot of the very amateur wiring layout.



Is anyone wants the code, please feel to PM me. Don't think I can add a .zip of it here.


----------



## malt junkie

Neutric Powercon plugs are rated @20amp they also have higher 32amp ones as well. Looks pretty damn sexy. Have you brewed with it yet?


----------



## mr_wibble

Very rough parts list (mostly from from aliexpress.com, but probably can get the same from ebay)

Arduino Nano - https://www.aliexpress.com/store/product/Nano-CH340-ATmega328P-MicroUSB-Compatible-for-Arduino-Nano-V3/1950989_32572612009.html
Screw terminal Board for Nano - https://www.aliexpress.com/store/product/New-Terminal-Adapter-Board-for-Arduino-Nano-V3-0-AVR-ATMEGA328P-AU-Module/1414081_32278702970.html
12V/2A Power Supply - https://www.aliexpress.com/store/product/AC-DC-12V-Power-Supply-220-to-12V-Transformer-1A-2A-3A-5A-6-5A-10A/1940364_32711917763.html
Real time clock module - (LIKE THIS) https://www.aliexpress.com/item/Tiny-RTC-I2C-modules-24C32-memory-DS1307-clock-RTC-module-without-battery-good-quality-low-price/2020927349.html
SPI 320x240 Colour LCD Display (a cheap and simple one, with no SD card slot) - (LIKE THIS) https://www.aliexpress.com/store/product/1Pcs-2-4-inch-240320-240x320-Dots-Full-Color-TFT-LCD-Display-Screen-With-ILI9341-Driver/215829_32746228420.html
Enclosed DS18B20 temperature sensors - https://www.aliexpress.com/store/product/1pcs-New-Digital-Temperature-Temp-Sensor-Probe-DS18B20-For-Thermometer-1m-Waterproof/808897_1297739612.html
2x SSRs - one from Jaycar ($45) :blink: , one from aliexpress (~ $5) - bloody found the 2nd "lost" one after I'd been to Jaycar. Geeze.

Enclosure, 20A cables & plugs from John R Truk (Turk?)
Actually these enclosures are really nice


----------



## mr_wibble

malt junkie said:


> Neutric Powercon plugs are rated @20amp they also have higher 32amp ones as well. Looks pretty damn sexy. Have you brewed with it yet?


Those Powercon plugs & sockets look good. Currently about $20/set on amazon.

I did one brew on it, a double-batch (45L) high-gravity Belgian. 
It held the temperature perfectly.

... but somehow I stuffed up the sparging? or it didn't mash so well. First time using new vessels too, I'd say I bollox'd up the manual parts of it


----------



## crowmanz

Nice work. That overview screen is cool, I'm guessing the fire symbol comes on only when the elements are on and heating?


----------



## mr_wibble

crowmanz said:


> Nice work. That overview screen is cool, I'm guessing the fire symbol comes on only when the elements are on and heating?


yeah.

I run the box off a single 20A input, My HLT is 20A/4500watt (from Romar Elements), and the HX a 10A/2200watt - I didn't want to run both the HLT and Mash heating elements at the same time because this is a theoretical overload of the 20A household circuit.

So when both are running, only one gets power at a time, and the Mash HX-heater takes precedence over the HLT heater. This works ok, because the bulk of the HLT heating is done way before I start mashing. (I thought about bringing a separate power circuit for the HX, but it seemed unnecessary.)

The upshot is that when both HLT & Mash are running, that little flame icon switches around every few seconds. it's pretty.


----------



## GibboQLD

Mr Wibble said:


> If anyone wants the code, please feel to PM me. Don't think I can add a .zip of it here.


I'd be keen to have a look -- PM incoming.

Side thought: you could always stick it on github if you plan on improving it over time..?


----------



## sp0rk

GibboQLD said:



> I'd be keen to have a look -- PM incoming.
> 
> Side thought: you could always stick it on github if you plan on improving it over time..?


Great idea there
I got a free rPi 3 that I was going to install CraftBeerPi on, but I'm using it as a Steam gaming box right now
However I've got half a dozen Arduinos/DS18B20s/SSRs/etc, if I can just use an Arduino and lose the non essential functionality that CraftBeerPi has, I'm keen to give this a go to control my HLT and HERMS


----------



## stilvia

That looks quite good. Have you considered using a mechanical switch or relay to cut power off prior to the SSDs?


----------



## SBOB

Nice work


----------



## mr_wibble

stilvia said:


> That looks quite good. Have you considered using a mechanical switch or relay to cut power off prior to the SSDs?


No I didn't consider using that.
The SSRs are (as far as I remember) optically isolated already, so don't present a danger to the circuit (theoretically).
(the cheap SSR is opto-isolated, I don't know about the jaycar one, typically SSRs are opto-isolated.)

Maybe an emergency stop switch might be a useful addition. 
But I'm really really crap at drilling holes in the right spot, and screwing bits of wood together I find difficult, so extra hardware is not really something I'd think of.

Is there some particular reason you ask?


----------



## TheWiggman

I want to start by saying this is bloody awesome, cool as shit way to brew beer. Yeah you don't need all the bells and whistles but I love creating stuff like this. The price of all those components is staggeringly cheap. So cheap that there's no excuse for me not to buy some for Christmas. It's also something my kids could really get into (the whole programming real life stuff to switch things on and off, understanding how electronics work etc. which I find is a dying art like sewing and car maintenance).
There's something you touched here that has a bit of untapped potential in my opinion for a 2V+ system -



Mr Wibble said:


> I run the box off a single 20A input, My HLT is 20A/4500watt (from Romar Elements), and the HX a 10A/2200watt - I didn't want to run both the HLT and Mash heating elements at the same time because this is a theoretical overload of the 20A household circuit.
> 
> So when both are running, only one gets power at a time, and the Mash HX-heater takes precedence over the HLT heater. This works ok, because the bulk of the HLT heating is done way before I start mashing. (I thought about bringing a separate power circuit for the HX, but it seemed unnecessary.)
> 
> The upshot is that when both HLT & Mash are running, that little flame icon switches around every few seconds. it's pretty.


I have a 2400W HLT and 2000W HERMS. One thing that shits me is I need to run power cables off two circuits in the house which invariably means extension cord spaghetti. With this program logic you could run 2 vessels off a single 10A power point. If the HERMS always takes precedence over the HLT then in between cycles of maintaining temp the HLT would heat until it gets to sparge temp. If you had both vessels full at the start of the brew this would absolutely work.
Great project, can't wait to hassle you about the program.


----------



## Maheel

TheWiggman said:


> It's also something my kids could really get into (the whole programming real life stuff to switch things on and off, understanding how electronics work etc. which I find is a dying art like sewing and car maintenance).


OT but i teach Man arts (wood work / metal work) and now robotics / coding / random tinkering / random building of IOT stuff

I have just done 20hrs with a basic robotics program using arduino with a Yr8 group. (new for my school)

they loved the problem solving that building, programing, wiring and even letting out the magic blue smoke on one robot gave them 

we went from some not knowing the what DC Pos and Neg and a basic circuit was to 15 small robots roaming the room and them being able to discuss with adults (Principle etc) what was going on with the robots.

it was low tech / high tech with hot glue guns and micro processors in a joining together of awesomeness 
fully engaged students like i have not seen in a while :beer:
Get a ebay kit for the kids, have a look at this SIK guide book (pdf)
http://cdn.sparkfun.com/datasheets/Kits/SFE03-0012-SIK.Guide-300dpi-01.pdf
add a Hot glue gun and a some lego and your making fun stuff 


Maybe just maybe i can talk "the man" into this awesome brew bot for process control in chemistry class........
or maybe i will seek forgiveness and fire up a brewery "inschool" :super:


----------



## TheWiggman

A few queries -

There are 3 sensors pictured in the original drawing but only two used, what's the go?
Why is there a resistor across one sensor's +ve and 'data' leg?
How do all two/three sensors work if they're read off a single terminal?
There are additional PCBs below the TFT, are there basically terminal boards to make screwing things easier?


----------



## Stouter

Very nice. Amazing to watch the tech over the last few years, not just in brewing but I mean generally, and how people adapt it for whatever they need.
I got my boy a Mechano set last Xmas, this year will be the follow up with an Auduino kit, then he can start making this stuff for my brewing, because it's all over my head.


----------



## GibboQLD

Not OP but can offer some insight:



TheWiggman said:


> A few queries -
> 
> Why is there a resistor across one sensor's +ve and 'data' leg?
> How do all two/three sensors work if they're read off a single terminal?


The DS18B20 temperature sensors operate on a 1wire bus (which needs a pull-up resistor to work properly), and each have their own unique hardware address which is "burnt in" at the factory and cannot be changed, meaning they can all be connected to the same pin and individually queried as required.


----------



## TheWiggman

Tops thanks.
Any reason I couldn't get a Uno R3 instead of the nano so there's more memory available? I like the idea of being able to expand in the future. Id imagine there are a few references in the coding to change.


----------



## Moad

very nice, love the display.

Second the Nuetrik adapters, I'm using 20a version.


----------



## sp0rk

Is this the rotary encoder you're using?
I can't find any on aliexpress that really say whether they've got a push button or not
https://www.aliexpress.com/item/2PCS-KY-040-Rotary-Encoder-Module-Brick-Sensor-Development/32545580568.html?spm=2114.30010308.3.140.I6t477&ws_ab_test=searchweb0_0,searchweb201602_2_10065_10068_10084_10083_10080_10082_10081_10060_10061_10062_10056_10055_10037_10054_10059_10032_10099_10078_10079_10077_10073_10097_10100_10096_10070_10052_10050_424_10051,searchweb201603_6&btsid=468b25bb-b076-48ea-99f6-3373b684531f


*edit*
NVM, I might just get these since they come with knobs as well
http://www.ebay.com.au/itm/3-Pieces-12mm-Rotary-Encoder-Switch-with-Keyswitch-Knobs/122095626566?_trksid=p2047675.c100005.m1851&_trkparms=aid%3D222007%26algo%3DSIC.MBE%26ao%3D2%26asc%3D39923%26meid%3D47d864032fbf446a808d2af372d128b9%26pid%3D100005%26rk%3D4%26rkt%3D6%26sd%3D141557670160


----------



## sp0rk

Mr Wibble said:


> SPI 320x240 Colour LCD Display (a cheap and simple one, with no SD card slot) - (LIKE THIS) https://www.aliexpress.com/store/product/1Pcs-2-4-inch-240320-240x320-Dots-Full-Color-TFT-LCD-Display-Screen-With-ILI9341-Driver/215829_32746228420.html


Using a slightly bigger screen with an sd card slot but the same resolution shouldn't be a problem as long as I'm only wiring the required pins, right?


----------



## mr_wibble

TheWiggman said:


> A few queries -
> 
> There are 3 sensors pictured in the original drawing but only two used, what's the go?
> Why is there a resistor across one sensor's +ve and 'data' leg?
> How do all two/three sensors work if they're read off a single terminal?
> There are additional PCBs below the TFT, are there basically terminal boards to make screwing things easier?


The three sensors are: HLT, Mash and internal panel temperature. The software produces an on-screen alarm if the panel temperature > 50C. I've read that SSRs can produce a bit of heat if they're working hard, that said, I've never seen them get anything but warm. So far, (on ~25C days) the panel gets to about 35C. That said, they are screwed to quite a heavy metal (aluminum?) base plate. 

The DS18B20 digital temperature sensors need this resistor for good readings. They suffer a bit from line noise, and this resistor helps. The capacitor there is also supposed to help with this, but it's probably a bit big. But it was the first one I grabbed, and it did seem help with failed re-reads.

The DS18B20 sensors use the "OneWire" protocol. Each sensor has a 5(6?) byte address - a bit like a MAC address of an ethernet card. When you request something from a sensor using the API, typically you include the sensor address in the call, so the sub-system knows which sensor to use.

The two extra PCBs in the photo are:
- Just a bunch of common (+) (-) screw points where power is delivered to stuff, and earths grounded.
- An attachment point for the DS18B20 sensor power lines, and the OneWire bus line. It also holds the 4.7k resistor and a hastily-added capacitor.
So yeah, you're basically correct, they just made wiring it up easier.


----------



## mr_wibble

TheWiggman said:


> Tops thanks.
> Any reason I couldn't get a Uno R3 instead of the nano so there's more memory available? I like the idea of being able to expand in the future. Id imagine there are a few references in the coding to change.


I'm prepared to be corrected, because I'm not going to go check - but the Nano has exactly the same specs as the Uno (apart from the obvious physical size differences)
Definitely at least as far as memory is concerned (~30k after the boot-loader).

But if you want to use an Uno, it should be 100% ok.


----------



## mr_wibble

sp0rk said:


> Is this the rotary encoder you're using?
> I can't find any on aliexpress that really say whether they've got a push button or not
> https://www.aliexpress.com/item/2PCS-KY-040-Rotary-Encoder-Module-Brick-Sensor-Development/32545580568.html?spm=2114.30010308.3.140.I6t477&ws_ab_test=searchweb0_0,searchweb201602_2_10065_10068_10084_10083_10080_10082_10081_10060_10061_10062_10056_10055_10037_10054_10059_10032_10099_10078_10079_10077_10073_10097_10100_10096_10070_10052_10050_424_10051,searchweb201603_6&btsid=468b25bb-b076-48ea-99f6-3373b684531f
> 
> 
> *edit*
> NVM, I might just get these since they come with knobs as well
> http://www.ebay.com.au/itm/3-Pieces-12mm-Rotary-Encoder-Switch-with-Keyswitch-Knobs/122095626566?_trksid=p2047675.c100005.m1851&_trkparms=aid%3D222007%26algo%3DSIC.MBE%26ao%3D2%26asc%3D39923%26meid%3D47d864032fbf446a808d2af372d128b9%26pid%3D100005%26rk%3D4%26rkt%3D6%26sd%3D141557670160


I think it's OK, as long as there's a "SW" pin on the board, or search for "Rotary Encoder with button/switch".

I found rotary encoders a bit of a PITA to solder into a board, so I started buying them pre-mounted.
I have a few of these: https://www.aliexpress.com/store/product/Rotary-Encoder-Module-24-steps/1950989_32678025587.html
The RobtoDyn stuff seems to have a good build quality. You can probably save 10 cents ordering direct too  http://robotdyn.com/
But I just used a generic one in my project, because it was on hand at the time.

(BTW: if you want to buy from an Australian retailer, Core Electronics is outstanding - http://core-electronics.com.au/ )
You'll (possibly) pay more, but of course you get a warranty, and faster delivery.


----------



## mr_wibble

sp0rk said:


> Using a slightly bigger screen with an sd card slot but the same resolution shouldn't be a problem as long as I'm only wiring the required pins, right?


Once the programme is loaded, there is only about 300 *bytes* of storage memory left, so using that SD card would probably be out of the question, since you couldn't even include the API for it.

But the short answer is: If it's connected by SPI and supported by the PDQ_GFX library, then yes. (So: ILI9340, ILI9341, ST7735, ST7781).

The LCD pins do seem to get moved about and renamed a bit. So it might be necessary to re-work out which pin goes where.
It will be pretty close to the existing naming, but I did have to spend some time experimenting to work mine out.
There was documentation, but it differed from reality. I'm no expect whatsoever, and I worked it out, so I doubt it'll be a problem.
The LCD I used does not even have a ChipSelect (CS)pin (AFAICT) - so you can only use one LCD board at a time. (i bought the chepest because I'd not used one before)

A bigger LCD might be easier to read though.


----------



## sp0rk

Brilliant!
My main thing was I'd already built a controller box with an STC1000 for my HLT and a pump, but the smaller screen wasn't wide enough to go in the hole that the STC currently fills (i'll be ditching the STC)
Might give a bigger screen a go and just see how it works


----------



## littlejohn

Nice work! :icon_cheers:

If you're not phased by a bit of fiddly soldering work I'd recommend looking at replacing the Nano with an ESP8266 12F in the future, skip over this if you're familiar with it but I like that it:

- can be programmed from the same Arduino program and likely the same Arduino '.ino' file you are using with just a few small tweaks. It can also be loaded with firmware for other programming languages if you like, most are 'interpreting' languages like Lua, JavaScript and Python - they take up more space but you can program live while the device is running rather than re-compiling every time you want to test an idea.

- is about the size of a postage stamp - plenty of left over real estate in your project box.

- has 4M of flash memory - which can help with adding extra peripherals / displays / sensors etc.

- can act as a WiFi server or WiFi client - so you can either push your data to a server like www.thingspeak.com to monitor your brew remotely, or it can act as a server and show the data in a webpage which you can monitor and control from the internet browser on your phone / computer etc. rather than relying on fixed displays

- crunches numbers at up to 160Mhz, 10x the Nano - not going to make any difference for this application but gives you scope to grow your ideas.

- is about $2 here - you could afford to have a whole bunch of 'things' all over your brewhouse / house all speaking to eachother, monitoring and doing . . . . . . beer stuff.

Anyway, food for thought and good luck with the project


----------



## mr_wibble

littlejohn said:


> Nice work! :icon_cheers:
> 
> If you're not phased by a bit of fiddly soldering work I'd recommend looking at replacing the Nano with an ESP8266 12F in the future, skip over this if you're familiar with it but I like that it:
> [...]
> - is about $2 here - you could afford to have a whole bunch of 'things' all over your brewhouse / house all speaking to eachother, monitoring and doing . . . . . . beer stuff.


I'm not really interested in _fiddly_ soldering 
So I ordered one of these: https://www.aliexpress.com/item/V3-Wireless-module-NodeMcu-4M-bytes-Lua-WIFI-Internet-of-Things-development-board-based-ESP8266-esp/32647542733.html

I also have an arduino mega in the post.
I like the Arduinos because I only get small snatches of time to work on stuff. Generally if there's any sort of problem, a bazillion people have already had it too, and solved it.
That makes it really quick to get your ideas turned into an actual machine.


----------



## sp0rk

Mr Wibble said:


> I'm not really interested in _fiddly_ soldering
> So I ordered one of these: https://www.aliexpress.com/item/V3-Wireless-module-NodeMcu-4M-bytes-Lua-WIFI-Internet-of-Things-development-board-based-ESP8266-esp/32647542733.html
> 
> I also have an arduino mega in the post.
> I like the Arduinos because I only get small snatches of time to work on stuff. Generally if there's any sort of problem, a bazillion people have already had it too, and solved it.
> That makes it really quick to get your ideas turned into an actual machine.


I know what I'll be buying once I've used/killed all my arduinos!


----------



## GibboQLD

littlejohn said:


> I'd recommend looking at replacing the Nano with an ESP8266 12F in the future, skip over this if you're familiar with it but I like that it:
> 
> - can be programmed from the same Arduino program and likely the same Arduino '.ino' file you are using with just a few small tweaks. It can also be loaded with firmware for other programming languages if you like, most are 'interpreting' languages like Lua, JavaScript and Python - they take up more space but you can program live while the device is running rather than re-compiling every time you want to test an idea.


If you have enough space left over after writing your C/C++ or Arduino code, the ESP8266 is capable of doing OTA updates -- handy when you need to tweak your sketch but physical access to the device is a bit tricky.


----------



## TheWiggman

After some thinking I think I'll just buy the bits and essentially replicate what Mr Wibble has put together. That'll get me brewing while I learn how Arduino coding works (I did C in one computing class in year 9, things have come a long way since the mid '90s and my memory ain't one of them). I only want to make a few changes, mainly being -

Add a button/switch to the front so I can turn the pump on manually. 2 ideas are -
Button+ SSD relay. -ve: Extra bits, no power when unit is offline. +ve: will look neat, requires no feedback, can program to shut off pump, SSD will allow any size pump or device
Double pole switch with feedback

[*]Change the code so the HEx won't run if the pump is off (that's trapped me a few times)
[*]Move the 3rd sensor to the HEx liquid temp, to show temp and prevent boiling in case flow is lost
[*]Add an additional 'sparge mode', which is in effect starting the pump and setting the HEx outlet temp to 80°C after I rearrange hoses
If my wife asks what the bits are for it's because I'll tell her I'm building an automated sprinkler system.


----------



## mr_wibble

Yeah, in the next version I'd like to add pump controls.

The boil-alarm sensor is a good idea. I also considered putting in some s.steel float switches in the various tanks to fail-safe the heating elements. I bought a couple, but I never got around to using them. They did seem a bit "lightweight".

I received my arduino mega yesterday, but maybe I'll wait until the ESP8266 arrives and see how much porting of libraries is necessary for it to work.
I guess the mega should be mostly just a simple re-compile.

It would not take much code to read a digital input from your switch to know if it's on/off.


----------



## TheWiggman

I've downloaded the Arduino software and had a look through Mr Wibble's code and boy oh boy, there is a hell of a lot of work there. Staggering amount. I thought I might have a chance at changing a few things if I wanted but I've found myself reading through the "how to turn on an LED" level guides to understand what the hell is going on. I'm fairly competent in VBA and was in Fortran but this is an entirely different kettle of fish. Full credit to you for sharing this code, clearly many hours of work here and much appreciated.

I was going to PM but figured this might be a broader issue. I've tried to compile the code and had a big issue with libraries (bear in mind this is my first experience with Arduino). I read the readme and uploaded the Adafruit and PDQ libraries for the graphics. However, it's stalling on the drawing of the pots with teh following error message: 

'class PDQ_ILI9341' has no member named 'drawEllipse'

Any ideas?

I took the plunge and bought a lot of components, first of which is the Uno (sitting in front of me). After some faffing about with drivers I realised why these things are so cheap... because they're counterfeit. Should have known at the price!


----------



## spog

You blokes who know about electronics etc are good value to others ( me) who have absolutely no idea of what your on about. But we are very happy to bung it in our rigs and say... look what I've got.
Brew porn rocks !


----------



## TheWiggman

I'm hearing you there spog.

As a side note for one of the temp sensors I've gone for a board mounted sensor like so: http://www.ebay.com.au/itm/172405211767?_trksid=p2057872.m2749.l2649&ssPageName=STRK%3AMEBIDX%3AIT
This has the pull up resistor and diode already mounted. No long leads or anything to coil up and can screw down easily to monitor the control box temp. Winner.


----------



## mr_wibble

TheWiggman said:


> I was going to PM but figured this might be a broader issue. I've tried to compile the code and had a big issue with libraries (bear in mind this is my first experience with Arduino). I read the readme and uploaded the Adafruit and PDQ libraries for the graphics. However, it's stalling on the drawing of the pots with teh following error message:
> 
> 'class PDQ_ILI9341' has no member named 'drawEllipse'


Sorry for the late reply, I have subscribed to this thread, but have not received a notification as yet.

You need the PDQ_GFX Libraries, these are based on the Adafruit ones, but optimised.
They can be found here: https://hackaday.io/project/6038-pdqgfx-optimzed-avr-lcd-graphics
(Note: it does say this in the README.md  )

I have added a couple of functions to the libraries, one of which is drawEllipse(), these additions can be found in the code under extra_graphics.h
However to save confusion, I have pulled a copy of the library into the project with these changes already made.
EDIT: if you add this library, you need to restart the Arduino editor (or at least you have had to in the past).

I hope this solves your problem.

-kt

PS> Post any changes you want to do and we'll nut them out here (or PM, whatever).


----------



## mr_wibble

TheWiggman said:


> I'm hearing you there spog.
> 
> As a side note for one of the temp sensors I've gone for a board mounted sensor like so: http://www.ebay.com.au/itm/172405211767?_trksid=p2057872.m2749.l2649&ssPageName=STRK%3AMEBIDX%3AIT
> This has the pull up resistor and diode already mounted. No long leads or anything to coil up and can screw down easily to monitor the control box temp. Winner.


I use the long-lead waterproof ones so I can shove it down inside one of those temperature probe housings you mount in the side of the pot.
I guess it doesn't need to be waterproof, since the stainless housing takes care of all that.


----------



## TheWiggman

Not sure if you're commenting on the fact I read the readme or not Mr Wibble, but I did follow the instructions in the readme and I still got the error. I'll check your comments about the extra code tonight (hopefully), otherwise it'll be after Christmas.
I've got 2 waterproof sensors on their way for my thermowells, the board mounted sensor is going in the control box.


----------



## TheWiggman

Tried again, exactly the same error. I did the following in this order -

Loaded updated project from Github
Deleted old PDQ_ILI9341 from library, uploaded the one you indluded in your package
I'll play around after a short holiday. Merry Christmas.


----------



## mr_wibble

TheWiggman said:


> Tried again, exactly the same error. I did the following in this order -
> 
> Loaded updated project from Github
> Deleted old PDQ_ILI9341 from library, uploaded the one you indluded in your package
> I'll play around after a short holiday. Merry Christmas.


You need at least the PDQ_GFX/ directory copied in there too, since this is where the header definition is.
The drawEllipse() is defined only in this super class, since it does not implement anything hardware-specific.

It's OK to copy in all the PDQ_* directories, and this is probably the best way forward.

In my extra libraries directory, I have:

DallasTemperature
Encoder
OneWire
PDQ_GFX
PDQ_ILI9340
PDQ_ILI9341
PDQ_ST7735
PDQ_ST7781
PID_v1

Just to streamline this, I've pulled all these libraries into the git project (now) under Libraries/
https://github.com/kt--/ArduinoMashController

So if you copy in everything from here, restart the IDE, it should build without issue.

If it doesn't:
- check you really restarted the IDE (no stray window left open or suchlike).
- check the library directory is being included in the compile
- It should be under [File]->[Preferences] then whatever is set for "Shetchbook location" /libraries

cheers,
-kt


----------



## TheWiggman

I can't see where I might have gone wrong here. See below is the dropdown of the libraries in Arduino -





I've included the error message from a compile as well as the extra_graphics.h tab selected to show you that it's there. Note that it's mostly greyed out though, I'm almost certain this is related.

Below are the folders in the directory linked as you said -




The only thing I might be missing is how you restart. The IDE is the Arduino software yes? And by restart do you mean close the program and reopen? I've rebooted/shut down the PC a number of times since trying to get this to work.

I removed the /* and */ etc. in the extra_graphics.h and now I'm getting errors in that:




Code:


Arduino: 1.6.13 (Windows 10), Board: "Arduino Nano, ATmega328"


E:\Leigh\Brewing\Arduino\ArduinoMashController-master\_20A_Kettle_Controller\_20A_Kettle_Controller.ino:45:34: warning: character constant too long for its type


 char hlt_start_timestamp[17] = { 'now\0\0\0\0\0\0\0\0\0\0\0\0\0' };


                                  ^


In file included from E:\Leigh\Brewing\Arduino\ArduinoMashController-master\_20A_Kettle_Controller\_20A_Kettle_Controller.ino:29:0:


extra_graphics.h:32: error: redefinition of 'static void PDQ_GFX<HW>::draw16bitBitmap(coord_t, coord_t, int, int, short unsigned int*)'


 void PDQ_GFX<HW>::draw16bitBitmap(coord_t corner_x, coord_t corner_y, int width, int height, unsigned short *pixel_data)


      ^


In file included from E:\Leigh\Brewing\Arduino\ArduinoMashController-master\_20A_Kettle_Controller\_20A_Kettle_Controller.ino:18:0:


C:\Users\the_w\Documents\Arduino\libraries\PDQ_GFX/PDQ_GFX.h:294:6: note: 'static void PDQ_GFX<HW>::draw16bitBitmap(coord_t, coord_t, int, int, short unsigned int*)' previously declared here


 void PDQ_GFX<HW>::draw16bitBitmap(coord_t corner_x, coord_t corner_y, int width, int height, unsigned short *pixel_data)


      ^


In file included from E:\Leigh\Brewing\Arduino\ArduinoMashController-master\_20A_Kettle_Controller\_20A_Kettle_Controller.ino:29:0:


extra_graphics.h:49: error: redefinition of 'static void PDQ_GFX<HW>::drawFourEllipsePixels(coord_t, coord_t, int, int, color_t)'


 void PDQ_GFX<HW>::drawFourEllipsePixels(coord_t x_centre, coord_t y_centre, int x, int y, color_t colour)


      ^


In file included from E:\Leigh\Brewing\Arduino\ArduinoMashController-master\_20A_Kettle_Controller\_20A_Kettle_Controller.ino:18:0:


C:\Users\the_w\Documents\Arduino\libraries\PDQ_GFX/PDQ_GFX.h:310:6: note: 'static void PDQ_GFX<HW>::drawFourEllipsePixels(coord_t, coord_t, int, int, color_t)' previously declared here


 void PDQ_GFX<HW>::drawFourEllipsePixels(coord_t x_centre, coord_t y_centre, int x, int y, color_t colour)


      ^


In file included from E:\Leigh\Brewing\Arduino\ArduinoMashController-master\_20A_Kettle_Controller\_20A_Kettle_Controller.ino:29:0:


extra_graphics.h:59: error: redefinition of 'static void PDQ_GFX<HW>::drawEllipse(coord_t, coord_t, coord_t, coord_t, color_t)'


 void PDQ_GFX<HW>::drawEllipse(coord_t x_centre, coord_t y_centre, coord_t width, coord_t height, color_t colour)


      ^


In file included from E:\Leigh\Brewing\Arduino\ArduinoMashController-master\_20A_Kettle_Controller\_20A_Kettle_Controller.ino:18:0:


C:\Users\the_w\Documents\Arduino\libraries\PDQ_GFX/PDQ_GFX.h:319:6: note: 'static void PDQ_GFX<HW>::drawEllipse(coord_t, coord_t, coord_t, coord_t, color_t)' previously declared here


 void PDQ_GFX<HW>::drawEllipse(coord_t x_centre, coord_t y_centre, coord_t width, coord_t height, color_t colour)


      ^


exit status 1
redefinition of 'static void PDQ_GFX<HW>::draw16bitBitmap(coord_t, coord_t, int, int, short unsigned int*)'


This report would have more information with
"Show verbose output during compilation"
option enabled in File -> Preferences.


----------



## mr_wibble

TheWiggman said:


> I removed the /* and */ etc. in the extra_graphics.h


The libraries from the github archive already have these changes included in them. 
That's why it's complaining about "_... blah,_ previously declared here"

It's only necessary to do the extra_graphics.h stuff to a new copy of the library, say you were starting with an updated version or suchlike.
If you undo the uncommenting changes to extra_graphics.h this will solve this problem.

I will update the comment in extra_graphics.h to reflect this.

cheers,
-kt


----------



## TheWiggman

I think I'm in over my head.

Before I got rid of the comment slashes I was getting the aforementioned 'class PDQ_ILI9341' has no member named 'drawEllipse' error (you can see the error printed in the background). Afterwards, I got the error in #41 above. I'll have another play tonight if the whole family allows so 'me' time.


----------



## mr_wibble

TheWiggman said:


> I think I'm in over my head.
> 
> Before I got rid of the comment slashes I was getting the aforementioned 'class PDQ_ILI9341' has no member named 'drawEllipse' error (you can see the error printed in the background). Afterwards, I got the error in #41 above. I'll have another play tonight if the whole family allows so 'me' time.


drawEllipse is defined in PDQ_GFX.h. This is a common file for all the LCD driver code, and PDQ_ILI3941 uses this as a template for its functions (that is, it inherits these definitions). 
All the other LCD display hardware files (~9340.h ~7735.h ~7781.h) do too.

So once drawEllispe() is defined in PDQ_GFX.h it is defined for all these others too.

Basically you can delete the extra_graphics.h file, and it should compile OK. Originally all of its content was commented out.

If then you are receiving the error about drawEllipse() being undefined, it is because the base class does not have it.
In this case, I would check that the PDQ_GFX.h has the two-part definition in the class, once in class definition (at line 136), and the function body (line 319).

If your PDQ_GFX.h *does* have these definitions, yet you still get the error, please make sure there is not some other copy of PDQ_GFX.h without the changes that is being included from somewhere else. It's not 100% clear to me how the Arduino IDE pulls in header files, nor in what order, but it seems to do extra stuff to "help".

What version of the Arduino IDE are you using? I'm on 1.6.13 Linux.


----------



## mr_wibble

I downloaded the Win32 Arduino IDE to test it. Here's a 7-step walk-through for compiling under Win32.

[1] Download the latest Arduino IDE (1.8.0 at the time of writing) "Windows Installer" from arduino.cc:
https://www.arduino.cc/en/Main/Software
Install this software with all defaults.

[2] Download a zipfile of the source from github.com: 
https://github.com/kt--/ArduinoMashController

[3] Start the Arduino IDE. 
It presents a dummy/empty project, save this. 
This ensures all the various project directories are created (they may be already, but to be sure).

[4] In your ~/Documents/Arduino folder (created by the IDE/installer) make a directory named (exactly) "_20A_Kettle_Controller".
(Alternatively, rename the file called "_20A_Kettle_Controller.ino" and the containing directory to whatever you like)

[5] Find where you saved the ArduinoMashController_master.zip. Open the .zip
Copy the content of the ArduinoMashController_master.zip into the directory from Step#4. 
Note that you _do not want_ the top level directory ("ArduinoMashController-master") of the .zip file. 
Under ~/Documents/Arduino/_20A_Kettle_Controller/ there should only be the set of source files, and a Libraries/ directory. 
If they're still inside ArduinoMashController-master/ it wont work.

[6] Copy all the _directories_ from ~/Documents/Arduino/_20A_Kettle_Controller/Libraries/ into ~/Documents/Arduino/libraries/

[7] If the Arduino IDE is still open, close it, all of it. 

Double-click on the Arduino project .ino file ~/Documents/Arduino/_20A_Kettle_Controller/_20A_Kettle_Controller.ino, this should bring it up in the Arduino IDE.
if you get an error message about it not being in the correct directory, see Step #5



EDIT: Compiling under Arduino 1.8.0 I have a fair bit more free space left, so I may be able to add a bit more to the code. I guess the newer IDE/compiler is better at optimising. It would be fun to get that bluetooth logging support in there.


----------



## TheWiggman

Thanks Mr Wibble. On Monday I had a crack at writing my own PID controller and learnt a bit in the process. I ended up going back to bare basic tutorials with simple stuff like turning the SSR's LED on and off. After a while I started to get a hang of things so commented out the 'extra_graphics.h' content and voila! it compiled.
Still waiting on everything bar the board and sensors. It'll be nice to plug in the screen and see it all happening. As a side note, when playing around with the PID example program I noticed that the output wouldn't change with an integral setting of 0 as per your program. If you haven't brewed yet it might be worth checking. All I did was
- created a setpoint, say 100
- changed the input to a fixed value of 80.
- Added a Serial.print(Output) line with a delay
Over time the Output (returned from the PID library) would remain fixed. However, changing the value of Ki to anything other than zero showed the Output increasing over time. In real life this would mean the setpoint would never be hit as the calculation would approach zero.

Once I get all the bits and pieces I'll post the build here. I'm going to make mine a 15A system and include a pump output on the control box, starting with a DPDT rocker switch so I can turn the pump on manually and add some additional protection to stop the HERMS running if the pump's off.


----------



## mr_wibble

TheWiggman said:


> [...] I started to get a hang of things so commented out the 'extra_graphics.h' content and voila! it compiled.


Ah, excellent!
It's hard debugging via internet message forums 



TheWiggman said:


> [...] As a side note, when playing around with the PID example program I noticed that the output wouldn't change with an integral setting of 0 as per your program. If you haven't brewed yet it might be worth checking. All I did was
> - created a setpoint, say 100
> - changed the input to a fixed value of 80.
> - Added a Serial.print(Output) line with a delay
> Over time the Output (returned from the PID library) would remain fixed. However, changing the value of Ki to anything other than zero showed the Output increasing over time. In real life this would mean the setpoint would never be hit as the calculation would approach zero.


Ref:

float Kp_mash = 500.0; 
float Ki_mash = 0.0; 
float Kd_mash = 0.45; 

I can confirm that these PID settings work OK in a real-world scenarios:
- 50l keggle with 2200w element
- 180l kettle with 4500w element
- 5l HERMS HX with 2500w element
- 2l domestic kettle with 2200w(?) element

Using these PID parameters I see my kettles approach the set point quite slowly (but this depends on the water volume and element power, I guess).
But of course with your mash, it's best to not ever go past that setpoint, so it really does err on the side of caution.

Sometimes if I'm watching it, I will move the target temperature by +2 degrees, just so it climbs that last few degrees quicker. But really only if I'm waiting for it.

Of course I don't think these PID settings are perfect. To be honest I would like it to approach the setpoint quicker. But at the time of writing the original version of the controller, I did lots of testing, and many times I got overshoot. I did try the PID Autotune library, but it looked like the system changed too slowly for it. My initial testing was done with a 2 litre domestic kettle, this hit the setpoint really quickly, I guess because of the small amount of water Vs element power.

If you manage to tweak it for the better, please don't keep it to yourself


----------



## TheWiggman

I'm going to do a trial setup with my PID controller and simply swap out the very-expensive-for-its-time Shinko controller (~$400) with the Arduino. I'll load similar settings in my mash tun which is only 38 litres, of which I'll circulate 15l.
This'll keep me busy until my fancy screen arrives.

Ed: I should note the idea of bumping the temp up to speed it irks me a bit. To me the idea of a PID controller is to negate having to do this. In fact, this should be pretty easy to circumvent. Eg:

If (mash_temperature <= mash_set_temperature - 2)
{
digitalWrite(MASH_RELAY_PIN, HEATER_RELAY_ON);
else
_Other PID mash logic here_

This would speed up ramp times significantly and I'm betting I wouldn't cop overshoot with my system. I'd rather move to a point quickly with a tiny bit of overshoot (say 0.5°C) than sit at a degree or two lower for too long. Reason being I think this would allow more consistent mashing.


----------



## mr_wibble

TheWiggman said:


> Ed: I should note the idea of bumping the temp up to speed it irks me a bit. To me the idea of a PID controller is to negate having to do this. In fact, this should be pretty easy to circumvent. Eg:
> 
> If (mash_temperature <= mash_set_temperature - 2)
> {
> digitalWrite(MASH_RELAY_PIN, HEATER_RELAY_ON);
> else
> _Other PID mash logic here_
> 
> This would speed up ramp times significantly and I'm betting I wouldn't cop overshoot with my system. I'd rather move to a point quickly with a tiny bit of overshoot (say 0.5°C) than sit at a degree or two lower for too long. Reason being I think this would allow more consistent mashing.


I completely agree about manually fiddling the temperature, it irks me too - the PID control is supposed to do all that for you.
But you're circumventing the PID control with that "IF" clause too 

I think it's slow to reach target simply because of the large volume of water involved. 
In my HX it can adjust the water temperature quite quickly (it's 2500watts in only about 6-8 litres), and I don't need to touch that at all.

My primary use-case for large volume is heating the HLT is between 04:30 and 05:30, so when I wander out around 6am, she's good to go.
I like these PID settings because they wont overshoot, for a small volume they're quick, and for a large volume I need to be patient, or jack up the target temp. 
Maybe I just need a "Turbo Heat" switch... yeah that sounds good.

if (turbo_heat == true && mash_temperature <= mash_set_temperature - 2)

Speaking a bit more realistically, maybe we could allow the PID parameters to be set via the GUI. 
Or maybe have a few sets, and one specifies the current volume of the HLT.


----------



## TheWiggman

Got all my bits and pieces save the clock so I thought I'd give the screen a run and see how it all goes. Here's my son giving it a test whirl for me -




Works like a charm. The GUI interface and use of an encoder instead of buttons make this setup light years ahead of the other controllers in my opinion. 
I'm going with a 15A setup so it'll cater for future upgrades should I have them. I have a 3600W element in my kettle which on a rare occasion I'll use as an HLT for things like half batches. 
Got 2 of these on their way for the HLT and mash tun - https://www.jaycar.com.au/mains-power-socket-with-cover-15a/p/PS4097
I use these on my current control boxes and will use one for the pump (1st iteration will use single pole switch the old fashioned way) - https://www.jaycar.com.au/mains-panel-socket/p/PS4094
Mounted in a sealed ABS box like so, except larger - https://www.jaycar.com.au/sealed-abs-enclosure-222-x-146-x-75mm/p/HB6132

Mad-keen to get this going. Creds again, very well programmed and thought out and appreciate you handing it out freely.


----------



## mr_wibble

No worries.

I've was thinking about the next version yesterday, watching the wort boil.


----------



## TheWiggman

Quick update in case anyone cares. I'm still waiting on the clock (found it sitting in my trolley, duh), terminal connectors and also got a simple PCB for more organised cabling. Here's the inside so far - 


The encoder was a complicated bitch to mount. I also accidentally cut too far with a slot for the switch so used some snappy arcade overlay to make it tidier. My acrylic is old and I can't don't have a completely clear piece, so until them I'm leaving the screen with the original plastic on it. A second SSR will be mounted on the cover once it turns up.


----------



## mr_wibble

Looks good.

How do those 3-pin sockets get held onto the housing ?


----------



## TheWiggman

Assuming you're referring to the 240 sockets? The black ones by screws, white one comes in two halves and the back is screwed into the front from the front. Easy as to install, only need to cut a single hole out using a hole saw.


----------



## TheWiggman

Finally got all the bits and am giving this a test run. For some reason the heating won't start. Note no little flame symbols. Both HLT and mash are 'running' in their sub menus. Any ideas Mr Wibble?


Ed: turned it awwf und then awwn again and it's working fine.


----------



## mr_wibble

Looks great!

Any time the kettle/HX isn't being fired it's because of 2 reasons:

The set-temperature is set to zero (off), or is set to be less-than what the sensor is reading.
There is a delayed-start set - but this should give an on-screen message on the first screen
So that means something was going wrong. I suspect the temperature sensors were a little slow to get going maybe?

If you get this problem again, please jot-down the current temperature readings, the set-points, calibration and any delayed-start info. Maybe then I can work out what's up.

The flame icon, etc. is basically independent of whether the heating side is actually working. All it can do is decide to raise the output pin on the SSRs and show the icon. 

-kt

PS> I just had a thought. It loads & saves the setpoint and calibration (if it changed) to the EEPROM, maybe it had dodgey initial calibration settings in the EEPROM?


----------



## TheWiggman

Here's what happened yesterday after I plugged in the RTC for the first time -
1. Turned it on, no temp readings at all. Changed a temp offset and that sensor started reading. Did the same for the other one, all good
2. No heating at all
3. Restarted, got the overheating alert on the overview page but the flame symbols were coming. Changed to a submenu and that got rid of it.

There's something a bit more sinister going on today and I think it has to do with electrical interference through the power supply.
1. Plugged in for the first time through the 12V external supply and it game me the 'sensor failure' error. Check all connections, no issues.
2. I plugged the USB on and it worked 100% - no dramas. I figured it was a power issue.
3. I already have a sensor with a board-mounted resister and cap so haven't bothered with a 4.7kΩ. I decided to put the additional resistor in place and this fixed it - sort of. The temps would flash on the overview screen as if the sensor connection was lost. They were probably showing up 30% of the time.
4. I wound the voltage down on the PS and this seemed to fix it. I took the resister out and got the connection error again, so put it back in place. Works fine now with the voltage set at 9.5V.
5. When I switched the front pump switch the screen played up (either streaking, turn off or freeze). The switch has a small globe in it which lights up when it's on. I disconnected the light and this fixed it.
6. Gave it a real-life test run. ALL GOOD. When I turned the pump on though the screen would get all streaky again which simply wouldn't work. The SSD was still running however so it appeared to be a problem with interference. I removed the pump and plugged it into a separate cord - solved.

I've been out a few times and more than once the screen froze or went white but I could hear the PID cycling the mash heater. Turning it off then back on fixes it. Something is causing the screen to play up and everything is pointing to an AC issue. Any ideas? I've got an EMI filter, would putting this inline help?

Additionally, recall my comments regarding the PID. It's taken far too long to reach the set temp and is stalling at 57.5°C when the target is 59°C. It's at 500 / 0.1 / 0.45 but this needs work with my system. Changing the I to 0.1 has made a difference but still taking about 45 mins to move the last 2°C. I've called brewday off for now, hopefully I can get on top of these two issues.


----------



## TheWiggman

Hmm, well I tried a few things today and it's not promising.

Installed EMI filter inline with the power supply, no change
Installed a USB (Apple) power source inside the box the power the Nano only, and plugged the bulb on the switch back in. No love.

Something's going on. I've got wire spaghetti in there at the moment while I wait for a delivery of terminal blocks and the like, so maybe there's some additional resistance on connections or something that might be causing the problem but it is strange. If I can't use that switch it really defeats the purpose of the whole control box.


----------



## mr_wibble

TheWiggman said:


> Here's what happened yesterday after I plugged in the RTC for the first time -
> 1. Turned it on, no temp readings at all. Changed a temp offset and that sensor started reading. Did the same for the other one, all good
> 2. No heating at all
> 3. Restarted, got the overheating alert on the overview page but the flame symbols were coming. Changed to a submenu and that got rid of it.


It's trying to read the 3x sensors all the time, no matter what state it's in. So doing another operation wont "nudge" the sensors.
Although it will only re-paint them if there's a change.

I'm pretty sure #3 is a bug, I get it sometimes too.
Probably there is a race-condition somewhere between: showing of the alarm, reading the sensor (which takes about 1.2 seconds), and not re-painting the screen unless there's a change.

Were you able to set the date+time for the RTC, and did it remember that time over a power-cycle?



TheWiggman said:


> There's something a bit more sinister going on today and I think it has to do with electrical interference through the power supply.
> 1. Plugged in for the first time through the 12V external supply and it game me the 'sensor failure' error. Check all connections, no issues.
> 2. I plugged the USB on and it worked 100% - no dramas. I figured it was a power issue.
> 3. I already have a sensor with a board-mounted resister and cap so haven't bothered with a 4.7kΩ. I decided to put the additional resistor in place and this fixed it - sort of. The temps would flash on the overview screen as if the sensor connection was lost. They were probably showing up 30% of the time.
> 4. I wound the voltage down on the PS and this seemed to fix it. I took the resister out and got the connection error again, so put it back in place. Works fine now with the voltage set at 9.5V.
> 5. When I switched the front pump switch the screen played up (either streaking, turn off or freeze). The switch has a small globe in it which lights up when it's on. I disconnected the light and this fixed it.
> 6. Gave it a real-life test run. ALL GOOD. When I turned the pump on though the screen would get all streaky again which simply wouldn't work. The SSD was still running however so it appeared to be a problem with interference. I removed the pump and plugged it into a separate cord - solved.
> 
> I've been out a few times and more than once the screen froze or went white but I could hear the PID cycling the mash heater. Turning it off then back on fixes it. Something is causing the screen to play up and everything is pointing to an AC issue. Any ideas? I've got an EMI filter, would putting this inline help?
> 
> Additionally, recall my comments regarding the PID. It's taken far too long to reach the set temp and is stalling at 57.5°C when the target is 59°C. It's at 500 / 0.1 / 0.45 but this needs work with my system. Changing the I to 0.1 has made a difference but still taking about 45 mins to move the last 2°C. I've called brewday off for now, hopefully I can get on top of these two issues.


EMI filter? I just don't know. I've no experience with them at all.

The screen going white and stuff - this sounds like a lose wire, or bad connection etc.
Of course it can also be a dodgey component. I only ever say that once during development, and I think it was because a wire popped off.
Also obviously it's not ideal that the sensors are not working properly.

Do you think it's worth making some debugging software that just loops through the activity logging to the screen?
At least to get the DS18B20 sensors sorted out.

How are you connecting to the Arduino? Do you have screw-terminals for the connections? It's quite easy for those pin-sockets to have a poor connection.


----------



## TheWiggman

I'm not sure it is a connection issue because problems occur when the 240V switch is turned on. These problems didn't occur when it was powered via USB and there was no other AC wiring nearby. Maybe it is, I suppose I'll find out when it's wired properly. 
Most connections are through screw terminals onto a simple strip board with the component wiring coming off the strip board. Plugged into pins via DuPont female plugs which I've checked over. The sensors are plugged with 3.5mm jacks and I've soldered all those bits together and they're schmicko. 
It's heating up now. The HLT is also plugged in and that functionality is awesome. Still not happy with the PID settings (referred to Adr_0's recommendations) so that part will be a WIP.


----------



## malt junkie

What type of relay are you using for the pump? If your using a mechanical one change it out for an SSR. Once you get your terminal blocks in, get real tidy with your cabling, try and keep HV and LV as separated as is possible in the confined space. Until you do this you'll continue to chase ghosts in the machine.


----------



## mr_wibble

Is there a rough guide as to how far apart they should be Malt Junkie ?

Mine ended up separated, but it just turned out that way, not by design.
I guess you could wire it up with coax


----------



## mr_wibble

TheWiggman said:


> The HLT is also plugged in and that functionality is awesome. Still not happy with the PID settings (referred to Adr_0's recommendations) so that part will be a WIP.


Yeah, I'm hoping you'll work it out better than I did 

Right now I'm making a mixer bar for the HLT.


----------



## TheWiggman

malt junkie said:


> What type of relay are you using for the pump? If your using a mechanical one change it out for an SSR. Once you get your terminal blocks in, get real tidy with your cabling, try and keep HV and LV as separated as is possible in the confined space. Until you do this you'll continue to chase ghosts in the machine.


No relay, just a switch. Full plans to clean up the shebang once the bits come in, at present it's a total mess.
I spoke to an electrical engineer at work and he suggested to hook the DC -ve to earth, as there could be some floating earth feedback to the DC side. If I get some time tonight I'll give that a try.


----------



## TheWiggman

I may have found the problem. Considering everything seemed to go awry when I connected 240V and specifically when operating the switch (which switches the active to the 10A socket on the back) I assumed that there must be an issue there. I disconnected the active line to the switch and viola - the flickering stopped. After that I removed the pullup resistor which seemed to improve the issue and bam - works!
If you look at post 52 you can see that the switch ends up sitting directly above the Arduino when the lid is closed, if anything between the supply and the Nano. Seems there's some interference here which I've fixed. I'll have to add an extra relay and run DC from the power supply through the switch to switch the relay. I'm backing this will put my rocker switch back in action.


----------



## Lionman

How hard would it be to include valve control, water level sensors and actuator control?

A system like this could be enhanced to provide similar functionality to a Brewie.


----------



## mr_wibble

It's fairly simple to operate these kind of sensors & actuators from an Arduino.

I want to make a "V2" of this on an Arduino Mega, which has a bunch more resources. I'd like to be able to do some geeky stuff, like plot temperature change curves, operate pump switching from the panel, etc.


----------



## TheWiggman

Doing my first brew with this controller today Mr Wibble, a Dortmunder Export. I've out so much faith in it I've left the house for the brew to do its thing on a 4 step program. Fingers crossed.


----------



## Adr_0

How's it going?


----------



## mr_wibble

TheWiggman said:


> Doing my first brew with this controller today Mr Wibble, a Dortmunder Export. I've out so much faith in it I've left the house for the brew to do its thing on a 4 step program. Fingers crossed.


Geeze, I feel pressured.  
I've only ever bench-tested that bit (I watched it switch the 4x set-points over a 15 minute test).

Did it work OK?


----------



## TheWiggman

Well I ended up with a 1.046 wort so all indications are that it's fine. Some feedback on it tjough:
1. The mash went quicker than I thought and I was away for about 4h. It was done and dusted before I got back. I set the mash out at 120 mins but it had finished well earlier. The mash temp had dropped to about 71°C. No biggie, bit I'd prefer it to simply sit on the final mash step whatever that is. I might try my programming skills at this one. 
2. The HLT defaults to the last temp and turns on following power up. After I finished the sparge, I fed the chooks the spent grain the filled the mash with water. Started the pump, set the mash temp to 60°C aaaaand... cooked the HLT element. It was glowing orange. It no longer has the nice stainless sheen to it and haven't tried to run it since but supposedly had run dry protection, it definitely tripped the breaker. Error on my behalf, probably worth forcing a restart following a reset. Still not sure if this will solve more issues than it causes. 
3. P=700 and I=0.05 was excellent for ramping but only got within 0.1°C of target at >60°C and no overshoot. There's enough loss through my pipes (evident with the temp drop following mash out) that warrants more integral in my opinion, still work to be done here. 
All in all not bad for a first effort, best of all I could take off during the day and I was ready for sparge on my return. Some minor tweaks and it'll be a pearler.


----------



## mr_wibble

TheWiggman said:


> Well I ended up with a 1.046 wort so all indications are that it's fine. Some feedback on it tjough:
> 1. The mash went quicker than I thought and I was away for about 4h. It was done and dusted before I got back. I set the mash out at 120 mins but it had finished well earlier. The mash temp had dropped to about 71°C. No biggie, bit I'd prefer it to simply sit on the final mash step whatever that is. I might try my programming skills at this one.


I'm not sure I understand you 100% - is there something wrong with the timing? Did not run for 120 minutes?
It definitely stops the mash temperature after step#4 of the mash cycle. The idea was that if you want to keep the final temperature, set it for a really long time.

The bit of code around "if (current_step == 4)" controls this. About line 1110.



TheWiggman said:


> 2. The HLT defaults to the last temp and turns on following power up. After I finished the sparge, I fed the chooks the spent grain the filled the mash with water. Started the pump, set the mash temp to 60°C aaaaand... cooked the HLT element. It was glowing orange. It no longer has the nice stainless sheen to it and haven't tried to run it since but supposedly had run dry protection, it definitely tripped the breaker. Error on my behalf, probably worth forcing a restart following a reset. Still not sure if this will solve more issues than it causes.


The remembering of the temperature settings is done via the function writeFloatToEEPROM() and readFloatFromEEPROM().
These functions are also used for storing (and reading) the calibration data, so you'd need to remove the call to get it, and make hlt_set_temperature=0, around line 427. 
I really like it that it pre-loads the set temperatures on start. But I am super-paranoid about keeping that element under water. Maybe a float-switch might be a good addition.



TheWiggman said:


> 3. P=700 and I=0.05 was excellent for ramping but only got within 0.1°C of target at >60°C and no overshoot. There's enough loss through my pipes (evident with the temp drop following mash out) that warrants more integral in my opinion, still work to be done here.
> All in all not bad for a first effort, best of all I could take off during the day and I was ready for sparge on my return. Some minor tweaks and it'll be a pearler.


I've read the absolute accuracy of the DS18B20 temperature sensor is only around +/- 0.5C, so if you're within 0.1C, I think you're pretty much home & hosed.
I might run a test on P=700, I=0.05 and D=0 to see how it performs in my kettle. I'm pretty much happy if it's within one degree.


----------



## Adr_0

Just a silly question... What is the absolute program value of the error when there is a temperature difference of 1°C? The reason I ask this is that generally inputs and outputs are scaled to 0-100%, and matched to the setpoint scaling. So your 1°C temperature error may be getting scaled to 0.01 for example. 

The sous vide PID examples have default gains of 200—500. If you have an error of 1°C, multiplied by 500 (500, then limited to 255 output in the program) would you be at 100% element power? Or is the error scaled back to %, so more likely a 5/255 or 2% output? 

Very curious to know. Might explain how 0.1°C temperature error gets lost in the numbers (0.1 x 0.01 scaling x 700 gain =0.7/255 = basically nothing.

If you check this - on your computer, can you hover over the 'error' and get a value, and force temperature/setpoint? - then we can further hypothesise.


----------



## TheWiggman

Yep, ran for the 120 minutes I'm assuming. For mine though that last step doesn't need a time - it should sit at it until I'm ready to sparge. If I do a 3 step mash, same story. No biggie and is just what I want in the controller.

I too am paranoid about the element being submersed but I simply didn't think about it in this instance because I've never had to worry about it before (I always had to physically turn the element back on). I like the fact it saves the temp - no issue. What I'd prefer though is forcing it on instead of it automatically turning on. Like I said in post #31, a 'sparge mode' or similar would be in order because I found myself playing around with a few things.

Here are 2 'upgrades' on the table -

Considering my AC induction issue I'm going to run the pump off a relay meaning the switch will have 12V running through it. I'll send another wire back to the Arduino to indicate the pump status. This will make sparging a lot better because as soon as I turn off the pump I'll set it so it disables the HEx element.
I've got a stainless float switch in my box of tricks. For fear of complicating things I didn't want to use it, but it's probably worth installing now (either in series with the relay DC or as an additional input).
I'm thinking of adding a switch on the back of the box to turn the Arduino on and off. I like the idea of local control rather than reaching for the power point. I was scampering hard when I saw the element glowing.

Regarding PID settings, watch out for overshoot. I figure the reason I haven't been suffering from it is that I have an ideal heating scenario where there is effectively zero lag between the power and change in output. If I had a larger volume HERMS or larger heating element it would be a different story. My next change was going to be P = 600, I = 0.075 as I know I get overshoot with I = 0.1. I check my temps with a Thermapen each brew day so I adjust the temps to suit, I'm confident I'm hitting exact temps.


----------



## TheWiggman

Adr_0 said:


> Just a silly question... What is the absolute program value of the error when there is a temperature difference of 1°C? The reason I ask this is that generally inputs and outputs are scaled to 0-100%, and matched to the setpoint scaling. So your 1°C temperature error may be getting scaled to 0.01 for example.
> 
> The sous vide PID examples have default gains of 200—500. If you have an error of 1°C, multiplied by 500 (500, then limited to 255 output in the program) would you be at 100% element power? Or is the error scaled back to %, so more likely a 5/255 or 2% output?
> 
> Very curious to know. Might explain how 0.1°C temperature error gets lost in the numbers (0.1 x 0.01 scaling x 700 gain =0.7/255 = basically nothing.
> 
> If you check this - on your computer, can you hover over the 'error' and get a value, and force temperature/setpoint? - then we can further hypothesise.


This is doable if it's plugged live into the PC but I don't have a safe method of doing this. My PC is in a different room and I don't have a USB out on the box. With curious kids I no longer leave live conductors exposed when troubleshooting.
Yeah I agree with your logic there, I was thinking similar but didn't know the calcs behind it. Wondering if I went back to I = 0.1 I'd overshoot. Could be that the happy medium is to max out P and 'tolerate' a 0.1°C error.


----------



## Adr_0

TheWiggman said:


> This is doable if it's plugged live into the PC but I don't have a safe method of doing this. My PC is in a different room and I don't have a USB out on the box. With curious kids I no longer leave live conductors exposed when troubleshooting.
> Yeah I agree with your logic there, I was thinking similar but didn't know the calcs behind it. Wondering if I went back to I = 0.1 I'd overshoot. Could be that the happy medium is to max out P and 'tolerate' a 0.1°C error.


If this is the actual problem, the scaling could be changed, but it might end up being a rounding error somewhere (even in the SSR where it doesn't have the resolution to get the 1-2% power cycle - ie it's off before it gets temperature up). You're using doubles everywhere which should have the resolution - but might be worth checking the 'chain' to see if there is rounding somewhere. 

Funnily enough, the answer may still be moarr gainz - basically enough to get it over the threshold of where the SSR and element can provide some Joules. Integral is accumulating output, and at some point it's enough to get over the threshold for the SSR. At the stabilising end and with the low I gain being used, it should be fine.

Your main risk with Integral -where it will hurt you - is when output is added as it's still ramping. Very hard to get that balance, but it's absolutely achievable - you must be pretty close around 0.05 - 0.1. 

With P gain, you have a lot more latitude for error. If you have very little lag, it will be harder to overshoot... but enough gain should get you in a pretty good place.


----------



## Adr_0

Actually when I mention SSRs, have you got the data sheet for yours? You will normally find there is a limit to how fast they can turn on and off - likely due to slew rate limitation.

This may be in cycles (eg 1.5 cycles) or a time with 50/60Hz assumed. Mine for example is 1.5 cycles, so 30ms on 50Hz.

The reason I mention this is your time proportional output should be in synch with this. So for 30ms, assuming we want 1% output, the time 'window' should be 3 seconds. If it were 2 or 2.5 seconds, it might not have switched on within 20ms (1% output) - not enough ramp/hold time in the SSR - so you might lose that resolution.


----------



## mr_wibble

Adr_0 said:


> Actually when I mention SSRs, have you got the data sheet for yours? You will normally find there is a limit to how fast they can turn on and off - likely due to slew rate limitation.
> 
> This may be in cycles (eg 1.5 cycles) or a time with 50/60Hz assumed. Mine for example is 1.5 cycles, so 30ms on 50Hz.
> 
> The reason I mention this is your time proportional output should be in synch with this. So for 30ms, assuming we want 1% output, the time 'window' should be 3 seconds. If it were 2 or 2.5 seconds, it might not have switched on within 20ms (1% output) - not enough ramp/hold time in the SSR - so you might lose that resolution.


Wow that's really interesting, I didn't know SSRs can have timings in the order of seconds. I just assumed it was in the order of milliseconds.

The PID algorithm is used to "time-slice" a 5000 millisecond period of heater-time. Very slow Pulse Width Modulation (PWM) if you like.

So if we are seeing a rounding-to-zero, or limitation of SSR switching speed for small times, it may be worthwhile to change the period to something bigger (HEATER_WINDOW_SIZE, line 103).
If I understand the numbers correctly, changing this period to say 10000ms would make the 1% output a 6 second window-part rather than 3 sec. Obviously there is a trade-off in responsiveness here, since now you can only plan 10 seconds at a time, rather than 5.


----------



## mr_wibble

Adr_0 said:


> You're using doubles everywhere which should have the resolution - but might be worth checking the 'chain' to see if there is rounding somewhere.


There's was a couple of floats used for the PID parameter variables, I've promoted these to doubles - all the Kp_mash and Kp_hlt (and the others).

I'll have to do some re-testing, but will check in the changes afterwards.

I left all the UI settings & what-not as floats. Given they all don't handle anything past 2 decimal points, there wont be a problem there.


----------



## Adr_0

Mr Wibble said:


> Wow that's really interesting, I didn't know SSRs can have timings in the order of seconds. I just assumed it was in the order of milliseconds.
> 
> The PID algorithm is used to "time-slice" a 5000 millisecond period of heater-time. Very slow Pulse Width Modulation (PWM) if you like.
> 
> So if we are seeing a rounding-to-zero, or limitation of SSR switching speed for small times, it may be worthwhile to change the period to something bigger (HEATER_WINDOW_SIZE, line 103).
> If I understand the numbers correctly, that would make the 1% output a 6 second window-part rather than 3 sec. Obviously there is a trade-off in responsiveness here, since now you can only plan 10 seconds at a time, rather than 5.


SSR response should definitely be in milliseconds. But its should be in synch as much as possible. From the datasheet, say it works out to 30ms and we want that for 1%, x 100 = 3000ms or 3s should be our window. 6000ms or 6s would give 0.5% resolution. I would not recommend more than that. I would not have it set to 2s, 4s, 5s or 7/8/10s though for a 30ms SSR minimum hold. 

A little bit of heat loss before the temperature sensor is ok - it might keep you above 1% under steady conditions. From the sensor back to the mash tun will result in an offset though, so insulate this section.


----------



## TheWiggman

I have a genuine FOTEK 40A and ripoff 25A with a new one in the mail.

http://www.fotek.com.hk/solid/SSR-1.htm

Still struggling with the idea that the Chinese are ripping off their already low quality products.


----------



## Adr_0

TheWiggman said:


> I have a genuine FOTEK 40A and ripoff 25A with a new one in the mail.
> 
> http://www.fotek.com.hk/solid/SSR-1.htm
> 
> Still struggling with the idea that the Chinese are ripping off their already low quality products.


Lol, yeah it's a little ridiculous. Still, there are a lot of businesses in China and some good stuff - so lots of business opportunity I guess. 

Looks like a <10ms response time to turn on. This should actually be the time for the LED in the photocoupler to turn on, and the photoresistor (or whatever) tu pick this up and send voltage to the AC zero switching circuit. 

At 50Hz, a half wave is 10ms. So as long as your PID signal it holding ON when the signal gets to the zero crossing detection, it will turn on the element. If it's then OFF within the half wave, it will only turn off at the next zero crossing, so a period of 10ms. That's zero switching and 50Hz, not really an SSR spec. 

So really, if you have a 10ms on signal and an 8s response time, even if it gets the signal early it should still be responding (8ms passed), on (from the input) and going past a zero crossing, so the element turns on.

So what if the input signal is less than 10ms, say 8s? Is the response time were 6s, you've got 2s of overlap to get that zero crossing in and 10ms of element time. But you could also miss it completely - with your input off before the zero crossing. 

So, really, your minimum input time should be something like 12ms. How's do you do this? Probably a few things to consider:
-you can keep the PIDoutputlimits to (0,255) (doubles) and recognise that for certain outputs it won't turn on the SSR
-You could set the outputs to (1,255), and the slice/window to be whatever 1/255 would be to equal 12ms (3s would benefit appropriate)
-you could multiply the output by 2.5 to normalise the 0-255 to 0-100, but I would recommend rolling the gain back to 400-500.

There are probably some other things too - but basically any output at the moment that is less than 10ms probably won't do anything.


----------



## Adr_0

Are you able to step through the code line by line (like pressing F5) with setpoint and input set, and see what the output and error are for a single iteration of the PID compute loop?

Perhaps 'input' and setpoint are not the correct variables to force but whatever you can set as far upstream as possible (even a voltage number from the temperature).


----------



## mr_wibble

Adr_0 said:


> Are you able to step through the code line by line (like pressing F5) with setpoint and input set, and see what the output and error are for a single iteration of the PID compute loop?
> 
> Perhaps 'input' and setpoint are not the correct variables to force but whatever you can set as far upstream as possible (even a voltage number from the temperature).


Hmm, I guess I could make a "debug" version that logged them to the screen.
AFAIK (and currently) there's no real debug features with Arduino.

But being a coding-carmudgeon, I'll warrant that a good debug-log is better than any fancy debugging IDE.


----------



## TheWiggman

Adr_0 said:


> Are you able to step through the code line by line (like pressing F5) with setpoint and input set, and see what the output and error are for a single iteration of the PID compute loop?
> 
> Perhaps 'input' and setpoint are not the correct variables to force but whatever you can set as far upstream as possible (even a voltage number from the temperature).


Could do. The way I did this prior to using the controller in this thread was to just run the PID program by itself and write to the serial port, reading real-time though the software. If you want a single iteration just upload and put a pause in the software after the PID output is calculated.


----------



## Adr_0

Cool. It would become interesting to see 20°C error (approx), 1 and 0.1 if possible with just P of 500-1000 ans I, D set at 0.

This way the output would be known, and we can consider the next steps from there.


----------



## TheWiggman

No promises I can do this in the short term, but if/when I respond I'll put it in the PID thread for you.


----------



## TheWiggman

Here's the layout nearly complete. I'm going to hook up a 1.3A fuse to the 10A socket and add a relay so I can use the program to control the pump as a later date. Haven't been able to get home in time.e to catch Jaycar open.


----------



## mr_wibble

Looks good. I'm envious of your plug-wiring 

What I would like to add to mine is a USB-socket so I can plug-into the Arduino without taking the cover off.


----------



## TheWiggman

I was thinking exactly the same thing regarding the USB. If you find a good one that's 'plug and play' let me know. I have some panel mount USB sockets but they go to a pin layout for a motherboard.

I had a quick effort at it again yesterday and I'm getting sensor errors AGAIN. Shitty. The only thing different is I removed a jumper between the DC -ve and mains earth. I might put it back in place and play around with a few more pullup resistors. Also might try and move that earth cable away from the 10A socket.


----------



## Adr_0

TheWiggman said:


> 1488693880897.jpg


So is the temperature sensor the black, green brown coming across from the top left? It looks rather long. Is this not shielded at all?


----------



## TheWiggman

No it's the red, black and yellow cables on the top right with the two external 3.5mm jacks. The 3 you mention are the for the SSRs with the black being -ve.


----------



## Adr_0

Ok, cool. So you've got a couple of sensors? Have you tried putting 100nF ceramic capacitors between the ground and supply of each sensor? With a digital signal it would not be a good idea to put them between ground and data.

At the socket would probably be best - with the goal to filter out spikes from inside your main box before they get to the sensors.


----------



## mr_wibble

Adr_0 said:


> Ok, cool. So you've got a couple of sensors? Have you tried putting 100nF ceramic capacitors between the ground and supply of each sensor? With a digital signal it would not be a good idea to put them between ground and data.
> 
> At the socket would probably be best - with the goal to filter out spikes from inside your main box before they get to the sensors.


Is there something special about 100nF ceramic caps Addr_0 ?
How come we use such small capacitors? Would bigger or smaller also work?
(sorry for the stupid question, but I didn't do any more EE after first year).


----------



## malt junkie

Mr Wibble said:


> Is there something special about 100nF ceramic caps Addr_0 ?
> How come we use such small capacitors? Would bigger or smaller also work?
> (sorry for the stupid question, but I didn't do any more EE after first year).


Smooth out power delivery, too big is a waste, too small will have little effect.


----------



## Adr_0

Mr Wibble said:


> Is there something special about 100nF ceramic caps Addr_0 ?
> How come we use such small capacitors? Would bigger or smaller also work?
> (sorry for the stupid question, but I didn't do any more EE after first year).


Don't ask me, I'm not an electrical engineer... 

100nF is a pretty common size for bypass capacitors. So is 220nF and 10nF. Having at least something there gets you 90% there - if noise is an issue - as it allows AC (likely high frequency) sitting on the DC lines to flow through the capacitor to ground rather than into your sensor - hence the term 'bypass capacitor'. 

The sizing/capacitance is related to reactance, ie resistance to current flow. Those sizes will have a reactance pretty high at 50Hz - 15-30,000ohms - which means very little current will flow through, but some will still get through (good). 

Hopefully you don't have a lot of AC current on your DC supply lines... 

But at higher frequencies, a reasonable amount of current will pass through if it's there in AC form. Spikes and RF interference should fall into this category, while mains hum will fall into the former - it should help a bit. 

I wouldn't see too much disadvantage in going a 220 or 560nF - but most circuits out there are perfectly fine with 100nF.


----------



## TheWiggman

Well wicked. I got some 100mF caps from work because that's all they had. Put one across the 3.5mm jacks as well as a 1.4k resistor from the signal to power. Power up and boom: result. Finally in a state where I'm ready to brew.


----------



## Adr_0

TheWiggman said:


> Well wicked. I got some 100mF caps from work because that's all they had. Put one across the 3.5mm jacks as well as a 1.4k resistor from the signal to power. Power up and boom: result. Finally in a state where I'm ready to brew.


Shit hot. Go RF theory!


----------



## mr_wibble

I just committed some minor changes to the code base:
1/ Fix that initial bogus temperature alarm message. With a trusty hair-drier I can confirm that alarms come and go, as planned.
2/ Set the PID parameters to P,I,D = 600, 0, 0 as per TheWiggman's experimental results - I'm going to test these myself in a sec.

With the Arduino IDE 1.6.13 there's now about 2000 bytes of programming space left. Previously (IDE 1.5.x) this was in the low-hundreds (IIRC).
Maybe we can add a bluetooth write-only stream of data. That way a phone (or pc, whatever) could log temperatures, etc. 
I guess we could log heater-coil activations and step-mash steps too.


----------



## Adr_0

Have you had any temperature error issues like TheWiggman?


----------



## mr_wibble

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.


----------



## TheWiggman

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.


----------



## Adr_0

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.


----------



## Adr_0

What sort of boards are you guys using, and approx how much memory (flash?) is being used by the program?


----------



## mr_wibble

Arduino Nano, knockoff, which can be had for about $5.
There's also handy screw-terminal boards

Writing from memory: 32k non-volatile "ROM", 2k RAM
About 16MHz (or 4x the clock speed of a 1983 Microbee)

These boards are basically the same as the Arduino UNO, except in a smaller format.


----------



## Adr_0

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.


----------



## Moad

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


----------



## Adr_0

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...


----------



## mr_wibble

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).


----------



## Adr_0

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.


----------



## mr_wibble

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.


----------



## Adr_0

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...


----------



## mrcopierman

[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]


----------



## mr_wibble

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).


----------



## mrcopierman

cool i will post my build when i get all my components good to hear all is working well.


----------



## Adr_0

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...


----------



## mr_wibble

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.


----------



## koshari

can this be ported to an "Uno" ??
as i have a couple lying round and size isnt an issue on my enclosure>


----------



## mr_wibble

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.


----------



## koshari

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.


----------



## Adr_0

koshari said:


> 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.


Download the Arduino IDE - https://www.arduino.cc/en/main/software

there are some build in libraries, but you will also need to download some.

i have a serial display which uses 4 wires (5V, GND, SDA, SCL) and it requires a LiquidCrystal_I2C library and a quick 'sketch' (program) to find out the specific address on the SDA bus - given you can have multiple I2C devices connected to the same wire.

Libraries are basically references to particular devices, that allow you to call specific functions. you have an #include ___ line at the start of your code, a single call line to a variable (e.g. LiquidCrystal_I2C lcd = LiquidCrystal_I2C(0x27,20,4); and then things like lcd.print(adsfsdfa) will allow you to put something on the LCD.

The biggest issue I've had is these GODDAMN TERMINALS THAT ARE TOO BIG FOR THE GODDAMN JUMPER LEADS BUT HAVE ZERO RANGE OF MOTION SO CAN ONLY FIT VERY SPECIFIC WIRE SIZES< UUURRRGHGHHGH


----------



## Adr_0

So much rage...


----------



## mr_wibble

My favourite is when you look down, and the screw out of the terminal block has disappeared!


----------



## TheWiggman

I finally installed the relay to my pump in my control box and gave it a whirl on the weekend. STILL causes screen freezing issues when I switch the pump or plug in a power cord (even though the power cord may not be connected to anything). I think it's beyond help now, there must be something with the screen that can't handle it. Interestingly I left it to do it's thing and it went through the whole mash cycle with a frozen screen so it appears to be a screen issue only. For the brewing side of things this isn't a concern, but is pretty irritating because I can't see what the current temps are. I might install a switch to the VIN on the screen and see what happens if I cycle it on and off. If this resets it that's a lot better than having to reset the program.


----------



## Adr_0

Do you have a cap on the power supply terminals for the screen? Every supply needs them. 

I assume that your screen print functions are part of the calculation loop?


----------



## mr_wibble

When you say "relay" do you mean solenoid-type relay with an electric-coil?
When these switch-back, they can produce a bit of back-EMF to the circuit. 

There's a few ways to fix this. I thought it was always diodes, but some of these links suggest other parts too.
https://progeny.co.uk/back-emf-suppression/ . 
http://forum.arduino.cc/index.php?topic=309096.0 . 
https://arduino-info.wikispaces.com/RelayIsolation?responseToken=7ee75136fab867114c0305e180abed48 . 

Can you upload a photo of the relay in-situ?


----------



## Adr_0

Yeah good point - the relay modules from Jaycar (5V) already have back EMF protection, are cheap and 10A/240V rated so these are a good pick.


----------



## TheWiggman

Here's the relay in question. Bear in mind I'm not getting the issues now that the relay is installed, I've always had them. The screen would play up simply by plugging in an IEC power cord to one of the heater outputs (even if the cord isn't plugged into the kettle - i.e. open circuit).
I have a cap on the power supply terminals, but not a separate one for the screen. I suppose I could give that a go.


----------



## Adr_0

TheWiggman said:


> Here's the relay in question. Bear in mind I'm not getting the issues now that the relay is installed, I've always had them. The screen would play up simply by plugging in an IEC power cord to one of the heater outputs (even if the cord isn't plugged into the kettle - i.e. open circuit).
> I have a cap on the power supply terminals, but not a separate one for the screen. I suppose I could give that a go.


Basically between the 5V and ground wherever you've got something digital.

Any loose data connections to the screen? Does pushing in a plug distort the box or move wires inside?

These are the relay modules:
https://www.jaycar.com.au/arduino-compatible-5v-relay-board/p/XC4419

The other thing is, is the display a parallel or I2C? 

And is your power supply regulated? I there heaps on the 5V bus putting too much load on the Arduino, lowering the supply voltage?


----------



## TheWiggman

I'm gonna need help here I think Mr Wibble. I fried my old Uno and have since upgraded my PC to Windows 10. The program you wrote compiles fine but for some reason I keep getting a 'programmer not responding' error regardless of how I try to connect to the unit.

Driver has been updated, Windows detects the Uno under port 'USB-SERIAL CH340 (COM5)'
Port is recognised in the IDE, correct port (5) is selected
Selected board is 'Arduino/Genuino Uno'
If I try to update the firmware when I test the connection it says "Programmer not responding"
After compiling, I get an error "avrdude: stk500_recv(): programmer is not responding" 
I've uninstalled then reinstalled the IDE, no change
I don't know if it's a Windows 10 issue with the bootleg driver or what but I'm going mad. Any ideas?

Ed: found it out. Had to select a different board than a Uno. Geez of the web didn't exist I would have killed myself before stumbling across that


----------



## mr_wibble

I've not used windows 10 with arduino.

Ok you got the #1 cause - the "Selected Board" in the IDE.

From what I've read, there are 2x USB drivers - one for genuine Arduino, and one for clone boards.
The "CH340" driver is for for clone boards - you have a clone board right?

There is an excellent "Have I bricked my Arduino" thread here - https://arduino.stackexchange.com/q...-arduino-uno-problems-with-uploading-to-board .
It covers some basic tests to runs to verify your board is OK (the loopback etc.)

FWIW: I have bought some cheap clone boards that were stuffed out-of-the-box and others where a certain pin just didn't work. (But this is very much the exception, 99% of the clone boards are OK).


----------



## TheWiggman

The driver is fine, and yes it is a clone. I have 3 x Unos but it looks like they have the wrong bootloader in them. I needed to select Duemilanove or Diecimila board to upload. I'll burn the correct bootloader on them tonight, only worked it out just before hitting the sack.


----------



## TheWiggman

I'm still getting a heap of hassles with this controller. I changed the sensor which worked during a test run, but as soon as I went to use it for some reason it kept freezing. After a few restarts it came good but then kept freezing until I got a white screen. I gave up and got the STCs out.
The encoder was playing up but I noticed there was a loose pin - fixed. There seems to be some issue with the 5V circuit in my opinion and there is some interference with the 240V system. As soon as I plug it in to a USB everything is fine. From the 12V power supply however... problems. I've bought a 12V to 5V converter so hopefully this will fix the issue. Then it won't be the Arduino powering everything in the circuit (which is 3 x sensors, RTC, screen and 2 x SSR) and I'm hoping this will take the load off the onboard regulator. Otherwise I'm out of ideas and starting the getting pretty frustrated considering all the effort I've put into this.
Ed: I've tried 3 different Unos, all with the same result


----------



## TheWiggman

Good news - converter has brought the unit back to life. Goes straight into the 5V pin on the board. I still get the occasional freeze if things are plugged into the 240V sockets but it looks like all the other niggles have been solved.
Back to brewing!


----------



## mr_wibble

Exactly what sort of power supply are you using?
I don't get these sort of issues, the supply I use is a little one for powering LED light strings (AFAIK - that's what the ad said).
It looks like a mini-PC power supply.


----------



## TheWiggman

Probably the same as you, it's a 2A job from eBay. See this post. That's a fair point though, it could be a power supply issue. I've measured the output voltage and have wound it from 9V - 12V which it seems to put out stably on my multimeter at least.


----------



## Adr_0

This is what I've done with mine. I'm not sure that it will be perfect but hopefully it will do the job for the following reasons:
- decent quality 15W power suppply, 11-15V at up to 1.3A directly driving the Nano
- A 3A, 5V fixed voltage regulator off this line driving the temp probes, display, relays
- 5V/ground buses with 330nF ceramic caps on each end and also will have 330nF caps on each user of 5V, as close to the user as possible, to absorb any RF/switching interference





My application is a heat/cool predictive on/off controller with data logging.


----------



## mr_wibble

Looks good.
Any chance you could upload a quick circuit diagram of how to wire in the voltage regulator ?

cheers,
-kt


----------



## Adr_0

mr_wibble said:


> Looks good.
> Any chance you could upload a quick circuit diagram of how to wire in the voltage regulator ?
> 
> cheers,
> -kt


This is the quick version:





The Vin is 14V in my case from the PSU, and then branches off before the regulator to the Nano Vin.

I used 330nF vs 10uF. I think 10uF would be better with ripple, and would also pass more interference current to ground at lower frequencies. 100nF is a common value though so *shrugs*.

In my photo, my Cin cap can be seen right on the regulator, while the Cout is between the other end of the 5V/gnd buses.

Did voltage checks yesterday and all is sweet.


----------



## Adr_0

There are heaps of voltage regulators around but I chose the 3A low drop out ST Micro LD1085V50.


----------



## Adr_0

Although the exposed buses may invite more RF/switching interference, hopefully the caps send this to ground.

One good thing is that the pull up resistor goes straight across to the 5V bus and the chosen DI pin, then every temp probe data line can come off the (correct) side of the resistor.

The photo shows that things are getting messier but after a wiring tidy up it should look better. The pull up resistor is out of the way though.


----------



## druid442

mr_wibble said:


> This is the over view screen. The flame-icon indicates the heater is currently on.
> Things like delayed start, control-box overheating alarm, step-mash running are also showed here.
> View attachment 93148
> 
> 
> This is where i can set the HLT temperature, and a delayed start-time. Typically I set my HLT to start heating at 4:30am, so when I'm up at 5ish, she's right to go.
> In the circuit is a battery-backed real-time clock, so the controller always knows what time it is.
> View attachment 93149
> 
> 
> The Mash screen allows the temperature to be set simply. If set to zero, the mash is considered to be off.
> A 4-step mash programme can also be set. The fields are XX minutes at YY degrees, the user fills out as may fields as wanted, then click "Run".
> View attachment 93150
> 
> 
> The calibration allows small adjustments to the HLT and Mash sensor readings, and to set the time on the clock (theoretically only needing to be done once, and on battery changes).
> View attachment 93151
> 
> 
> Finally, a shot of the very amateur wiring layout.
> View attachment 93147
> 
> 
> Is anyone wants the code, please feel to PM me. Don't think I can add a .zip of it here.




hi !

congrats to you, you did a very nice job. I,m very interrested in the arduino code of your project, do you mind sharing it ?
thank you very much and have a good brew
eric


----------

