Yet another Arduino Based Brewing controller

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

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]

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]

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]

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.

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.

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 -

1. 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.
2. 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]

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]

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]

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]

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]

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.