BruControl: Brewery control & automation software

[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.

 

[oakbarn]

I have attached a pdf of my own instructions after I upgraded to v46B.

They may be of some help to others.....

I updated this on Aug 6, 2022 to reflect that you will need to use the correct new Port when creating your new Port 54+ Analog Elements to maintain your current wiring.

 

[BrunDog]

Yes, I agree we need to clarify the update... kinda rushed the instructions!

 

[CDCTx]

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

In positive news, I found solder points on the board where I can control each relay externally, so my alternative may be to use a separate ESP32 interface to monitor and control pressure, then have one of its pins control a relay on this board. At least that frees up resources on each board.

 

[BrunDog]

Ran a test... was reading 5 no matter what. Quick debug reports its reading correctly but reporting incorrectly... will get the fix posted asap!

 

[CDCTx]

Ran a test... was reading 5 no matter what. Quick debug reports its reading correctly but reporting incorrectly... will get the fix posted asap!

You beat me to it! My TinyPICO was also reading 0 or 5. I went back to v45 and I had normal values. I was just posting a reply when you responded

 

[CDCTx]

A few more connection fixes and I'm infact getting accurate enough PSI readings based on an old calibration and v45O. I'm so glad this has been sorted. No need for extra wiring for a secondary ESP32! I'll watch for your v46 fix. Thanks for following up!

 

[BrunDog]

OK... fixed. I was able to handle this one. Use v46C, updated in the FW package. Keep in mind there may be other bugs yet to discover!

Will get 46C for the MEGA, GC, and ESP8266 updated in the package soon.

 

[CDCTx]

OK... fixed. I was able to handle this one. Use v46C, updated in the FW package. Keep in mind there may be other bugs yet to discover!

Will get 46C for the MEGA, GC, and ESP8266 updated in the package soon.

Sounds good. I'll report anything I come across. I'm just glad the electronics confidence I've gained since getting BC wasn't destroyed by not getting this set up right.

At least 45O is a great fallback. You = awesome

 

[CDCTx]

I can confirm that analog pins for ESP32 are good to go on 46C. I've reworked my math with the 12 bit ADC and have it tuned quite nicely. This relay board is a dream now!

 

[CDCTx]

@BrunDog TLDR, hysteresis for cooling and heating with 1-wire input aren't acting right on FW v46C.


There may be some communications issues regarding hysteresis devices with FW v46C. I was able to get my analog sensor set up and have my hysteresis device (solenoid) working great with Active High. Everything acts as expected when the target pressure is higher or lower than the measured pressure value (offset of 0.2); the solenoid turns on and off as it should, and BC shows "ON" and "OFF" accordingly.

But then I tried to set up my cooling and heating devices, controlled by a 1-wire probe. I put them both in Active High like the pressure setup. With my previous setup, the cooling offset just needed to be a positive number, and the heating offset needed to be a negative number. However, I am having trouble getting both cooling and heating to act right (and have BC show the proper status).

The Communications don't seem to be reflecting what the device is doing. Sometimes, I can see that the cooling relay is triggered (connected NO device is on, LED is on), but the Communications channel shows "?32=0," and BC says "OFF." Even when I change a value to make that relay physically switch off, Communications still says "?32=0," and if I switch it back on, the RX message remains "?32=0."

I tried Active Low configurations just to test what happens, but I see the same issues no matter whether the relay is triggered or not.

Here's an example process I took:

1) Set port 32 to the following properties:
Input: 1-wire temp probe (port 200).
Target: 80
Offset: 1
Active Low: OFF

The measured temperature is 77F.

The Communications show "TX !32,5,200,8000,8100,0,0" then "RX !32,5,200,8000,8100,0,0," indicating the transmission was received and confirmed. The ESP32 turns off the relay (the plugged-in fan is off, LED is off), and BC continues to show "OFF." The Communications show "?32=0." "OFF" makes sense here since cooling should only be enabled when the temperature reaches 81; at 77, this means the measured temperature is cool enough.

I then set the target to 50F, meaning it should switch on at 51F or higher. Since 77F is higher than 51F, I expect it to switch on. The Communications reflect the new target was sent, received, and confirmed, but the relay does not switch on. Communications show "?32=0." If I set the offset to -1, the relay then turns on, making it act as heating, even though the measured temperature is higher than 50F.

I've since put FW v45O back on the ESP32, and everything acts as expected. Both cooling and heating are set to Active High (or Active Low = OFF), and when my target temp is set lower than the measured temp (50F and 77F, respectively), cooling kicks on. Likewise, if my target temp is set higher than the measured temp, heating kicks on.

So this seems to be narrowed to FW v46C and not BC or its outgoing communications. Since my hysteresis device works properly with analog input on 46C, it could possibly be related to the 1-wire as input. I'll keep 45O for now since I want to use this for a new brew in a few days, but I'll check back about v46 updates. Thanks!

 

[BrunDog]

OK... we'll test it. Thanks for reporting!

 

[BrunDog]

Posted 45D... actually didn't have time to test it, but found a potential bug. If you are willing to give it a try and report back, that will be cool. Otherwise we'll test and update you.

 

[CDCTx]

Posted 45D... actually didn't have time to test it, but found a potential bug. If you are willing to give it a try and report back, that will be cool. Otherwise we'll test and update you.

I can install the firmware but I can't get to the setup mode in Termite. Went back to 45O and it works, so 46D may have an issue with setup. I'll try updating over WiFi

Update: WiFi update didn't play nice. No connect. Going back to 45O now

 

[BrunDog]

ok thanks. That’s odd because nothing else changed. Will examine.

That said, you shouldn’t need setup. Once your network setting are stored, they stay in EEPROM and carry forward.

 

[CDCTx]

ok thanks. That’s odd because nothing else changed. Will examine.

That said, you shouldn’t need setup. Once your network setting are stored, they stay in EEPROM and carry forward.

I thought that, but I didn't see it come online. I'll run it again

 

[CDCTx]

@BrunDog Alright, it came online quickly this time. And all three hysteresis devices (2 controlled by 1-wire, one by analog input) work as expected. Nice quick work!

 

[exoticatom]

I have attached a pdf of my own instructions after I upgraded to v46B.

They may be of some help to others.....

I updated this on Aug 6, 2022 to reflect that you will need to use the correct new Port when creating your new Port 54+ Analog Elements to maintain your current wiring.

Thanks for the great work.
I briefly looked at the document, just be sure on a high level of what needs to be done:

1) collect all the information /details about analog ports that need to be changed. Make a visual backup. Make all other backups.
2) edit cfg file and change _only_ the wiring map as in your document. This change only works with 46x and the newest BC.
3) install the latest BC software which supports a new wiring map.
4) install the 46x firmware.
5) start all
6) delete old and create again changed elements based on backup in point 1.

Did I get your procedure correctly? I cannot change interfaces in cfg, do they really need to be recreated?

EDIT: I might notice an error in your instructions. For example, the wiring map for Wi-Fi should be Wi-Fi_FW_v46 (in your document is Wi_Fi_FW_v46 – all with underscores).
Also, it seems I have found an older link post that confirms my assumptions.

 

[exoticatom]

Hi @BrunDog

I am using wifi shield over Arduino Mega. I was going through FW46 config steps, I just realized that my wiring map is set to default instead of to Wi-Fi for a long time.
However, I didn't notice any issues the past year using it like that.

If I try to correct it and change it now, having all my elements created, UI It gives a warning:

If I shut down the windows app, and change it in the brucfg file, the application starts without issues, and have it set correctly:

Do you see issues with it? Is that ok to change it like this, or I really need to recreate all elements from scratch?

Thank you for your answer.

 

[oakbarn]

Thanks ..

EDIT: I might notice an error in your instructions. For example, the wiring map for Wi-Fi should be Wi-Fi_FW_v46 (in your document is Wi_Fi_FW_v46 – all with underscores).
Also, it seems I have found an older link post that confirms my assumptions.

Typo on my part (or stupid auto correct??). I will correct it. I do not use wi-fi for my Mega so I could not check it.

 

[oakbarn]

Thanks .....

1) collect all the information /details about analog ports that need to be changed. Make a visual backup. Make all other backups.
2) edit cfg file and change _only_ the wiring map as in your document. This change only works with 46x and the newest BC.
3) install the latest BC software which supports a new wiring map.
4) install the 46x firmware.
5) start all
6) delete old and create again changed elements based on backup in point 1.

In a nutshell, yes.

I would also say that you need to look at the interface wiring maps (v45 vs v46) for the Analog Ports. You want to make sure that you use the new correct port for your A1 pin as that is how YOU wired it.

If you have your Brew Kettle Temperature probe wired to Pin A1, then the old Port was 101 on v45 firmware.

For a Mega, the new Port would be 55.

On a Grand Central, the new Port would be 68.

I always make a Backup of my brucfg anytime I Am changing Scripts as well. You can always revert to the backup if your changes fail to work.

If you have been following this trend of v46, you will notice that @CDCTx has switched between v45 and v46 as needed.

As a side note, anyone who upgrades to v46x, is a Beta Tester.