• Please visit and share your knowledge at our sister communities:
  • If you have not, please join our official Homebrewing Facebook Group!

    Homebrewing Facebook Group

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.
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...
1694518662875.png
 
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.
 
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.
I figured as much, yeah its probably overkill but could be nice in certain situations. One way to do it that I found was to set up a duty cycle or pwm control on the element then implement the PID algo in script and use that to just constantly adjust output on the element based on w/e reading I want.
 
I figured as much, yeah its probably overkill but could be nice in certain situations. One way to do it that I found was to set up a duty cycle or pwm control on the element then implement the PID algo in script and use that to just constantly adjust output on the element based on w/e reading I want.
I would like to be able to assign any temperature probe regardless of interface to be used as the Input for a PID or Hysteresis Element I could also see where and average might work good. I understand the issue the interface still going on something like fermentation where the Input would need to be on the same interface, but if I am doing a Mash, I would know that it failed, just give me a Warning that it could cause issues if the interface with the Probe was disconnected.
,
 
So after years of fault free automation brewing with BruControl, I have a strange issue crop up in my last brew.
After mashing in and clicking on my proceed button the program threw an error and halted the program. I have not modified the program in over a year, and the line that caused the error was a print command to send to the output log. I deleted the line, restarted the program and the program threw the same error even with the line gone.
Rebooted, restarted everything, same results. I have version 1.1 build 22 software version. Should I reload the program or is there a newer release available that I should use?
Thanks!
 
So after years of fault free automation brewing with BruControl, I have a strange issue crop up in my last brew.
After mashing in and clicking on my proceed button the program threw an error and halted the program. I have not modified the program in over a year, and the line that caused the error was a print command to send to the output log. I deleted the line, restarted the program and the program threw the same error even with the line gone.
Rebooted, restarted everything, same results. I have version 1.1 build 22 software version. Should I reload the program or is there a newer release available that I should use?
Thanks!
what was the error? do you have pictures or copies of the script and output log?
 
Is it only the script that failed or the entire program crashed?


If a script error, what is the error?

FYI: The line number in the error handling can be just close and is not exact
 
Is it only the script that failed or the entire program crashed?


If a script error, what is the error?

FYI: The line number in the error handling can be just close and is not exact
Thanks for the quick reply Oakbarn and poptarts.
Script error was invalid command or some such. I don't have the exact error since the program halted and I was frantically trying to debug and restart the script at the same time. The line of code was a print command to the log which is the same as a previous line in the code and has never failed in the past. I was getting ready to post my brew code and was looking in the manual for fault code descriptions when I saw the existence of the controller log and opened it.

Yes, I have seen script error that was a line off, close but not exact. I did not see any other strangeness in the area it stopped. After restarting everything, the script errored at the same point so I commented out the line and restarted the script. It halted at the same place as if the line of code was still there. Again I removed the line entirely and put a couple of blank spaces just to see that the script still halted with the same error that called out the line that now no longer existed. Weird.
132 [dough_in]
133 BrewStatus = "Dough In Temp Achieved"
134 Comments = "Click PROCEED to start Dough In"
135 call "switch_loop"
136 Print "Start of Dough In"
137 HLT = "HLT Temp" value
138 MTT = "Mash Tun Temp" value
139 Print "HLT Temp is:"
140 Print "HLT"
141 Print "Mash Tun Temp is:"
142 Print "MTT"
143 Print "_______________________"
144 BrewStatus = "Dough In"
145 "Brew Alarm" Active = false
146 "HLT GAS Cntl" Enabled = false
147 "HLT GAS Cntl" background = 1

Don't think the script is an issue, the script errored saying "line 144 Print "____________" was invalid".
Never had this fail, and have been running this version of my main script since Feb of this year. No sub script has been modified either.

I had been doing Remote Desktop sessions from my office computer and iphone to verify I could RD into the brew computer from inside and outside my home network. The only issue I had was that the brew computer did not redirect the sound to the brew computer monitor. I was trying to get that to work just before starting the brew, but ran out of time so I went without sound. Everything was normal until I pushed the button to start the mash steps after mash-in. That is when the program halted and I started troubleshooting.

Here is the controller log. You can see where I was trying to get the computer sound working and testing it by activating the 'brew alarm'. 'Alarm 1' is called when a desired temperature is reached, in this case when the mash-in temp is achieved, and you can see this at 09:48. At 09:49 I unlocked the workspace and started to troubleshoot.

08:54:09.281: Alarm 'Brew Alarm' activated
08:54:10.858: Alarm 'Brew Alarm' deactivated
08:59:02.240: Alarm 'Brew Alarm' activated
08:59:03.685: Alarm 'Brew Alarm' deactivated
09:13:48.545: Alarm 'Brew Alarm' activated
09:13:49.993: Alarm 'Brew Alarm' deactivated
09:48:53.778: Alarm 'Alarm 1' activated
09:49:04.709: Controller unlocked.
09:49:09.629: Alarm 'Alarm 1' deactivated
09:59:43.297: Alarm 'Brew Alarm' activated
10:00:10.795: Controller unlocked.
10:14:09.467: Alarm 'Alarm 1' activated
10:14:25.529: Alarm 'Alarm 1' deactivated
10:15:48.298: Alarm 'Alarm 1' activated
10:16:04.263: Alarm 'Alarm 1' deactivated
10:16:41.186: Device 'BruControl' @ 192.168.1.78 = Disconnected
10:16:41.217: Controller stopped.
10:16:58.552: Controller started.
10:16:58.552: Controller version 1.1 (build 0.22)
10:16:58.552: Loading global settings file 'C:\Users\User\Documents\BruControl\settings.brusettings'...
10:16:58.615: Loading configuration file 'C:\Users\User\Documents\BruControl\default.brucfg'...
10:16:58.740: Opening database: Data Source=(LocalDB)\MSSQLLocalDB;AttachDbFilename=C:\Users\User\Documents\BruControl\Data\Data.mdf;Integrated Security=True
10:17:00.020: Loading device definition file 'C:\Program Files (x86)\BruControl\ArduinoDue.brumc'...
10:17:00.066: Loading device definition file 'C:\Program Files (x86)\BruControl\ArduinoMEGA.brumc'...
10:17:00.082: Loading device definition file 'C:\Program Files (x86)\BruControl\ESP32.brumc'...
10:17:00.098: Loading device definition file 'C:\Program Files (x86)\BruControl\ESP8266.brumc'...
10:17:00.113: Loading device definition file 'C:\Program Files (x86)\BruControl\FeatherM0.brumc'...
10:17:00.129: Loading device definition file 'C:\Program Files (x86)\BruControl\GrandCentralM4.brumc'...
10:17:00.144: Loading device definition file 'C:\Program Files (x86)\BruControl\M5_Stack.brumc'...
10:17:00.348: Starting data exchange servce...
10:17:00.363: Device 'BruControl' @ 192.168.1.78 = Connected
10:17:00.519: Failed to start data exchange service, exception: HTTP could not register URL http://+:8000/. Your process does not have access rights to this namespace (see Configuring HTTP and HTTPS - WCF for details).
10:17:42.548: Alarm 'Alarm 1' activated
10:17:58.462: Alarm 'Brew Alarm' activated
10:17:58.462: Alarm 'Alarm 1' deactivated
 
Ok, just starting testing the script again. It stopped at a new place saying [ERROR Line 21: Cannot assign a value to an immediate value]. Without entering a long winded script and log paste, let me say here that I added a fresh copy of my main program to my script list, named it Main 28FEB23 to better see last time it was modified, lowered my global temperature values below ambient (to allow the script to progress) and found everything is working.
Somehow my Main script became unstable? So bizarre.
 
Thanks going out to oakbarn for finding my issue. A line of code got modified and I did not find it for whatever reason. If/when something like this happens again, I now know where to look.
And now, back to brewing.
 
Build update: Started extending and terminating the the sensors and valves. I'm adding about 10/11 feet of 22/4 shielded security cable to each sensor and valve. The cable terminations are microphone cable connectors and I'm adding a braided sleeve (blue - valve)(red - sensor). I'll eventually label each as well, but I've got a loooong way to go before I'm anywhere near finishing them.
image_50458625.JPG
image_50770177.JPG

Anyone have suggestions for how I can "bench test" these as I build each?
 
Just apply 24v to the open/close contacts according to your build pinout.
Thanks @RiverCityBrewer that makes sense for the Motorized 2-way valves, but for the pressure sensor (pins: 3(signal), 2(GND), 1(VCC)) I don't imagine this approach would provide any useful output.

Also, I have two proportional valves[not yet wired] (pins: 4(Feedback), 3(Control), 2(GND), 1(VCC)...not sure how to bench test these either.
 
Apologies in advance for a novice question, but I am compiling a table top dry run of devices to Brucontrol using an Arduino Mega with V46A firmware, and I am struggling to connect / get my single Adafruit Max31865 RTD to show any readings? For information I have connected the wiring as follows:
SCLK - Pin 50
SDO - Pin 51
SDI - Pin 52
CS - Pin 15
Thanks.
 
Thanks @RiverCityBrewer that makes sense for the Motorized 2-way valves, but for the pressure sensor (pins: 3(signal), 2(GND), 1(VCC)) I don't imagine this approach would provide any useful output.

Also, I have two proportional valves[not yet wired] (pins: 4(Feedback), 3(Control), 2(GND), 1(VCC)...not sure how to bench test these either.
For the pressure sensor, power it then put your multi-meter positive probe on the signal wire and negative to ground. Be gentle but you should get a voltage change when you touch the sensor membrane. The proportional valve will be more problematic unless you have a variable power supply that you can supply the signal to the valve to make it move. Otherwise you can power it and make sure it turns on and leave it at that until you have the panel ready.
 
For the pressure sensor, power it then put your multi-meter positive probe on the signal wire and negative to ground. Be gentle but you should get a voltage change when you touch the sensor membrane. The proportional valve will be more problematic unless you have a variable power supply that you can supply the signal to the valve to make it move. Otherwise you can power it and make sure it turns on and leave it at that until you have the panel ready.
Awesome, thank you for the advice. I'll report back results here when I complete some tests.
 
All of a sudden, I'm having a really strange issue (that I've now replicated on 3 different ESP32's that have been freshly flashed).

Regardless if I have anything connected to my ESP32 (replicated with nothing connected to my ESP32), whenever I enable a digital output device, I get a bad checksum error and the interface starts disconnecting/reconnecting.

Here's an example of the error. My RTD (SPI) inputs all seem ok. It's just when I enable a digital output (any pin):

1701199545609.png


Any suggestions?
 
Back
Top