BruControl: Brewery control & automation software

Homebrew Talk

Help Support Homebrew Talk:

This site may earn a commission from merchant affiliate links, including eBay, Amazon, and others.
Would be nice to have an new element class that is just like a global but does not communicate with the local DB. It could act like a global in all other aspects except for the sql. I have used tons of globals and would use these instead. Of course, fixing the Globals so they do not communicate but are just like variables in action except the values are persistent.
 
NTC 10k Probes Calibration

I am using a few NTC 10k probes and throughout my brewery and I find them unreliable. I find myself constantly calibrating them, adding various offsets at start of each brewday. The max total offset range is anywhere from +10 to minus 10.

One of those probes is the same as used with my BCS-482. My BCS-482 as been working reliably so far.

Could this issue be linked to some EMF pollution? I find it quite difficult separating my DC and AC wires in my control panel..
Is your DC - bus connected to your AC ground?
 
My set up has 2 x DC negative bus and one AC ground bus all connected to a single stud in my control panel; does this make sense?
 

Attachments

  • image.jpg
    image.jpg
    2.9 MB
Yes it does, your EMI may be induced via something noisy on the AC ground. Try connecting the 2 DC - together and isolating them from the AC ground.
 
Is there a script command to see if a Timer is running? I have different timers (different workspaces or position on the same workspace) that I want to mirror 100% of the time. I know how to mirror them, I just would like to know if a timer is running so that the others will be running.
 
So my control panel would have 2 grounding studs like this..?

View attachment 825814
As mentioned above keep the AC and DC grounds isolated. If the 2 ground studs you have pictured are attached to the side of the control panel or have a common connection then you haven't isolated them. What I did with my panel was to use the AC supply ground via supply cable and have that terminated on a series of terminal blocks which I only attach AC grounds to. This termination grounding block is isolated from the rest of the panel. My electrical panel is grounded via steel rod driven 9' into the ground. I then ran a separate ground from my copper water pipe (street side) to the side of the control panel and used a star pattern to connect my DC ground termination block for all things DC related. In other words I have 2 ground sources (1) ground from 4 wire supply AC and (2) water pipe separate path to panel and DC termination array. Both are isolated from one another. There are other ways of doing this but this was more convenient for my application.
 
Last edited:
Typically home copper water pipes would be grounded to the AC ground, even if the main AC ground is through a steel rod into the ground from the main panel. Would this still meet your isolation for EMI purposes?
 
I just checked city water pipe inlet with AC panel ground and they are indeed bonded…

Perhaps I should use install a dedicated grounding Rod for my DC..?
 
Typically home copper water pipes would be grounded to the AC ground, even if the main AC ground is through a steel rod into the ground from the main panel. Would this still meet your isolation for EMI purposes?
In my case the water supply street side is copper to the water meter then PEX pipe after that so no bond/connection between the copper pipe and the main electrical panel. This situation provides 2 different paths to ground ( steel rod and copper water pipe) so yes it would meet criteria for isolation of grounds.
 
Last edited:
I just checked city water pipe inlet with AC panel ground and they are indeed bonded…

Perhaps I should use install a dedicated grounding Rod for my DC..?
No, we are trying to eliminate potential intrusion of AC signals on the DC - bus. Simply tie a wire between all of your DC - terminals and see if that eliminates your EMI you are seeing in your temperature probes.
 
NTC 10k Probes Calibration

I am using a few NTC 10k probes and throughout my brewery and I find them unreliable. I find myself constantly calibrating them, adding various offsets at start of each brewday. The max total offset range is anywhere from +10 to minus 10.

One of those probes is the same as used with my BCS-482. My BCS-482 as been working reliably so far.

Could this issue be linked to some EMF pollution? I find it quite difficult separating my DC and AC wires in my control panel..

No, we are trying to eliminate potential intrusion of AC signals on the DC - bus. Simply tie a wire between all of your DC - terminals and see if that eliminates your EMI you are seeing in your temperature probes.
Shielding your thermistor wires can help too. Would need a metallic shield/sleeve with it tied to ground at the enclosure side only.
 
I am trying to trouble shoot an issue with Hysteresis and the Unishield, I have the control wire hooked to PIN/Port 5 (and have tried PIN/Port 9) connected to the P screw terminal 9-2P (8-2P for Port 9).

Hysteresis Elements demands 255 but the elements are not heating.

I have created Digital Outputs to test the signal coming from the Ports. The voltage is less than 1 v and fluctuates with the digital Out state = true.


I would think 5 v would be correct.

FYI, I have Port 7 (Screw Terminal 8-4P) set up as PID going to the AA-1 and it works fine.

Any help?
 
I am trying to trouble shoot an issue with Hysteresis and the Unishield, ----
I have traced my wires and rechecked the connection. I also purchased a 0 to 5 v analog voltmeter.

It was my fault it was not working. I was trying to find out what "Predictive Hysteresis" did and was re reading the manual an found my issue. Offset must be NEGATIVE :rolleyes:for heating or it will never turn "ON".

I changed to a negative number and all is well.:p:rock:


I could not find ""Predictive Hysteresis" in the manual but have left it selected for my heating element. I still can only guess what it does.


Suggested Edit on the Dialog for a Hysteresis Element.

Hys1.png
 
Self Induced Odd Error

I had a script named scrTest

I created another script named scrTest ( stupid I know, but I had forgotten the other one).

When I put the

stop scrTest

as the last line and ran the second one, it gave me the
"End of Script" error.

This is NOT an issue, just FYI.

Removed the other scrTest and all works.
 
Another Self Induced Odd Error

This NOT an issue, but an FYI

I created a script that was looping. it was a fairly short script but had several

sleep 100

commands in the loop.

When I ran it, it would basically not allow me to stop the script or even shut down BruControl.

I would have to use the Task Manager to kill BruControl.

I was rebuilding my scripts from scratch as I was having this issue with my program after I had changed some scripts.

I was trying to add a short delay within the scripts, but I had too many.

I have added a delay timer when I need that but rather than 100 milliseconds, the delay is now one second.
 
Forgive me if I missed this, been busy running the brewery lately and have not kept up around here. Mega just burned up on me (Brewery is down!!) and I need to flash firmware on the new unit purchased. I see version 46 was released last month and the note says "This version requires new interface definition files in BruControl" I'm fairly certain I was on 45O because I had not yet changed over any interface definition files associated with 45Q.

Can someone give me a rundown on what this means (pros/cons) and the tasks/effort that are in front of me so I can better decide whether I should stick with 45O or run the new 46? I'm currently running BruControl 1.1 Build 22 which I believe pretty much confirms I was on 45O.

Steve
 
If your production is down and you are reliant on this system, I would definitely just flash the latest 45 firmware and get back running. To move to 46 requires some changes to your BC configuration file that I presume you don't have the time to deal with right now.
 
Forgive me if I missed this, been busy running the brewery lately and have not kept up around here. Mega just burned up on me (Brewery is down!!) and I need to flash firmware on the new unit purchased. I see version 46 was released last month and the note says "This version requires new interface definition files in BruControl" I'm fairly certain I was on 45O because I had not yet changed over any interface definition files associated with 45Q.

Can someone give me a rundown on what this means (pros/cons) and the tasks/effort that are in front of me so I can better decide whether I should stick with 45O or run the new 46? I'm currently running BruControl 1.1 Build 22 which I believe pretty much confirms I was on 45O.

Steve
River City is correct to get you up and running. Don't fix it if it a'int broken. For upgrading to v46,The biggest change will be with Analog Ports A1-A15 if you have used them. You will need to delete the "old" Elements and recreate "new" ones for any analog ports.

See

BruControl: Brewery control & automation software
 
I am having an issue again with too many Global Elements. I use globals for lots of things like labels and to store things that do not change between brews (such as flow rates between vessels). I also use Globals to store Setpoints that I can change and then update the Target of an Element.

Once I reach the "limit" the program stops being logical (if and endifs do not function properly, among other things). I took the same script from a "funky" Configuration and went back to saved Configuration and the same script placed in the old configuration worked fine.

Attached is my main brewery Screen where I have 31 Globals, not of which I need for any data.

