BruControl: Brewery control & automation software

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.
I’ll stand as above that resolution without accuracy is a meatless sandwich, but who am I to tell you what to eat? If you want resolution, I can cut you a custom FW with higher 1-wire resolution. We honestly picked 11-but as a good empiric value and never exhaustively tested higher. So perhaps you’ll test and report back?

I agree that I’ve seen RTD values that didn’t jive out of the box. I wrote it off because the RTD was probably junk. Real Pt100’s need platinum (hence the Pt, right?) and last I checked Pt wasn’t cheap, so I have to believe a $15 RTD never found itself in the company of any platinum. The wires, terminations, connectors in between also play a role as these add variability in the net resistance, even in 3 or 4 wire configurations.
 
The DS18B20 has a measuring range of 324F (180C). 11 bit resolution would theoretically give 324/2048 = 0.158 so a resolution of about 0.16 degrees F. That is a bit over 6 divisions per degree. That is best case. The accuracy remains at about 0.9F in any case.
 
I get wanting better resolution. When I worked as a commercial brewer our brewhouse displays and the vessel displays only read to the nearest degree. When I have info to 10^-1 I just use it as a trend indicator.

In my application, a commercial distillery, a tenth of a degree actually means the difference in proof of alcohol vapor being 190 proof or not, which is a legal requirement through the process of distillation of neutral spirit. This temperature is 172.94 according to science, higher than that and I am not making 190. I use a PID to control reflux flow to increase reflux and ensure that the outlet vapor temperature is below 192.6 to have a bit of safety and to see trends... as should be apparent, a .22F step with the 1-wire resolution is not enough to watch the trend. That is why I use an RTD, it does have the resolution, it is just a pain to set up compared to the 1-wire...
 
I’ll stand as above that resolution without accuracy is a meatless sandwich, but who am I to tell you what to eat? If you want resolution, I can cut you a custom FW with higher 1-wire resolution. We honestly picked 11-but as a good empiric value and never exhaustively tested higher. So perhaps you’ll test and report back?

I agree that I’ve seen RTD values that didn’t jive out of the box. I wrote it off because the RTD was probably junk. Real Pt100’s need platinum (hence the Pt, right?) and last I checked Pt wasn’t cheap, so I have to believe a $15 RTD never found itself in the company of any platinum. The wires, terminations, connectors in between also play a role as these add variability in the net resistance, even in 3 or 4 wire configurations.

all of my probes, no matter the price were pretty close to each other, it was the boards that were off, including the adafruit... I posted this a while back...
 
The datasheet for the DS18B20 claims that 11 bits converts to 0.125°C and 12 bits to 0.0625°C, respectively. That's about 0.225 and 0.1125 deg F, respectively.

This matches perfectly with what I see on my 1-wire, I am not sure if the extra bit is worth your effort at this time, but if someone makes a 14-bit 1-wire in the future, I will be extremely interested...
 
Centrifugal pumps work best by throttling output with a valve. I personally use a proportional valve and a BC analog amplifier powered by a PID output in BC and then the valve has feedback which I tie to an analog input with resistor voltage divider. I also set up a manual control by programming a PWM output in BC to the same interface output, and setting the multiplier to 255 so I put in 'percent open'. With two outputs to same interface output, if you enable one, it disables the other, so you can have manual control in an instant.
 
