RIMS Controller Build

Homebrew Talk - Beer, Wine, Mead, & Cider Brewing Discussion Forum

Help Support Homebrew Talk - Beer, Wine, Mead, & Cider Brewing Discussion Forum:

This site may earn a commission from merchant affiliate links, including eBay, Amazon, and others.

thekraken

Well-Known Member
Joined
Aug 18, 2014
Messages
1,957
Reaction score
449
Location
DFW
I decided I'd document my controller build so here it goes...

This box will simply control one chugger pump and one 1375 watt heating element for a RIMS tube.

The RIMS tube will be controlled by an arduino. The arduino will have (at least) two temperature probes, one at the rims inlet and the other at the rims outlet. The arduino will read a flow meter to monitor wort flow through the RIMS tube to limit it's duty cycle to prevent scorching.

All tips, suggestions, warning, etc. are welcome.

Here's my progress so far: I got my components placed and am ready to wire it up. I still need to place my fuse holder and cap those exposed metal screw heads that mount the LCD. I'll be grounding the heatsink.

9cDJFpC.jpg

6caujxH.jpg

SOfqobj.jpg

EWS5I3W.jpg
 
Will the display show both the temperature info and the flow rate?

You are doing something very similar to what I was planning except I was thinking of using the arduino solely for monitoring flow control with a hall effect flow meter and a dedicated display and use a separate PID for controlling the heating element. I want to have the heating element tied to the flow so that no or low flow means no heat.

Looking forward to future updates!
 
Will the display show both the temperature info and the flow rate?

You are doing something very similar to what I was planning except I was thinking of using the arduino solely for monitoring flow control with a hall effect flow meter and a dedicated display and use a separate PID for controlling the heating element. I want to have the heating element tied to the flow so that no or low flow means no heat.

Looking forward to future updates!

Yep, the display will be connected to the arduino and will display inlet temperature, outlet temperature, flow rate (gpm), system current draw, duty cycle, and what ever else I can fit on it. The arduino will be the element controller, using some PID logic in more of a cascade type control.

You might be interested in this project, he has done exactly as you described. I'm doing that, and cutting out the generic seperate PID as it's no longer necessary with the mcu.
 
Yep, the display will be connected to the arduino and will display inlet temperature, outlet temperature, flow rate (gpm), system current draw, duty cycle, and what ever else I can fit on it. The arduino will be the element controller, using some PID logic in more of a cascade type control.

You might be interested in this project, he has done exactly as you described. I'm doing that, and cutting out the generic seperate PID as it's no longer necessary with the mcu.

Double poast
 
Yep, the display will be connected to the arduino and will display inlet temperature, outlet temperature, flow rate (gpm), system current draw, duty cycle, and what ever else I can fit on it. The arduino will be the element controller, using some PID logic in more of a cascade type control.

You might be interested in this project, he has done exactly as you described. I'm doing that, and cutting out the generic seperate PID as it's no longer necessary with the mcu.

Thanks I stole the idea from him; I just want to make my controller box UI a little more attractive than his.
 
Thanks I stole the idea from him; I just want to make my controller box UI a little more attractive than his.

I actually had a pretty lengthy email back and forth with him discussing his set up and I bounced ideas off of him. I'm sure if you have questions about his setup he'd be happy to respond.
 
How will you measure current draw?

-BD

Using a CT sensor like this.

It'll be kind of a safety/sanity check to make sure the system is operating as it should. IE if I'm measuring 13amps, but the element is supposed to currently be switched off then throw some alarms and indicate a possible SSR failure.
 
Alright, I've got most of her wired up. I'm running a prototype circuit board, the board is controlled by an arduino, controlled by a computer in another room via bluetooth.

Disclaimer: don't do what I do, securing components with little pieces of electrical tape is not securing! (This is just a prototype and a careful test run) Also, still need to properly insulate the exposed screw heads at the LCD.

rA42ze1.jpg

ISvAJmW.jpg

0Z1tuen.jpg

4vocfkt.jpg

dGe4LUR.jpg
 
What are you using to measure flow?

Nice work BTW! I always wanted to do a 'duino RIMS controller but in the end, laziness and beer drinking won out.
 
What are you using to measure flow?
I'm using this flow meter: http://www.adafruit.com/products/828
I realize it's not food grade. After much deliberation, and listening to the basic brewing podcast series with the toxicologist guy, I decided to go ahead and use it.

