BruControl: Brewery control & automation software

CornyKegs 728
Homebrew Talk - Beer, Wine, Mead, & Cider Brewing Discussion Forum

Help Support Homebrew Talk - Beer, Wine, Mead, & Cider Brewing Discussion Forum:

This site may earn a commission from merchant affiliate links, including eBay, Amazon, and others.
Also, I suggest you judge boiling by boiling... not by temperature. Temp probes are often not accurate If they haven’t been calibrated (ongoing discussions here for sure!). The only time the temp *really* matters is at mash rests.
 
I edited my comment above and you may not have seen it, but check the resistance across your element legs. At 5500w it should be between 10-11 ohms. If it's higher, then it is putting out a lower wattage than you think it is.
 
As a thought exercise, boiling is evaporation (violent evaporation, more correctly). If you wanted to use PID for to control the 'strength' of the boil, you would place a thermometer probe above the boil where the vapor would hit it, and shoot for a temperature, but it would have to be placed high enough where it also naturally cooled if there were no boiling. In a critical process automation scenario, an engineer could set this up, for us, not really worth it... a set of probes to measure 'boilover' would be practical but reduce the excitement and memorable-ness a lot from my personal experience......
 
BrunDog said:
Started a build on a 50A control system, which will be called the UniCon. This control enclosure will be the "standard" type box and will include a bunch of automation capability including lots of digital I/O, analog inputs, analog outputs, etc. Its control foundation will be a UniShield, and will show how it can be leveraged using universal connectivity to accommodate a user's expansion into more automation over time.

This build will be documented in a video series along the way. Here is the first video in this series. Happy to take any comments and questions as this is built!

Click to expand...

Great video, well thought out and explained. Please keep them coming. It would also be useful to have a parts/source list of what components you use for this build to make it easier to follow along. Sourcing is always an issue when seeking quality components at a fair price, so your guidance and experience would be greatly appreciated. If you use amazon you could even make a small percentage on providing this service...just a thought.
 
Where do you find the bus bar and lugs for breakers from the main contactor? And the distribution blocks for the low voltage stuff?

Those are very slick and streamlined. Good stuff!
 
DoubleHaulBrewing said:
I may be ok then. This is my first foray into electric and I am used to gas burner and a much more aggressive boil. There is definite turbulence where the element is, not individual bubble coming off the element like when at mash or strike temp. Just not as aggressive as I was thinking it should be in my mind and not the temp I was expecting. But taking into account RiverCity's comment about altitude. I am at 751 feet which should be about 210.5 degrees so I am not as far off as I thought.
Click to expand...
Boil on a particular day is related to pressure (Altitude is a cheat in a way for pressure). You can find the Barometric pressure from an airport near you and use a boil/pressure calculator to get the daily boil temp. You really to not want to set a temperature regardless as the boil temp could change some from morning to afternoon.
 
Thank you to everyone for the advice on the boil. Between using the PID to start with rather than the duty cycle and not have a realist expectation of what the boil should look like with the element inside the kettle rather than a pot on a stove or burner, I think everything is good. I did verify the resistance of the elements as RiverCity suggested and they are 5500w elements. Looks like everything is working as it should, just lack of experience and over thinking it on my part. I really do appreciate all the feedback, definitely learned a lot.
 
I'm trying to change the RTD input to a PID using a script and the InputPortID property of the PID but just not sure how to script this. The InputPortID property is listed as a string. I have multiple RTD's (i.e. "RTD 1", "RTD 2", etc...) and just want to change the input to the PID from RTD 1 to RTD 2 using the script. I tried:

"PID 1" InputPort ID = "RTD 2"

but that gave me an "unknown type" error.
 
Piggles22 said:
I'm trying to change the RTD input to a PID using a script and the InputPortID property of the PID but just not sure how to script this. The InputPortID property is listed as a string. I have multiple RTD's (i.e. "RTD 1", "RTD 2", etc...) and just want to change the input to the PID from RTD 1 to RTD 2 using the script. I tried:

"PID 1" InputPort ID = "RTD 2"