If you look, you can see that 1,2, & 3 are stacked(you cannot see 2 or 3). I have to have 3 because I use colors to "guide" what I am doing. For Example. a Blue Background means to Wait and the program will auto advance. The same is true for 7,8,&9. If I was able to just use a path for background 1, I would go from 6 to 2 globals with more functionality with endless Backgrounds.

1 to 10 are simple Text boxes where I can change the value of the text.

11 is where I can manually enter a value and save it to a different Global (on my Data Exchange workspace) that I do want to save, such as OG, or the Volume of the Brew Kettle pre Boil.

12 to 22 are just for display. I tried using an Inspector for this but they "Blink" continuously.
23 to 26 show the status of my Heating Elements. They simply become hidden when the heater state = false.

The background of my pumps (27 to 31) change depending on the state.


32 and 33 have a Script that allows me to quickly change the Mash and Boil Timer when I am testing the program. This are normally hidden and only set to visible when I am testing some scripts.

34 is an incremental global where I branch the program and skip steps if I need to go down a different line. Some of the Texts in 1-10 can also be set in the same script depending on the value of 34 (gBrewStatus)

The program works fine until I exceed the undocumented limit on Globals, then it slows down and scripts that were working no longer do so properly. It is hard to describe what happens when that limit is exceeded.

I have a lot more globals than this for importing a BeerSmith xml file and to store things like volumes and transfer times on other workspaces,

globals that do not need to be read.png


1. An Element that is just like a Global except that it is not hit to transfer to the database would solve the issue I think. I do not use the localDB because it gets very large (gigibytes) very quickly.

2. Paths for background and fileIndex where I could leave on Image 1 (or Index 1) and just change the path in the box would be super and make it much easier. The choice of 3 is not enough. I think I have something like 20 alarms because I want different sounds (Lots of Text to Speech)

3. Global that hit the Local DB should have the option of Never, a Time Choice, Once, Forced save (script command). I am not sure if setting to "Never" would solve my issue as the program is still "looking" at the Global to see that status. I do not know how the internal program "looks" at Globals, but I think the problem lies there.

I spent the past 4 weeks rebuilding the program from scratch, but it looks like I am going to have to go back to one that works properly(from last week to be sure I go back far enough) It will not have the automation I wanted because I used globals to manipulate and save data. I tried using variables but every time I crashed a script in testing, I lost my variables. And many scripts use the same global to get or save data which makes them much better suited to do that.
 
Last edited:
I got everything changed over and back up and running. I purchased a few extra Mega and Sunfounder Ethernet boards. In theory I should be able to install same firmware and Ethernet settings for a quick swap out in the event of another failure? Should I use same MAC address or a unique one?

What are the advantages of the newest firmware?
 
I got everything changed over and back up and running. I purchased a few extra Mega and Sunfounder Ethernet boards. In theory I should be able to install same firmware and Ethernet settings for a quick swap out in the event of another failure? Should I use same MAC address or a unique one?

What are the advantages of the newest firmware?
I did upgrade from V45 to V46 with the mindset that with any future updates I wouldn't have to mess around with the Analog port conversions on top of the actual update. Not all updates in V46 affect my situation but some have had some very useful improvements,. I figured do it now and not prolong the inevitable, just my 2 cents worth. You mention you have purchased additional MEGA's, why not install the new firmware on them, do the Analog conversion and have everything set in case the existing board goes down, this way you have a updated board to swap out in the event of a toasted board. You wouldn't have to take your existing system offline unless something happened to your production board. It's proactive insurance the way I see it.
 
Last edited:
I got everything changed over and back up and running. I purchased a few extra Mega and Sunfounder Ethernet boards. In theory I should be able to install same firmware and Ethernet settings for a quick swap out in the event of another failure? Should I use same MAC address or a unique one?

What are the advantages of the newest firmware?
Tartan has a great idea. Just save your configuration and give it a name beside .....copy.brucfg and choose it as your configuration under settings. You could then upgrade at your own pace and switch boards between FW 45 and FW 46 (or Just reflash them).

Go between configurations and FW 45 and FW 46

Here is a link to what @BrunDog said when FW 46 was released

https://www.homebrewtalk.com/thread...ntrol-automation-software.624198/post-9307818

Here is a link to how I converted:

