BruControl: Brewery control & automation software

[BrunDog]

Four Questions:

1> In looking at my configuration, my ESP32 is set up as Network TCP. It is Wi-Fi~ed to the router and seems to work fine. In my configuration file the <WiringMap> tag is

<WiringMap>Default</WiringMap>

Assuming it should be changed to

<WiringMap>Ethernet_FW_v46</WiringMap>

2> I have four interfaces. I assume that any Interface that you want to be v46 and on, the <WiringMap> tag needs to be changed for each one in the brucfg file.?

3> Can you have a mix between v45 and v46 interfaces within the same brucfg file?

4> What if you add a new interface?

1. We didn’t change the wiring map for ESP-32, so no changes needed.

2. No, just MEGAs and GCs

3. Yes

4. Add it based on the FW you will use.

The reason for the interface config files is they tell BC which ports are available and which modes each port can support. The selected map needs to match the FW in the interface, otherwise BC may try to create a port that doesn’t exist or will not show you one that actually does. Three maps have to line-up: the one used by BC, the Interface Wiring Map we provide for your wiring awareness, and the FW. Ultimately the FW has checks in it to make sure a port/mode combination is allowable, so even if the application calls for one, crashes or freezes are unlikely. But The app wont necessarily issue an error… you just won’t get any results.

 

[CDCTx]

Yes, correct. Thanks for that reminder. It’s only “new” on the ESP32.

That said, if anyone has any trouble moving from one Wiring Map to the new ones, feel free to send us your configuration file and we can swap it over for you. I know it’s a pain… but a growing pain. Eggs —> omlette… you know the deal.

Good timing since I'm getting the new ESP32 relay boards today. I might as well rework my math for my pressure tranducers as I set these up. Thanks for posting and clarifying this!

 

[oakbarn]

A little cheat sheet for the re-porting from v45- Firmware to v46+ Firmware:

Edited for Grand Central

 

[oakbarn]

Trying to add the new ports to my configuration. I deleted all of the old ports. I get the following: mia culpa!!! You also need to install the latest application (BruControl.exe) to add new devices !!!!

 

[BrunDog]

A little cheat sheet for the re-porting from v45- Firmware to v46+ Firmware

View attachment 776604

Note the MEGA and GC are different - this may apply to one but not the other.

 

[BrunDog]

Trying to add the new ports to my configuration. I deleted all of the old ports. I get the following:

View attachment 776611

What wiring map is selected in the configuration?

 

[oakbarn]

What wiring map is selected in the configuration?

I had not downloaded the latest version of BruControl. Was not clear in your instruction to me although it said:

"OK, new application has been uploaded to accommodate FW v46+."

Prehaps:

You will need to download and install the latest version of BruControl. The version that works with the v46 firmware is "BruControl v1.1.0.22 (Build 22 / v1.2 RC, Updated 7/30/22".

 

[oakbarn]

Note the MEGA and GC are different - this may apply to one but not the other.

A better cheat sheet:

 

[oakbarn]

FYI: I installed v46B on my two Mega 2560 and the Grand Central. I updated from v450.

I had to redo the Setup for the network settings. This would be expected on the Grand Central but not the Mega~s.

Once I redid the Network Setup, all connected

 

[CDCTx]

The I/O for the buttons are smartly only inputs anyway. Probably need to desolder the pullup / pulldown resistors in addition to or instead-of the buttons. That said, if you really need these I/O, it's probably easier to just add another interface instead.

So good news, the boards did in fact arrive! D- for communication, A+ for the boards' arrival.

All is pretty much setup now other than the analog pressure transducer since the buttons and relays take up the analog pins. I tried soldering to the left leg of button 1 (pin 34, a trace shows it leading ultimatelt to the chip), but I don't get anything in BC (not even raw ADC bit values). @radzieju indicated that they simply soldered to the leg of a button with success.

I added all four buttons as analog inputs, and they all simply show either 0, 2, or 5 (no multiplier or offset yet). If I disable one pin, another pin may switch to one of those other numbers, which is odd. But nothing indicates a good analog read of any type (my voltmeter shows proper voltage return based on PSI level of my 30 PSI transducer).

I traced the legs to their pins, and all 4 go through the resistors above the UART area. I traced those, and the uppers seem tied to the 3.3V like and the lowers seem tied to ground (or something near a ground pin). The pin lines then go to the chip in the area of their respective GPIOs.

I removed the resisters for pin 34, but still no dice on a good analog read. I'll need a closer look in the morning to ensure I completely cut the connections, but they looked broken.

Any thoughts here?

 

[CDCTx]

@BrunDog As an alternative to the above, I know the SPI input is geared toward RTD probes, but its calibration setup in BC looks like an analog input, with linear multiplier, offset, and such. Could an ADC SPI board be used with a pressure transducer? Or even a SPI pressure sensor/evaluation board? I assume it would just be a matter of figuring out the multiplier based on the bit conversion values of my low and high voltage values (paired against 0 and 30 psi respectively), then working out the offset.

I considered a separate interface just for the pressure transducer, but I need one of this board's relays for the pressure release solenoid, and sometimes my PC acts up, so I can't rely on a script controlling the two interfaces.

 

[BrunDog]

Did you test the buttons as digital inputs? Assuming they are active high, you should see them as off by default and on when pressed.

Since you are removing pull-up and pull-down resistors, I’d check the voltage at the pins you are reading in BC. If the voltage isn’t what you expect/want, then it’s something else on the board. If the BC value doesn’t match the voltage you are reading, then LMK.

SPI won’t read anything other than the RTD amplifiers right now. Those are tuned to read the Pt probes which vary resistance in accordance to temp in a very narrow range, so they wont work unfortunately.

 

[CDCTx]

Did you test the buttons as digital inputs? Assuming they are active high, you should see them as off by default and on when pressed.

Since you are removing pull-up and pull-down resistors, I’d check the voltage at the pins you are reading in BC. If the voltage isn’t what you expect/want, then it’s something else on the board. If the BC value doesn’t match the voltage you are reading, then LMK.

SPI won’t read anything other than the RTD amplifiers right now. Those are tuned to read the Pt probes which vary resistance in accordance to temp in a very narrow range, so they wont work unfortunately.

I checked the Digital In of each button, but they show "On" as default and "Off" when pressed (using the default Digital Input settings, Active Low isn't enabled), which differs from what you said should be default...

Measuring the voltage of the opposing pins on the buttons, there seems to be a steady flow of 3.3v. When I then press the buttons, the measured voltage drops to 0v. So I guess these are active low when pulled to ground by the button press.

I measured the voltage at the connection point on the button (pin 34) as well as at the button leg that's connected to the connection point as well (red on the connection points, black to a ground pin). Both read the same voltage as what I got coming directly off the XLR that I'm using for the transducer. But for Analog Input on pin 34, it just sits at a plain value of 2.000, sometimes 5.000. And nothing changes if I press the button (for any that I have set to Analog Input).

And thanks. I figured about the SPI...just trying to find workarounds rather than climb the hill, so to speak

 

[CDCTx]

To add to the above, I measured between the connection point on the button and the solder point for GPIO 34 on the ESP32. I'm getting 0v, which I believe means there is a connection between the button and GPIO 34 since the current isn't flowing through the meter as a closed connection.

This is further supported by getting a correct reading when I touch GPIO 34 on the ESP32 to ground. The right voltage is making it to the ESP32, but it's not showing on BC.

 

[oakbarn]

I have Two digital Output type Elements that when I enable, they automatically go to disabled. There are no scripts running when this happens and I have looked at all the scripts and there is no code for

"My Widget Digital Out" enabled = false

Is this maybe the interface itself? The Interface has the green check.

 

[BrunDog]

To add to the above, I measured between the connection point on the button and the solder point for GPIO 34 on the ESP32. I'm getting 0v, which I believe means there is a connection between the button and GPIO 34 since the current isn't flowing through the meter as a closed connection.

This is further supported by getting a correct reading when I touch GPIO 34 on the ESP32 to ground. The right voltage is making it to the ESP32, but it's not showing on BC.

I’m sorry, but I’m not following any of the testing you are detailing here. Not knowing the schematic for the board, it’s very hard to know how it’s set up. It does sound like there is a pull-up resistor setting the pin to high, and the button pulls it low. This would be an active low input, as you mentioned.

Unless you successfully remove any pull-ups resistors, pull-down resistors, inline (current limiting), resistors, transient or voltage limiting diodes, the chip’s pin my not see a floating signal. Bottom line is you need to get the sensor’s voltage to the chip’s pin, and see it vary appropriately as expected by its output signal. Get all that right in hardware. Then you can enable the Analog Input in BC and read that voltage. If for some reason BC doesn’t report the same voltage (scaled of course) then there is an issue I’ll look into. But otherwise I’m afraid I can’t offer much support as we don’t know the hardware of that board.

 

[BrunDog]

I have Two digital Output type Elements that when I enable, they automatically go to disabled. There are no scripts running when this happens and I have looked at all the scripts and there is no code for

"My Widget Digital Out" enabled = false

Is this maybe the interface itself? The Interface has the green check.

Dunno. If you delete the DO Element and recreate it, does it do the same thing?

 

[CDCTx]

I’m sorry, but I’m not following any of the testing you are detailing here. Not knowing the schematic for the board, it’s very hard to know how it’s set up. It does sound like there is a pull-up resistor setting the pin to high, and the button pulls it low. This would be an active low input, as you mentioned.

Unless you successfully remove any pull-ups resistors, pull-down resistors, inline (current limiting), resistors, transient or voltage limiting diodes, the chip’s pin my not see a floating signal. Bottom line is you need to get the sensor’s voltage to the chip’s pin, and see it vary appropriately as expected by its output signal. Get all that right in hardware. Then you can enable the Analog Input in BC and read that voltage. If for some reason BC doesn’t report the same voltage (scaled of course) then there is an issue I’ll look into. But otherwise I’m afraid I can’t offer much support as we don’t know the hardware of that board.

Very fair. The right voltage is at least making it to the solder point for GPIO 34 of the ESP32 module (measuring between that solder point and ground), but it's just not registering as a voltage. I'll keep tracing and seeing if anything else is messing with the signal. Otherwise, the form factor of this board is very nice and easy to work with on BC

 

[BrunDog]

What voltages are you reading referenced to ground and what is BC reporting at those voltages?

 

[CDCTx]

What voltages are you reading referenced to ground and what is BC reporting at those voltages?

At ~4.5 PSI in a keg, I'm reading 0.670v when I touch the red meter lead to the solder point for GPIO 34 on the ESP32 module (WROOM-32D, so 6th down on the left side when looking from top and no touch area up) and the black lead to a ground pin on the board. I get the same if I touch the red lead to the connection point at the button or on the female RXL pin where my signal comes in.

I initially measured 0.761v at all points for 5 PSI, but I released some gas to make sure the lower pressure registered.

BC shows nothing for the device. Even looking at the Calibration tab for my Analog Input for Pin 34, there's no initial value showing (I set the multiplier to 1 to check this).

 

[BrunDog]

What do you mean “nothing”. Does it show dashes, 0 as in zero, what?

Can you give a screenshot of the communications window when that Analog Inout is enabled?

 

[CDCTx]

What do you mean “nothing”. Does it show dashes, 0 as in zero, what?

Can you give a screenshot of the communications window when that Analog Inout is enabled?

Ah, yes. 0.000.

Here is the device box and the communications window. Port 34.

 

[radzieju]

There is a pinout at Rocketcontroller.com you can check. As i remember , i just solder a sensor to a leg of button nr2 and IT just works.Button nr1 didnt work.I will be at brewery in couple days , i'ill check.

 

[BrunDog]

Ah, yes. 0.000.

Here is the device box and the communications window. Port 34.

Ok, reading zero. I’ll run a test to see if I can duplicate it.

 

[oakbarn]

I have a pid element that I want to start with script

"Pid 1" enabled = true

The Pid 1 is not enabled

is there a script command to turn on a PID?

I can control it manually with the Enable Button switch on the Element. I just want to do it with a script.

 

[clearwaterbrewer]

The following works for me(case sensitive E or in the name?):
"380 RC PID" Enabled = true

 

[CDCTx]

I have a pid element that I want to start with script

"Pid 1" enabled = true

The Pid 1 is not enabled

is there a script command to turn on a PID?

I can control it manually with the Enable Button switch on the Element. I just want to do it with a script.

I tried replicating this just now. I had a similar issue, but once I set the input device (1-wire in this case), it worked. It only failed to enable when no input device was set in the properties. I scripted it as:

[test]
if "35" value == 0
"PID 1" enabled = true
print "PID 1 is enabled"
endif
sleep 5000
goto "test"

If you already set one and it fails, let me know your property settings and I'll see if I can replicate and help.

Edit: I see the same behavior for hysteresis output.

 

[oakbarn]

The following works for me(case sensitive E or in the name?):
"380 RC PID" Enabled = true

no cap needed. Held my mouth different and now works

 

[oakbarn]

Dunno. If you delete the DO Element and recreate it, does it do the same thing?

I deleted the Element and re made it with the exact same attributes and it was able to be enabled via script.

I have several Elements that exhibit the same behavior:
Digital Outs that do not enable via Script Command
Digital Outs Value as LED Indicators that do not change with state
I also tried value as text and that did not update as well with change of state.

I deleted and re made the Elements and they now work fine.

Is this a known issue with a cause?

 

[CDCTx]

@BrunDog Here's a fun one: Hysteresis seems to hate the numbers 32, 34, and 35 as target values.

With my fermenters, I have a conditional to check whether I've set the fermenter to cold crash before the script does anything else. If my global "SP1 Cold Crash" is set to "Yes," then it will set my two hysteresis devices for cooling and heating to whatever I set their targets to in the script and skip everything else. The cold crash part looks like this:

if "SP1 Cold Crash" value == "Yes" //Checks to see if cold crashing. If yes...
    "SP1 Cool" target = 35
    "SP1 Heat" target = 35
        if "Spike 1" value != "Cold Crash" //If Spike 1 doesn't already show "Cold Crash"...
        "Spike 1" value = "Cold Crash" //...set it to "Cold Crash"
        restart "SP1 Time in Step"
        "SP1 DT of Step" value = now
        endif
else //See if a yeast is even identified (meaning fermentation is a go)

"SP1 Cool" and "SP1 Heat" are the hysteresis devices.

I just set a beer to cold crash, which threw an "[ERROR Line 19: Object reference not set to an instance of an object.]," where Line 19 was the "SP1 Cool" piece. This didn't make sense since the code was good and is coded the same elsewhere depending on the yeast selected and state of fermentation. It's also exactly the same for another fermenter, just with a little higher temp set.

After playing around, I realized that it wasn't the code, but the value. It throws an error if the target is set to 35. I also found it does the same if the number is 34 or 32. But other numbers in the 30s are fine.

I assume there's an issue here and not that you find the numbers 32, 34, and 35 as unlucky I am using BruControl v1.1.0.22 (Build 22 / v1.2 RC, Updated 7/30/22, installer executable), the latest release you posted about the other day.

 

[oakbarn]

If you have any elements named 35, this can cause that error.

As an example, if you have an element named "SPI 1" and then you try to assign that to a global string element value

"My Global String" value = "SPI 1"

You will get an error.

Not likely that you have an element named 35, but just a thought.

 

[oakbarn]

Learning the hard way:

Upgrading to firmware v46:

If you have a Hysteresis or PID Element that does not have an input assigned, you cannot enable it.

When I upgraded to v46, I deleted all my analog port 100+ Temperature Probes. That removed them as inputs on my Hysteresis and PID Element.

I then created my Temp Probes with the new Ports (55+)

Spent most of the day trying to figure why my Hysteresis or PID Elements would not enable after updating to v 46 Firmware.

After setting the inputs to the new Ports (55+) Temperature Probes, they enable fine.

 

[CDCTx]

If you have any elements named like 35, this can cause that error.

As an example, if you have an element named "SPI 1" and then you try to assign that to a global string element value

"My Global String" value = "SPI 1"

You will get an error.

Not likely that you have an element named 35, but just a thought.

Oh super interesting. I do have elements named with those numbers because I'm testing my new ESP board and I named them after their pins. That makes a lot of sense, I should have considered that (I forgot I had 32 as a name since I'm messing with 34 and 35). I would have assumed it would look for this: "35" value. But I can also see how it's hard to differentiate between a string and element name in this case.

