BruControl: Brewery control & automation software

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.
I've been playing around with the M5Stack the last few days. Thanks to Pete for his always prompt support; we were able to get all 3 buttons enabled with a new FW build within 24 hours of me reporting that only 1 button was able to be used.

I have found that using the display on the M5Stack with Brucontrol scripting to be a little clunky. I am wondering if others are using the M5Stack to display any sort of timer or wall clock that updates the display every second and how you coded this up? Just looking to see how others have skinned this cat.
 
oakbarn said:
Since I am rebuilding, one consideration I am making in my Build is that the USB port of any interface is accessible. Is there any reason not to leave a USB cable attached to the interface while the upstream USB A Connector(the end attached to a computer) is left unconnected? I plan to add these to the exterior side of my Interface enclosure: https://www.l-com.com/usb-waterproof-usb-a-panel-mount-jack-female-to-female. I found those small Micro USB connectors on Mega Interfaces very fragile. All of my interface devices will be powered via a separate Power Supply rather than USB.
Click to expand...

sounds like a good idea if they are free...

However in my case, they are not. I use USB for powering my Mega's since I have 12VDC, 24VDC, as well as 24VAC, and 120/240/3-phase in the panel... Not adding a 7-9VDC power supply just for the mega, so USB power it is. (I did order the keyestudio 'super mega' with 2A 5V driver yesterday, so will try that on 12V, which may leave the USB jack open..)
 
crane said:
I've been playing around with the M5Stack the last few days. Thanks to Pete for his always prompt support; we were able to get all 3 buttons enabled with a new FW build within 24 hours of me reporting that only 1 button was able to be used.

I have found that using the display on the M5Stack with Brucontrol scripting to be a little clunky. I am wondering if others are using the M5Stack to display any sort of timer or wall clock that updates the display every second and how you coded this up? Just looking to see how others have skinned this cat.
Click to expand...

Not the M5 Stack, but the Wemos D32Pro, which has built in TFT header and such... was that the 45O firmware?
 
Couple gotchas on the upgrade, all licensing based.

1 - The license didn't automatically activate on startup, I had to manually tell it to. This may be by design, but wasn't explicitly spelled out.
2 - If running the pro license, data exchange faulted because the license wasn't activated on startup. I had to turn off and turn on data exchange after activating and everything came back to life.
 
BrunDog said:
That's odd, since the P type pins are directly tied to the microcontroller pins. Did you cross-checked the port# to the UniShield pin number per the Interface Wiring Map?
Click to expand...

Yes, I always have the wiring map on a monitor when doing this as I don’t trust my memory enough to try to shoot from the hip on this stuff. 6-1 is port 29 on the Mega UniShield. I’ve disconnected the wire from the UniShield and tested voltage that way to ground for both D & P pins.

I get this comm log output when enabling the Direct Output device:

09:27:55.442: Tx: !29,1,1,0
09:27:55.457: Rx: !29,1,1,0,-1,#
09:27:56.457: Tx: ?29
09:27:56.473: Rx: ?#

Here's the config in BC:

1608831056239.png
 
Ok, that helps. The hashes in the log tell you a mismatch in the message between the application and the interface. Disable the Element. Then change the Dual Throw Port from blank to None. Then re-enable it.

** THIS WILL LIKELY BE AN ISSUE FOR ALL UPGRADERS **. Sorry! We need to document this better! Moving pieces!
 
RiverCityBrewer said:
Couple gotchas on the upgrade, all licensing based.

1 - The license didn't automatically activate on startup, I had to manually tell it to. This may be by design, but wasn't explicitly spelled out.
2 - If running the pro license, data exchange faulted because the license wasn't activated on startup. I had to turn off and turn on data exchange after activating and everything came back to life.
Click to expand...

Thank you for reminding me of this experience. I have updated the Product Note for the beta.
 
BrunDog said:
Ok, that helps. The hashes in the log tell you a mismatch in the message between the application and the interface. Disable the Element. Then change the Dual Throw Port from blank to None. Then re-enable it.
Click to expand...

Funny thing. I did that last night because I noticed the empty field. The value does not stick for me. When I close the dialog and re-open it, the field is blank again.
 
I did that about 5 times yesterday. My first instinct is that I've done something wrong and want to recheck. Once more for the team...
  • Create a Digital Output device and Dual Throw Port is blank.
  • Set it to None.
  • Click OK.
  • Open device and Dual Throw Port is blank again.
 
Can you update to the .15 version I just posted?

Any my recommendation is that if you ever revert back to a prior application version, do not use the current configuration file (which would have been updated by the newer application version). Restore the prior version's configuration before running the prior version so they match.
 
Absolutely. Will report back when done.

EDIT:

The Dual Throw Port is sticky between openings of the properties dialog. It initially came up as zero (0) but I changed it to None and that is being maintained. No wiring changes to my panel and that CZH relay is now powering on.

I did have to relicense but this was covered above by @RiverCityBrewer.

Thanks again, Peter!
 
Last edited:
I just tried to update to 1.1.0.15 It acted weird in that elements were disabled and enabling one would disable another unrelated element on the same interface. this weird behavior was in place on three separate interfaces, video is at BruControl 1.1.0.15 issues

This procedure was shutting down BC, copying the config file to another machine that had 1.1.0.9 installed yesterday and 1.1.0.15 installed just now, starting BC on that machine... I had to, and was able to activate the 2nd machine with 1.1.0.15, but it did this weird behavior described above, so I decided to shut down 1.1.0.15 and then boot 1.1.0.9 on that same 2nd machine, but now, it had no licenses available... I scrambled back to the original machine that was on 1.1.0.9, and upon loading brucontrol 1.1.0.9, all interfaces were disabled, and I figured out the license was not there... I was able to add activate license since I have 2...

so for testing, I went back to the new machine and renamed my .brucfg file and opened 1.1.0.9 with default config, and it was not licensed and I could not activate a license. I shut it down and re-ran 1.1.0.15, and it came up as unlicensed, and had a new screen for 'evaluate', so i tried that , and it said my email was already assigned to a license, so I said activate... (keep in mind I had activated the license only 30 minutes prior...) and it activated. How What are the possible ways that a license can be deactivated?
 
clearwaterbrewer said:
I just tried to update to 1.1.0.15 It acted weird in that elements were disabled and enabling one would disable another unrelated element on the same interface.
Click to expand...

Not sure if this helps, when I first opened my device after upgrading to 1.1.0.15, the dual throw port was set to zero and I changed it to None. As there is a zero port, maybe that’s causing this issue.

@BrunDog, existing devices are defaulting to zero for the Dual Throw Port instead of None. Any way to get that changed?
 
Last edited:
DonWMason said:
Not sure if this helps, when I first opened my device after upgrading to 1.1.0.15, the dual throw port was set to zero and I changed it to None. As there is a zero port, maybe that’s causing this issue.

@BrunDog, existing devices are defaulting to zero for the Dual Throw Port instead of None. Any way to get that changed?
Click to expand...

Yes, I just noticed that as the default is zero. Please change to none, and we'll fix it going forward.
 
clearwaterbrewer said:
I just tried to update to 1.1.0.15 It acted weird in that elements were disabled and enabling one would disable another unrelated element on the same interface. this weird behavior was in place on three separate interfaces, video is at BruControl 1.1.0.15 issues

This procedure was shutting down BC, copying the config file to another machine that had 1.1.0.9 installed yesterday and 1.1.0.15 installed just now, starting BC on that machine... I had to, and was able to activate the 2nd machine with 1.1.0.15, but it did this weird behavior described above, so I decided to shut down 1.1.0.15 and then boot 1.1.0.9 on that same 2nd machine, but now, it had no licenses available... I scrambled back to the original machine that was on 1.1.0.9, and upon loading brucontrol 1.1.0.9, all interfaces were disabled, and I figured out the license was not there... I was able to add activate license since I have 2...

so for testing, I went back to the new machine and renamed my .brucfg file and opened 1.1.0.9 with default config, and it was not licensed and I could not activate a license. I shut it down and re-ran 1.1.0.15, and it came up as unlicensed, and had a new screen for 'evaluate', so i tried that , and it said my email was already assigned to a license, so I said activate... (keep in mind I had activated the license only 30 minutes prior...) and it activated. How What are the possible ways that a license can be deactivated?
Click to expand...

No need to panic. This is related to the Dual Throw port defaulting to zero, such that when you enable one Digital Output, it is disabling the other. The default Dual Throw port of 0 is not by design, but the cross-element disabling is. Please change those Dual Throw ports to 'None' per above, and you should be good to go.

My apologies again for the lack of clear documentation on this. I have since updated the note.
 
I only have 1.1.0.9 at home due to the licensing schema nto allowing a fast switch to 1.1.0.15, but it looks like 45O and 1.1.0.9 have the same communication problem as 45K and 1.1.0.15


ALL THREE mega boards flashed to 45O, and worked properly with 45K before...

45O with 1.1.0.9 on a sunfounder Mega2560R3 with a keyestudio W5100 in a fresh-from-default config has the same issue.
1608901174093.png


Via USB it has the same issue:
1608901388588.png


Keyestudio supermega with keyestudio W5100 same issue:
1608901656979.png


Keystudio supermega via USB same issue:
1608901766666.png


robotdyn mega2560eth via tcpip has same issue:
1608901942006.png


robotdyn mega2560eth via USB same issue.
1608902036556.png



To verify, I took the keyestudio board back to 45K and added the digital output(I used changing between IP and USB to delete)
1.1.0.9 connecting to keyestudio supermega w/ W5100 and 45K via IP
1608903474873.png

and via usb:
1608903387735.png
 
1.1.0.15 with 45O on robotdyn mega2560eth connected via IP, screen grab of the communications enabling the device.
1608909639516.png


The supermega connected via USB:
1608910193095.png


I switched the IP to the address of my production sunfounder mega on 45K, and the familiar ---- is back...
1608910453004.png



from my observations, 1.1.0.15 *requires* 45O, and 1.1.0.9 *requires* 45K for Digital Outputs to work.
 

Attachments

  • 1608909929375.png
    1608909929375.png
    47.9 KB · Views: 2
It looks like the enable command for 1.1.0.9 and 45K has 4 fields, and the enable command for 1.1.0.15 and 45O has 6 fields...

Sending 4 fields to a device that is looking for 6, or sending 6 to a device that is looking for 4 causes the issue.
 
I upgraded the production sunfounder mega to 45O, and it will not connect while in the system with the W5500:
1608911294632.png


I disabled that interface and created a new one via USB and similar issues:
1608911507677.png


I removed the interface from the screwshield and removed the W5500, so it is completely isolated, I deleted the interface and re-added with a new DO element and it still will not connect, I downgrade back to 45K and it works:
1608913389871.png


I unplug it, plug it back in, upgrade to 45O, and still cannot communicate.
I downgrade to 45K, put it back into the production environment on the screwshield with the W5500 on that and it works with the exception of the digital outputs working when controlling the 45K mega from 1.1.0.15.

I will have to do the header mod to the supermega, or see if I can figure out a way to use the W5100 and maybe some extra stacking headers to get it to work on the screwshield to test. as far as the robotdyn, I will need a full set of stacking headers as the POE board keeps it from seating on the screwshield...
 

Attachments

  • 1608911898183.png
    1608911898183.png
    44.1 KB · Views: 8
  • 1608913051035.png
    1608913051035.png
    44.9 KB · Views: 7
  • 1608913166273.png
    1608913166273.png
    30.8 KB · Views: 7
Again, odd that K works and O doesn’t on that board. Do you have it fully separated from any shields during this test. Can you post a link to it?

Also, the serial debug would be helpful... though I suspect you will get no response at all.
 
So as mentioned, the 1.1.0.15 (v1.2 Beta) has a new license system. Based upon frequent requests, and in an effort to give new users a chance to test out the application, we incorporated an "Evaluation" license. This will allow the app to function with an Advanced level license for up to 15 days without requiring activation. So anyone looking to test it out with full functionality, can do so going forward.

1608923569679.png
 
Hey @BrunDog! I'm having some issues with the Beta when it comes to the graphs. I have a workspace dedicated to graphs (mostly temps of my ferm chambers and tilt gravity readings). First, I had to reset the input devices for the graphs when I first opened the Beta version, which wasn't a big deal, but worth noting. After I reset the devices, the graphs started show the time markings as data started coming in, and all seemed fine, but if I clicked to another workspace and back to the graphs workspace, the appearance of the other workspace seemed to remain overlayed atop the graphs. One graph would appear perhaps, but the others couldn't be seen due to the overlay of the other workspace. I had to minimize the app then restore it for the graph workspace to appear normal.

I note that I also get error messages from BruControl that are related to the graphing services. I'll post a screenshot of the weird overlay issue and the error when they occur again.
 
BrunDog said:
Yes, you are correct. I’m sorry I didn’t explicitly state that .15 application needs 45O firmware. I’ll update the product note.
Click to expand...
Does this only apply to the mega DOs? I have a couple 8266 boards who's DOs appear to work and they are on *OLD* firmware.
 
When we added the Dual-Throw function to the app, we had to do some back and forth to solve not a communication issue, but a timing one (when both Dual Throw and One-Shot being used together). It is possible there are combinations of new app with old FW (pre- 45K) that will work.

We tested found some bugs in builds 10 - 14, so never let them into the wild, and that might have created the gap as well. That said, and I know it's a PITA... but I recommend keeping app and FW in sync in terms of most recent. If you are going to use a beta software, then you should plan on updating the FW too. We made changes to the PID and Digital Output elements, so any problems should be seen there.
 
OK, i grabbed a 2nd sunfounder (lets call it call it sunfounder B) from home, loaded 45O and used the keyestudio W5100 and it works...
1608916733360.png


I swap out the W5100 for the W5500, and it is dog slow at the command prompt, and will not get an IP address.
1608917320030.png


I put the W5100 back on sunfounder B and it works, I move the W5500 back to the prod 45K 'sunfounder A' and it is not responsive.

I take the sunfounder A and the W5500 to another non BC computer, and load 45K.MEGA.E then go to debug level 1 and do setup but hit 'n', and see it grabbed the address:
BruControl v45K.E Debug:1
%1&14;Rsp:%1
End:17432
IP:192.168.1.201
CL:0
IP:192.168.1.201
CL:0

I load 45H.MEGA.E with option 1 and do the same thing and get:
BruControl v45H.E Debug:1
%1&14;Rsp:%1
End:1196
IP:192.168.1.201
CL:0

I load 45O.MEGA.E with option 7 and then in termite I get *no response* from %1&14;

I close that and reload 45K.MEGA.E with option 4 and go to termite and with %1&14; I get:
BruControl v45K.E Debug:1
%1&14;Rsp:%1
End:971
IP:192.168.1.201
CL:0


I swap in 'Sunfounder B' with 45O and the same W5500 (I only have one) and get no response in termite.
I burn 45H.mega.E and it takes 20 seconds to get a response to setup in termite

I swap in the supermega from keyestudio with 45O and the W5500 and go into termite and it takes 20 seconds or so to respond, I do setup, and when I exit, it is really slow and does nto get a DHCP address... I power cycle it and go back into termite and wait over minute and get no response from the debug command. I downgrade to 45K and still no response.. I brought it back to my desk (connected via usb to it) and upgraded, and downgraded a couple times and got it working with 45O and IP connection to 1.1.0.15 on my test BC server..

I spent a couple hours tinkering without taking notes to get my production sunfounder A and W5500 back to operational status on 45K and connected to production BC server with 1.1.0.9..

it seems I will not be using a W5500 with new firmware, which is bad, because the W5500 I have has a lower profile RJ45 jack and fits the screwshield much better than a W5100, but I would really like to get away form modding the mega and ethernet shield
 
If I open a termite window to a mega running 45O, it breaks the TCP/IP connection to BruControl 1.1.0.15 , is this normal? (the PC with termite and the usb connection is NOT the brucontrol server, I just wanted to log the data while connected, but this seems impossible.)

edit: I just tested with 45K to 1.1.9, and it flashes 'disconnected' one time for a fraction of a second, but lets me enter the %1 in the communications window and the debug shows up at the termite window on the other PC
 
Last edited:
I picked up a few of those a couple months ago. Found out that ESP32S and ESP32-DevkitC are not the same sized board. The DevkitC is about 2-3mm wider than the 32S. Not a big deal as long as you didn't plan on using existing boards.
 
clearwaterbrewer said:
If I open a termite window to a mega running 45O, it breaks the TCP/IP connection to BruControl 1.1.0.15 , is this normal? (the PC with termite and the usb connection is NOT the brucontrol server, I just wanted to log the data while connected, but this seems impossible.)

edit: I just tested with 45K to 1.1.9, and it flashes 'disconnected' one time for a fraction of a second, but lets me enter the %1 in the communications window and the debug shows up at the termite window on the other PC
Click to expand...

If you have RTS/CTS or DSR/DTR on for low control in Termite, it will reset the MEGA, so yes, this will break the comms with BC. Turn that flow control off and that should no longer happen.

I'm having a hard time following all your movements with the other stuff. Bouncing back and forth is not a good way to debug. Also, if you use different MAC addresses with the same IP, you will lose communications unless that link is deleted in the computer's translation table. Even using ARP I have had a hard time correcting this. A PC reboot usually fixes it.
 
I am using termite the way the InterfaceSetup.bat for that particular code level opens it... did that change in version 45O? (termite.txt looks similar) I guess I could open it directly... I tried setting my old school HyperACCESS up, but cannot seem to get the terminal emulation right to send the codes, just view the debug, which is OK, and I have it's flow control off..

mac addresses seem to stay with the mega, not the W5x00 based on all my swapping, but sometimes they are not 'sticky', and need to be reprogrammed, or at least it appears that way in the termite window.

If it was just IP connectivity, the ARP table entry waiting to timeout would explain it, but they are unresponsive to USB serial connectivity.
 
Had some time to update my mega (previously on 45K with no issues) to 45O this evening, and I am having similar problems with 45O and the W5500 ethernet shield. Ethernet communications are also strange (I'll see if I can get a packet capture tomorrow to confirm what I think is going on), but I was able to get a stable network connection into BC after some tinkering. After the flash, I also cannot seem to get communications via termite to do debug or setup.

Question: Did the network stack code get updated or changed for the MEGA in 45O?
 

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
6K
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