BruControl: Brewery control & automation software

[VacationLand]

OK, thought I would share the BC brew house and ferm house workspaces that I have been working on a bit recently. I went with more of a PFD/P&ID (process flow diagram/piping & instrumentation diagram) direction and less of a photo-realistic direction. Just another example to show what you can do with BC and to perhaps inspire others.

For anyone interested. I used Lucid Chart to create these and imported a few graphics. I have zipped up those graphics and attached them to this post if anyone wants to use them for their HMI.

FYI. This is for a two vessel RIMS system...there is no HLT.

 

[BrunDog]

Really nice looking layout!

 

[augiedoggy]

I think the answer to @augiedoggy 's question is this "simple": There are many, many variables from one system to the next.

Bottom line is noise needs to be prevented, isolated, and squelched, in that order of priority. I know that doesn't help much - we need a comprehensive bit of documentation on the topic.

I believe I found the source of my hlt spikes at least. The rtd cable for that kettle was replaced with a longer one I bought later and the shielding was not connected at the probe end.. since I did not connect it at the panel end it wasnt shielded at all.. after shielding at one end it's been not spiking when I tested with the oven.

 

[clearwaterbrewer]

Do you have a lot of VFDs in your building? Those rascals are notorious for throwing out EMI, and they raise hell with harmonic distortion.

If I start a Allen-Bradly VFD(3-phase in and out usign same main panel breaker as the power supply that powers the mega), with output set to zero, I still get a cyclic pattern where each 1-wire probe, in turn, goes to -196.6 every 2 seconds...

 

[clearwaterbrewer]

We're going to tackle the drop-out issue with Tilts. I think the problem is with the ESP32's Wi-Fi and BT radios working at the same time.

We also have plans to add a "Reject" calibration such that values outside of an expected range will get ignored.

This is awesome, happy to beta this feature, and would love if it took readings every 2 seconds like TiltPi does, but went a step further and threw out the ones with obviously bad values, and averaged the rest maybe just using a avg weight like analog/rtd do now... quick and instant display via the UI is desired, but the charting value could literally be every 15 minutes, no need to eat up a lot of data for a Tilt...

 

[RiverCityBrewer]

Awesome. Thankyou for sharing

What do you use the reset button for?

The FV Resets just set all the fermentation calcs back to a default value (0 or 1). Makes it easy to clear everything out after a fermentation is over.

 

[RiverCityBrewer]

This is awesome, happy to beta this feature, and would love if it took readings every 2 seconds like TiltPi does, but went a step further and threw out the ones with obviously bad values, and averaged the rest maybe just using a avg weight like analog/rtd do now... quick and instant display via the UI is desired, but the charting value could literally be every 15 minutes, no need to eat up a lot of data for a Tilt...


View attachment 660668

I talked with Marcus at Tilt about this some time ago. If I recall correctly, the tilt sends a beacon every 2 seconds, but the beacon broadcast is only updated with new values every 10 seconds. This was on the first gen units so it may not be valid for current gen models. If the goal is to just get more chances to catch the beacon broadcast, it makes sense.

 

[clearwaterbrewer]

I talked with Marcus at Tilt about this some time ago. If I recall correctly, the tilt sends a beacon every 2 seconds, but the beacon broadcast is only updated with new values every 10 seconds. This was on the first gen units so it may not be valid for current gen models. If the goal is to just get more chances to catch the beacon broadcast, it makes sense.

I have gen1 and gen2 units and they act the same to me... Watching one now, I can see the 10 second thing... Thanks for that tidbit I never quite got it as that before, but noticed it did not change as fast as the beacons... That might be a great approach for BC to take to eliminate drop-outs... I wonder what the actual process is for the 5 beacons collected in that 10 second period..

My main issue with TiltPi was that when you woke up the units, they added data to the last google spreadsheet they were assigned to, and that may have been months old... I begged them to have it just start a new log automatically if it had been 24 hours since last use and to keep log number separate from log name.. that and make the 'start private cloud logging' more intuitive......

 

[oakbarn]

Sorry, I don't quite understand what you are looking for. I personally hide the input device element since it is duplicitous. If you don't want the input value shown in these Hysteresis to PID elements, then you would need to handle it via a script. We include it thinking more info is better.

