Yet another Arduino Based Brewing controller

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

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]

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]

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]

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

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

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 ***** 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:

1. The set-temperature is set to zero (off), or is set to be less-than what the sensor is reading.
2. 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]

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?

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.