BruControl: Brewery control & automation software

[Die_Beerery]

Wow, you rock!... saved me a lot of time building out the same thing. I'm working on getting an EasyDens connected in... I'll share my work as well (if I ever get it finished) if anyone else has one.

@Die_Beerery - It should be possible to parse out an XML file and send it to separate elements. Before moving to BruControl, I was thinking about building a new control system using a SCADA/DCS system called Ignition, which also has a Node Red connector. I was working on something similar, so I'll look up my old work and see if I can make a parallel.

ooh I have an easydens as well.

I am able to easily import the xml, and convert it to nodejs, but the hang up I am having is how to send it to the BC device since its looking for numbers only.

 

[RiverCityBrewer]

ooh I have an easydens as well.

I am able to easily import the xml, and convert it to nodejs, but the hang up I am having is how to send it to the BC device since its looking for numbers only.

Ahh, in that case, use a change function node after your parsing function and intercept all your payloads. Use a set rule for each msg.* and select J: from the "to" dropdown and set the expression "$number(somepayloadnamehere)". This will convert all strings to numbers, just watch out for mixed strings as they will fail if its not all numbers. I'm sure there are a dozen other ways to do this, but that's what I would do. Feel free to PM me if you want.

Edit - added the node with some example code

Joe

 

[adman]

@BrunDog, having a licensing issue and could use help fairly immediately, since I'm planning to brew tomorrow. Thanks.

 

[BrunDog]

@BrunDog, having a licensing issue and could use help fairly immediately, since I'm planning to brew tomorrow. Thanks.

Please see email replies and/or response to PM.

 

[adman]

Thanks for your prompt response BrunDog!

 

[user 232000]

Hello BrunDog,

Need a little guidance. I have been having constant issues with BC that it stops communicating with the mega, all of the devices go offline and stop working, intermittently. I thought it was my code, and having two scripts crashing into each other as it is random, will work for 3 hours, then 5 hours etc, so I am down to 1 script now with less than 15 lines of code, same problem. I have upgraded to BC version v1.1 Release Candidate last week but no change. Today I downloaded Interface v44k and BC would not see anything, everything was offline or disabled, I tried V44J, same thing, then went back to V43, and I am back on line and working. I am running serial to the mega with a 16 i/o opto, 8 1 wire sensors and 2 hyst devices and one script running. I have a dedicated 5 v to the mega and a separate ground direct to the board. Reading some older posts it looks similar to others having this issue before the new releases, which I think was addressed in the new version.

The current fix for me is to disable the app, restart and things come back for a few hours. I have teamviewer remote running on my phone and office computer so I can get by by checking & restarting BC remotely , but ........

Should v44j or k work in my environment? The interface download was successful on both versions but only v43 works.

Thanks

KDAZ

 

[Die_Beerery]

Hello BrunDog,

Need a little guidance. I have been having constant issues with BC that it stops communicating with the mega, all of the devices go offline and stop working, intermittently. I thought it was my code, and having two scripts crashing into each other as it is random, will work for 3 hours, then 5 hours etc, so I am down to 1 script now with less than 15 lines of code, same problem. I have upgraded to BC version v1.1 Release Candidate last week but no change. Today I downloaded Interface v44k and BC would not see anything, everything was offline or disabled, I tried V44J, same thing, then went back to V43, and I am back on line and working. I am running serial to the mega with a 16 i/o opto, 8 1 wire sensors and 2 hyst devices and one script running. I have a dedicated 5 v to the mega and a separate ground direct to the board. Reading some older posts it looks similar to others having this issue before the new releases, which I think was addressed in the new version.

The current fix for me is to disable the app, restart and things come back for a few hours. I have teamviewer remote running on my phone and office computer so I can get by by checking & restarting BC remotely , but ........

Should v44j or k work in my environment? The interface download was successful on both versions but only v43 works.

Thanks

KDAZ

It's your 1 wires. 4 is the max for serial IO functions. Been there done that.

 

[user 232000]

