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 think I know what is happening and it is on the docket to be remedied. Basically the script is forcing the device setup or change repeatedly so it gets caught in an “initial check” mode. If you edit the script to have a toggle which prevents the device declaration from repeating, the problem will go away.

BC should not be sending repeat instructions to the interface, and we will address it. In the meantime, if you post your script section, I can offer tips to fix it as I have noted above.
 
Hi BrunDog, I am having the same problem, but I believe its my coding more then anything , I have attached it as well for you to review. Some of the devices go off line in the "-------" state and stopping then resuming the code sets it back , but its random.
 

Attachments

  • JAN 6 CODE FINAL (002).txt
    1.4 KB · Views: 23
Hi, I see multiple requests for help... rather than me trying to fully understand each, let me first post a general example to see if this can help you. This should be temporary until we make the update in BC.

In this example, you will see that the PID is enabled due to a condition (A is bigger than B), but then repeatedly established:

Code:
[start]
new value A
new value B
A = 2
B = 1

[loop]
if A > B
"PID" Enable = true
endif
sleep 1000
goto loop

BruControl will not repeat commands to the interface which were generated by user via the device elements, but will when the script calls for it. Therefore in this example, the PID is repeatedly enabled on the interface, and since the frequency is every second, which likely matches the default refresh interface, the value of the PID never gets read by BC. The workaround in the script is to use a toggle to make sure the PID is only enabled once:

Code:
[start]
new value A
new value B
new bool trigger
A = 2
B = 1
trigger = false

[loop]
if A > B
if trigger == false
"PID" Enable = true
trigger = true
endif
else
trigger = false
endif
sleep 1000
goto loop

In this example, trigger is a "toggle" that ensures the PID is only enabled the first time the condition is met, and not on subsequent turns. When the condition fails to be met, trigger is reset, ensuring that when the condition is met again, the PID will be enabled.

I hope this makes some sense. I know it is not ideal but should not be hard to implement as a workaround. I will try to review the scripts above and suggest where this fits.
 
Last edited:
Hi, I see multiple requests for help... rather than me trying to fully understand each, let me first post a general example to see if this can help you. This should be temporary until we make the update in BC.

In this example, you will see that the PID is established due to a condition (A is bigger than B), but then repeatedly established:

Code:
[start]
new value A
new value B
A = 2
B = 1

[loop]
if A > B
"PID" Enable = true
endif
sleep 1000
goto loop

BruControl will not repeat commands to the interface which were generated by user via the device elements, but will when the script calls for it. Therefore in this example, the PID is repeatedly set up on the interface, and since the frequency is every second, which likely matches the default refresh interface, the value of the PID never gets read by BC. The workaround in the script is to use a toggle to make sure the PID is only established once:

Code:
[start]
new value A
new value B
new bool trigger
A = 2
B = 1
trigger = false

[loop]
if A > B
if trigger == false
"PID" Enable = true
trigger = true
endif
else
trigger = false
endif
sleep 1000
goto loop

In this example, trigger is a "toggle" that ensures the PID is only established the first time the condition is met, and not on subsequent turns. When the condition fails to be met, trigger is reset, ensuring that when the condition is met again, the PID will be established.

I hope this makes some sense. I know it is not ideal but should not be hard to implement as a workaround. I will try to review the scripts above and suggest where this fits.
Could you use?

If "PID" enable == false
"PID" enable = true
Endif

This would avoid having to create and set a separate variable. I'm not sure if the first line is valid or if it would require communication to the MCU.
 
Could you use?

If "PID" enable == false
"PID" enable = true
Endif

This would avoid having to create and set a separate variable. I'm not sure if the first line is valid or if it would require communication to the MCU.

Brilliant!! Even better! No, it does not require communication.

More than one way to flay the feline.
 
I think the transmitter should have 3 wires, +,-, and out...

You can find the wiring at brucontrol.com under 'build' --> 'schematics' --> 'BruControl Analog Sensor Schematic'

You are correct for the sensor he is pointing to and most newer devices. The diagram he linked to actually shows how 4-20mA sensors were originally designed to only need 2 wires for both power and signal output. The sensor draws up to 4mA to power itself and its circuitry, then uses a transistor to draw up to another 16mA current as the sensor output. Because of the proliferation of these 2 wire sensors, this spawned the HART protocol as they now needed a way to get more information out of these 2 wires as industrial plants wanted an alternative to replacing miles of cable.
 
Thanks for quick answers.

It's actually this pressure sensor https://www.aliexpress.com/item/YB-...587.html?spm=a2g0s.9042311.0.0.27424c4dfmKO1c
Sensor does have 4 outs (PIN 1-3 and Ground), but on schematic (in item description) there are only 2 wires (power and signal).

Weird I have the exact same sensor and mine has only two wires. The connector has four pins, if you unscrew the nut holding the sensor connector you can check how many wires which goes from the sensor to the connector and to which pins. I have wired it like in the item description with the negative wire over a resistor and then to ground. Then you get 1-5V on the sensor side of the resistor.
 
2 Wire current sensors are very popular. The wiring in post 1729 is how it should be done. +24vdc into transmitter, out to resistor, other side of resistor to -24vdc. Measure the voltage drop across resistor.

Voltage = current x resistor

1v = 4ma x 250
5v = 20ma x 250
 
2 Wire current sensors are very popular. The wiring in post 1729 is how it should be done. +24vdc into transmitter, out to resistor, other side of resistor to -24vdc. Measure the voltage drop across resistor.

Voltage = current x resistor

1v = 4ma x 250
5v = 20ma x 250

Right-on.

But... and I shouldn't be technically anal but can't help it... "-24VDC" is actually a unique voltage level, not ground. "0VDC" is a better declaration of ground. Sorry! Carry on!
 
Ok I hope this isn’t a dumb question but here goes...

If I am running a feather (with ethernet wing) on a ferm/serve system, it will be on all the time, (brucontrol will be running on a networked desktop). A mega would be used on the brew side, this mega would only be powered during brew sessions, is there a proper way to power down the mega or do I just disconnect the brew side power and call it a day?
 
No, actually a great question! Never been asked here, surprisingly.

I have a similar setup on my personal equipment. Feather/fermenter runs all the time of course. Upon completing a brew day, I set all the devices where I want them, in a “default” state if you will. I have a script that does this - it’s called Brew Reset. Most devices are disabled but some continue running like temp probes. Sometimes I run that and then override a valve or two to get them more open to atmosphere for drying. I have a PC on my brew rig serving as the screen sharing machine, which I then initiate its shutdown. Then cut the power to the rig.

The MEGA powers off and BruControl sees the interface disconnect and just sits there, indefinitely, waiting for it to reconnect. No harm there at all.

So basically, yeah, cut the power and call it a day. Oh, grab a homebrew, too, to celebrate.
 
*IF* you have a script misbehaving and you frantically cut power to the breaker that the mega is on in you brew panel because an element wasn't shutting off as expected, then turn it back on... BruControl will turn that element right back on as soon as it sees the interface! and while the mega is powered off and disconnected, you cannot turn it 'off'... there are a bunch of ways to skin that cat, but none seem to be perfect...
 
True... we try to have BC be tenacious about connecting and controlling the interface. So it will command the state of any outputs when an interface reconnects.

I suggest any design separates the interface power from the element power. For example, the main power switch powers the power supply which feeds the interface, and the E-Stop switch powers the high voltage devices such as elements, pumps, etc.). This way a quick E-stop will stop any run-away situation, but you don't lose control/command of the interface.

So to add another detail to my shutdown sequence above... disable the E-stop, then power off the main power.
 
Hello! I just installed BruControl and wanted to say that I'm pretty impressed with the system so far. I have just been doing basic things, and writing some scripts to get my feet wet.

I have a build that I'm working on a new Low O2 setup with 2 vessels and using a counterflow as a heat exchanger for both heating/maintaining mash and chilling. The end game being full automation from the point that I put the grain into the MT until the wort goes into the fermenter.