In my application, a commercial distillery, a tenth of a degree actually means the difference in proof of alcohol vapor being 190 proof or not, which is a legal requirement through the process of distillation of neutral spirit. This temperature is 172.94 according to science, higher than that and I am not making 190. I use a PID to control reflux flow to increase reflux and ensure that the outlet vapor temperature is below 192.6 to have a bit of safety and to see trends... as should be apparent, a .22F step with the 1-wire resolution is not enough to watch the trend. That is why I use an RTD, it does have the resolution, it is just a pain to set up compared to the 1-wire...
You could rent a precision lab thermometer with that resolution and use the lookup table to set your RTD to 172.94 for that one point. Before my barn burned, I had used a Thermapen (has it's own resolution issues so not as precise as a lab thermometer) to calibrate from 148.0 to 156.0 for my mash at the integers. I had that only those points because I did not care if the probe read off a bit from 60- 148 or above 156. You could use any type of probe as your "correction" was 172.94. In fact you could quickly set up a lookup table all around your 172.94 in whatever resolution you wanted. I would set the lookup every 10 degrees outside your precise range if I was doing it.

I do not know if the probes always maintain the same error over time, so that could be a factor for that precision.

https://jmtest.com/i/fluke-calibration-hart-scientific-1504-tweener-thermistor-readout/
 
This matches perfectly with what I see on my 1-wire, I am not sure if the extra bit is worth your effort at this time, but if someone makes a 14-bit 1-wire in the future, I will be extremely interested...

12-bit is the max, per the data sheet. It's a few settings on our end if you want to test it. LM (and for which interface).
 
How would a relay board connect to the Uniflex Controller to control a Duty Cycle device using a PID algorithm? What parts would have to be purchased besides the Uniflex controller and relay board? Does an I/O cable come with the Uniflex? Is there an I/O breakout board?

Is there any documentation on the Uniflex?
 
Good questions
How would a relay board connect to the Uniflex Controller to control a Duty Cycle device using a PID algorithm? What parts would have to be purchased besides the Uniflex controller and relay board? Does an I/O cable come with the Uniflex? Is there an I/O breakout board?

Is there any documentation on the Uniflex?

Good questions! You would only need a relay or relay board board for high voltage items since the outputs are via high current drivers, so you can power DC devices directly. For example, a motorized valve, small DC pumps, solenoids, relays, etc. can be driven without intermediate relays.

We do not include an I/O cable but the connector is included. The connector is a 20 pin solder-cup piece. It would require a user to solder the wires in, but if you contact us with your needs, we can solder one in for you.

The manual is being written as we speak... should be up within the next two weeks. I can answer any questions in the meantime.
 
For anybody in the planning phase of their control panel I thought I would pass along something I discovered. I have a Square D QO main panel. An electrician friend put a 240V/50A drop in for me to a range outlet. He used 6awg wire and said I could go to 60A if I found I needed to (11,000W load). As I started shopping for GFCI breakers I discovered something. Square D does not make a 60A GFCI with a load neutral, it is for 240V only. They do make a 50A GFCI with load neutral. So without re-designing my control panel to separate the 120 and 240 feeds, it looks like my most direct option is to put a 60A spa panel between my main breaker panel and the range plug, this allows me to go with a 60A GFCI with load neutral at the spa panel to a standard 60A breaker in the main panel.

I know it's a unique situation but there may be others out there with a Square D QO panel looking to start down the electric path and this panel slightly complicates decisions you may have to make.
 
How would a step mash be done without manually setting the temperature of the PID GUI element each time.

Scripting? Do you then have to write a script for each brew?

Can it be done through the interface elements? Think Brewzilla, Braumeister interfaces... set all steps and click play to begin the automated processing of all steps.
 
How would a step mash be done without manually setting the temperature of the PID GUI element each time.

Scripting? Do you then have to write a script for each brew?

Can it be done through the interface elements? Think Brewzilla, Braumeister interfaces... set all steps and click play to begin the automated processing of all steps.
You could have time and temperature global variables. A single script would execute and read those variables. All you would do is set those variables at the start of your session either manually or by data exchange from a recipe.
 
So you can edit the script each time but can you put 5 temp/time text boxes on the GUI and have the PID control updated with the temp and execute for the time for each step? Maybe save these steps to a recipe file?
 
You can do it where you actually never edit the script... it uses variables (values) that affect the brew parameters. Per @helibrewer 's comment, you have global variables that hold the values you want. These could affect every aspect of the brew, such as strike temp, mash step temp and times, fill volume, sparge volume, boil time, whirlpool time and temp, and so on. Here is a look at my very basic set of globals. I edit these before a brew, then let the script eat.

Some brewers are importing this data directly from their beersmith files using NodeRed as an intermediary. We have plans to build in an XML converter to read beer.xml files, but this is a longer term plan.

1592959615708.png
.
 
So a script is written that makes use of variables and these variables are edited or imported before brewing but... what about the GUI for such a process? What does that look like? Is it dynamic (edit variables on the fly, pause/start script) or does it simply follow the script and variables to the end? Again, I'm comparing to Braumeister type GUIs where step temps/times are present and editable on one screen and then played.
 
Yes, the GUI is dynamic, meaning you can interact with those as you see fit. You can change parameters, or allow the script to do it. There are some examples here. I don't have a current one of mine with the devices active... here is an old one of mine (boring by comparison), but here is a look. The UniFlex video I just posted above shows another one in action.

You can download and try the software. It will run scripts, but will not communicate with interfaces (microcontrollers) until activated.
 

Attachments

  • BruControl5.png
    BruControl5.png
    260.5 KB · Views: 31
So a script is written that makes use of variables and these variables are edited or imported before brewing but... what about the GUI for such a process? What does that look like? Is it dynamic (edit variables on the fly, pause/start script) or does it simply follow the script and variables to the end? Again, I'm comparing to Braumeister type GUIs where step temps/times are present and editable on one screen and then played.

Here is what my Heat Strike water script looks like. I will add a couple more lines so that it will start based on a timer or system clock time. The items in double quotes are GUI elements. I keep my global variables on a separate tab (Globals) from my main GUI (Wifi):

I have another script that monitors the "Set Mash Temp" GUI element so that any time it changes, my RIMs PID GUI Element updates the target temp. This is the most flexible brewing software I have ever worked with.

Code:
[start]
"Heat Strike" state = false   //resets heat strike button element
wait "Heat Strike" state == true  //wait until heat strike button is pressed
"Heat Strike" background = 2  //Change boarder to green while script is running
"Heat Strike" state = false   //reset button state so it is active again
//Make sure pump is running
sleep 5000
if "Recirc Pump" value < 50   
    "Recirc Pump" value = 50
endif
sleep 2000        //Give pump time to start moving fluid across element
//Enable RIMs heating element
if "Enable RIMs" state != true
    "Enable RIMs" state = true
endif
"Set Mash Temp" value = "tmpStrike" value //Retrieve global variable tmpStrike
"Heat Strike" background = 1 //reset button background color
goto start "heatStrike" //go back to top of script

And here is my very simple GUI:

BC_GUI.JPG
 
So a script is written that makes use of variables and these variables are edited or imported before brewing but... what about the GUI for such a process? What does that look like? Is it dynamic (edit variables on the fly, pause/start script) or does it simply follow the script and variables to the end? Again, I'm comparing to Braumeister type GUIs where step temps/times are present and editable on one screen and then played.
I personally use a Global Element type as the variable. Because they are not "volatile" and they are available on the GUI, they are easy to change. You can easily control via a GUI that you set up. Things that are repeatable automatically can be in scripts, while things that you want your manual input may be via an Element on the GUI. In fact, they can be both. My Chugger pumps are automatically controlled at times, but I can also manually control them. You have excellent control via script or via an Element on the GUI. You can start very simply, and grow complex as you learn the system. There is a "learning" curve regarding the use of Elements and scripting.

While there are many different types of Elements, they generally share many of the same properties.

Scripting is coding. If you have ever written a Macro or used a scripting language, it will be familiar to you. If you have never used any "coding", it will be more difficult to learn, but this forum and its members are very helpful.

Regardless, BruControl allows you to control your Brewery with ease once it is set up. In addition, there is basically no hardware limitations. If you wanted a 100 temperature probes, you could add hardware to do that. In fact, if you wanted a 1000, it could be done.
 
Good evening,

We posted v1.1.9 (v1.2 Beta). Please consult your authorization email for a direct link to the page or access it via the form on the Download section of the website.

We have a few items to add to this version before releasing it as 1.2, but below is a list of some of the updates, in addition to various fixes (thank you to those who notified us of issues). Some of the fixes below are already incorporated into the released v1.1.4.

One MAJOR item to note: This version utilizes an SQL database to store data. Therefore: the installation steps must be followed in the Product Note and your existing data will not carry over. It is possible to import that data back to the DB by but we aren't able to write that or support it right now.

Fixed: Hysteresis result is not a boolean type
Fixed: PID Calc and Out Times
Fixed: Overlapping alarms prevent second+ alarms sounds and email
Fixed: Certain text characters pasted in script causes crash
Fixed: Graph of Global on different Workspace doesn't display
Changed: Swap Settings/Menu icons
Changed: Updated to use .NET Framework 4.4
Added: Automatic Lock
Added: Direct script command
Added: SQL Database for data
Added: Switch to disable log files (default)
Added: String text line feed
Added: Element Display Name (alias) field
Added: Script running status available in another script
Added: Dual Throw output (pending FW 45K)
Added: Device Element Enable Switch
Added: Choice of 3 or no Alarm sounds, plus script control
Added: Element location and size in properties
Added: Use PWM (if available) in PID and Deadband (pending FW 45K)
Added: Direct command (to interface) via script
Added: Script window height in settings
 
Hell yeah, I'm looking forward to the database as it such a pain now to save all of my graphs from brew day.

You can access the data in the database directly if needed. Use the connection string "(LocalDB)\MSSQLLocalDB". For example, in Excel: Data... Get Data... From Database... From SQL Server Database...

1593092143086.png
 
Got another scripting question. I have looked through the manual and tried to search through the past threads with no luck. Is there a way to script the Time Span and Primary Value Source for a graph element? I have a "single pane of glass" overview workspace and to conserve space I would like to have only one graph that I can change the source and time span on depending on what process / script is running.
 
I see the database option is running as local, any way to point this to an existing SQL server?
RiverCity, Step 7 in the Installation Product Note on the download page looks like it should have everything to point to a SQL Server. I haven't tried it yet but looks like should be able to just modify the DBConnection path to point to a network SQL server I would think.
 
RiverCity, Step 7 in the Installation Product Note on the download page looks like it should have everything to point to a SQL Server. I haven't tried it yet.
Thanks, I was just looking at that... just about to crack open the MDF file and see if I need to recreate the schema though. SSMS decided it needed an update, so I'm currently waiting on that...
 
Thanks, I was just looking at that... just about to crack open the MDF file and see if I need to recreate the schema though. SSMS decided it needed an update, so I'm currently waiting on that...
Keep us posted on the results. I will want to do the same thing if possible. Already got a SQL server running that is backed up regularly for pieces of the network.
 
I'm definitely not knowledgeable in database stuff. We picked the local db for ease of installation and management. I'll ask my partner, but he is on vacation so not sure the response time. You'll probably report back before me!

Edit: Also will be curious on your experience for those using less powerful computers. I think the overhead (definitely on the disk subsystem) goes down with the database, but need more opinions to know for sure.
 
Last edited:
Back
Top