It's your 1 wires. 4 is the max for serial IO functions. Been there done that.

OK! Can you suggest my best course of action?
I do have a backup mega I could split the sensors across two interfaces, RTDs dont seem to be the answer, seem to need an amp for each one. I am putting an ESP32 in next week to connect my new tilt, but its only bluetooth/wireless, i went with serial as it seems more stable.
Can i run my mega wireless and avoid the issue with the 8 sensors connected?

I would appreciate your opinion on a path forward and thank you for replying!!!!

Kent

 

[Die_Beerery]

I switched over all my devices to ethernet.. specifically https://www.amazon.com/gp/product/B07L34ZG7J/ref=oh_aui_search_asin_title?ie=UTF8&psc=1

They support 10 sensors no problem.

Either that or split them.

 

[BrunDog]

Hello BrunDog,

Need a little guidance. I have been having constant issues with BC that it stops communicating with the mega, all of the devices go offline and stop working, intermittently. I thought it was my code, and having two scripts crashing into each other as it is random, will work for 3 hours, then 5 hours etc, so I am down to 1 script now with less than 15 lines of code, same problem. I have upgraded to BC version v1.1 Release Candidate last week but no change. Today I downloaded Interface v44k and BC would not see anything, everything was offline or disabled, I tried V44J, same thing, then went back to V43, and I am back on line and working. I am running serial to the mega with a 16 i/o opto, 8 1 wire sensors and 2 hyst devices and one script running. I have a dedicated 5 v to the mega and a separate ground direct to the board. Reading some older posts it looks similar to others having this issue before the new releases, which I think was addressed in the new version.

The current fix for me is to disable the app, restart and things come back for a few hours. I have teamviewer remote running on my phone and office computer so I can get by by checking & restarting BC remotely , but ........

Should v44j or k work in my environment? The interface download was successful on both versions but only v43 works.

Thanks

KDAZ

Hi @kdaz

Thanks for the info and patience. Let's debug this systematically. DB may be right but let's work through it and get it right.

First, please send us your most recent log files (not data) where you know the problem occurred. Also send us your configuration file. (.brucfg file in the BruControl folder).

Second, please test this with all outputs disabled. Typically the problem is power supply or overload related. Without a schematic and parts used, I can't venture a guess, but one quick way to test it is to remove all the output stuff to ensure the current output is not exceeded.

 

[user 232000]

I will go to Ethernet, as soon as I get this my ferm/kegger system stable, I'm upgrading my analog electric brew equipment to BC, so I am very happy I have a fix for this!

Thanks again!
KDAZ

 

[user 232000]

Hi @kdaz

Thanks for the info and patience. Let's debug this systematically. DB may be right but let's work through it and get it right.

First, please send us your most recent log files (not data) where you know the problem occurred. Also send us your configuration file. (.brucfg file in the BruControl folder).

Second, please test this with all outputs disabled. Typically the problem is power supply or overload related. Without a schematic and parts used, I can't venture a guess, but one quick way to test it is to remove all the output stuff to ensure the current output is not exceeded.

Will do, but I cant take down the system for that long, I have fridge/frezzer, lager & ferm chambers and gycol chilling the kegs, all in one, I can take the down for 10 or 20 minutes but 4-6 hours to see if it works or not, not today. Next week I can keg up my beer and switch it over to my old kegger and then take it all down and do testing. I can easily upgrade the 12vPS ( 30amp now) and that can be done quickly. One thing I dont have or understand is line filters, I have read in other posts that this is important, but dont know where to start, so if this is an issue I can go there too. Will send the log and config file later today.

Thanks

kDAZ

 

[BrunDog]

Understood. You can start with the logs - that may give us some direction.

 

[BrunDog]

OK... I just ran a test to see why 44K didn't work... and indeed we had an unrestricted debug report in the code which when issued, caused the communications between the interface and BC to fail. This would only happen with 1-wire devices, but not gonna lie - that is a big mistake on our part. Note: this would not show up on networked interfaces because the communications is not via the same pipe as the debug reporting (Serial).

So I have published an updated FW which now includes 44L for the MEGA for both S and SR variants. Apologies to users like @kdaz and @swimIan but we thank you for bringing the issue to light. Serial users with 1-wire devices should upgrade to 44L if using v44 of the FW.

Also, I just tested 8 concurrent 1-wire temp sensors on a serial-connected MEGA without issue - I'm not sure if this was an issue in the past (per @Die_Beerery's comment), but it is working correctly. I would always caution anyone from running this many 1-wire sensors at the same time since there is a small delay that occurs when 1-wire communications take place (hey - you don't get a free lunch here... there is a 1-wire is easy to wire but it sure isn't fast!). I doubt it would materially impact anything in most applications other than lots of rapid/sensitive PID devices, but nonetheless, disabling unused sensors is a good practice to help minimize any delays. In hysteresis applications like refrigeration it should be a non-issue.

 

[user 232000]

https://fbusa-my.sharepoint.com/:f:...pCkcLXy90JQ-kBCN_-ycXKlbo0euDYo6Grow?e=qCscfa

This is the download link for the files, too big to upload here. Thanks

 

[BrunDog]

Please see my post above. Also, the link didn't work. Please email it to us at info [then the at sign] brucontrol.com.

 

[user 232000]

I will upgrade to the 44l for my serial mega, but have ordered the Ethernet version for my Fermonster 3 and will split the serial mega out for my brew side upgrade, always planned on a separate interface so I could test and debug my brew side without impacting my ferm system. Am upgrading the 5v PS as well, I have a stout 12v but want a dedicated 5V with more amps to support the 3 interfaces. I need 7 sensors for the ferm side when ruining at full capacity so between better coms and possible software fixes, I will get there.

having fun!

Thanks to all for the support!

Kdaz

 

[BrunDog]

Hi All,

Positive update and a negative update:

Positive: We posted v1.1 Release Candidate (build v1.0.1.14). Updates in this build:
1. Added a Primary Value setting for Counter, Hydrometer, and PID elements - this will allow you to select which data will be displayed with a digital gauge.
2. Updated ability to enter up to 12 decimals (was 6 previously). If you need to put in decimals beyond 12, such as in thermistor calibrations, please use cut and paste.
3. Subroutine 'call' / 'return' functions now work properly when nested inside 'if' / 'endif' blocks.
4. Corrected the custom color dialog box to fit in on the screen (buttons now correctly visible).
5. We tried to add more LED Indicator colors, but unfortunately these are fixed, so we cannot do that at this time. Will continue working on this.

Negative: Per posts above and feedback from users, I've confirmed that a MEGA connected via Serial/USB using a bunch of device elements, some of which are 1-wire, will lose communication occasionally. We're debugging this, but wanted to acknowledge it is a problem. @kdaz and @swimIan pointed these out and I have been able to reproduce. We thought the firmware 44L would correct the issue, but it will not. The workaround for this is to minimize the number of enabled devices (other than digital outputs), especially 1-Wire devices. Switching to network resolves the problem, too. We think the 1-wire is interrupting serial communications, but that's just conjecture at this point. Stay tuned for updates to remedy this.

Thank you to all those who report issues/bugs - we appreciate your willingness to help us!

 

[day_trippr]

Serial, One-Wire, USB, I2C...they all use interrupts. Be cautious about how/when interrupts are disabled...

Cheers!

 

[VinceBrews]

I know folks around here have tended to stay away from using mass as a means to measure volume but in my area (biopharmaceutical manufacturing), mass is the gold standard if you want to know the volume of a liquid. This is especially true in fixed/permanent tank installations where mass information is feed into a DCS historian every ~5 seconds 24/7/365. Where hygienic design is paramount, any extra wetted components are frowned upon. Granted that level of cleanliness is not as important in brewing but to be considered none the less. Following on work done by @paledragon I went with load cells, two Uno's w/lcd displays, HX711, and MCP4725 DACs to measure the mass of my boil kettle and MLT for my two vessel RIMS setup. I know drift (it is actually characterized as "creep") is often cited as a concern but I have not seen that to be a problem and I have found readings to be more cyclical (when looking at days of data) where the values will go down and up not just down, down, down. I attribute that to changes in room temperature but it is a tiny amount (0.038 kg max so far). While I do not intend to use the mass cells for long term measurement, I see no evidence that it couldn't. I am also using a one wire temp sensor to provide temp info from the load cell installation location and using that to provide "temp comp" for the load cells if/when they get outside the designed "already temp compensated" range for the load cells. I was going to deploy some time based compensation for creep and while I may still do that, I have not found that I need to at the moment.

Especially with the advent of the lookup table function in the BC RC, calibrating the analog output from the MCP4725 has made the mass (I convert to volume in the BC element) to be very accurate throughout the entire measurement range even if the input (DAC output) is not exactly linear. Creep appears to be insignificant in the context of how I plan to deploy it.

Sure it would be great to perhaps integrate this into a controller connected to BC directly and perhaps someday that will be possible. Considering the low cost of these controllers and how I wanted a local display with local tare functionality from that local UI, the separate controllers, lcd displays, and feeding an analog output to the BC controller via the 12-bit MCP4725 DAC works really well. That kind of detail would not be easy within the confines of a BC element for example nor would driving a local display to show the units I want, etc.. Don't be afraid to use mass is what I would say and also don't use super cheap load cells from a bathroom scale that lacks any specifications. The 50 kg units from Phidgets for less than $10 a piece look to be good units. A beauty of BC is the flexibility to do it your way!

This is what my scale enclosure for two vessels looks like. Also note you could do this with one controller but I wanted two displays showing the same data at the same time for both load cell setups.

I find this concept very interesting. I wish I could measure volume or mass more accurately during boil (I've got a pressure transducer that I cool during the boil, but still, hard to get good result).

That said, looking at my boil kettle, I've got a bunch of plumbing and stiff wiring for the heating element hanging off of it. Wondering how one would minimize the external forces from those to make a mass measurement useful... Thoughts?

 

[BrunDog]

Curious: Why is the pressure transducer is hard to get a good result?

 

[VinceBrews]

Signal goes all over the place when it starts boiling (typically a big spike up that takes a few minutes to recover). After a few minutes of boiling it gets a bit better but still difficult to trust.

 

[VacationLand]

I find this concept very interesting. I wish I could measure volume or mass more accurately during boil (I've got a pressure transducer that I cool during the boil, but still, hard to get good result).

That said, looking at my boil kettle, I've got a bunch of plumbing and stiff wiring for the heating element hanging off of it. Wondering how one would minimize the external forces from those to make a mass measurement useful... Thoughts?

It is not uncommon for a load cell equipped tank or vessel to have cabling connected to it. This doesn't present a problem as long as you do not remove the cabling or make some sort of significant adjustment to it such that the forces presented by those cables are altered. The mere presence of the cable weight is not problematic (assuming you tare the vessel with these in place).

 

[BrunDog]

Signal goes all over the place when it starts boiling (typically a big spike up that takes a few minutes to recover). After a few minutes of boiling it gets a bit better but still difficult to trust.

Interesting... would be curious to learn more. If you have the time, would you PM me details (sensor model, mounting, wiring, etc.)?

 

[Die_Beerery]

Interesting... would be curious to learn more. If you have the time, would you PM me details (sensor model, mounting, wiring, etc.)?

FYI I see the same thing in my BK with a direct attach. Its on my list to write a script, to account for temp. I run the same sensors you sell.

 

[VinceBrews]

It's the sensor you sell. Bottom mounted. I use a MEGA

 

[BrunDog]

Do you have a graph of the data or the data you can email us?

 

[VinceBrews]

Don't have data handy. I'll try to run some tests this weekend and I can share the data.

 

[Die_Beerery]

Do you have a graph of the data or the data you can email us?

sent

 

[VinceBrews]

Looking for best practices in v1.1. Why would one not mostly use global variables instead of in script variables? What's the disadvantage other than taking space in a workspace? Wouldn't you always have more flexibility with a global?

 

[oakbarn]

I would use a Global vs variable for many reasons. In fact, since I am still in the Build mode, I doubt that I would use a script variable unless I never want to see it or manually change it. The point of taking up Workspace is a valid one in my mind. In fact, I suspect that I would use a Global Boolean Type versus a Switch Element as well. There is no doubt using it for "Status" so you do not have to run a loop. If there was a Global Boolean Button Type, I would do away with Buttons as well.

It is also very handy for a label. On my wish list was a Text Element but a Global works for that.

So if there is a reason NOT to use a Global, I would like to know as well.

 

[VinceBrews]

We're on the same page. In fact for workspace realestate, I'll just park all the variables I don't want to see on a separate workspace called variables.

 

[BrunDog]

Great question... I suppose there is a degree of personal preference here, but my recommendation would be to use Variables ("in-script" as you noted), unless you need to share the data across scripts and/or you want the data to persist in perpetuity and/or always want it to be visible on screen. The reason: variables are a little less resource intensive (don't require screen updates, don't get written in the configuration file, etc.). Now, this is indeed very minor, and we want you to have it your way so shouldn't hesitate to use only Globals if that is your preference.

Also, in my opinion, it's a bit easier to use Variables since you only need to handle them in the script, whereas Globals need to have their elements created first. Again, a minor difference!

 

[VinceBrews]

Should I be using quotes for the globals? It seems that both these syntaxes work:

"GlobalVariableName" value = 1
GlobalVariableName value = 1

Maybe quotes are only needed when the name includes spaces?

 

[BrunDog]

It may resolve without quotes, but I suggest you use them by habit when referencing an element. Variables do not need them as they are not elements.

Great questions!

 

[oakbarn]

When creating a Device Element you are given several choices as a Device Type. For example, you may select "Counter Input" for Port 3 on a Mega 2560 with Wiring Firmware ER. Once used, the Counter Input type is no longer available as it has been used. But you may create a different Device Element with Port 3:
Digital Input, Digital Output, Duty Cycle etc.

Is this a good idea or a terrible idea to do so? Does anyone do this?

I would like to understand how or if you would do this.

Is there any additional circuits that must be created if it is OK to do?

As in above, If I had a Flow meter on Port 3, could I also have a "Duty Cycle" SSR on Port 3?

 

[RiverCityBrewer]

When creating a Device Element you are given several choices as a Device Type. For example, you may select "Counter Input" for Port 3 on a Mega 2560 with Wiring Firmware ER. Once used, the Counter Input type is no longer available as it has been used. But you may create a different Device Element with Port 3:
Digital Input, Digital Output, Duty Cycle etc.

Is this a good idea or a terrible idea to do so? Does anyone do this?

I would like to understand how or if you would do this.

Is there any additional circuits that must be created if it is OK to do?

As in above, If I had a Flow meter on Port 3, could I also have a "Duty Cycle" SSR on Port 3?

I guess you *could* do that if you were short on I/O and wanted to physically swap stuff out during a brew day, but coming from the industrial control world it would never even be considered in our environment. Simply disable the one element and enable the other.... just be careful though as I think it would be very easy to screw something up and fry something unintentional.

 

[oakbarn]

It may resolve without quotes, but I suggest you use them by habit when referencing an element. Variables do not need them as they are not elements.

Great questions!

One reason to use quotes in the script:
Color Coding:

 

[oakbarn]

I guess you *could* do that if you were short on I/O and wanted to physically swap stuff out during a brew day, but coming from the industrial control world it would never even be considered in our environment. Simply disable the one element and enable the other.... just be careful though as I think it would be very easy to screw something up and fry something unintentional.

I would put it in the category of "terrible" idea. That was my initial inclination.

 

[Die_Beerery]

I would put it in the category of "terrible" idea. That was my initial inclination.

I use a pid and a duty cycle on the same input. No reason not too.