I was wondering if anyone used the Input Value Display for anything. Since it is a scale that does not mean much, I thought it might be not very important.


I was thinking that it (INPUT) was not of much use. On my old BCS, the "Element" would flash on and off and it was annoying. I am going to replace with a Global with a pix of an Element that is "On" when PID or Hysteresis is enabled and hide the real Element. It will not flash or change with the cycle, but really tell me if the Element is enabled.

 

[oakbarn]

Another Thought on PIDs:

Could you add a property to a PID Element like Pseudo that changes the Clock Speed Calculation to make it compatible with BCS PID wiring and SSRs?

 

[BrunDog]

We built it so that In one display, you get the current (input) value aka PV, the Target aka SV, and the output status (on/off or proportional percentage).

I personally feel the Input value is very important. When brewing, I like to see the difference between where it is and where it needs to be and cross check that the output is correct.

 

[aeviaanah]

OK, thought I would share the BC brew house and ferm house workspaces that I have been working on a bit recently. I went with more of a PFD/P&ID (process flow diagram/piping & instrumentation diagram) direction and less of a photo-realistic direction. Just another example to show what you can do with BC and to perhaps inspire others.

For anyone interested. I used Lucid Chart to create these and imported a few graphics. I have zipped up those graphics and attached them to this post if anyone wants to use them for their HMI.

FYI. This is for a two vessel RIMS system...there is no HLT.

Very impressive! Thankyou for sharing the art.

 

[oakbarn]

We built it so that In one display, you get the current (input) value aka PV, the Target aka SV, and the output status (on/off or proportional percentage).

I personally feel the Input value is very important. When brewing, I like to see the difference between where it is and where it needs to be and cross check that the output is correct.

OK, I do not have my Temp Probes connected so I was getting a reading of 1023 on the Input, but after looking there are 3 "values" presented on the Element"

Output: Range from 0-255 (This is the value I thought not important)
Input: PV of the Temp Probe Input.
Target: SV of the Element


So I will be doing my own thing as I do not need the Output. I have a Temp Probe Element and the Setpoint as a Global that updates the Element target.

A Setpoint (SV) is controlled by BruControl. My TG (Targets) are manually controlled and are not controlled by BruControl. I found that with my modified HERMS that the dog was chasing its tail if I used a probe in a different vessel to maintain a temperature in a different vessel (hot water bath).

I am getting there. The UI has so much that you can make your own!

Preheating Strike Water:

 

[oakbarn]

Preheating strike

 

[JoeyChestnutFan]

Hey @BrunDog, at the end of the podcast you and Bryan were talking about graphing multiple variables and being able to pull up past data. Are you guys planning to implement a device/element that would act as a "BruLog"? Essentially, an element that we could "start" a brew day, write notes, and then "end"/"save". And this could also serve as the session master so we could "Open" a past brew day and that would pull up all the graphs/data during that period + the notes. This would allow for easy access to past brew days without having to remember dates and times and such.

 

[aeviaanah]

Hey @BrunDog, at the end of the podcast you and Bryan were talking about graphing multiple variables and being able to pull up past data. Are you guys planning to implement a device/element that would act as a "BruLog"? Essentially, an element that we could "start" a brew day, write notes, and then "end"/"save". And this could also serve as the session master so we could "Open" a past brew day and that would pull up all the graphs/data during that period + the notes. This would allow for easy access to past brew days without having to remember dates and times and such.

Love this idea.

 

[BrunDog]

Hey @BrunDog, at the end of the podcast you and Bryan were talking about graphing multiple variables and being able to pull up past data. Are you guys planning to implement a device/element that would act as a "BruLog"? Essentially, an element that we could "start" a brew day, write notes, and then "end"/"save". And this could also serve as the session master so we could "Open" a past brew day and that would pull up all the graphs/data during that period + the notes. This would allow for easy access to past brew days without having to remember dates and times and such.

I think the concept I had in mind was a sub-app which would allow you to graph multiple data points with dynamically definable start and end times. I didn’t have notes in mind but that is an interesting and cool idea!

 

[VacationLand]

