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.
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!
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.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.
Below is how I got this to work. The InputPortID wants the actual PortID of the RTD element not the "name"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.
new string "RTDID"
"RTDID" = "NAME OF RTD" ID
"PIDELEMENT" InputPortID = "RTDID"
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...
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.
Hi all,
Here is the second Build Series video forthe UniCon:
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.
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.
Will I need to tie the AREF pin to the MEGA'S 5v pin for the RTD's (per the schematic)?
And which wires should be twisted? The wires for the SPI bus?
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.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.
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:
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.
- Add an Element (I initially used Global but tested it with a few other elements i.e graph, timer, etc...)
- Assign the element to a different workspace (other than the active workspace)
- Without clicking on "Apply" or OK, I choose to "Delete" and confirmed "Yes"
- Got the error message (screen shot attached)
- Clicked on continue in the error message window (error message window closed)
- Clicked on "Cancel"
- The new "element" did appear on the selected workspace
View attachment 688383
Enter your email address to join: