Host Engineering Forum
General Category => Do-more CPUs and Do-more Designer Software => Topic started by: RBPLC on August 18, 2021, 11:49:00 AM
-
Would you guys consider making a combined forward/reverse combination PID? I realize this can be done with two loops (obviously) but the setup isn't that straightforward (IMO). The issue is in how to deal with the changeover from heating to cooling (and vice versa). What I envision is something that is similar to a typical single loop process controller. Typically, a process controller of this style will smoothly transition throttle output from heating, through zero to cooling without having a sudden step response in throttle output. This would be a nice feature to have for those of us who would like to replace single loop controllers with the much more capable BRX but could be setup as easily as most of these dedicated devices. The complexity is compounded if you want to implement cascade control as this then becomes four loops instead of two.
-
Couldn't the CV 0-100% be split between heading and cooling? So 0% output is full cooling, 50% is neutral, and 100% is full heating effort? You'd do the scaling from the loop output to the two devices external to the loop. Neutral wouldn't even necessarily need to be 50%.
-
I'm trying to think through this. How would the forward/reverse setting affect setting up the PID like this?
-
Well, like any PID. If you set it up the way I suggested, where increased CV tends to increase PV, then it's normal/direct. If you had 0% be full heating and 100% full cooling, then you'd set it up as reverse.
-
I think how I'd select the neutral/crossover point would be so that equal deltas of CV% represent equal BTU effect. For example, if full heating is 100k BTU and full cooling is 50k, then make the neutral point 33%.
I think I might also put in a little deadband, so for CV between +/-1% or so of the neutral point, you don't do any output at all.
-
I guess what I'm struggling with is that (for example with forward acting) if your PV is any value less than your SP, Output goes to zero (because it's forward acting). This is not the intent. I must be missing something obvious.
-
We actually had this conversation once before ;D:
https://forum.hosteng.com/index.php?topic=2793.0
What you have to remember is that "direct acting" for Host, and this is the norm for me as well, is that increasing CV will tend to increase PV (so heating). And the loop doesn't automatically go to 0 output (unless its P-only), it moves in the direction it needs to (possibly towards 0) and stabilizes at the point that zeros the error, until the load changes.
-
I'm not confused by forward/reverse acting as implemented in DmD. I just don't understand how you can split the range when you've specified the PID to be forward acting (for example). For simplicity sake assume that you have only a P loop (no I, no D). With a Gain of 1, if PV=55 and SP = 50, Output is 0. In this case, the desired output would be Output = 5 if this was a cooling (reverse) loop. For this scenario, I want this to be 5% cooling throttle. How would this be set up?
-
Whichever portion of the CV range is mapped to cooling you have to scale outside the loop. For example, if cooling is 0-32%, then if CV < 32%, cooling output = 100% - 3.125*CV. The inversion is external.
-
For example, if cooling is 0-32%, then if CV < 32%, cooling output = 100% - 3.125*CV. The inversion is external.
This makes sense. This however doesn't work the way that I currently have it set up. The way I currently have it set up, the PID output goes to zero when PV>SP . See attached for reference. As shown, when PV is above SP, Output = 0. The desire here is not to have 100% cooling but 5% cooling.
-
Yeah, but you're in P-only. Reduce Kp, put in some Ki, and preload some bias before you enable the loop. Then let the loop start seeking.
Even if you just go as is, yes it will start cooling at 100% but pretty soon, even the P term will figure out that's too much and ease off. Even better if you use some integral. Loops always start with the wrong CV, that's why they constantly adjust till they find the right one.
-
Thank you for your help. The key thing that was missing was proper initialization of the loop (see attached). Initialization could be done many ways but initializing the loop to Output=50 (when the desire is 0-50 cooling and 50-100 heating) produces the response that I would expect.
Even if you just go as is, yes it will start cooling at 100% but pretty soon, even the P term will figure out that's too much and ease off.
It was only starting at 100% cooling due to the fact that I initially had it initialized at Output=0. You're right in that if hooked to an actual system it would eventually correct itself, but immediately jumping to 100% cooling when the loop starts running is not a desirable thing for my use case.
-
Awesome, glad you got it going! 8)
Are max cooling & max heating about the same capacity, BTU-wise? If not, and if you have trouble getting gains that work well in both heating and cooling, you might move the neutral point, so that it's roughly equal BTU per CV%.
-
The key thing that was missing was proper initialization of the loop (see attached). Initialization could be done many ways but initializing the loop to Output=50 (when the desire is 0-50 cooling and 50-100 heating) produces the response that I would expect.
You can do that?? It'd have assumed that bias was the integral accumulator, and that output was recalculated from scratch each cycle as P + Bias + cycle integral contribution + D. But, if that were the case, it would immediately wipe out your initialization.
Host guys? Does .Output have some retention cycle to cycle? Where does the integral sum get saved?
-
Host guys? Does .Output have some retention cycle to cycle? Where does the integral sum get saved?
No. Output gets assigned at the top of the calcs to the pTerm + Bias and then offset by other terms as appropriate.
Integral term gets applied to the Output (as a delta, this scan) and integrated into Bias for future scans.
-
Are max cooling & max heating about the same capacity, BTU-wise? If not, and if you have trouble getting gains that work well in both heating and cooling, you might move the neutral point, so that it's roughly equal BTU per CV%.
For this application, capacities are roughly equal. I suspect splitting it down the middle will work fine for this application with same parameters for each side. My intent though is to make them independent by having different tuning parameters that are used when heat/cool, cool/heat transition occurs.
-
No. Output gets assigned at the top of the calcs to the pTerm + Bias and then offset by other terms as appropriate.
OK, so I think we're saying the same thing. But if that's the case, then presetting Output to some value and zeroing Bias won't have any effect past the first cycle, correct?
-
OK, so I think we're saying the same thing. But if that's the case, then presetting Output to some value and zeroing Bias won't have any effect past the first cycle, correct?
That should be true, yes.
-
That should be true, yes.
Weird. @RBPLC claimed that doing so kept the CV from going to 100% even long enough for the PID to wind back down. Maybe it didn't actually do anything and it integrated fast enough that it appeared to be OK?
Also, does Bias freeze on a disabled loop? So that if you start a loop that's been off, first-scan CV will be (P + saved Bias)? Or does Bias clear if you disable the loop?
-
Weird. @RBPLC claimed that doing so kept the CV from going to 100% even long enough for the PID to wind back down. Maybe it didn't actually do anything and it integrated fast enough that it appeared to be OK?
Also, does Bias freeze on a disabled loop? So that if you start a loop that's been off, first-scan CV will be (P + saved Bias)? Or does Bias clear if you disable the loop?
Either loop in manual or sample time not yet expired should leave it untouched.
Bias does freeze when in manual and is bumped on manual-to-auto based on bumpless mode setting.
-
Maybe it didn't actually do anything and it integrated fast enough that it appeared to be OK?
It's not "integrating fast enough". Even with Reset set to zero, the behavior is the same. On transition to from manual to auto, Output=Output+(SP-PV)*Gain.
-
Maybe it didn't actually do anything and it integrated fast enough that it appeared to be OK?
It's not "integrating fast enough". Even with Reset set to zero, the behavior is the same. On transition to from manual to auto, Output=Output+(SP-PV)*Gain.
Bumpless mode pushes Output into Bias.
-
Ah, so that's the one cycle of 'retention'