Thanks for the catch!

 

[oakbarn]

Oh super interesting. I do have elements named with those numbers because I'm testing my new ESP board and I named them after their pins. That makes a lot of sense, I should have considered that (I forgot I had 32 as a name since I'm messing with 34 and 35). I would have assumed it would look for this: "35" value. But I can also see how it's hard to differentiate between a string and element name in this case.

Thanks for the catch!

I also found that the hard way. A year or two ago when I was first setting it up, there were no Display Text attributes yet. I was using Global Sting Elements as Labels for my Elements.

I had an Element named "Yellow Pump" I wanted a different Element "Yellow Pump 1" on a different workspace. I had written some script so that the "Yellow Pump" could be controlled by either Element.
I wanted the label for Both to be "Yellow Pump"
I kept getting errors trying to use the string "Yellow Pump" in my Global Element Labels. I had forgotten about it until I saw your post.

 

[CDCTx]

I also found that the hard way. A year or two ago when I was first setting it up, there were no Display Text attributes yet. I was using Global Sting Elements as Labels for my Elements.

I had an Element named "Yellow Pump" I wanted a different Element "Yellow Pump 1" on a different workspace. I had written some script so that the "Yellow Pump" could be controlled by either Element.
I wanted the label for Both to be "Yellow Pump"
I kept getting errors trying to use the string "Yellow Pump" in my Global Element Labels. I had forgotten about it until I saw your post.

Hah, sorry to have revived traumatic memories. I'm glad it's not some peculiar BC issue though. I ended up changing cold crash to 36. I'm testing my new Spike CF10 with internal cooling element and coolong jacket wrap to see how low I can get it, and I doubt it'll get past 38, but I'll let BC's graph telling me where the asymptote is. 36 should be low enough to show me.

 

[BrunDog]

I deleted the Element and re made it with the exact same attributes and it was able to be enabled via script.

I have several Elements that exhibit the same behavior:
Digital Outs that do not enable via Script Command
Digital Outs Value as LED Indicators that do not change with state
I also tried value as text and that did not update as well with change of state.

I deleted and re made the Elements and they now work fine.

Is this a known issue with a cause?

No, not known... but then again with the new FW and interface maps there are going to be issues. We need to be able to reproduce any issues so we can solve them. That said, please include as many details as you can (versions, interface, steps to repeat) to increase a chance for us to debug it here casually. We are going to create a ticket system on the website to formalize it too.

 

[BrunDog]

@BrunDog Here's a fun one: Hysteresis seems to hate the numbers 32, 34, and 35 as target values.

With my fermenters, I have a conditional to check whether I've set the fermenter to cold crash before the script does anything else. If my global "SP1 Cold Crash" is set to "Yes," then it will set my two hysteresis devices for cooling and heating to whatever I set their targets to in the script and skip everything else. The cold crash part looks like this:

if "SP1 Cold Crash" value == "Yes" //Checks to see if cold crashing. If yes...
    "SP1 Cool" target = 35
    "SP1 Heat" target = 35
        if "Spike 1" value != "Cold Crash" //If Spike 1 doesn't already show "Cold Crash"...
        "Spike 1" value = "Cold Crash" //...set it to "Cold Crash"
        restart "SP1 Time in Step"
        "SP1 DT of Step" value = now
        endif
else //See if a yeast is even identified (meaning fermentation is a go)

"SP1 Cool" and "SP1 Heat" are the hysteresis devices.

I just set a beer to cold crash, which threw an "[ERROR Line 19: Object reference not set to an instance of an object.]," where Line 19 was the "SP1 Cool" piece. This didn't make sense since the code was good and is coded the same elsewhere depending on the yeast selected and state of fermentation. It's also exactly the same for another fermenter, just with a little higher temp set.

After playing around, I realized that it wasn't the code, but the value. It throws an error if the target is set to 35. I also found it does the same if the number is 34 or 32. But other numbers in the 30s are fine.

I assume there's an issue here and not that you find the numbers 32, 34, and 35 as unlucky I am using BruControl v1.1.0.22 (Build 22 / v1.2 RC, Updated 7/30/22, installer executable), the latest release you posted about the other day.

I don't think the value is the issue. In your If statement, "Yes" should not be quoted. Also, the correct set of value options are true or false. Please see in the manual, under Element Properties... property for Hysteresis is 'Value' and its parameters are true or false.

 

[BrunDog]

If you have any elements named 35, this can cause that error.

As an example, if you have an element named "SPI 1" and then you try to assign that to a global string element value

"My Global String" value = "SPI 1"

You will get an error.

Not likely that you have an element named 35, but just a thought.

Will test this but I don't think this is correct.

 

[BrunDog]

Learning the hard way:

Upgrading to firmware v46:

If you have a Hysteresis or PID Element that does not have an input assigned, you cannot enable it.
...

This was always the case - this is not related to the FW. When you made the transition, any ports that referenced the prior Analog Inputs are now not valid and need to be updated. Since BC doesn't see those reference ports on startup, it just blanked them out in the Hysteresis or PIDs. Please don't assume it's the FW's fault.

 

[oakbarn]

This was always the case - this is not related to the FW. When you made the transition, any ports that referenced the prior Analog Inputs are now not valid and need to be updated. Since BC doesn't see those reference ports on startup, it just blanked them out in the Hysteresis or PIDs. Please don't assume it's the FW's fault.

I did it to myself.

It was that when you Delete an Analog Element, it is also removed from the Input Device attribute of the PID or Hysteresis Element.

When there is no Input Device on a PID or Hysteresis Element, it will not enable.

It does not throw an Error, so any scripts just continue to run.

As part of your instructions for upgrading to v46, you should add that:

"When you delete all of the 100+ Analog Ports and re create them with the new v46+ Firmware port scheme" (55+), you will need to reset the Input Device attribute on any PID or Hysteresis Element that used any of the deleted Elements. If you fail to do so, the Input Device attribute is blank. You cannot enable the PID or Hysteresis Element that has the Input Device attribute blank. Any scripts that try to enable on of the PID or Hysteresis Element where the Input Device attribute is blank, will not throw any errors, but the Element will NOT be enabled. You cannot enable the PID or Hysteresis Element where the Input Device attribute is blank manually either. It will say the element is enabled, but will revert to disabled in a very short time. This is also true of Enable Button on the Element.

IF you changed the name of any of the new Analog Ports 55+ Port Elements , you will need to change those references in any Scripts. If they were named exactly the same as the 100+ Ports, then no action is required.