Yeah i noticed something similar to that at these points looked like a heat and a cool
Step one: tweak individual heat and cool PID settings to prevent overshoot.
Step two: add lockout time/extra hold time so in case of overshoot the drop/rose back is passive (and not active on both directions).
Looks like you have tuned it pretty well, the step responses look very good.
Can I just double check and this is being really picky, when the cooling came on in this graph 22:24 it dropped the temperature from 10.125 to 9.8125 which is a slight overshoot, would this be best corrected via tweaking a combination of Td and Ti (currently Td is 4 minutes Ti is 0s) or via lockout time/extra hold time
You really can’t tell from this graph. The PID graph will be much more insightful.
Bob
I’ve now run through a good bunch of loops and am pretty happy with the results. One thing I cant really get my head around is after the the initial ramp down from 12-10 which gracefully tapered off in the attached graphs it can be observed that the cooling came on again around 03:02 and although Duty achieved appears to be consistently lower than the Duty Setting throughout the colling period and Output Value lower than Output Target (P+I+D), it has resulted in an overshoot of 0.4 (9.65 instead of setpoint 10)
Everything else seems to be stable and maintaining setpoint throughout the tests other than this one point in the cycle
I’ve tried a number of tweaks but cant seem to eliminate this!
What are Ti and Td? Seems like you are running on P alone. Some Td could help reduce the overshoot.
Your pump is also so weak that you are almost running it digitally. There is not much of a gradual approach if it goes from 100% to 0% because of the high Kp. You could try halving Kp.
Yeah both 0 running on P alone, i just wondered why it hadn’t overshot on the initial ramp down, is that because it had more temperature range to play with and taper down, where as in the cooling coming on at 03:02 it doesn’t and so overshoots?
I didnt apply any TD because i didnt see any overshoot in that initial ramp down, will apply some and see if that helps!
[Edit: Yep thats done the trick 6m Td has kept it just around 0.1oc overshoot on that second cooling]
1 Like
Yeah I’m not controlling the pump im controlling a ball valve open or shut that allows flow from the pump which runs constantly at a speed i’m not in control of at the moment, so yes it’s an on or off scenario!!
As per screen shot the cooler recirculates the glycol internally via its own in built pump at a constant speed which I dont control at the moment, the Spark simply opens one of the ball valves to allow flow of Glycol through the coil in the left or right or both fermenters, the only control I have on the cooling at the moment is the amount of time that the ball valve that feeds the cooling coil is open for and hence the amount of time Glycol is circulated or pushed through that coil!
I had this setup before SS Brewtech offered their packaged heating and cooling solution so its less than ideal but just making do with what I have. I have all of the SS Brewtech FTSS2 kit but just not the pump or their extortionate Glycol chiller!
As you will see from the most recent graph with Kp -80 Ti 3h and Td 0 it seems to be doing a pretty decent job, its able to drop 2oc in 20 minutes and hold temp within 0.05 so i’m not really sure how much faster i’d really want it to be able to drop the temperature anyway! I don’t know if i will run into problems with a real fermentation as a result of the limited cooling control but i guess I’ll see when i run with a real fermentation.
I mean I guess I just dont see the point in having a cooling capability that is then handbraked down to 5% of its output in order to maintain steady state cooling a small capacity system particularly given the costs. Kinda feels like buying a Ferrari and then driving it about in first gear most of the time whilst paying for a car that can do incredible speed. Obviously i can see the benefits if you are running multiple large capacity fermentation vessels, but i’'m only running two 50L vessels which aren’t going to have the same cooling demands at exactly the same points in time. Yes you need that extra capability to be able to adequately and quickly crash cool but the majority of fermentation time is going to be about maintaining steady state.
Do you have a link to those pumps you sell that you were suggesting so i can have a look?
It would probably help a lot of you close he third valve whenever one of the coils gets water. Do you do this already? If not, it is not the pump that is weak, just that you have a alternative path with lower friction.
The third valve is open all the time but only a small amount, I’ve set it by observing the flow with no return from the fermenter coils and tried to limit it to just effectively be a pressure relief. Bob had suggested doing a test with it closed to see the difference I’ve not done that yet as it’s a manual valve but will try and find time to do this. Ideally I’d like an automated solution for this controlled via logic block in brewblox and associated hardware.
For info I’m running a test now with Kp at 50 to see how that goes!
1 Like
Bob/Elco
Does the integral reset to zero once the error is zero.
In the example of the tuning test I’m noticing windup of the Integral (set at 2h) when I’m ramping up from one of the steps going from 10oC up to 12oc. as can be observed around 14:30 mark.
Although setpoint was reached around 16:21 the integral continued to accumulate and heating continued and as you will see overshoots.
If I don’t have any integral set then this doesn’t happen, but would be concerned in real fermentation that without the Integral then steady state errors wouldn’t be corrected?
Is there a setting I should be inputting to prevent this if running with integral, or something i’ve set incorrectly that would cause this?
Still Heating even though above set point
[EDIT: Might be because of the five minutes of Td that were applied as it only seems to occur when there is a derivative value as can be seen in PID graph below, integrator doesn’t seem to build up otherwise on the 2c ramp up.
Generally speaking, you reduce overshoot by reducing Ti, or increasing Td. You won’t need drastic changes.
For a more detailed approach, you’ll need Elco. He has significantly more experience zeroing in PID settings.
One request: could you select the -10 to 20 range for the Ferment-left Heat PID? (drag a box to capture the full X range, and the -10 => 20 Y range). Right now, most of the data is made illegible by the spikes in P.
See attached
As a side note the UI doesnt like me doing that as it bounces me out of the graph and back to the dashboard and sometimes shows the spark as not responding for about 5-10 seconds (red icon next to it in the services)
Example of it throwing me out of the graph about 2 minutes after zooming in to that graph
Could you please tun ctl log? That’s really weird, as graph data isn’t fetched from the spark service.
I’m seeing a lot of what looks like network resets. You may benefit from following the instructions at Some basic newbie questions to disable IPv6 on your Pi.
1 Like
The graph is a bit hard to read. Try some longer cycles and only show 2 or 3 instead of 20.
As requested, this is a rise to 12 from 10 and hold for 4 hours, pretty happy with how its tuned so far (never really dips below 0.1 degree difference) but at the moment im seeing on the steady state oscillation +/- 0.1 degree, throughout the 4 hours. Not sure if i can expect much better than this, so will go up to 12.125 and then down to 11.875 and cycle around that oscillation?