but that gave me an "unknown type" error.
Click to expand...
Below is how I got this to work. The InputPortID wants the actual PortID of the RTD element not the "name"

Code: 
new string "RTDID"
"RTDID" = "NAME OF RTD" ID
"PIDELEMENT" InputPortID = "RTDID"

Substituting the actual name of your RTD device you want to use for "NAME OF RTD" and the actual name of your PID device for "PIDELEMENT" in the code above.
 
I've been having a problem with my WiFi connection. I have the Adafruit Win1500 WiFi card and it's been working okay most of the time except that occasionally it stops communicating with BC. When it does stop, I've noticed the "active" LED on the WiFi card is on steadily (amber or yellow LED). Usually the "active" LED is blinking when working properly. I can reset the WiFi card and it starts working again so I don't know if this is a problem with the WiFi card or with my local WiFi net work dropping the signal. I can see the WiFi signal strength is at about -70 decibel when I log into the administrator page of my router. This should be sufficient signal since all my other devices seem to be working fine with the same signal strength. Open to any ideas on how to fix this...
 
Piggles22 said:
I've been having a problem with my WiFi connection. I have the Adafruit Win1500 WiFi card and it's been working okay most of the time except that occasionally it stops communicating with BC. When it does stop, I've noticed the "active" LED on the WiFi card is on steadily (amber or yellow LED). Usually the "active" LED is blinking when working properly. I can reset the WiFi card and it starts working again so I don't know if this is a problem with the WiFi card or with my local WiFi net work dropping the signal. I can see the WiFi signal strength is at about -70 decibel when I log into the administrator page of my router. This should be sufficient signal since all my other devices seem to be working fine with the same signal strength. Open to any ideas on how to fix this...
Click to expand...

First... did you get the WINC1500 from us? If so, we updated the module's Wi-Fi firmware. Otherwise, I suggest you update it to version 19.5.4 or 19.6.1.

Second, the signal noted by your router is your router's receiving signal, not the interface card's signal. The way to know the signal there is to connect your computer to the USB port on the interface and enter debug mode. This is also the way to see what is happening when a disconnect occurs.

Disconnects typically happen due to power issues on the interface (your interface should be powered by a quality switching power supply) or by poor Wi-Fi. Mentioned signal - this could be remedied by location, mounting, external antenna, etc.

Also, In my personal experience, when I upgraded from consumer "home" grade Wi-Fi to a more commercial grade system (Ubiquiti UniFi), my occassional disconnects and latency across all my devices (not just BruControl) went away, so I do believe there are significant differences in quality. I know this isn't a solution, but an FYI.

That said, the interface should ALWAYS automatically reconnect. If it is not (noted by the debug mode), then we need to resolve why.
 
Last edited:
Automated brewing fans... BruControl Firmware 45K has been posted.

This version includes the following changes:
  • Supports the "PWM" switch in PID and Deadband in BC version 1.1 Build 9. This means you can decide whether a PID or Deadband should resolve to a PWM or duty cycle output. Currently, if an output supports PWM per the Interface Wiring Map, it will always be used. This should give users more flexibility to select the pin/port they prefer for wiring.
  • Supports the "Dual Throw" option in Digital Outputs in BC version 1.1 Build 9. This means you can select a slave digital output port which will have an inverted output. This simulates the outputs of a dual-throw relay (hence the name). In addition, an ON-ON delay can be used to ensure that both outputs are OFF for a period of time. For example, if you were switching power to two devices using contactors, and wanted to ensure that one was fully off before turning the other on - this will handle that.
  • Added ability for ESP32 WiFi network settings to be set via a mini-access point mode. This was created for the UniFlex which does not provide USB access. When grounding I/O pin 5 on power-up, the ESP32 will enter this mode (creates an access point which can be connected to). This means ESP32 can be completely wireless once initial FW is installed.
    • This will cause an issue for users who have I/O pin 5 grounded on power-up. The mode will time out after 3 minutes and revert to normal operation, but please be aware of this new restriction and re-locate any devices which pull pin 5 to ground to another pin/port.
    • Please also note that SSID and passwords with special characters are not currently handled correctly - so continue to use the USB network settings if you use special characters.
  • Fixed Grand Central Analog Inputs 8-15 not reading correctly.
  • Fixed ESP32 counters, analog port deletion, and other issues
  • Fixed other minor bugs

