Here is the graph from today's trial. The left side is difficult to read because I switched the chart from 4hrs to 8hrs in the middle. I'll add the important numbers below.
PB 10
Ti 9999
d 0
I also have a good csv file with sampling at 1 minute available for the whole run too.
This is proving a bit tricky isn't it. I think the problem is that the cooler is massively more powerful than is needed. I think you said earlier that the max ambient would be something like 90F which with a brew temperature of 60 means 30F cooling. It would be interesting to know what percentage cool that actually needs. It may be the best solution would be to limit the max cool power to a bit more than that to stop the massive undershoot you are getting. Try setting the setpoint to about 30 below ambient and see what power it settles out at. Also, something I should have noticed earlier, you have (or at least had) the Initial Integral set to 0. That means that after a node red restart or a deploy of the PID node, that if the process happens to be close to the setpoint it will start off with an output of zero. But an output from the PID of zero means full cool (1 means no cool). That is why in the chart just posted it is starting off on full cool. I presume the node was re-deployed for some reason (or node red restarted). Set the Initial Integral to 1 for the moment and that should help with the restart situation.
Good morning!
Here is what I woke up to this morning:
I did wonder about the initial i term but assumed that all zeros was where we should start.
So, earlier my ii was set to 0.5 (default?) and I got a slow start with a power level not above 50%. My thought then was it was to slow but now I see what you are looking for.
I'll let it all settle down and start over with all the same parameters except for ii.
Charles
Oh, one more thing. We still have heat turned off, right?
I just noticed that the cool% is about 2% with a 20F difference between garage temperature and bucket temperature. That should be a clue. If I wait until my garage is up to 90F it may be some time before the local weather presents that opportunity. Looking back at previous data my highest garage temp was 88F.
Is that in a stable situation with the bucket temperature staying constant and therefore the box temperature around the same value? I don't remember seeing that on any of the graphs. If necessary drop the setpoint down in order give the freezer something to do. As long as you don't go below freezing it should not affect the dynamics much.
It was in the last graph. The box temp was up and down and the bucket temp was on a very slow decline toward the setpoint with power at 2.35%
I already started the 30F below ambient trial run but I can turn it off.
Yes, I see what you mean, in fact the box temp is going down even with the power at 2.3%. The steady state will need the box and brew temp both to be around the setpoint so that means that with an ambient 20F above the setpoint it only needs about 2% of power, which is only 12 seconds every 10 mins. I think the thing to try is to limit the maximum power something like 5% of power. Is each one of the kicks in the box temperature from the compressor switching on for not much more than the 15 seconds setup as the Actuator Time in the timeprop node? If so then that could come down a bit as even on the min it is giving a noticeable kick to the box temp. So this is what I suggest:
If I have got my brains round that correctly then the compressor should never be on for more than about 5% of the time (plus a bit because of the 10 second actuator time).
If you make those changes and just deploy changed nodes then it should not affect anything else and you can just leave it running. That should have a very dramatic effect on the stability, hopefully it will be overly stable and then we can get back to tuning it.
On the chart, plot the value coming out of the PID not the value coming out of the Change node.
I"m not sure I understand how to implement #2.
Is it a node I can install or use a function node?
Sorry, it is called the Range node, not Scale. It is one of the standard nodes.
got it running. 
I took your first advice and set my setpoint at 30f below ambient so I'll have to wait for things to equalize again.
I've got the pid feeding into the cool sequence in the chart. I did some math and have PID = 70 - (payload * 10) which with 0 input it maps to 60F, but wouldn't it be better to get it off the Split Heat/Cool node?
You haven't got the split node in the flow at the moment have you? You shouldn't have, we need to tune heat and cool separately first and then combine them with the split node. I thought you set it up so the output of the PID goes straight to the timeprop node for tuning the cool. Once it is all up and running it will come off the splitter node.
No, that is not what we want. With that half the pid output is doing nothing, but the pid algorithm thinks it should be, which will mess up the control. In fact that won't have made much difference to the results so far as the problem has been the fact that the freezer is so powerful. Feed the output of the range node straight into the timeprop node. You will have to check (or uncheck) the invert bit in the timeprop node as the splitter usually does that for you.
OK, splitter bypassed and invert checked. Waiting for temps to equalize.
How about PID power output when disabled? After making the changes my freezer turned on even though the bucket temp was well below the setpoint.
I'm getting the 'infinity error again. I'll have to reboot...
Where are you getting infinity? Rebooting shouldn't help. This is linux not windows.
It was on the output of the pid again, and it did fix it.
Copyright OpenJS Foundation and Node-RED contributors. All rights reserved. The OpenJS Foundation has registered trademarks and uses trademarks. For a list of trademarks of the OpenJS Foundation, please see our Trademark Policy and Trademark List. Trademarks and logos not indicated on the list of OpenJS Foundation trademarks are trademarks™ or registered® trademarks of their respective holders. Use of them does not imply any affiliation with or endorsement by them.
The OpenJS Foundation | Terms of Use | Privacy Policy | OpenJS Foundation Bylaws | Trademark Policy | Trademark List | Cookie Policy