Hello @BrunDog. I perhaps need to test this more to better understand the boundaries but would it be possible for an inspector to be able to show output from more then one script at a time (i.e. not be forcefully linked to one)? I have an inspector used to show process notifications and I need to assign the inspector to look at a specific script. It would be more universally helpful if the inspector could show the chosen variable output from any script, not just the one specifically assigned script. At this point it is unclear how the inspector would handle output from a variable that is issued from a script that is called from another script (the calling script would be the one assigned to the inspector). Prompting and operator messaging is an important part of the robustness of any automated processing environment from my experience. It would be great if an inspector (or some other function not yet implemented) could show messages from any script without having to go in and reassign the inspector or work an inspector in a hidden/visible manner in a script. What are your thoughts on the current or future for BruControl and notification/prompting?

 

[crane]

Hello @BrunDog. I perhaps need to test this more to better understand the boundaries but would it be possible for an inspector to be able to show output from more then one script at a time (i.e. not be forcefully linked to one)? I have an inspector used to show process notifications and I need to assign the inspector to look at a specific script. It would be more universally helpful if the inspector could show the chosen variable output from any script, not just the one specifically assigned script. At this point it is unclear how the inspector would handle output from a variable that is issued from a script that is called from another script (the calling script would be the one assigned to the inspector). Prompting and operator messaging is an important part of the robustness of any automated processing environment from my experience. It would be great if an inspector (or some other function not yet implemented) could show messages from any script without having to go in and reassign the inspector or work an inspector in a hidden/visible manner in a script. What are your thoughts on the current or future for BruControl and notification/prompting?

Isn't that what a global is for? Maybe I'm not understanding your use case.

 

[BrunDog]

Yes, I suggest you use a global for this.

Inspectors were elements to interact with what a script variable was, but we had no way to share data across scripts. So Global’s were created, and we added the ability for that data to remain permanent.

The only downside to Globals IMO is they reside in elements which you may not want displayed - which means you need to hide them.

 

[VacationLand]

Hmm, so it appears that a string (of text) would just be considered a "value" by the global and display it as it would for numerical values as long as the global is setup as a string type. It was not clear in my mind that you would set the value of a global to have it display a string when one of the options for the global is to have it be a "value" type. I.e. I tested setting a global (global1 String = "some text") as the global was setup as a "string". Of course that fails as the global string is not a thing but set the global value (global1 Value = "some text") and if the global is setup as a string type, it displays the text. Easy enough once you get there. Thanks.

 

[oakbarn]

Hello @BrunDog. I perhaps need to test this more to better understand the boundaries but would it be possible for an inspector to be able to show output from more then one script at a time (i.e. not be forcefully linked to one)? I have an inspector used to show process notifications and I need to assign the inspector to look at a specific script. It would be more universally helpful if the inspector could show the chosen variable output from any script, not just the one specifically assigned script. At this point it is unclear how the inspector would handle output from a variable that is issued from a script that is called from another script (the calling script would be the one assigned to the inspector). Prompting and operator messaging is an important part of the robustness of any automated processing environment from my experience. It would be great if an inspector (or some other function not yet implemented) could show messages from any script without having to go in and reassign the inspector or work an inspector in a hidden/visible manner in a script. What are your thoughts on the current or future for BruControl and notification/prompting?

Use a Global. It is independent of any scripts and can be anywhere on any workspace, hidden or not. I had the advantage that I came late to the game and basically never use an inspector. Anything you can do with an inspector you can do with a Global. Globals do not require a running script to display and you can easily change the value of a Global either manually or via a script. They are also static, meaning that if you close BruControl, you do not lose your variables if they are Globals. If you use Globals once for a variable, I doubt you would ever look back and use an inspector.

Inspector:
1. Requires the Inspector Element to be created.
2. Require Script to create the variable.
3. Requires Script to define the parameters of the variable (precision).
4. Requires a running script to display the Inspector.
5. Requires Script to change the Variable
6. Is dynamic and you lose the last value when you shutdown BruControl
7. Is Script Dependent

Global:
1. Requires the Global Element to be created.
2. Does Not require Script to define the parameters of the variable (precision), but may be changed via script
3. Does Not require Script to be displayed, but you may use the visibility property to hide the Global Element
4. You may change a Global manually or via Script.
5. Is Static and the last value is retained if you shutdown BruControl. I use this to create recipes for Strike and Mash Temps and have a script that changes all the appropriate variables (Strike, Mash, Hop Drops) with a simple one button click for brews we repeat.
6. Is independent of any Script or WorkspaceI.

 

[VacationLand]

Indeed, Global elements are very powerful and I have deployed them extensively for brew and fermentation parameters and for storing values from various activities as they are indeed not volatile. I simply found the issuing of a "value" for a global when the global was set as a "string" compounded with the fact that there was a global type that was a "value" to be a little problematic from a logical perspective and that just locked me into the example of using an inspector for posting string text to an element (for display on a workspace). I had seen it in an example script from Die_Beery a while back and never revisited the underlying process of how it was the most flexible to do it. A global string with its value set via any script is that mechanism for doing just that.

 

[BrunDog]

Indeed, Global elements are very powerful and I have deployed them extensively for brew and fermentation parameters and for storing values from various activities as they are indeed not volatile. I simply found the issuing of a "value" for a global when the global was set as a "string" compounded with the fact that there was a global type that was a "value" to be a little problematic from a logical perspective and that just locked me into the example of using an inspector for posting string text to an element (for display on a workspace). I had seen it in an example script from Die_Beery a while back and never revisited the underlying process of how it was the most flexible to do it. A global string with its value set via any script is that mechanism for doing just that.

I agree - not logical nor technically proper. Maybe a simple fix we should make so values are values, strings are strings, etc.

 

[oakbarn]

I use Globals a lot. A lot of them are strings but the "value" is blank. I use them to host pixs of things like my pumps that are interactive when a pump is "on". I just use the background property to change the pump from off to on.

I also use several globals to message me as what to do next or where I am in the process. The green rectangle changes as needed for every step. I have people who help me brew and this reminds them of what to do and when.
I like having my targets (setpoints ) where I can change them quickly. I just have running script that is looping and looking for any changes

[loop]
if "gblRadiatorSetpoint" != "Radiator Element" target
"Radiator Element" target = "gblRadiatorSetpoint
endif
goto "loop"

I also use globals to set the flow of the program.

Some of my timers and alarms are reused and I just set the "title" with a global.

 

[oakbarn]

I agree - not logical nor technically proper. Maybe a simple fix we should make so values are values, strings are strings, etc.

Strings are Strings, Values are Values as a type in a variable or global. I think that the confusion is in the property attribute value of a global. It can be any of the allowed types. It is simply nomenclature and that would be hard to change if someone has used the value property attribute (not type) of a global in a script.


I would say the same is true for state and value. To me I find it confusing to use state in some cases and value in others. I know the difference, and why. I just accept it that I get confused.

I would leave as is. I cannot think of a good word for the "value" of a global other than "value" It certainly is not a state.

The global value can be a :
string
value
time
datetime

If you are worried as to which type, you can name your globals using CamelCode:

gblvS...... for strings

gblvV..... for values

gblvT.... for time

gblvDT..... for datetime

 

[VacationLand]

It isn't problematic. Just that it wasn't intrinsically clear in the way I looked at it. That is on me as others have found it clear enough to see through it well enough. Could it be clearer in the manner in which BrunDog mentions, sure but it isn't a big deal as it stands today. I've already made all the needed corrections and moved back to working on the scripts

 

[swimIan]

I recently acquired and have been playing with the Plaato airlock and the Plaato keg devices. I am interested in integrating the airlock readings into my Brucontrol panel. Might this be on the horizon?

 

[BrunDog]

Good idea. We haven’t reviewed them... how do they communicate with the world?

Edit: ok both are WiFi. Do they publish the protocol? If so it would be easy to link over with NodeRed right away.

 

[swimIan]

They use a webhook for the airlock. The keg thingy is new so I’m not sure yet. Good idea with node red though. Thanks.

 

[dubfitz]

when i add additional 1 wire temperature probes to an existing interface the system seems to reorder my existing ones and they end up on different tanks than they should be. Am i doing something wrong?

 

[RiverCityBrewer]

When the 1-wire bus initializes, BC enumerates the bus via probe hardware address and assigns them to the interface in some order (ascending/descending not sure). This means you can't really swap out probes on the bus without reordering everything. There have been several requests for static ordering, but Brundog will have to speak to that.

