Maximite Brew-troller

[Blackened]

Anyone using a Maximite to control their rig?

I'm working on a RIMS (would work for HERMS too) controller. Initially just doing the code to control the heat exchanger using 3 DS18b20 temperature probes, HX in, HX out, and mash temperatures. Also log the temperature readings to a file for later analysis.

It would be handy to bounce ideas of someone else doing similar things.

 

[Blackened]

No takers I see.. never mind. Perhaps I should elaborate and see if I can fire anyone's imagination.
Essentially, it's a tiny computer, fits in the palm of your hand. You plug in a monitor and keyboard, and you have yourself a controller (think DOS, not Windows).
It is arduino shield compatible to a degree, with a further 20 IO ports (digital, analog, freq etc) on the back that can directly power a SSR amongst a raft of other things.

You do need to learn the programming language it is based on, but with that learning curve, comes a device limited only by your imagination. You type up your instructions, and the maximite interprets them immediately. No compiling, no flashing etc..No need to program using an external PC or any other device. Although you can plug in into a PC via USB to upgrade the firmware, transfer files blah blah blah...

No affiliation etc..... I bought an early version (clone called a Duinomite Mega) ready made as I'm not up to the task of building one myself. I used to mess around with electronics but I was never very good.

For brewing purposes, it would make a fantastic automation tool IMHO, and for climate control etc... I've always wanted to set the temperature in a ferment box, and walk away, too cold? Heat on. Too hot? Blow some fresh air if the ambient temp is cool enough (night time or just a cool day). Outside air too warm? Switch on the fridge etc...... And lets not forget to log all that data for future analysis. Funny taste in this batch? lets just check and see if there was any temperature problems during ferment. Maybe the setpoint was too high to take into account this yeast strain's vigorous metabolism (depending how you place your probe if it's not immersed) . Compare ambient temperature and wort temp, perhaps (I'm guessing here) even to the point of identifying when the yeast has finished working when the ambient and wort temps have equalised, and crash cool automatically.

Some links below. Mainly for the newer colour version, but there is an older BW version which I suspect could be found for cheaper still.

Home page:
http://www.geoffg.net/maximite.html

In kit form:
http://www.altronics.com.au/index.asp?area=item&id=K9555

Completed board ready to use:
http://www.circuitgizmos.com/products/cgcolormax2/cgcolormax2.shtml

Complete packaged product, not available just yet:
http://www.fuze.co.uk/product/the-fuze-maximite-edition-pre-order-2/

Video of someone who wrote a game to run on it.

 

[Blackened]

Baby steps at the moment.

I completed a second and successful test with water only.
Overshot the set point by about 1C before it dropped back to the target. There's some lag with the DS18B20 temperature sensors. Seems like this result is good enough for mashing purposes though so I'm going to leave it as it is and try using it for my next AG IIPA on the weekend.

This is the raw screen output. I will have a RIMS diagram with the temperatures shown eventually. Simple text output for now though:



A graph of the logged data, showing the power output falling as the setpoint was reached:


Any comments re: useability during the mash? I reckon the temporary 1C overshoot will be ok but without any experience I'm curious to know what others think.

cheers

 

[Yob]

Video of someone who wrote a game to run on it.

Thats impressive given how long it took him to type >Run :lol:

...sorry..

 

[Blackened]

Well, I've finally got the software to something useable. I haven't implemented automatic step mashing just yet but it's logging data to file, displaying it to the monitor and the temperature control is a bit more reliable. Automatic cutout if there's an over-temperature event but allowing for small overshoots. Manual control and pause is also handy for when the recirculation gets stuck or something goes awry. I have to enter the desired setpoint and set a timer for the rests, but I'll sort that out in the next version.

Got myself a second Duinomite (finished circuit board un-boxed) as an embedded controller for $42 inc postage and add-on IO card. You can get them a little cheaper, but the IO card has all the connectors on a strip that will make life easier when I mount it in an enclosure. The enclosure is on it's way from the UK and all the other bits are already assembled in a very ghetto kind of way so I can brew... but it's not pretty or waterproof.

Don't hang me for the graphics. This version of the machine is only capable of black and white display and I suck as an artist lol. This is a screen shot captured by the device itself. Took me all day today to get the graph to display properly :huh:

The message box in the upper RHS scroll downward and only displays a few most recents events, whatever they may be.



The DM's screen res is only 480 x 432 so the image will appear pretty small on most monitors.

Cheers

 

[djar007]

Is it possible to regulate the pump according to pressure. Say keeping it below 0.8 bar and cutting it if it becomes stuck. Great work so far. Very cool project.

 

[Edak]

I actually really like your display, reminds me of some basic scada systems.

Congratulations on getting it to the point you have on your own, well done.

With respect to your overshoot, are you using PID? It might be a case of tuning one of the variables. Perhaps you need to increase {D} or put a cap (upper limit) on the {I} term.

 

[MCHammo]

Always saturate (put a maximum +/- value) on your integral values in a PID... Integral wind up can be messy (and dangerous).

 

[Blackened]

Is it possible to regulate the pump according to pressure. Say keeping it below 0.8 bar and cutting it if it becomes stuck. Great work so far. Very cool project.

Djar007, Thanks I haven't looked into pressure sensors thoroughly yet. Once I'm completely happy with my current logic/sensor combination I'll definitely be adding more. Your idea of avoiding a stuck mash is a good one, I've been thinking about that, but hadn't considered monitoring the pressure as a method of detecting possible problems.

I actually really like your display, reminds me of some basic scada systems.

Congratulations on getting it to the point you have on your own, well done.

With respect to your overshoot, are you using PID? It might be a case of tuning one of the variables. Perhaps you need to increase {D} or put a cap (upper limit) on the {I} term.

Thanks Edak, yeah, the Maximite (and clones) are intended to emulate the experience of the old TRS80 computer. Great little learning device for those of us with no real programming experience. Hobby for me only. See below for PID concerns.

Always saturate (put a maximum +/- value) on your integral values in a PID... Integral wind up can be messy (and dangerous).

MCHammon and Edak Re: PID
I decided to go a different route for the temperature control side. I measure the HXinput/output temperature, compare the two and use this figure to calculate the gain as degreesC per 1% Duty, then calculate the %Duty required to reach my target temp. If the target temp is currently out of reach then it defaults to 80% (the remaining 20% is diverted to a second SSR to supply power for the HLT sparge water). This is admittedly not perfect, and I do get some minor temporary overshoots. The program handles larger overshoots by cutting power entirely and waiting for the temperature to drop before re-applying power. I had a stuck sparge in my first run and had spikes where the liquor in the RIMS tube boiled and my algorithm couldnt react fast enough. Hence the cutout LOL.

The remaining short (ie a few seconds) overshoots are IMHO due to the lag in the sensors detecting the actual temperature. So my controller is acting on old (a few seconds) information. I'm not sure if I'll include a predictive aspect into the algorithm, or just leave it as is. I'm pretty happy with it but I'll be monitoring future runs and modify as seems necessary. It seems to me that a few short overshoots shouldn't significantly effect the end result, given the relative volume of high temperature liquor to the cooler mash liquor.

Having said all that, I'm open to using the PID control method in the future. I guess it will just depend on if it seems necessary.

Thanks everyone for the encouragement

 

[MCHammo]

MCHammon and Edak Re: PID
I decided to go a different route for the temperature control side. I measure the HXinput/output temperature, compare the two and use this figure to calculate the gain as degreesC per 1% Duty, then calculate the %Duty required to reach my target temp. If the target temp is currently out of reach then it defaults to 80% (the remaining 20% is diverted to a second SSR to supply power for the HLT sparge water). This is admittedly not perfect, and I do get some minor temporary overshoots. The program handles larger overshoots by cutting power entirely and waiting for the temperature to drop before re-applying power. I had a stuck sparge in my first run and had spikes where the liquor in the RIMS tube boiled and my algorithm couldnt react fast enough. Hence the cutout LOL.

The remaining short (ie a few seconds) overshoots are IMHO due to the lag in the sensors detecting the actual temperature. So my controller is acting on old (a few seconds) information. I'm not sure if I'll include a predictive aspect into the algorithm, or just leave it as is. I'm pretty happy with it but I'll be monitoring future runs and modify as seems necessary. It seems to me that a few short overshoots shouldn't significantly effect the end result, given the relative volume of high temperature liquor to the cooler mash liquor.

Having said all that, I'm open to using the PID control method in the future. I guess it will just depend on if it seems necessary.

Thanks everyone for the encouragement

If your control algorithm is dependant only on (output-input), then what you have there is simply a proportional (P) controller. Slightly modified in your case, but purely P, none the less. You might find that adding a bit of derivative action (D), you should be able to prevent overshooting... to some degree, anyway. This would be done simply by adding an extra term to your control output (currently just P, and appropriately scaled). Your derivative term would come from the rate of change (derivative) of the output value. You will find that a properly tuned PD controller should prevent overshoots, but as a result, may not end up reaching the final setpoint (temperature) desired, instead settling down maybe a few degrees away. It is for this reason that the integral (I) value is often used - basically a summation of the error over time. The longer your temperature spends away from the desired setpoint, the larger the output of this term becomes. But it comes with its own risks (as I mentioned before).

PID is not really an optimal control algorithm, but it is relatively simple to implement. When I eventually get to the stage of building my own temperature control system, I'll be designing my own discrete time controller, but that relies on a bit of system modelling, etc. For this, the controller basically knows how the system behaves, and how it should react, so it can predict what the effect of a certain output will be and apply what it thinks is required. A bit beyond most people here, I would think, but to anyone with a grounding in control theory, it shouldn't be too hard. But every system would be unique, so it would require a brand new set of calculations for each one.

 

[Blackened]

If your control algorithm is dependant only on (output-input), then what you have there is simply a proportional (P) controller. Slightly modified in your case, but purely P, none the less. You might find that adding a bit of derivative action (D), you should be able to prevent overshooting... to some degree, anyway. This would be done simply by adding an extra term to your control output (currently just P, and appropriately scaled). Your derivative term would come from the rate of change (derivative) of the output value. You will find that a properly tuned PD controller should prevent overshoots, but as a result, may not end up reaching the final setpoint (temperature) desired, instead settling down maybe a few degrees away. It is for this reason that the integral (I) value is often used - basically a summation of the error over time. The longer your temperature spends away from the desired setpoint, the larger the output of this term becomes. But it comes with its own risks (as I mentioned before).

PID is not really an optimal control algorithm, but it is relatively simple to implement. When I eventually get to the stage of building my own temperature control system, I'll be designing my own discrete time controller, but that relies on a bit of system modelling, etc. For this, the controller basically knows how the system behaves, and how it should react, so it can predict what the effect of a certain output will be and apply what it thinks is required. A bit beyond most people here, I would think, but to anyone with a grounding in control theory, it shouldn't be too hard. But every system would be unique, so it would require a brand new set of calculations for each one.

Thanks for expanding on PID control MCHammo. Feedback like this is really valuable for my build. Keep it coming everyone.

I had some thinking time today. Had a quick browse of PID control on Wiki too after reading your reply. My observations (Not RIMS setup, just generally) of my previous PID controllers have been that they are slow to react to a changing process. So I was approaching this design with the intent of a fast response to change (ie: tap closed/opened a bit, grain bed compacted and reduced flow etc...). This may or may not be the correct approach but I guess I had to start somewhere and my solution seemed like a good idea at the time LOL.

IMHO using a single temperature sensor on the output and using accumulated data to guess when the temperature will reach the desired set point, then altering the power in a predictive manner would work really well in a process that doesn't change much, but with my ghetto gear, recipes that are never the same, and new bits of gear almost every time I brew...... nah!!! So I decided on the 2 sensors ($2 bucks each if you buy off ebay in a bag of 10), plus one more to monitor the mash temp.

The faster response of my solution will no doubt result in some over/under shoot and oscillation. As you also mentioned, I wanted to avoid the whole "creep up on the setpoint, just in case I overshoot" saga and decided I could live with a bit of overshoot provided the system responds fairly quickly and drops again.

With all this thinking I have uncovered a bug in my existing algorithm that I suspect has contributed to my inaccuracies. I average the last 10 readings and use these values to calculate the gain, however this compares current values with current values. This is a mistake on my part. Let me explain further.......I assumed ( without applying the grey matter) that cause and effect would be almost instantaneous.


Step1. liquor passes HXinput temp probe
Step2 liquor is heated over a period of x time guessing @ 40% of the time between in and out based on my RIMS tube
Step3 liquor passes HXouput temp probe

Now if I'm pumping maybe 4 LPM, and the RIMS tube has a volume of 1L (just guesswork to show the principal) then there is a delay between liquor in --> heat applied (~6sec) --->liquor out (~further 9 sec). I should be comparing my current HX output with 9sec old power data and 15sec old input data to get meaningful values. This would explain a few strange values I was seeing in the data too. Especially when the power needed to drop quickly. Not all of them LOL but some at least. The above figures are not measured or even correct. I've got a feeling that the actual lag will be smaller than these estimates. I need to go out and measure the RIMS tube and my flow rates to get a proper estimate. Doesn't need to be perfect but it may chip away at some of the imperfection.

I will fix this bug first and test it out before I alter the code further. When my headache goes away from all this mental effort anyway :lol:

 

[MCHammo]

yeah, one limit of the PID controller is that it pretty much just operates on current values. You could, I suppose, create a predictor algorithm to feed into the PID control... but I wouldn't bother. If you're going to that much trouble, you're better off designing a proper discrete time controller to do the whole shebang.

Also, you will find that this system will probably be fairly slow to react anyway. There's a lot of thermal inertia involved when dealing with water, particularly that quantity. It will take a long time to show a reaction to your inputs. For this reason, I wouldn't have thought that you'd need to average out any readings. When you do that, you're effectively slowing down the speed at which you can take readings, by introducing a low pass filter (averaging algorithm). With all that thermal inertia and slowly changing values (within reason), I don't think there'd be any need for that.

Another reason that I will steer clear of PID is that with a proper discrete controller, you can account for the frequency that you can take sensor readings, calculate control values, set control... and lag in the system regarding readings, etc... but again, that's quite advanced and probably overkill. But as far as I'm concerned... no half measures And you're right about overshooting, it's probably not a huge deal. Just keep an eye on it, and define BEFORE YOU START what an acceptable overshoot is. If you do that later, you'll just get lazy and end up with a 10 degree overshoot (trust me, I've been there...) If you're after a quick ramp time, you'll always end up overshooting. Whether or not you start oscillating or not is another matter. Just be aware that the faster you try to ramp, the more you'll overshoot, and the more likely you'll set up oscillations. I usually aim for the "critically damped" result - the fastest possible response without overshooting.

And go take your measurements. They will provide valuable insight into your system - how you need to set up your sensors, how the system behaves and reacts, etc... Any more questions and I'll be happy to answer (or at least try to ). Control theory is one of my things. Microcontrollers is another.

 

[Blackened]

yeah, one limit of the PID controller is that it pretty much just operates on current values. You could, I suppose, create a predictor algorithm to feed into the PID control... but I wouldn't bother. If you're going to that much trouble, you're better off designing a proper discrete time controller to do the whole shebang.

Also, you will find that this system will probably be fairly slow to react anyway. There's a lot of thermal inertia involved when dealing with water, particularly that quantity. It will take a long time to show a reaction to your inputs. For this reason, I wouldn't have thought that you'd need to average out any readings. When you do that, you're effectively slowing down the speed at which you can take readings, by introducing a low pass filter (averaging algorithm). With all that thermal inertia and slowly changing values (within reason), I don't think there'd be any need for that.

Another reason that I will steer clear of PID is that with a proper discrete controller, you can account for the frequency that you can take sensor readings, calculate control values, set control... and lag in the system regarding readings, etc... but again, that's quite advanced and probably overkill. But as far as I'm concerned... no half measures And you're right about overshooting, it's probably not a huge deal. Just keep an eye on it, and define BEFORE YOU START what an acceptable overshoot is. If you do that later, you'll just get lazy and end up with a 10 degree overshoot (trust me, I've been there...) If you're after a quick ramp time, you'll always end up overshooting. Whether or not you start oscillating or not is another matter. Just be aware that the faster you try to ramp, the more you'll overshoot, and the more likely you'll set up oscillations. I usually aim for the "critically damped" result - the fastest possible response without overshooting.

And go take your measurements. They will provide valuable insight into your system - how you need to set up your sensors, how the system behaves and reacts, etc... Any more questions and I'll be happy to answer (or at least try to ). Control theory is one of my things. Microcontrollers is another.

Yeah, I kinda got that it was your thing LOL.Very grateful for the input.

I've been pondering the exact same thing re: averaging recent values and that this only slows down reaction time. I wanted to use some sort of averaging method as I don't know how to implement CRC error checking on the DS18B20 probes and I've noticed that at mash temps they are prone to reading +/- a couple of degrees between read cycles (approximately 800-900ms). I'm not certain but I believe the spurious readings could be data corruption, perhaps related to the heat or maybe my electronics are noisy. Either way error checking the received data is also on my "get my head around it" list.

I was thinking a work-around might be to do something like this:

initial target temperature = setpoint minus 3 degrees.
once temperature has reached or overshot this lower value, wait for the temperature to stabilise for xx seconds
then increase target temperature to setpoint minus 2 degress and repeat above
repeat with setpoint minus 1
then off we go............

This might reduce overshoot, whilst not prolonging the heat up phase by a huge amount. Tweak those delays down to as low as possible.


But as you also noted, the entire system has inherent lag and provides the short term averaging for me no doubt. I actually rely on this short term averaging as my power control is via a poor-mans-PWM. I calculate the on-time and off-time over a 3sec cycle. An arbitrary figure that seemed like a decent one to keep heat fluctuations to a minimum, but not cycle the SSRs too quickly and give a duty% resolution of 0.33% (probably unnecessary accurate). Seemed like a good compromise. I can't measure temperature fast enough to be certain there aren't any short term fluctuations though.

I'll definitely be taking some measurements time permitting.

Overkill??? Nothing succeeds like excess!!!

 

[Blackened]

Before I forget.... here's a link to a discussion forum. It tends to focus on the Maximite. The links I've mentioned previously are far from an exhaustive list of sources and info for MM and clone devices. Anyone with an interest in electronics or programming may find it interesting, and perhaps helpful if you're thinking of adding any sort of automation to your setup.

Cheers

Micro-controller forum:
http://www.thebackshed.com/forum/forum_topics.asp?FID=16

My (short) thread in particular:
http://www.thebackshed.com/forum/forum_posts.asp?TID=5972&PN=1

My username is the same in both forums. I got lucky.

 

[Blackened]

I used the controller last weekend. So far so good . A couple of bugs in the display to fix, but functionally pretty good IMHO.

In an effort to reduce some of my hard-coded data, a couple of weeks ago I started working on a menu system to take user input for the control phase, including a step mash routine, sensor IDs and various other program default values will be user configurable. I've finished the part of the menu that allows entering/editing of a step mash. Including the ability to test if the last routine completed properly (in the event of power failure etc...) and continue where it left off. I haven't changed the control routine to use this data just yet as I'm also building a more waterproof control box and getting distracted by other shiny things. The amount of time I waste just browsing around Ebay for simple things like LEDs and SSRs!!

Anyway, I'm after opinions on the following ideas.

1.
I believe it would be useful to add calibration options in this new menu. To calibrate the temperature sensors I could simply measure all the sensors together in a single glass of room temperature water, and work out the average value, and assign each sensor ID an offset so they all read the same (though not necessarily the actual temperature). Or allow user input which would require a glass of water, sensor/s dipped in it, and an accurate thermometer to use as the gold standard.

2.
A calibration routine for the temperature control. Something like using a garden hose to run water through the HX. The water would need to run at a rate similar to the flows experienced during mashing. The reason for the tap water is simply to ensure the input temperature is always the same so detecting temperature fluctuations on the output would be more distinct. The goal for this would be to determine the lag between switching power on, and seeing a rise in output temperature, as well as the lag from power off/temperature levelling off. Then using this lag data in the control software to help hit the target temperature.

I'm building this primarily to suit my own setup, but I've also got half an eye on the idea that someone else may want to use this software on a similar setup.

 

[Blackened]

Work in progress:


Had some time this weekend to work on the hardware. More components enroute so it's far from finished. I haven't started on the front panel just yet. Need to wait for the LCD screen to rock up so I can figure out where I want all the indicator LEDs etc...

All cable access is via the bottom of the box, USB for the keyboard, power in/out, panel mount sockets ordered to plug in all the temperature sensors. Two fans (one sucks, the other blows so they work together, not against each other), long story short I changed my mind partway through the build and the second fan was part of the pre-loved ATX power supply I decided to use). No holes on the sides or rear to keep it as splash proof as possible. There will be a hole in the front for the screen, but I'll cover that with some clear acrylic and seal it back up.

Internally I've got quite a bit of redundant relay capacity. Redundant right now as I haven't developed the software to use much, but there should be enough bit's n bobs in there to automate the rig entirely (eventually).

 

[mr_wibble]

There's some lag with the DS18B20 temperature sensors.

You can configure the accuracy on these sensors from (IIRC) 9 bits to 12 bits.
The better the accuracy the longer it takes to measure - 12 bits taking a few seconds.

 

[Blackened]

You can configure the accuracy on these sensors from (IIRC) 9 bits to 12 bits.
The better the accuracy the longer it takes to measure - 12 bits taking a few seconds.

Thanks Mr Wibble,

I allow 800ms for a 12 bit conversion. Not exactly instant, but if you request all sensors to convert in parallel, then read them sequentially the total time to read ALL sensors isn't much more than the initial 800ms conversion time.

I haven't updated this thread for a while. I'm still working on the whole setup, but kids and work have killed a lot of my free time of late. I've got a TFT monitor mounted in the front panel of the box so I can get rid of the old 14" external monitor. I've also been tweaking my hardware due to some problems during the last batch I ran. I'll update with some pics of the setup once it's all sorted out and ready to go

 

[marksy]

Hey, just found this. Was thinking of getting maximite to play around with. How is your build going?

 

[Blackened]

Hey, just found this. Was thinking of getting maximite to play around with. How is your build going?

It's kinda stalled at the moment. I'm using the control box for a couple of other projects. I'm not making beer at the moment.

I'll get back to it eventually, but for now other shiny things have caught my attention lol. The controller's next job is to automate a VM reflux column. Fairly simple in comparison.