EDIT: I just noticed that a Dual-Throw ON-ON delay of 0 is not working correctly... Use 1 ms or more for now. Will correct this shortly.
EDIT #2: Ignore EDIT above - this has been corrected.
EDIT #3: Ignore the second sub-bullet about special characters for ESP32 Wi-Fi Config. This has been fixed in v45L which is now in the v45 package.
 
Last edited:
BrunDog said:
First... did you get the WINC1500 from us? If so, we updated the module's Wi-Fi firmware. Otherwise, I suggest you update it to version 19.5.4 or 19.6.1.

Second, the signal noted by your router is your router's receiving signal, not the interface card's signal. The way to know the signal there is to connect your computer to the USB port on the interface and enter debug mode. This is also the way to see what is happening when a disconnect occurs.

Disconnects typically happen due to power issues on the interface (your interface should be powered by a quality switching power supply) or by poor Wi-Fi. Mentioned signal - this could be remedied by location, mounting, external antenna, etc.

Also, In my personal experience, when I upgraded from consumer "home" grade Wi-Fi to a more commercial grade system (Ubiquiti UniFi), my occassional disconnects and latency across all my devices (not just BruControl) went away, so I do believe there are significant differences in quality. I know this isn't a solution, but an FYI.

That said, the interface should ALWAYS automatically reconnect. If it is not (noted by the debug mode), then we need to resolve why.
Click to expand...

I got the WiFi board many months ago from Adafruit and had installed the firmware that was current at the time (19.5.4). I'm going through the process of updating the firmware for both BC (to 45H) and the WiFi shield (to 19.6.1) but I am running into difficulties when I try to update the WiFi firmware.
Using the Arduino IDE (ver. 1.8.8) and following the instructions in the BC manual, I'm able to upload the "WiFi firmware Update" sketch to a Mega2560 controller (at least it appears to upload with no error messages) but when I test the connection or try to actually update the firmware, I get a message to "make sure the update sketch is loaded". I've tried this numerous times and confirmed all the settings (com port, board, and processor) but get the same message each time. I know sketches will upload; I was able to upload the "CheckWiFi101 Firmware Version" sketch and confirm I have 19.5.4 installed. I even tried to update the firmware on my spare WiFi shield with the same results. After many attempts, I left it alone and installed the BC firmware update and configured the WiFi for a static IP address (making sure the IP address was outside the range of the router). The WiFi is working (for now) except that now the green LED on the WiFi shield is no longer lit. I don't understand why the WiFi shield would not update or why the green LED is not working but it is communicating with BC. Also not sure what I would be looking for in debug mode; can you provide some detail here?
 
Yeah... I should have warned you... there seems to be a problem with the MEGA or UNO performing the Wi-Fi firmware update. Something must not be right with that sketch. We've been doing it with a Metro or the Grand Central. That said, IDE version 1.8.12 is current... perhaps they fixed it. That also said, 19.5.4 should be perfectly fine - it was earlier versions that had some re-connection issues.

Another repeat issue (that isn't ours) is the green LED you mentioned. It does NOT light when connecting via Static IP, even though the green LED is supposed to light upon SSID connection. We reported this a while ago to the library authors but it never got fixed. Dunno!

When you enter debug mode level 1, you will see lots of repeat messages regarding network status. With this running, you can watch for a disconnect and see how it reports connectivity during the reconnect attempts.
 
For the next FW update, we will add some error rejection for the Tilt to eliminate the aberrant spikes that occur on occasion. These seem to stem from the simultaneous use of Wi-Fi and Bluetooth and its difficult to time around those unless we want to pause Wi-Fi, which the application will not like.

While we are at it, we can look at 1-wire and RTD, but wanted to get feedback from this group first. The purist in me feels like we should not discard data because it means something (like noise that tells you something is wrong). We feel that noise needs to be managed in hardware, not software, but yet recognize how ugly it is and how it can cause issues, so some level of rejection might be warranted.
 
BrunDog said:
Hi all,

Here is the second Build Series video forthe UniCon:

Click to expand...

Another great video with a number of super ideas about layout and hardware.

I'm unfamiliar with the "accessories SSR Bank" as a hardware component. Does it come like that, or do you need to assemble it from parts? (If you could supply any part numbers and/or manufacturers that would be extremely helpful.) I guess I'm a bit confused because you don't seem to factor in this bank of 4 SSRs into your heat equation for not needing any external means for dissipating heat (unless that extra 20 watts in the "80 to 100 watts" comes from these 4 SSRs. Granted that they will all be controlling 120 V SSRs under a relatively light load, but I'm wondering if thereIs there something special about the design of the bank that allows better heat dissipation?

I'm also curious about the wattage and amp requirements for the 5 V dc to dc power supply you have included. In your earlier spec at Brucontrol.com you had a 5V, 15W, 3 Amp; 5V 50 W, 10 Amp listed among others. Is the dc to dc conversion so much more efficient that sizing it is less of a problem? (Again, any part numbers or manufacturers info greatly appreciated.)

Thanks so much and keep up the great work.
 
sedgington said:
Another great video with a number of super ideas about layout and hardware.

I'm unfamiliar with the "accessories SSR Bank" as a hardware component. Does it come like that, or do you need to assemble it from parts? (If you could supply any part numbers and/or manufacturers that would be extremely helpful.) I guess I'm a bit confused because you don't seem to factor in this bank of 4 SSRs into your heat equation for not needing any external means for dissipating heat (unless that extra 20 watts in the "80 to 100 watts" comes from these 4 SSRs. Granted that they will all be controlling 120 V SSRs under a relatively light load, but I'm wondering if thereIs there something special about the design of the bank that allows better heat dissipation?

I'm also curious about the wattage and amp requirements for the 5 V dc to dc power supply you have included. In your earlier spec at Brucontrol.com you had a 5V, 15W, 3 Amp; 5V 50 W, 10 Amp listed among others. Is the dc to dc conversion so much more efficient that sizing it is less of a problem? (Again, any part numbers or manufacturers info greatly appreciated.)

Thanks so much and keep up the great work.
Click to expand...

Hi Steve,

Thanks for the feedback. We haven't published a parts list yet, and honestly may not (due to the varied sourcing/availability which changes often when suppliers are not industrial-level such as Amazon). Over time this gets tricky to maintain and takes a lot of effort to support. No decisions yet - stay tuned.

The accessory SSRs will only switch maybe 5 amps total... so there isn't much heat generated there. It is this model: https://www.amazon.com/gp/product/B07WGVB4SC/

Yes, I was including all the SSRs when I mentioned the 100W number. The inside of the enclosure will get a little warm under all full load, because of course not only the SSRs generate heat. Its rare that anyone would have the full 50 amps running for any extended period (and should not), and a quick evaluation seems to indicate the enclosure should be able to sink the heat to the atmosphere so long as it is not heated itself. Will test it after build and see how much of a temp rise it generates. Worse comes to it, will add some fans. In fact, maybe will add the holes now. The connectors are not splash-proof, so some fan/vents wont hurt.

The DC power supply is up to the designer to determine how that power will be used. In this build, the 5V is really only for the I/O power. It would likely be used to power some sensors like flowmeters, etc. The UniShield will have its own DC:DC converter on it to power the interface, so it will take power directly from the 24VDC power supply. You can see that one is beefy to handle all the DC power needs throughout this whole unit.
 
More on my WiFi connectivity problem...
Still having trouble with this but with further troubleshooting I have found what I think is the source of the problem and, oddly enough, it's looking like it's related to the RTD amplifier board(s) and specifically the the SPI bus.
I have the BruControl RP-3 RTD platform with 4 Adafriut Max 31865 amplifier boards for 4 PT-100 temperature sensors. For power supplies, I have a Mean Well DR-15-12 (12v / 15watt / 1.25amp) isolated power supply to power both the Mega2560 and the Win1500 WiFi shield. I have a separate Mean Well DR-15-5 (5v / 12watt / 2.4amp) power supply to drive a 5 volt relay board and the RTD amplifiers mounted on the RTD platform.
Through my troubleshooting I disconnected all the outputs from the Mega2560 and reconnected a couple at a time. I would then power up the 12 volt power supply and verify I have WiFi connectivity. I did this for each of the outputs from the interface (a few at a time) and what I found was when I connected the SDO output (port 50) to the RTD platform, there was no WiFi connectivity. I did this several times to confirm the problem. Then I found another oddity; I left the SDO output connected to the interface and powered up both the 12 volt and the 5 volt power supplies and the WiFi connectivity returned.
I've checked and re-checked my wiring several times (and fixed a minor grounding problem not related the RTD's) but other than that I didn't find any wiring discrepancies.
I don't know what this indicates (i.e. bad amplifier? bad SPI bus? wrong port for the SDO? bad interface?) or what I can do to fix it or if this is normal (I wouldn't think so). I'm definitely not at all familiar with SPI bus connectivity or components but simply followed the wiring schematics and instructions in the manual. I have no experience with SPI so wondering what to do here.
 
Both the Wi-Fi and RTD boards use the SPI interface. Noise on the bus will affect both. This is a high-speed bus, so the first thing to make sure is that the wiring to the RTD platform is SHORT. I would suggest also twisting these signal wires together to reduce noise.

Second, make sure all your grounds are tied together at one point (star pattern). This will reduce ground loops. I'm wondering if this is your issue since the SDO connection is causing your WiFi to drop.

Third, try powering the RTD platform from the MEGA's 5V pin. We'll be pushing the 5V regulator on the MEGA a bit since the Wi-Fi board uses a chunk of power, but it's worth a go. The RTD amps don't use much power. This will ensure all have the same power source, which could potentially reduce issues.
 
OK, thanks for the input on my questions.

I agree that you are rarely going to load the 50 amps at the same time, but I was thinking about doing double batches where I start a new one as soon as the first batcfh goes into the BK. Since I'm playing with low oxygen brewing, this would require boiling the water in the HLT as the first step (while the BK is boiling as well) which could get toasty (I'm thinking of an 80 watt bulb burning inside a metal box for an hour. Obviously you have real-world experience with this, so I defer to your judgement, but i'm thinking a temp controlled fan might be something to consider during that hour down the road.

A word about parts lists: Some of the parts you listed at Brucontrol.com are no longer available or have been updated since 2018 and that is fine. By listing what was available at the time it gives the novice builder of the system a guide as to what to look for. So I wouldn't be worried about keeping it updated, just kind of a snapshot of where things were at during the time of the build. For example, I never knew the buss bar and lug solution you came up with even existed. Elegant solution.

Thanks again!
 
BrunDog said:
Both the Wi-Fi and RTD boards use the SPI interface. Noise on the bus will affect both. This is a high-speed bus, so the first thing to make sure is that the wiring to the RTD platform is SHORT. I would suggest also twisting these signal wires together to reduce noise.

Second, make sure all your grounds are tied together at one point (star pattern). This will reduce ground loops. I'm wondering if this is your issue since the SDO connection is causing your WiFi to drop.

Third, try powering the RTD platform from the MEGA's 5V pin. We'll be pushing the 5V regulator on the MEGA a bit since the Wi-Fi board uses a chunk of power, but it's worth a go. The RTD amps don't use much power. This will ensure all have the same power source, which could potentially reduce issues.
Click to expand...

Will I need to tie the AREF pin to the MEGA'S 5v pin for the RTD's (per the schematic)?
 
Piggles22 said:
Will I need to tie the AREF pin to the MEGA'S 5v pin for the RTD's (per the schematic)?
Click to expand...

No. AREF is for analog inputs. Doesn't hurt to tie it by default though (use the MEGA 5V).

Piggles22 said:
And which wires should be twisted? The wires for the SPI bus?
Click to expand...

Yes... all the wires going to the platform. How long are they? They should be a few inches at best.
 
Piggles22 said:
More on my WiFi connectivity problem...
Still having trouble with this but with further troubleshooting I have found what I think is the source of the problem and, oddly enough, it's looking like it's related to the RTD amplifier board(s) and specifically the the SPI bus.
I have the BruControl RP-3 RTD platform with 4 Adafriut Max 31865 amplifier boards for 4 PT-100 temperature sensors. For power supplies, I have a Mean Well DR-15-12 (12v / 15watt / 1.25amp) isolated power supply to power both the Mega2560 and the Win1500 WiFi shield. I have a separate Mean Well DR-15-5 (5v / 12watt / 2.4amp) power supply to drive a 5 volt relay board and the RTD amplifiers mounted on the RTD platform.
Through my troubleshooting I disconnected all the outputs from the Mega2560 and reconnected a couple at a time. I would then power up the 12 volt power supply and verify I have WiFi connectivity. I did this for each of the outputs from the interface (a few at a time) and what I found was when I connected the SDO output (port 50) to the RTD platform, there was no WiFi connectivity. I did this several times to confirm the problem. Then I found another oddity; I left the SDO output connected to the interface and powered up both the 12 volt and the 5 volt power supplies and the WiFi connectivity returned.
I've checked and re-checked my wiring several times (and fixed a minor grounding problem not related the RTD's) but other than that I didn't find any wiring discrepancies.
I don't know what this indicates (i.e. bad amplifier? bad SPI bus? wrong port for the SDO? bad interface?) or what I can do to fix it or if this is normal (I wouldn't think so). I'm definitely not at all familiar with SPI bus connectivity or components but simply followed the wiring schematics and instructions in the manual. I have no experience with SPI so wondering what to do here.
Click to expand...
I definitely agree with what BrunDog is saying about powering the RP3 boards off the Mega. I was having a ton of intermittent problems when I was running a Meanwell 5v power supply. I had verified voltage coming from the power supply and adjusted it as close as possible to the same voltage coming out of the Mega 5V connection but was still having a ton of issues. As soon as I switched to the Mega for 5V power the vast majority of my issues instantly went away. A few lingering problems related to stability / RTD spikes was resolved with changing over to shielded cable.
 
Thanks for all the help here...so far so good but it's still too soon to be sure. I changed the 5v source over the to Mega and now the WiFi connects right away (as stays connected) with just the 12v power supply on (the way it should). I reconnected and powered everything up and tested all the relays, RTD's and SSR's to be sure they're working (and they are). I still have a little work to do shortening my RTD cables that connect to the platform and making sure everything is properly grounded but all seems to be working at the moment. My RTD cables are shielded, twisted cables but I need to check to be sure these are also grounded, at least to the main panel if not back to the Mega.
I was planning on letting it run overnight and was wondering if there is a way to go back and look at the connection history overnight?
 
Good to hear so far. For the shield tie it to the MEGA ground on that end only. Do not use the shield as the ground wire.

Yes, you can check the logs after a period of time to see if any disconnections/reconnections occured. If you are on the new version of BC (v1.1 Build 9), then you need to enable diagnostic logging for that interface, as it is now off by default.
 
Since I didn't have Build 9 installed yet I decided to wait until morning to install it, then let it run all day and log the WiFi communications (diagnostics logging enabled). So here it is, the next day and I've got Build 9 installed and running. BC connected with WiFi right away and seems to be running smoothly (so far).
After getting Build 9 installed, I was testing a few features, one of which was adding an element and ran across an error message (file attached). This was repeatable so thought I would pass this on. Here are the steps I used to get this error:
  1. Add an Element (I initially used Global but tested it with a few other elements i.e graph, timer, etc...)
  2. Assign the element to a different workspace (other than the active workspace)
  3. Without clicking on "Apply" or OK, I choose to "Delete" and confirmed "Yes"
  4. Got the error message (screen shot attached)
  5. Clicked on continue in the error message window (error message window closed)
  6. Clicked on "Cancel"
  7. The new "element" did appear on the selected workspace
Following the same steps above with the exception of step 2 (assigning the element to a different workspace) I did not get this error message and it worked as expected (the element is never created in the workspace). Not sure if this is a known issue and something just to be aware of or if you can make any changes to alert the user not to do what I did.

Capture.PNG
 
Last edited:
So fun putting a build together, waiting for parts like Christmas morning. I do find myself in analysis paralysis often. I have 2 enclosures, a 16x16 and my old 12x12. A 50A design needs room, the outlets are big and surprisingly, the control-side stuff takes up a lot of space too. At first I split my design by putting the 240V and DC control stuff in the 16x16 and the 120V stuff with all the Aux outlets in the 12x12. Now I'm leaning toward All AC stuff in the 16x16 and all DC stuff along with panel lights/switches in the 12x12 box....I think I'm just goin to have to rough wire things up without drilling any holes and see how it plays out.

I'd be interested to hear from anyone who has split their design across multiple enclosures. I have no automation in the design right now (valves/flow meters/level sensors) but am trying to leave a little room for addition if I go that route.....I will also be controlling my keezer, Unitank, and Brite tank with BruControl. It can be a mind numbing exercise but sometimes I enjoy it as much as brewing.

Cheers

The stuff mounted to the cover (12x12) is a LCD display and my existing RASPi with touchscreen which I will leave for now 20200707_165138.jpg
And the 16x16 20200707_165048.jpg
 
Before my fire, I had several boxes. When I rebuild, I will have several boxes. My 110. SSRs My DC SSRs on another. (to be replaced with a UNI Mega.) I had a separate box for the Megas. I had boxes for input switches. I say divide and conquer.
 
Piggles22 said:
Since I didn't have Build 9 installed yet I decided to wait until morning to install it, then let it run all day and log the WiFi communications (diagnostics logging enabled). So here it is, the next day and I've got Build 9 installed and running. BC connected with WiFi right away and seems to be running smoothly (so far).
After getting Build 9 installed, I was testing a few features, one of which was adding an element and ran across an error message (file attached). This was repeatable so thought I would pass this on. Here are the steps I used to get this error:
  1. Add an Element (I initially used Global but tested it with a few other elements i.e graph, timer, etc...)
  2. Assign the element to a different workspace (other than the active workspace)
  3. Without clicking on "Apply" or OK, I choose to "Delete" and confirmed "Yes"
  4. Got the error message (screen shot attached)
  5. Clicked on continue in the error message window (error message window closed)
  6. Clicked on "Cancel"
  7. The new "element" did appear on the selected workspace
Following the same steps above with the exception of step 2 (assigning the element to a different workspace) I did not get this error message and it worked as expected (the element is never created in the workspace). Not sure if this is a known issue and something just to be aware of or if you can make any changes to alert the user not to do what I did.

View attachment 688383
Click to expand...

There are several methods of handling unhandled exceptions in WPF.

https://stackoverflow.com/questions/1472498/wpf-global-exception-handler
You could easily then post the exception text to a url on your website to automatically collect them or just write them locally to a text file or the event log etc... and allow the user to send them when/if the device is connected to the internet.
 
Last edited:
I'm brewing in the morning, so it'll be getting a workout. I haven't noticed anything with my setup yet other than the multiple alarm issue appears to be working correctly now!
 

Similar threads

h22lude
My BruControl UniFlex review
Replies
3
Views
2K
h22lude
h22lude
duncan.brown
Brewery Dashboard
Replies
18
Views
2K
suprchunk
suprchunk
braumke
Automate your electric brewery - 4 Testers needed for open source project
Replies
29
Views
5K
estricklin
estricklin
RonBurgundy10
BruControl Uniflex: Automation For All
2
Replies
51
Views
8K
BrunDog
BrunDog
muhteeus
muh's BruControl Build
Replies
25
Views
6K
sensei247
sensei247

Latest posts

Back
Top