BruControl: Brewery control & automation software

combining configurations has hit some snags... I need to use the same contactors for my 2nd Still, I just swap heating element plugs... (Putting in 3 duplicate 50A 3-phase contactors is not possible without a lot of expense, and likely would need a new electrical panel or perhaps even service, going by the NEC..)

I guess I need to use 2 outputs and 2 SSR's for each contactor coil... If I use the BC unishield, is this allowed? is the high current output 'floating'?

 

I have an issue with my ESP32 connected via WiFi disconnecting and reconnecting randomly, sometimes every 5 mins or so. Is there a way to get some verbose debugging or logging from that device? The ESP32 is not losing wifi connection according to my router logs, so it seems to be communication with bc. I have my timeout setting around 5 seconds I think. Update time is still at 1 sec, perhaps I should change that and see. I think this is affecting my hys element as it it not working as I imagined it would. It is turning on at offset, but then switch off before it gets to my set point.

 

On of my ESP32 boards seems to disconnect from BC every 3 hours on the hour starting at 1am... no logs of the client dropping from the AP. This 3 hour drop is new since the latest firmware update. I also do 1 second updates but have the timeout set to 10.

 

I have 45D, and it is not doing it... will swap one unit to 45E
edit - change is made, will monitor... I LOVE OTA!!

 

Hi. I assume this is on 45F. Obviously connectivity is a chain, where any link breaking risks the overall integrity. Could be signal strength, power supply, etc. Things to check:
1. It’s debug log by connecting it to a computer via serial and enabling debug level 1.
2. Move it closer to the WiFi Access Point to ensure signal integrity.
3. Change its power supply and ensure it’s proper voltage. USB wall warts may not be of adequate quality.
4. Disconnect all wired-in devices and operate the ESP -32 on just power alone.
5. Disable all devices and just monitor network communications with heartbeat alone (marked by * in the interface communications dialog.
5. Revert to an older, working FW and see if the problem resolves.

Regarding your hysteresis statement, are you running a script, or this is without? If your script repeatedly commands the port to be a hysteresis with each refresh cycle, it’s state can never be polled back. In that case either a delay or toggle code will remedy it.

 

Whaaa? Are you saying that once you connect... no matter how many hours later, at 1 am it d/c, then again every three hours indefinitely?

 

Not sure your question? One UniShield output can drive probably a thousand SSR's. When you say "floating", are you asking the OFF state? When it's off, its high impedance (i.e. will not sink current aka not grounded).

 

can I have 2 outputs (one on each workspace) output to the same SSR (or unishield driver)

If I have:
'workspace 1' with 'digital out 1' and it is *OFF*
'workspace 2' with 'digital out 2' and it is *ON*

And they are *both* physically connected to the same 24vdc contactor, will I release the magic smoke?

 

I will try those.

For my hysteresis element, there was a script that has an if statement checking the state against a script variable (if x != "Hys" Target). If the "if" was true then it would change the hysteresis target, but it would never have been true in this case unless the disconnect was causing a problem. The script loop had a delay of 3 seconds.

 

Ahhh... yeah this is not a good idea with the output of the microcontroller pins. You could get away with doing this ONLY if you ensure both devices are disabled before enabling one. When you do that, the disabled digital output will go tri-state, and not care what voltage arrives on it. However, if you accidentally turn one on and the other off, one will be chip voltage and the other will be ground - hence a short. Now, you asked about the UniShield... doing what you are asking in with those outputs shouldn't be a problem, because they do not sink to ground.

 

OK. The Target property shouldn't change as it doesn't come from the interface, but no matter what... let's figure out your disconnection issue.

BTW, if you want to look for a disconnection in a script (to increase a counter or such) you can use the 'connected' property on a Device Element. For example:

Code:

if "Device Element" connected == false
...
endif

This plus some toggle code can accurately assess each new disconnection.

 

Dup post

 

I use connected == false nearly all my alarm triggers. Temp probe, device, etc. works a treat.

 

no issues yet with 45F, here are my Fermenter temp RTD's sitting in the empty 10BBL's

 

Oddly enough, yes, but only as seen by BC and recorded in the controller logs. My first thought was the wifi AP, so I updated and rebooted the AP and controller yesterday, but the issue persists. I don't see any evidence that the device is dropping from the AP, so I'm going to setup an ESP32 from a different manufacturer tonight and see if it displays the same behavior.

 

I didn't see any evidence of drops on my charts either, it wasn't until I looked at the controller/device logs that I saw it.

 

I suppose you could run a ping routine and then you can verify the network disconnect.

The odd thing is the 1:00am time. The firmware doesn’t reference any clock times.

Please email is the controller log when you get a chance.

 

I added a Mega and did not wire it except for the Ethernet. I use the Digital Outs to control a Digital Out on another Workspace.

I like the way Digital Outs look and feel versus a switch or button. It allows both Yellow Pumps to look identical on the different workspaces. You could likely do the same with a switch or button.

I have a running script that synchronizes on the yellow pump along with lots of other house keeping:

//Yellow pump is in own script
//gblYellowPumpControl is a global value that tells me "Who is on First?"
if "gblYellowPumpControl" value == 0
if "Yellow Pump" state == true
start ScrYellowPump
endif
endif
if "gblYellowPumpControl" value == 1
if "2B_YellowPump" state == false
"Yellow Pump" state = false
endif
endif
if "gblYellowPumpControl" value == 0
if "2B_YellowPump" state == true
"Yellow Pump" state = true
endif
endif


Then I have a separate script that turns on the Yellow Pump


//Turn On Yellow Pump
// 2B_YellowPump is on the not wired Mega (Fake Out)
//The only Element wired to the Yellow Pump SSR is "Yellow Pump_1"
"Yellow Pump_1" state = true
"gblYellowPumpControl" value = 1
"2B_YellowPump" state = true
"yellowpumpix" background = 2
"2B_yellowpumpix" background = 2
wait "Yellow Pump" state == false
"Yellow Pump_1" state = true
"gblYellowPumpControl" value = 0
"2B_YellowPump" state = false
"yellowpumpix" background = 1
"2B_yellowpumpix" background = 1
stop ScrYellowPump

 

Hmmm? This is what makes BruControl so much better for an end user than the BCS. I have other novices brewing with me almost all the time. I have put my Alarms on a different workspace and created a separate Alarm for each. It would just be some much easier for me if I could script the wav path and have one Alarm Element. I do not use the Alarm Timers on the Alarms myself as Brew Time is how I control my scripts (some written before that was available) so one Alarm is easier to maintain on a busy workspace.

 

dup

 

I think he is trying to control heating elements and would have duplicate PID elements, not digital outputs.

 

Here is a little script for those interested. This checks to see if a device is connected and will catch a disconnection if it occurs within a 1 second window, which should be the case for a 1 second refresh. The toggle variable is to make sure it only counts this initial disconnection, not each time it is disconnected when the script loops through.

Code:

new value counter
new bool toggle
toggle = false
[loop]
if "RTD" connected == false
     if toggle == false
          counter += 1
          toggle = true
     endif
else
toggle = false
endif
sleep 1000
goto loop

 

I have been using 2 wait codes instead of the if loop. Wait for discon, counter +1, wait for reconn, go-to loop. This is blocking, so you obviously can't do anything else within the loop, like check multiple elements in one script. You would have to have separate scripts for each element.

 

Agreed! Skinning cats!

 

You guys mind if I ask a question here unrelated to BC?

I have a commercial dishwasher that isn't turning on. No error codes so I cant use the manual to assist diagnosis. I think I found the issue to be this door bell transformer. Its a 120v to 12v DC 30VA. I confirmed 120V in but am only getting 7V out. Possible signs of a bad transformer?

Looking for confirmation on my diagnosis as well as a part I could use to sub this out. Would I be crazy assuming I can use something like this for testing/confirmation of diagnosis? Any help would be appreciated.

https://www.amazon.com/Rail-Power-S...co-20&linkId=2a0a6f442168aaaa8b381a20ba826f7f


This is the OEM transformer but I'd like confirmation before spending this kind of money or simply buying something much cheaper

https://www.amazon.com/Hobart-00-294500-00051-Transformer-30Va-60Hz/dp/B00A4NNH3A

 

I would not assume the transformer is the root cause of your dishwasher problems without at least using an ammeter on the secondary side to see if something down stream is asking too much of the transformer...

Cheers!

 

Transformers are fairly durable, so likely not that, though 7V is pretty low, so if something downstream is shorted or drawing too much current, it could read that. @day_trippr is on point with the current assessment.

That said, the transformer puts out AC voltage, not DC. The power supply you show is DC. Might work, might not, since there is likely a rectifier or additional power supply circuitry after the transformer.

Anyway, here is a cheaper transformer that should work (not plug and play since the one above has spade terminals, but you could add male spades to this transformer's wires for a PnP solution): https://www.amazon.com/Jameco-Valuepro-P-8658-Transformer-117VAC/dp/B00B8863E0

 

So my hysteresis is somehow caused by having a script running that polls if a script value is not equal to the hys Target. When this script is active the target shown on the element is correct, but it is somehow using the offset as the target and applying no offset. For example if the target is 50f with offset of 4. It will turn on above 54 then turn off when it hits 54. If I disable the script and just run the hys it works normally.

 

Pls post the script or email it to us so we can try to understand what is happening.

 

EDIT: IM AN IDIOT! I am checking the wrong thing in my if statements!
I am keeping this here for reference. But, I will post my updated code in a bit.

The code uses 2 dummy PIDs attached to 2 empty pins that are driven by the temp of the fermenting beer. Then the PID values are converted to a "fridge offset" for what temp to set the fridge at (typically like 10F) which uses fridge temp sensor to drive the Hys elements. For example, if we want to keep beer at 65F and we are using an "fridge offset" of 10, then at -255 for the cool PID, the code will set the hysteresis for the fridge temp to 55F. The code uses Globals to set the ferm temp and fridge offset, and checks if they have changed to update them if necessary. Then the loop checks to see if the Hys target needs to be changed (which is driven by the PID value). Then it loops.

The issue:
So, using the 65F ferm temp/55F fridge temp example above with an acutal liquid beer temp of 90F (to keep the PID static at -255).... I have my Hysteresis Cooling Element's offset set to 4F. When the script is running, the Target is set to 55F from the script, and the element cools down to 59F, turns off, then kicks back on minutes later when temp goes up above 59F. If I turn off the script and just set the Hys target to 55F, it cools to 55F turns off then kicks on at 59F as expected. During my testing, no values change (PID nor Globals), meaning the if statements should never be true.

UPDATED CODE:
Seems to work now.

Code:

[setup]
"Beer Cool PID" Enabled = true
"Beer Heat PID" Enabled = true
"Fridge Cool Hys" Enabled = true
"Fridge Heat Hys" Enabled = true
new value offset
offset = "Fridge Offset" Value
new value fridgeTarget
new value fridgeTarget2
new value coolPID
new value heatPID
"Beer Cool PID" Target = "Fermentation Temp" Value
"Beer Heat PID" Target = "Fermentation Temp" Value

[loop]
if offset != "Fridge Offset" Value
offset = "Fridge Offset" Value
endif

if "Beer Cool PID" Target != "Fermentation Temp" Value
"Beer Cool PID" Target = "Fermentation Temp" Value
fridgeTarget = "Beer Cool PID" Value
fridgeTarget /= 255
fridgeTarget *= offset
fridgeTarget2 = "Beer Heat PID" Value
fridgeTarget2 /= 255
fridgeTarget2 *= offset
fridgeTarget += fridgeTarget2
"Fridge Cool Hys" Target = "Beer Cool PID" Target + fridgeTarget
"Fridge Heat Hys" Target = "Beer Heat PID" Target + fridgeTarget

endif
if "Beer Heat PID" Target != "Fermentation Temp" Value
"Beer Heat PID" Target = "Fermentation Temp" Value
fridgeTarget = "Beer Cool PID" Value
fridgeTarget /= 255
fridgeTarget *= offset
fridgeTarget2 = "Beer Heat PID" Value
fridgeTarget2 /= 255
fridgeTarget2 *= offset
fridgeTarget += fridgeTarget2
"Fridge Cool Hys" Target = "Beer Cool PID" Target + fridgeTarget
"Fridge Heat Hys" Target = "Beer Heat PID" Target + fridgeTarget
endif

if "Beer Cool PID" Value != coolPID
fridgeTarget = "Beer Cool PID" Value
fridgeTarget /= 255
fridgeTarget *= offset
fridgeTarget2 = "Beer Heat PID" Value
fridgeTarget2 /= 255
fridgeTarget2 *= offset
fridgeTarget += fridgeTarget2
"Fridge Cool Hys" Target = "Beer Cool PID" Target + fridgeTarget
"Fridge Heat Hys" Target = "Beer Heat PID" Target + fridgeTarget
endif

if "Beer Heat PID" Value != heatPID
fridgeTarget = "Beer Cool PID" Value
fridgeTarget /= 255
fridgeTarget *= offset
fridgeTarget2 = "Beer Heat PID" Value
fridgeTarget2 /= 255
fridgeTarget2 *= offset
fridgeTarget += fridgeTarget2
"Fridge Cool Hys" Target = "Beer Cool PID" Target + fridgeTarget
"Fridge Heat Hys" Target = "Beer Heat PID" Target + fridgeTarget
endif

coolPID = "Beer Cool PID" Value
heatPID = "Beer Heat PID" Value

sleep 3000
goto "loop"

 

Ok I’m glad you figured it out. Because looking at your description... I’m not sure I ever could! Lol.

 

I also think I fixed my ESP32 disconnect issue. My wired ethernet cable was unplugged (probably my child), and my BC cpu fell back to wifi. Since plugging back in, I have not had a disconnect in about 12 hrs.

 

edit: removed.

 

@BrunDog I have a question about the Reversed switch on the PID. In this example, for a "heat" PID I have a process variable (aka temp) at 45.5F with a set point of 46, with the default PID settings with Kp = 1 and Ki and Kd = 0, the output is 49. This makes sense. However, if I want the PID to "cool" to a set point of 45F, I toggle the Reversed switch and my output becomes -255 (not -49). Also, if I keep the Reversed toggled, and change my set point to 46F, my output becomes -206. What is going on here? If the PID is supposed to cool, how is the proportional output non-zero if the PV is below the SP?

I have tried disabling/enabling, and tried using negative numbers in the Kp value. Also, if I increase the Kp to 5, my output becomes -116. What am I missing here? No scripts are running that affect this PID element.

 

Yup that looks broken. We'll fix it ASAP.

 

Ok, updated the firmware on the site. Only ESP32 was updated (is now 45G in the package). Please let me know if you need a different microcontoller updated. As mentioned this fix will roll into future releases.

 

The output is now a positive number, but there is still the issue of it being a non-zero number when the PV is less than the SP. For a cooling system, shouldn't the output be zero if the PV<SP? Again, this is only using Kp, Ki and Kd are zero.

 

Yeah something’s not right. I don’t think this has ever been used before! Stay tuned.

 

I know I have had the issues with reverse pids and deadbands that I have talked to you about. Don’t know if this is similar.

 

Sorry I don't remember that! Anyhoo... PID's fixed, will look at the DB's reversed function next.