I had been using another system for the last year(craftbeerpi + custom arduino scripts), but this is spot on for the broad configurable functionality that I really wanted.

One question I do have is (and maybe this was covered in the previous 44 pages of this thread...I only read about 20 of them), but is there a compelling reason to try to minimize the number of controllers being used? Does the IO overhead get noticeable when you get to a certain number of nodes that the system is talking to? Currently, I'm looking at just using a MEGA and an 8266, but I had thought about trying to compartmentalize some more things and have separate 8266s on many parts so they would all just talk over the network rather than a bundle of cables running from the panel to the various doo-dads.

-Nate
 
Hi Nate. Thank you for the feedback!

I don’t think you will run into any bottlenecks with multiple interfaces. The only limits I can think of are CPU processing on the host computer or network overhead. BruControl doesn’t need a ton of horsepower, even running a bunch of concurrent scripts seems to keep it understressed. Lots of elements updating rapidly will cause the disk system to do a lot of data writes, so I suppose that could be an eventual bottleneck. Finally BruControl uses a fairly compact network protocol, so I doubt we would overload that unless communicating with hundreds of interfaces.

As always, users should be conservative with respect to data updates (refresh intervals). For brewing, maybe 1 second updates are nice, but for fermentation and other slow stuff, 5 or 10 sec can be more appropriate and minimize data transfer and recording.

All that said, I personally like the idea of distributed controls. We have a few users who run parallel interfaces even though they are just a foot or two away from each other - to reduce wiring as you noted.
 
Hi Nate. Thank you for the feedback!

I don’t think you will run into any bottlenecks with multiple interfaces. The only limits I can think of are CPU processing on the host computer or network overhead. BruControl doesn’t need a ton of horsepower, even running a bunch of concurrent scripts seems to keep it understressed. Lots of elements updating rapidly will cause the disk system to do a lot of data writes, so I suppose that could be an eventual bottleneck. Finally BruControl uses a fairly compact network protocol, so I doubt we would overload that unless communicating with hundreds of interfaces.

As always, users should be conservative with respect to data updates (refresh intervals). For brewing, maybe 1 second updates are nice, but for fermentation and other slow stuff, 5 or 10 sec can be more appropriate and minimize data transfer and recording.

All that said, I personally like the idea of distributed controls. We have a few users who run parallel interfaces even though they are just a foot or two away from each other - to reduce wiring as you noted.

I can confirm I am running 10 interfaces at the same time, all wifi (feathers&esp8266s) and most of them with 1 second refresh interval and theres no issues at all. Just make sure theres enough disk space for the log files.
 
Thanks for the feedback. I don't imagine I would have more than a dozen different interfaces going on across everything. (I say that now...)

On a different note, I'm curious what the preferred connector is for sensors and other low current things like ball valves? I have been thinking about using 1/4" stereo headphone jacks, but I'm a little concerned about the long term reliability of them. Previously I used XLR jacks (I only had 3), but they are kind of bulky and relatively expensive.
 
SHHHH... super sneak peak of some new goodness..

iPyvGpr.png


CpWgjvH.jpg
 
Last edited:
Finished the re-design from 1.0-1.1, I have not even started with features, I was pretty fixated with element redesigns..

Old
zzKVkZv.png


New
EoXYK1W.png


With Dynamic LED indicators, Dynamic gauges for volume, and proportional valves. Still have some final touch up work to do.

wWdMTj5.png


Now on to new fetaures....
 
I really like the new look. Does the top menu hide (like the windows bar) or did you just clip it out of the screen shot?
 
Just wanted to give a followup that we have made about 1000 gallons of beer with brucontrol with the new system in anticipation of our opening hopefully in a few weeks.. Everything is performing great.
I can wait for the new version with the tilt and possibly multiple screen support so we can have our fermenter info on one monitor at one resolution and the hot side on another..
milk stout.jpg
 
Back
Top