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.
Die_Beerery said:
I use a pid and a duty cycle on the same input. No reason not too.
Click to expand...
OK, that makes sense. Outputs like Digital Output, Duty Cycle, Hysteresis, and PID could all work on the same Port. In fact, you can have two Digital Output types on the same Port, Just Have one at 100% Duty Cycle.

So change that to "OK Idea as long as you know who is on first".
 
You guys are fast! Yes, we don’t think it would be practical to have both inputs and outputs on the same pin. But you could have inputs OR outputs and change the practical function as you see fit. PID or Duty Cycle is a perfect example.

We didn’t want you to be limited in your I/O, so built it this way. Because flexibility.
 
Different topic: has anyone automated dosing of salt additions? I use RO water that I build back up. Wondering if I could just input my desired water profile and have the brewery automate the additions. The code part would be easy... How do I dose the salt additions? The only way that comes to mind is to make solutions and use dosing pumps... Wonder how concentrated those solutions can be. Any other thoughts?
 
Is it expected behavior (or am I doing something wrong) that I can't do concatenation with a global string?
"Global 1" value = “Temp: “ + “Vessel Temp” Value
results in a [ERROR: The operands not do not match type]

This is the sort of thing I was wondering in my earlier post... are there functional limitations of global variables over in-script variables?
 
"Global 1" value = “Temp: “ + “Vessel Temp” Value

"Global 1" value = "Temp: " + "Vessel Temp" Value
 
I was not able to perform a string concatenation directly to a global either, so I use a script variable to do the concatenation, then write it to the global.

Try this:

new string x
x = "Temp: " + "Vessel Temp" Value
"Global 1" value = x

Also, make sure that the global type is configured as string.
 
VinceBrews said:
Different topic: has anyone automated dosing of salt additions? I use RO water that I build back up. Wondering if I could just input my desired water profile and have the brewery automate the additions. The code part would be easy... How do I dose the salt additions? The only way that comes to mind is to make solutions and use dosing pumps... Wonder how concentrated those solutions can be. Any other thoughts?
Click to expand...
Peristaltic dosing pumps would likely be the easiest way to do it. An automatic powder trickler/dispenser could also be used as long as you could interface it. You can automate just about anything, it usually only depends on how much money you have!
 
What methods do people use to assign 1-wire temp probes?

Right now, because I use the *awesome* ability to change configurations with a couple mouse clicks, I change things around between 4-5 configurations on my stills. I disconnect one string of 5 temp probes and reconnect a string of another 4 and maybe a string of 2 and reset the Arduino. Once set up it is awesome... but I want it idiot proof so I can pass the reigns to the assistant distiller... If I change something, add something, I have to go back and verify each and every probe... some are easy to get to , and I just take the lighter I use for heat shrink and put a quick flame under the probe and run back and see which one spiked in value and write it down... when I am all done (4 of probes are upstairs on the 2nd floor, so I get some exercise) I go through and reassign the indexes.

That being said, CBP let me see the actual address, and I put labels on my probes with a labelmaker like a network cable would have... it also kept weird and dangerous things from happening if I forget to plug in a probe or a probe was not seen after a power glitch and the order was screwy because one was missing...

I would like the ability to separately be able to *enter* or *choose from*, and *lock* a 1-wire temp input to a hardware address, and have the ability for a script to read present or not... maybe it already exists?
 
I have had some success using a Relay Board to swap probes.

Using either the NC or NO for the supply form a set of Probes to the common that goes to the Port 5 on the Mega.
 
oakbarn said:
I have had some success using a Relay Board to swap probes.

Using either the NC or NO for the supply form a set of Probes to the common that goes to the Port 5 on the Mega.
Click to expand...

I really did not mean physical switching, but good point. Thinking, if they could be hard coded and you did a switch, then reinitialized the 1-wire, you would be good... I would look at a 'latching' relay and send it a pulse to switch it... You could also have a script that if more than x number of probes stopped transmitting, you could re-initialize the 1-wire process and attempt to re-capture them.
 
clearwaterbrewer said:
What methods do people use to assign 1-wire temp probes?

Right now, because I use the *awesome* ability to change configurations with a couple mouse clicks, I change things around between 4-5 configurations on my stills. I disconnect one string of 5 temp probes and reconnect a string of another 4 and maybe a string of 2 and reset the Arduino. Once set up it is awesome... but I want it idiot proof so I can pass the reigns to the assistant distiller... If I change something, add something, I have to go back and verify each and every probe... some are easy to get to , and I just take the lighter I use for heat shrink and put a quick flame under the probe and run back and see which one spiked in value and write it down... when I am all done (4 of probes are upstairs on the 2nd floor, so I get some exercise) I go through and reassign the indexes.

That being said, CBP let me see the actual address, and I put labels on my probes with a labelmaker like a network cable would have... it also kept weird and dangerous things from happening if I forget to plug in a probe or a probe was not seen after a power glitch and the order was screwy because one was missing...

I would like the ability to separately be able to *enter* or *choose from*, and *lock* a 1-wire temp input to a hardware address, and have the ability for a script to read present or not... maybe it already exists?
Click to expand...

I asked @ brundog about this the other day. Because I don't like having to play 1 wire roulette either.
 
We initially thought “Once someone sets up their probes, they aren’t going to change them”. Generally this is true but you guys are demonstrating it’s not always the case. 1-wires will always initialize in order, but adding or subtracting them will change the indexes.

We did this to make it easier for users (1-wire addresses didn’t mean much as they were discovered, not keyed in, so indexes made more sense) and to reduce communications overhead (would need to first discover the available sensors then determine which goes on which port, etc).

I suppose you could automate the discovery via a script: for example, turn on a heater, see which increases by a percentage, then assign the correct index to the correct element. This assumes each probe can be “tickled” by a device which heats or cools, but that may not always be possible in a setup sense.

Otherwise, we would need to contemplate a way to make this something you could do. The only unique identifier is the sensor address, so we would have to hand that to the user.

Another option would be to deploy more sensors than you need and just enable and use the ones you want in that current situation. Maybe not ideal but throwing it out there.
 
clearwaterbrewer said:
I really did not mean physical switching, but good point. Thinking, if they could be hard coded and you did a switch, then reinitialized the 1-wire, you would be good... I would look at a 'latching' relay and send it a pulse to switch it... You could also have a script that if more than x number of probes stopped transmitting, you could re-initialize the 1-wire process and attempt to re-capture them.
Click to expand...
I did it with 10K NTC probes. I forgot about the indexing on 1 wire which I have not implemented in my Brewery. I have plenty of the 10K NTC Probes and several RTD so not using 1 wire yet, if ever.
 
oakbarn said:
I did it with 10K NTC probes. I forgot about the indexing on 1 wire which I have not implemented in my Brewery. I have plenty of the 10K NTC Probes and several RTD so not using 1 wire yet, if ever.
Click to expand...

I am still waiting on my RTD and analog boards I ordered a week ago from @BrunDog to make sure I was giving him some money for his effort ;-)
 
BrunDog said:
We initially thought “Once someone sets up their probes, they aren’t going to change them”. Generally this is true but you guys are demonstrating it’s not always the case. 1-wires will always initialize in order, but adding or subtracting them will change the indexes.

We did this to make it easier for users (1-wire addresses didn’t mean much as they were discovered, not keyed in, so indexes made more sense) and to reduce communications overhead (would need to first discover the available sensors then determine which goes on which port, etc).

I suppose you could automate the discovery via a script: for example, turn on a heater, see which increases by a percentage, then assign the correct index to the correct element. This assumes each probe can be “tickled” by a device which heats or cools, but that may not always be possible in a setup sense.

Otherwise, we would need to contemplate a way to make this something you could do. The only unique identifier is the sensor address, so we would have to hand that to the user.

Another option would be to deploy more sensors than you need and just enable and use the ones you want in that current situation. Maybe not ideal but throwing it out there.
Click to expand...

Not just for changing probes all the time, but also for knowing a sensor was DOA *after a re-initialization*.. right now, sensors set to an index higher than the number of sensors just shows the highest sensor, this seems like a potential issue also.... there is no way to tell quickly if you have a bad or missing sensor (after re-initialization) other than noticing two temps are the same...

also thinking it would suck if someone had a controller reset and the order changed and they froze a beer while gone for the day or week... or if a RIMS sensor got out of order due to a failed sensor and the rims heater went WFO...
 
clearwaterbrewer said:
Not just for changing probes all the time, but also for knowing a sensor was DOA *after a re-initialization*.. right now, sensors set to an index higher than the number of sensors just shows the highest sensor, this seems like a potential issue also.... there is no way to tell quickly if you have a bad or missing sensor (after re-initialization) other than noticing two temps are the same...

also thinking it would suck if someone had a controller reset and the order changed and they froze a beer while gone for the day or week... or if a RIMS sensor got out of order due to a failed sensor and the rims heater went WFO...
Click to expand...

First paragraph: valid points

Second: the order won’t change unless a sensor is added or deleted. But if one goes DOA, then you are correct... the order would change.

As I mentioned, we’ll stew on it. It won’t change in the near term but we’ll add it to the list.
 
FYI: 1-wire sensors have a unique 64 bit ID which could actually be returned instead of just numbering them in the order they are discovered. This would allow them to be 'named' in the interface and always identifiable no matter which ones were plugged in.
 
brewslinger said:
FYI: 1-wire sensors have a unique 64 bit ID which could actually be returned instead of just numbering them in the order they are discovered. This would allow them to be 'named' in the interface and always identifiable no matter which ones were plugged in.
Click to expand...
yeah, but as @BrunDog said, a lot of user probe changes were not anticipated, and it was desired to make it easier...
 
Is there a way to assign the computer current datetime to a Global Variable with script?

Something like this type of VB Code

"Global 1" Value = Now()

If not, it would be nice to have a system Variable when called to return current system datetime.

Along that line, is there any list of all script commands and properties in a List other than the User Manual?
 
clearwaterbrewer said:
also thinking it would suck if someone had a controller reset and the order changed and they froze a beer while gone for the day or week... or if a RIMS sensor got out of order due to a failed sensor and the rims heater went WFO...
Click to expand...

I have actually had this happen more than once. I have probes that I remove when not in use. Acually its 4 whole assemblies (my spunding assembly. pressure sensor, 1 wire sensor, solenoid and needle valve). They all connect to cat 5 jacks, via 1 cat 5 so I can add and subtract assemblies based on what I am using.

More than once I lost in probe reassign roulette, and have torched a fridge due to it leaving the heater on, froze beer and lost fermenting beer.

I have all 10 sensors in the BC and its a major pita, when at any time I am swapping out 1-4.

I have tried to script some of it out, but its not flawless. It may be easier to drop the thought of a single fermentation mega and go to everything on its own something.
 
oakbarn said:
Is there a way to assign the computer current datetime to a Global Variable with script?

Something like this type of VB Code

"Global 1" Value = Now()

If not, it would be nice to have a system Variable when called to return current system datetime.

Along that line, is there any list of all script commands and properties in a List other than the User Manual?
Click to expand...

That was just added in the latest RC - check here on page 3 "Real Time Functions".
 
Die_Beerery said:
I have actually had this happen more than once. I have probes that I remove when not in use. Acually its 4 whole assemblies (my spunding assembly. pressure sensor, 1 wire sensor, solenoid and needle valve). They all connect to cat 5 jacks, via 1 cat 5 so I can add and subtract assemblies based on what I am using.

More than once I lost in probe reassign roulette, and have torched a fridge due to it leaving the heater on, froze beer and lost fermenting beer.

I have all 10 sensors in the BC and its a major pita, when at any time I am swapping out 1-4.

I have tried to script some of it out, but its not flawless. It may be easier to drop the thought of a single fermentation mega and go to everything on its own something.
Click to expand...

You've reported issues, which we appreciate, but nothing of this magnitude... was this a failure of the system or swapped out sensors which created index reassignments? If it is not working as we claim, then we need to fix it. If it is working as advertised but not meeting your expectations, then we will try to make it better.
 
RiverCityBrewer said:
That was just added in the latest RC - check here on page 3 "Real Time Functions".
Click to expand...
I guess I was not specific enough.

The Now function works with a declared script variable but not a Global DateTime. It throws an error:

new DateTime DT
DT = Now
print DT
"Global 1" = DT

06:14:59.909 [Loading...]
06:14:59.909 [Load complete]
06:14:59.909 [Started]
06:14:59.909 04-05-2019 06:14:59 PM
06:14:59.909 [ERROR: Index was outside the bounds of the array.]

My error adding the () on the Now as I have coded in years with VB
 
BrunDog said:
You've reported issues, which we appreciate, but nothing of this magnitude... was this a failure of the system or swapped out sensors which created index reassignments? If it is not working as we claim, then we need to fix it. If it is working as advertised but not meeting your expectations, then we will try to make it better.
Click to expand...

I never took it as you. The system works as you state and it’s me mucking with it.

The problem stemmed from swapped out and reassign.
 
My BruControl created some data files. I see they are csv. Mine have a Time and one Data Point which are all 0. Could someone point me to where the Data is explained. I could not find in the User Manual. I do not have any Temp Probes hooked up yet but will shortly. I just want to understand what the Data Files are.
 
Hi. Yes, BC records data files in order to feed graph data. Basically all running elements’ data are stored in these files.

We don’t publish info about them in the manual as they are really there for the application, but certain users are re-using some of that data for their own purposes. You need to be careful not to modify, delete, or lock these files else the data will become corrupted.

Each element has a unique identifier, which is the name of the file. If you are crafty you can look up the ID in the configuration file but looking at date/times can point out which is which too.

Since on the topic, we are aware these can get pretty big and take up disk space, considering 30 days’ worth of data is stored here. Something to consider when setting up interface refresh intervals and device refresh multiples. Each time a device is refreshed, the data is stored, so increasing your intervals will reduce the data amount if that’s important to you.

We’ll be providing an option for a remote network location and to store these and a limit of the number of days of data soon. Also we’ll likely move to a database format at some point.
 
I suspected it was the Graph Data. Does the Refresh Interval and Refresh Multiple effect the data storage or only the Refresh Interval of the Graph. You maximum Refresh Interval is 60. When logging a Mash, that is fine, but logging a Fermentation 3,600 (hour) or even higher would be better, at least on the Graph Refresh Interval. You could go as high as a Day (86,400) in my mind.
 
Just realized it has nothing to do with the Graph Refresh Interval but Elements? The data records all enabled Elements? You said "running". That could be quite big if using for fermentation of a Barley Wine.
 
Each time a device element updates, it stores that data. So 1 per second will store twice as much data as once every other second.

Brew operations at a second might make sense, but fermentation doesn’t need such frequency, so maybe 5 or 10 second intervals is a good option there.
 
in the release notes of 1.1, you state that the time type can now span days. Is the format
ddd.hHH:MM:SS

12.14:30:10 12 days, 14 hours, 30 minutes and 10 seconds?
 
VinceBrews said:
Is it expected behavior (or am I doing something wrong) that I can't do concatenation with a global string?
"Global 1" value = “Temp: “ + “Vessel Temp” Value
results in a [ERROR: The operands not do not match type]

This is the sort of thing I was wondering in my earlier post... are there functional limitations of global variables over in-script variables?
Click to expand...

It does look like inline operations for Globals is not implemented yet. We'll add it to the list. In the meantime, perform the conversion and concatenation using a (local) variable:

Code: 
new string temp_string
temp_string = "Temp: "
temp_string += "Vessel Temp" displaytext
"Global 1" value = temp_string
 
Played around with with time variable , Global Element as time and Timer Element:

Time Variable Value in Inspector Element and Global Element are displayed as dd.HH.MM:SS

The Timer Element is displayed as dd:HH:MM:SS

All time values will accept either format in a Script.
if you use the print command, they are all
dd.HH.MM:SS

The maximum number of days is: 9999999 which is roughly:
2,739 years (about the time my Barley Wine will be finished)
 
BrunDog said:
You guys are fast! Yes, we don’t think it would be practical to have both inputs and outputs on the same pin. But you could have inputs OR outputs and change the practical function as you see fit. PID or Duty Cycle is a perfect example.

We didn’t want you to be limited in your I/O, so built it this way. Because flexibility.
Click to expand...
This is exactly what I do with my boil kettle, Its the only time I need to unlock the setting on the software while brewing to go in and enable the duty cycle mode after I bring my kettle up to 190 degrees with the pid function and add the antifoaming agent.

Unrelated question... I see in the new timers feature theres an ability to activate outputs but is there a was to deactivate outputs or any plans to implement that feature? say if I want my boil kettle to automatically turn off after a 75 minute boil?
I know I can write scripts for this but looking for simplicity right now.

also just in case its there and I havent figured it out.. In the new software, is there a way to display multiple workspaces at one time on 2 screens.. We have a 50" display I keep on above our brewing system with all our fermenter temps and /tilt info like graphs and I was wondering if there was a way to keep that up there while using the hot side brew controls on my touchscreen. I know it was asked about a while back but dont remember the outcome of the conversation.
 
Last edited:

Similar threads

h22lude
My BruControl UniFlex review
Replies
3
Views
2K
h22lude
h22lude
duncan.brown
Brewery Dashboard
Replies
18
Views
2K
suprchunk
suprchunk
braumke
Automate your electric brewery - 4 Testers needed for open source project
Replies
29
Views
6K
estricklin
estricklin
RonBurgundy10
BruControl Uniflex: Automation For All
2
Replies
51
Views
8K
BrunDog
BrunDog
muhteeus
muh's BruControl Build
Replies
25
Views
6K
sensei247
sensei247
InkBird 300

Latest posts

Back
Top