In my initial testing I was surprised to find that it's pulse rate was very linear, though off zero. It also seemed to have a slight break-in period where I had to recalibrate after the first few test runs, but it's been accurate ever since.

I plan to make checking and recalibrating a quick and pain free process through the UI so it can easily be checked each brew day if I'm so inclined. Just a simple matter of pump some water at x flow rate for y period of time into a vessel -> measure volume -> if measured volume is within expected range then brew on, otherwise the software will recalculate the calibration factor to match the measurement(s).

Nice work BTW! I always wanted to do a 'duino RIMS controller but in the end, laziness and beer drinking won out.
Thank you. Yeah, it's definitely something to keep me busy between brew days.
 
I've got the same flow meter and have though about a simple project that will turn the RIMS element off if the flow drops below a programmable threshold value... And then wire it in between the PID's and SCR.

Maybe a project for this winter.
 
I've got the same flow meter and have though about a simple project that will turn the RIMS element off if the flow drops below a programmable threshold value... And then wire it in between the PID's and SCR.

Maybe a project for this winter.

Yeah that's a good idea. Beernutz said that's what they wanted to do too on page 1. Here is a guy that has already done exactly this: http://www.astrocaver.com/rims/ I had an email conversation with him a while back, nice guy, he might be willing to share his arduino code if you don't want to mess with coding.
 
So the control algorithm is a little different than your standard PID. Forum member BigBlock came up with this algorithm:

Code:
pid_output        = pid.calc();

calc_temp_diff    = min(max_temp_diff, pid_output);               //BIGBLOCK PID output reduces rims output temp as MLT temp nears the setoint

rims_output_limit =( mlt_setpoint + calc_temp_diff - mlt_temp )   //Temp diff     (F)  BIGBLOCK - max_temp_diff changed to calc_temp_diff
                   * 1.0                                          //specific heat (Btu/(lb*F))
                   * flow_rate*8.3/60.0                           //flow rate     (lb/sec)
                   * 3600.0/3.412141                              //convert to wattage
                   / rims_wattage*100.0;                          //convert to % watts of my element

duty_cycle        = constrain( rims_output_limit, 0.0, 100.0 );   //BIGBLOCK Final output

For those of you who don't read in c++ code I'll try to explain what's going on. Instead of using a PID algorithm to output a duty cycle directly, like most systems are set up, this PID algorithm is tuned to calculate a RIMS tube output temperature that will raise the input temperature to your setpoint. So for example if we measure the flow coming into the RIMS tube at 0.5 degrees F below setpoint the PID might calculate that we need to raise that inflow by 8F to bring the whole volume up to setpoint.

Now that the PID has given me a temperature differential to shoot for I use this equation to estimate the duty cycle required by my heating element to raise the incoming wort by said amount: (temperature difference) * (specific heat of water) * (flow rate) = BTU/second, throw in a conversion factor to get wattage required, then divide that by the wattage capacity of my heating element and I have a duty cycle.

Notice that the algorithm is dependent on flow rate, one advantage to this is the slower the flow rate the lower the calculated duty cycle and vise versa. This should (hopefully) automatically minimize any chances of scorching.

That snippit is part of some working code, but as a whole I'd say my code looks more like chicken scratch than anything. When I can find some time I will clean it up and post my project to github.
 
I am doing something very similar (build thread coming soon). I am using two flowmeters tied to an arduino with an Ethernet shield. The arduino calculates and reports flow of the two flowmeters via a web page. Since I use a BCS controller I already have the tablet/laptop interface via browser so thought this a better approach in my application rather than an LCD. The arduino also generates two binary outputs to the BCS: one that flow through the RIMS tube is at an acceptable level or higher (so if not the element will not turn on) and the other will cycle the mash tun outlet pump into the BK on and off to basically match the sparge water volume entering the mash tun. This is basically an electronic auto sparge and will give me freedom to set the pump valves without having to match and monitor volume over the fly sparge period. I will post up my arduino code soon.

I am using the same flowmeters from adafruit (plastic model). I put camlocks on both sides so they can be easily removed. I have found them to be fairly accurate. I am staying within the temp limits and not really sweating the food safety, as the wetted materials seem food safe enough. I have looked for stainless paddle wheel or similar flowmeters and have not found much at any reasonable price.

-BD
 
the other will cycle the mash tun outlet pump into the BK on and off to basically match the sparge water volume entering the mash tun. This is basically an electronic auto sparge and will give me freedom to set the pump valves without having to match and monitor volume over the fly sparge period.