Edit: The bus ordering system is better explained in the user manual on page 40.

 

[oakbarn]

when i add additional 1 wire temperature probes to an existing interface the system seems to reorder my existing ones and they end up on different tanks than they should be. Am i doing something wrong?

One of the reasons I will not use one wire.

 

[oakbarn]

In a nutshell, what is the difference/advantage of an Adafruit Grand Central vs a Mega 2560. I am thinking of the new integrated board (BruControl MEGA Format UniShield – Model UM-1) that BruControl has for sale as a controller for valves that I intend to purchase, replacing a lot of manual valves. There is a cost difference so I was wondering if the price difference is worth it. ($425 vs $389 for Ethernet Ones)

 

[clearwaterbrewer]

mainly memory.. there is some discussion earlier in this thread.. Until more people adopt the Grand Central, I just went with the MegaEth from robotdyn, which integrates the Ethernet onto the board... they even have POE version for a few dollars extra... This should go right onto the BC UM-1 I myself will get one of those as soon as I trust myself not to release the magic smoke every 6 months...

 

[VacationLand]

Where do we stand with the Grand Central anyway? Is the firmware any better then it was mid 2019? I prepared my system for 3.3V logic to use this board and then I tested it a bunch back in June. Things were not quite ready at that time. A number of I/O were not correct in the wire map or was correct but didn't work and few other maladies that caused unstable behavior. I posted about it a bunch. I eventually got it working with an ethernet shield but it had too many of those issues so I pulled it out and went back to the MEGA 2560 waiting for maturity of the firmware.

 

[oakbarn]

mainly memory.. there is some discussion earlier in this thread.. Until more people adopt the Grand Central, I just went with the MegaEth from robotdyn, which integrates the Ethernet onto the board... they even have POE version for a few dollars extra... This should go right onto the BC UM-1 I myself will get one of those as soon as I trust myself not to release the magic smoke every 6 months...

I order the UM-1 MEGA UniShield. I have a RobotHouse Mega 2560 on the way with on board ethernet. A little more robust than the Robodyn (can take higher Voltage). The real deciding factor was 3.3 vs 5v. All my Input Circuits are 5v and changing to 3.3 for some would be a PITA. Christmas in January! Now just need to get some proportional valves. I am hoping to use it to control the cooling flow through a Duda Diesel Plate chiller to maintain a Pitch Temp. We have never Fly Sparged as the Time seems less important than a little extra grain for a few dollars. We have controlled the Pitch Temp with a manual ball valve successfully so I am hoping this will make it easier. I also have 14 manual valves in my manifold that I will start replacing. These do not need to be proportional. I also assumed I needed the AA-1D Analog Amplifier board as well to run the valve. Now to break out more wire.

 

[day_trippr]

One of the reasons I will not use one wire.

Oh, puhleaze. It's a simple matter of enumerating the available probes then allowing the user to assign them to logical functions.
Explicit addressing and a persistent configuration would make all of this easy as pie...

Cheers!

 

[BrunDog]

Where do we stand with the Grand Central anyway? Is the firmware any better then it was mid 2019? I prepared my system for 3.3V logic to use this board and then I tested it a bunch back in June. Things were not quite ready at that time. A number of I/O were not correct in the wire map or was correct but didn't work and few other maladies that caused unstable behavior. I posted about it a bunch. I eventually got it working with an ethernet shield but it had too many of those issues so I pulled it out and went back to the MEGA 2560 waiting for maturity of the firmware.

I’d say the FW is slightly better... partly due to our code and partly due to the core libraries. There are likely issues lurking so if you need production ready I wouldn’t commit to the GC yet. I do know there is an issue which multiple simultaneous PWM outputs.

I’m going to upgrade my personal rig with a UniShield MEGA, then when it’s running swap out the MEGA for the GC.

However it is very exciting to see the expansion opportunities coming given increased capability, memory, etc. We want more options... so this provides that.

 

[VacationLand]

I can stand some "buggery" with the GC but I will probably wait until some of those potential new "GC only" type of capabilities arrive in the future. I too look forward to some of the new possibilities a new interface with more muscle might bring to the table.