https://www.homebrewtalk.com/thread...ntrol-automation-software.624198/post-9310064
 
Tartan has a great idea. Just save your configuration and give it a name beside .....copy.brucfg and choose it as your configuration under settings. You could then upgrade at your own pace and switch boards between FW 45 and FW 46 (or Just reflash them).

Go between configurations and FW 45 and FW 46

Here is a link to what @BrunDog said when FW 46 was released

https://www.homebrewtalk.com/thread...ntrol-automation-software.624198/post-9307818

Here is a link to how I converted:

https://www.homebrewtalk.com/thread...ntrol-automation-software.624198/post-9310064
Hi thanks,
but upgrade at this point of time brings nothing, or am I wrong?
Sorry I was away for longer time, I didn't see any new version of the software? Did I miss it :-S
Br
 
Last edited:
Hi thanks,
but upgrade at this point of time brings nothing, or am I wrong?
Sorry I was away for longer time, I didn't see any new version of the software? Did I missed it :-S
Br
Most firmware updates have
Not had any effect on the scripts. Fw46 does, but was fairly easy to fix. If you are not using any analog ports, really an easier upgrade.

The are more options for some ports than before.

One reason is upgrade for Future Firmware updates
 
720ma total draw is also How I see it
Earlier posted was the this question about the relay current draw;
Control signal input
High level current
[email protected] 0.4mA@5V 1.1mA@12V 2.2mA@24V
[email protected] 1.0mA@5V 2.4mA@12V 5.0mA@24V
So to answer my own question, the control output from the Mega2560 would be .001 amp, which is below the max amp draw of .020.


I'm late to the post, but for anyone researching this issue, the above spec data refers to just the current required to control the relay. You also need current to operate the coil in the relay, so the total energy required needs to include both the signal to operate and coil current to pull the contacts closed.

If you are using the 5V version of the D-229 relay module for example, relays like this typically use under 100mA to maintain an ON state , so the the operating current for all 8 relays being in the ON state should be less that 800mA (the spec sheet for the D-228 relay module give a max (relay all action) of 720mA.
The 12V version of this board with 12V relays has a 400mA all action specification.
Hope this clears things up.
 
I have an ESP32 with the following elements:
- Heating element (SSR) on Pin 5
- Relay for 110v pump (switches the neutral line) on Pin 16
- RTD on pin 32 (with parallel connections on pins 23, 18, 19)
- RTD on pin 33 (with parallel connections on pins 23, 18, 19)

When I toggle the relay for the pump, the RTD measurements drop out to negative and then come back. Any suggestions on what to consider for this problem?
 
When I toggle the relay for the pump, the RTD measurements drop out to negative and then come back. Any suggestions on what to consider for this problem?
grounding... and isolation... the sudden change in current to the start or stop of the motor and/or relay is causing an actual change in voltage on your RTD, and the RTD smoothing algorithm takes a while to return.. research: "flyback diode"
 
grounding... and isolation... the sudden change in current to the start or stop of the motor and/or relay is causing an actual change in voltage on your RTD, and the RTD smoothing algorithm takes a while to return.. research: "flyback diode"
So true. Definitely look into playing around with the RTD software filer algorithm. In my case the dropouts seem to come from the relay cycling of the 24VAC transformer I have in my control box for the burner (yes, I am gas fired). Several ways to fix this, but since I have the software filter engaged the impact of a random event (0-3 times during the brew) getting through is not worth worrying about. I really am glad to have moved over to the stability and accuracy of the RTDs, since the 1-wires were a bit persnickety.

I am wiring a new control box for the two 1/2 barrel Spike fermenters and Penguin chiller based on a Lilygo-T 8ch relay with an ESP32 module and will start with 1-wire thermistors. I'm looking for input what people here use on their fermenters.

I have been working on the ferment control box for several months now in-between Honey-dos and several other hobbies. Being retired is the busiest I've been in a long while.
 
I got the Giga R1 Wifi boards in, I know there is no BC firmware yet, so just tinkering... of course the usb port doesn't work with standard win10 or Win7 drivers

It looks like a lot of people having issues with the Giga R1 connecting via usb to a COM port from what i am seeing on the Arduino forum, so I would be wary of being an early adopter..

edit - all good, they shipped some units without the bootloader, and their instructions on how to prep it to load the .elf file were not quite dummy-proof..
 
Last edited:
I am having an issue again with too many Global Elements. I use globals for lots of things like labels and to store things that do not change between brews (such as flow rates between vessels). I also use Globals to store Setpoints that I can change and then update the Target of an Element.

Once I reach the "limit" the program stops being logical (if and endifs do not function properly, among other things). I took the same script from a "funky" Configuration and went back to saved Configuration and the same script placed in the old configuration worked fine.

Attached is my main brewery Screen where I have 31 Globals, not of which I need for any data.

If you look, you can see that 1,2, & 3 are stacked(you cannot see 2 or 3). I have to have 3 because I use colors to "guide" what I am doing. For Example. a Blue Background means to Wait and the program will auto advance. The same is true for 7,8,&9. If I was able to just use a path for background 1, I would go from 6 to 2 globals with more functionality with endless Backgrounds.

1 to 10 are simple Text boxes where I can change the value of the text.

11 is where I can manually enter a value and save it to a different Global (on my Data Exchange workspace) that I do want to save, such as OG, or the Volume of the Brew Kettle pre Boil.

12 to 22 are just for display. I tried using an Inspector for this but they "Blink" continuously.
23 to 26 show the status of my Heating Elements. They simply become hidden when the heater state = false.

The background of my pumps (27 to 31) change depending on the state.


32 and 33 have a Script that allows me to quickly change the Mash and Boil Timer when I am testing the program. This are normally hidden and only set to visible when I am testing some scripts.

34 is an incremental global where I branch the program and skip steps if I need to go down a different line. Some of the Texts in 1-10 can also be set in the same script depending on the value of 34 (gBrewStatus)

The program works fine until I exceed the undocumented limit on Globals, then it slows down and scripts that were working no longer do so properly. It is hard to describe what happens when that limit is exceeded.

I have a lot more globals than this for importing a BeerSmith xml file and to store things like volumes and transfer times on other workspaces,

View attachment 827761

1. An Element that is just like a Global except that it is not hit to transfer to the database would solve the issue I think. I do not use the localDB because it gets very large (gigibytes) very quickly.

2. Paths for background and fileIndex where I could leave on Image 1 (or Index 1) and just change the path in the box would be super and make it much easier. The choice of 3 is not enough. I think I have something like 20 alarms because I want different sounds (Lots of Text to Speech)

3. Global that hit the Local DB should have the option of Never, a Time Choice, Once, Forced save (script command). I am not sure if setting to "Never" would solve my issue as the program is still "looking" at the Global to see that status. I do not know how the internal program "looks" at Globals, but I think the problem lies there.

I spent the past 4 weeks rebuilding the program from scratch, but it looks like I am going to have to go back to one that works properly(from last week to be sure I go back far enough) It will not have the automation I wanted because I used globals to manipulate and save data. I tried using variables but every time I crashed a script in testing, I lost my variables. And many scripts use the same global to get or save data which makes them much better suited to do that.
Probably nothing to do with globals but I did find that I had some comments that might be causes some issues.

I had several
//<><><><><><><><><><><><<><><><><><><>

When I looked at the raw brucfg file, they were converted to some code. I go rid of those and it looks like it solved many issues I was having,
 
Been working on a fermentation controller using a Lilygo 8 relay board I bought last year. The embedded ESP32 loaded fine and I have been able to test functionality of the 1-wire temperature probes, LCD screen, and relays to control Heat/Cool of two fermenters and power to their chiller. I split the supply power to the box, one power cable furnishes AC to the relays and the other furnishes 12VDC to the board. I did this to reduce the load on my UPS (have done the same for my brew stand). If (and when) the grid goes down, my controllers and computer will run until I am able to get backup power going.
I have hacked in a level converter to control the 1-wire and LCD which I power with 5VDC that the onboard regulator puts out from the 12V.

I wrote a test script and everything works as expected. Have not tracked the cost, but I'm sure it is under $100.
Now I am searching for fermentation script examples on this thread to run the little critter.

FermCntl&Outlets.pngFermController.pngLCD.png
 
Been working on a fermentation controller using a Lilygo 8 relay board I bought last year. The embedded ESP32 loaded fine and I have been able to test functionality of the 1-wire temperature probes, LCD screen, and relays to control Heat/Cool of two fermenters and power to their chiller. I split the supply power to the box, one power cable furnishes AC to the relays and the other furnishes 12VDC to the board. I did this to reduce the load on my UPS (have done the same for my brew stand). If (and when) the grid goes down, my controllers and computer will run until I am able to get backup power going.
I have hacked in a level converter to control the 1-wire and LCD which I power with 5VDC that the onboard regulator puts out from the 12V.
Any issue with I/O conflicts for the 1-wire or anything else??
 
Any issue with I/O conflicts for the 1-wire or anything else??
Yes, but not for the 1-wire.
I had to run a wire from the ESP32 pin 33 (GPIO21) to an unused pin on the board's 11x2 header to use the SDA signal for the LCD. Since this board uses GPIO21 to control its relay K5, I just removed the inline resistor next to the pin to break the connection to the relay. I did not bother to wire relay K5 to another IO because I have unused relays at this point, but it can be easily done later if needed.

I also moved the inline resistor next to pin 29 of the ESP32 off the pad 90 degrees and connected it to pin 26. Pin 29 is GPIO5 will cause the ESP32 to go into AP mode if at a logic low during startup and on the LILYGO is connected to relay K4. Pin 26 (GPIO4) is now running relay K4.

I used a tiny 4 channel level converter PCB to allow the 3.3V ESP32 to interface to the 5V LCD and 1-wire. I found from a previous build that the 1-wire temperature probes do work at 3.3V, but under certain conditions the voltage will sag and the probes drop out. At five volts there is no issue. I soldered small thru-hole terminal blocks to the board and use a zip tie anchor to mount the level converter next to the signal header.

I get 5V to operate the 1-wire probes, LCD, and level converter from the onboard MP1593 DC-DC voltage converter. I supply the board's power input with 24VDC from an external 2A power supply (wall wart). From my calculations, the voltage converter has plenty of operational headroom.

With the exception of the relay controlling power to my chiller, the 120V 10A relays will have no issues operating the pumps inside the chiller glycol well and the heaters in the Spike fermenters I use (the Inkbird ITC-308 use the same relay). I have bought a couple board mount relays that have the same operation input parameters and form factor but with a higher current carrying capacity. I may use the higher rated relay for the chiller if I see any issues, but I don't expect to. The chiller has its own temperature cycle circuitry to hold a constant temperature in its glycol well I usually set to 28F, so the LILYGO relay making the chiller operational stays closed, and not be doing the make-break cycles that create wear.

MPUrework.jpgLevelConvert.jpgLevelConverterPCB.jpg
 
Last edited:
How would I go about averaging inputs for a PID control? Lets say I have 2 temp probes I want to use as an average input for my PID for my mash temp.

Probe 1: 150
Probe 2: 160

I want my PID to know its currently 155 and use that as its input.
 
How would I go about averaging inputs for a PID control? Lets say I have 2 temp probes I want to use as an average input for my PID for my mash temp.

Probe 1: 150
Probe 2: 160

I want my PID to know its currently 155 and use that as its input.
I think you would have to get @BrunDog to add that to the program. Right now the Input is on the PID Element and that single Probe Provides the Temperature for the Probe. When I was using the BCS early on, you could do that, but after using it for a while, I decided it was a bad idea. I was using it with a HERMS system and averaging the Temp IN vs Temp OUT. I soon realized that the Temp IN was TOO hot. When I went back to not average and only use the Temp IN, the Mash got to that temp and eventually the Temp OUT matched the Temp IN.

If you were thinking about the Mash, you would not want your Temp IN to exceed your desired Mash Target.

BTW I use a Chillzilla to keep my Mash Temperature. I use a Quadzilla to and a small HLT Reservoir to provide the "Bath" in the Outer Tube and the Wort through the Inner Tube. I was recycling the Mash and measuring the temperature of the Mash returning to the MLT (Temp IN) and the Mash Drain (Temp OUT) prior to the pump.
 
Back
Top