What kind of pump are you going to be using? How rapid are the pulses going to be?

Off the top of my head I wonder if it might be better to pulse the sparge water out of the HLT rather than pulse from the MLT and disturb the grain bed.

I ordered an MPX5010DP pressure sensor a few months back to use as a bubbler volume level sensor in order to accurately and automatically dispense liquids. But at this point I think this feature is well down the road. And with a little more in depth testing I wouldn't be surprised if the flow meter could handle this job accurately enough.
 
I plan to make checking and recalibrating a quick and pain free process through the UI so it can easily be checked each brew day if I'm so inclined. Just a simple matter of pump some water at x flow rate for y period of time into a vessel -> measure volume -> if measured volume is within expected range then brew on, otherwise the software will recalculate the calibration factor to match the measurement(s).
...
I ordered an MPX5010DP pressure sensor a few months back to use as a bubbler volume level sensor in order to accurately and automatically dispense liquids. But at this point I think this feature is well down the road. And with a little more in depth testing I wouldn't be surprised if the flow meter could handle this job accurately enough.

It just occurred to me that I can use the pressure sensor to automatically calibrate any flow sensors...
 
What kind of pump are you going to be using? How rapid are the pulses going to be?

Off the top of my head I wonder if it might be better to pulse the sparge water out of the HLT rather than pulse from the MLT and disturb the grain bed.

I ordered an MPX5010DP pressure sensor a few months back to use as a bubbler volume level sensor in order to accurately and automatically dispense liquids. But at this point I think this feature is well down the road. And with a little more in depth testing I wouldn't be surprised if the flow meter could handle this job accurately enough.

I considered the pressure method, but I then decided it would be too much of a headache to handle/keep clean, etc. I thought it a pain to have a tube down into my MT or BK.

My pumps are chuggers. I agree it is better to cycle the outlet, and that is how I have it set. My inflow will be set via the ball valve, with the flow meter reporting/confirming the ~1 qt. per minute rate. It will run continuously. Then the outlet pump will turn on when the flow meters determine a 1.5 quart difference between them. It will turn on at 1.5 qts and off at zero. The outlet pump valve needs be more open than the inflow pump valve, but after that, how much more is not really critical. The pumps are powered by SSRs, so no wear/tear there. Just a few extra cycles on the outlet pump.

My BCS will handle the stage when the sparge water runs out and transition to just draining of the MT, as this will sometimes happen from running out of sparge water, or sometimes manually as the boil volume has been achieved or the runnings get too lean.

-BD
 
Just a quick lesson learned on the arduino rims using modbus....

One thing I didn't realize about many of the arduino ds18b20 temp sensor libraries(because I never looked) is that they will implement a delay when waiting for the sensor to convert temp. This delay wreaks havoc with the modbus comms. To remedy I used the Dallas library and setup with sensors.setWaitForConversion(0) . Then you can write your own timing for requesting temps and writing temps to avoid using delays. Once I fixed that, my modbus comms between arduino and PLC were rock solid at 100ms update rate. I didn't bother going faster since that was fine for brewing.
 
Just a quick lesson learned on the arduino rims using modbus....

One thing I didn't realize about many of the arduino ds18b20 temp sensor libraries(because I never looked) is that they will implement a delay when waiting for the sensor to convert temp. This delay wreaks havoc with the modbus comms. To remedy I used the Dallas library and setup with sensors.setWaitForConversion(0) . Then you can write your own timing for requesting temps and writing temps to avoid using delays. Once I fixed that, my modbus comms between arduino and PLC were rock solid at 100ms update rate. I didn't bother going faster since that was fine for brewing.

Yeah you don't want to be waiting around on those conversions. I don't know if you remember from the code I sent you but that was why I had that goofy scheduler system set up. I've gone to quite a bit of effort to make sure things fire off in the correct sequences and timings. What resolution are you using on the ds18b20?

And are you still using the control algorithm that I posted on the last page?
 
Yeah, I focused mainly on the PID section and trusted the rest of your code on the timing aspects without actually going through it. :mug: Since I'm using my PLC for the actual control code I hadn't worried about timing on collecting data from a few sensors until issues arose.

I didn't have too much opportunity to play around with tuning before spring came and I had to put my toys away for the season. I did try running at 11bit as well as 12bit and the increased delay didn't seen to have much impact. My cartridge heating elements were a little underpowered (840W) so my system response was much slower and more forgiving. I have some new elements that should bump me up where I would like to be (1200W).
 
Back
Top