Die_Beerery
Well-Known Member
- Joined
- Aug 21, 2017
- Messages
- 842
- Reaction score
- 641
@swimIan I see at least 3 1 wire temp sensors in the pic. Do you by chance have more? Like 5? My serial started shutting down at 5 1wire.
When it comes time to update interface firmware, do you need to serially connect up to perform the update, or can you do it via network? I was thinking about putting some 8266 modules in some harder to reach places, but would think twice if I had to physically access them to do updates.
I'm biased, but I would be interested!OTA is built into ESP32 firmware. It’s not activated just yet but we can if there is interest.
My concern with brass is beer brewing specific. Beer (wort) is slightly acidic, which is what causes the concern for me when using brass.Micro Motions I see on Ebay are $$$$$$$. Brass is not my favorite either but who wants to live forever? My water meter at the front of my property is brass. The connections on my hot water heater are brass. Bras or Plastic, pick you poison.
Hysteresis question/issue:
I'm trying to script an override timer to reset a hysteresis value if a timer runs past a certain time. When I issue a "Hysteresis Device" value = 0 to stop the device, it stops, then it comes back on during the next refresh cycle to the interface. I was hoping it would adhere to the On Delay time set, but it only appears to do that if the target temperature is met. It also does this if I issue a "Hysteresis Device" Enabled = 0 command then re-enable it. Is this a bug or intended operation?
Edit: After further testing, issuing "Hysteresis Device" value = 0 does not appear to do anything while the device is in use. While the screen says the device goes off then back on, the relay itself doesn't change state.
PID question: When does the I term start accumulating? Initial ramping or just before set point or only after reaching set point?
The Hysteresis value property is read only as it is determined by the interface. Yes you can temporarily override it via your script but it will only reflect in the device element, not in the actual device. Enabled property will enable or disable the device, which will turn it off completely. This is all intended operation.
What are you trying to do? When you say “reset a Hysteresis value” - what does that mean? IMO you should just change the ON setpoint and the offset.
If you are looking for some type of custom Hysteresis, you might be better off scripting your own using a standard digital output.
Yeah we probably should document that better. Technically you can write the value in the element, but as you noted, as soon as BC polls the interface, it will be updated again.
Is a variable with value of zero equivalent to false?
Thanks! I am trying to figure out the Scripting Code and what it will (or will not) do.I was able to write to Target, OnOffset, and OnDelay. Didn't try InputPortID. Writing the Value makes the element visually change state, but on the next poll cycle will go back to whatever state the device is really in.
Not sure how the PortID is important either.
This might be a difference between serial and Ethernet interfaces. AFAIK you can swap out an Ethernet device for another as long as the IP address doesn't change.One thing I do think is needed is to be able to somehow change the Device Interface of a Device Element. One potential issue I could see in the future if you have to replace an Arduino because it got fried. Since I am so new to this, I just might not understand enough. I was trying to figure out loading different configurations and while doing so, it looks like if you change out a physical Arduino for a different one, you have lost any Device Element and get a Fatal Error in BruControl, even if "named" the same. It looks like the Device Interface attribute of a Device Element is somehow tied to the physical device somehow.
In the User Manual:
Hysteresis
o InputPortID (number)
o Target (number)
o OnOffset (number)
o OnDelay (number)
o Value (true/false)
Are these all just "read only"?
new bool x
x = True
if x == 1
print x
endif
No error thrown!
x is true. you must assign a boolean value (0,1, True, False) {x = Boolean Only}
You can evaluate x == only with a a boolean value (0,1, True, False)
It appears that 0 = False and 1 = True and you could use either in Scripts.
If you use a non boolean value in either statement, an error is thrown:
[ERROR: '2' is not a valid boolean value]
Thanks! I am trying to figure out the Scripting Code and what it will (or will not) do.
I am writing some simple Scripts to test most of what the User Manual says it will do.
I would be trying it as soon as I have mine wired. I have used a BCS in the Past and have changed the Target and the Swing (offset). I would think that InputPortID would have to be R/O. I think the Value would be of little use since it changes every cycle. Not sure how the PortID is important either.
One thing I do think is needed is to be able to somehow change the Device Interface of a Device Element. One potential issue I could see in the future if you have to replace an Arduino because it got fried. Since I am so new to this, I just might not understand enough. I was trying to figure out loading different configurations and while doing so, it looks like if you change out a physical Arduino for a different one, you have lost any Device Element and get a Fatal Error in BruControl, even if "named" the same. It looks like the Device Interface attribute of a Device Element is somehow tied to the physical device somehow.
This might be a difference between serial and Ethernet interfaces. AFAIK you can swap out an Ethernet device for another as long as the IP address doesn't change.
So, unfortunately in my brew day yesterday, I had the opportunity to further investigate this question, as my mash was sticking horribly due to an overaggressive crush. I made some interesting (to me, anyway) observations. As predicted by my friend, @RiverCityBrewer, and @BrunDog, once the mash stuck, the pressure/volume reading read the full volume of the mash. However, prior to the mash sticking, and I surmise as the mash bed was compacting, the volume measurement did drop. And relatively predictably, if the volume measurement got too low, the next thing that happened was that the flow would drop and I'd end up over the mash tun stirring the grains off the false bottom before restarting recirculation. Based on my observations, I think the automash logic might actually work for me to prevent a stuck mash by slowing the flow as it detects the bed beginning to compact!Hey @BrunDog and others--I'm working on refining my brew day script after my first brew, specifically attempting to use my mash kettle volume sensor to detect a grainbed restriction/stuck mash situation and adjusting the proportional valve on the other side of the pump to compensate. BrunDog has this in his script in an "automash" loop that checks the mash volume and adjusts the valve if it is above or below a specified range relative to the original mash volume.
Unlike BrunDog's mash volume sensor, mine is mounted to the side of my mash tun, above the false bottom. Is there any way to use a pressure sensor located there to detect a sticking mash? I was talking it over with my friend, and he was of the opinion that if the mash starts sticking and the pump pulls a small vacuum under the false bottom, the pressure above the false bottom will remain more or less the same, thus rendering the pressure sensor, as currently located, fairly useless for detecting a stuck mash. Have any others used a pressure sensor (or flowmeter--I have one of those too) to detect mash problems and automatically adjust their recirculating pump flow in response?
Thanks!
Man!! This guy is good! Yes @smort, you are correct. We clamped the integral from zero to max, not negative max to positive max. This means that the integral error will stop at zero if the input is “past” the target. We did this knowing our applications are unidirectionally biases (meaning our kettles heat up actively by the element but have no mechanism to actively cool).
But in truth, a real control system (like a flexible arm on a gear drive positioning a mass into a a specific location) would need the integrator to work in both directions. This makes for a more aggressive system and tuning potentially trickier.
That said, do you want the integrator to work negatively? It will probably make overshoots undershoot more, but if the consensus is desired, it’s a simple switch in the FW. I suppose we could make it a setting in the element properties but that would probably add a lot of user confusion.
Anyway... nothing to see here. Carry on!
I ran my still for 13 hours today turning unhopped beer into malt whiskey, 11 hours of that it I was trying to get the PID tuning right on my reflux condenser cooling valve, the BC PID seems to not like cooling for the reasons mentioned, I would really appreciate the ability for the integrator to work the other direction, I think it is causing my issues, and the lag might be a factor also.....
And a funny thing, if I ran with Ki and Kd set to zero and tinkered with just Kp, i could get it to do pretty small oscillations, but they were not centered over the set point, they oscillating above and below an imaginary line about 5 degrees below the setpoint... I understand that integral takes care of steady state error, but this seemed like the algorithm was scared to get close to the setpoint, every time it got close, it did an about face and went the other direction... wierd... I could have taken a hundred screenshots with different unexplained situations..
Side question: I started to put in very small Ki, it seemed to not do anything and then all of a sudden it would add far too much... my question is.. if i put in 0.005, it shows as 0.01 when i click away, and if i put in .004, it shows 0... I guess that the question is: "Is .01 the smallest non-zero value we can use?" is it reading the .005 or is it rounding it up to 0.01?
doing some tests today with a script running trough some PID values of Kp 0.1 to .30:
(orange line shows how 'closed' the valve is.. the top clipped area is 75% PWM, which translates to 7.5v, which is just before where the valve actually starts flowing. when the orange line goes down, it is allowing more cooling water. the setpoint is 160, which it never reaches(well at least with my range of P values so far...)
View attachment 615685
This is not moving it fast enough, so stopped it at .25 and I re wrote the script from .10 to 5.0
I have had a funny error show up:
View attachment 615686
No issues in the normal script log. I am more aware of what fixes it now, at first I was flustered. I first reset the arduino, then the script, then reset BC fully before realizing that just disabling/re-enabling the PID fixed it. I will load v.44J on the mega later today.. not sure what version of 44 is on it now
Enter your email address to join: