I received an email today asking about reset windup during the unoccupied mode and what can be done to avoid it. Its useful info worth repeating here.
There’s no on-off feature for the PID controllers but internally there’s a limit, when the total of P + I + D hits 100% the PID gets clipped to 100%. At startup however the windup that is there could potentially cause problems. Here’s a couple work arounds:
We could hold the room temperature in a virtual variable and write a small program to toggle this variable between the real temperature in the day and the setpoint itself at night.
Here’s the virtual ‘temperature variable’ in the vars table and below is the program.
10 REM ******* USE A VAR TO HOLD THE ROOM TEMP ****
20 IF OCCUPIED THEN ROOMTV = ROOMTEMP
30 IF NOT OCCUPIED THEN ROOMTV = ROOMSET
This way the PID is satisfied at night and the I term doesn’t wind up. The only tradeoff is the program is a bit more complex, a trendlog will tell you whether its worth it.
Thinking about this a bit more:
In the example programs I have done recently there’s both a day and a night setpoint for both heating and cooling. The night cooling is disabled effectively by setting the cooling setpoint to high number. The PID sees the setpoint is achieved and therefore the PID doesn’t wind up.
I have learned that just by making the input = setpoint or visa-versa the built up error doesn’t go away it changes/stops the output but once the input is allowed to go back to an actual value and setpoint is allowed to go back to its actual value all of the existing error goes right back into the PID equation. Is there a way to pull all the error (PV-SP) additive from having an active I Term in the PID Algorithm. Even dropping I Term doesn’t clear that build up error.
Can you explain in general terms what you are working on here.
If I recall correctly, the team here set things up so that inputs are not writeable, therefore the input= set point test might not be working.
Maurice Duteau
Ah, I see from the subject line now that you are working on avoiding reset windup at night. doesn’t having a separate night set point work for you?
Maurice Duteau
Maurice,
I write the input to a variable which is used as the Process Variable in the PID. Since I had already seen that the T3000 PID could “wind-up” I tried a corrective measure to, when I don’t need PID operation such as “unoccupied” , “fan status = off” or “control off” then I write the set point to my PID Process Variable. When the system is turned back “on” “occupied” “fan status = on” then I write the input back to my Process Variable. I was hoping that when PV = SP the error would Zero and the PID would unwind, but it did not, or at least in a reasonable amount of time. Mind you this was all done with a T3000 BB on a test bench.
Thank you for responding to me as quickly as you have.
OK, understood about the windup problem you are battling there now. Have you experimented with the Time setting, setting it to Minutes will make the PID recalculate more often and hence hopefully zero out the I term quicker.
Maurice,
The time setting is already in minutes. The work I do is typically in the Institutional, Medical, Educational industries. I am testing this product for future use in facilities that require tight controls to Cooling & Heating thru modulated valves and Discharge Air Temperature Control and VAV Systems requiring specific static pressure settings and accurate velocity matching. I’ll continue to work on solutions here and determine whether this product is a fit or not. I really appreciate your time and attention. Thank you for your support!
Dave
As I understand it, you have faked out the PID in the unoccupied period and would expect the I term to die out over time but it doesn’t. We can check into this…
After thinking about this a bit and doing a thought experiment: if room temp = setpoint at night, and if there were a 20% I term to get there, would that 20% not settle in and remain indefinitely? The PID sees that 20% is good, room temp is hitting setpoint, so the I term continues.
Also thinking about this more, ideally you wuold like a basic control command to just turn off the PID at night.
IF NOT SCHEDULE THEN STOP PID1 ELSE START PID1
Looking forward to your feedback.
Maurice,
Thanks for getting to me! I have seen, in testing, a PID “lock” up for more than 24 hours. Typically controllers watch for PIDOUT Saturation at either the 0 or 100% ends and stop calculating or halting the additive error. Some even feed back the ERROR as a difference back into the calculation. I am attempting to build PID loop that looks at the ITerm and if the PTerm Value exceeds 100% then I make ERROR not exceed PB. Once I complete that I will attempt to keep the ITerm from saturating. I’ll let you know my results. As far as having a methodology to “shut down” a PID Calculation on either “Occupancy” or “Equipment Status” that would be an incredible plus, allowing the Error calculated and accumulated to be more manageable. Also having that same command zero out the ITerm would be very helpful.
Definitely the total PID total is clipped at 100%, once the PID hits 100% the I term is turned off and will not windup. If you are seeing some other behavior we can look into it.
We’ve had folks digging into the PID behavior before but never at this level. Hope we can manage to satisfy you with what we’ve done. If not then I guess we’ll have to look at adding some commands … or something.
2 Likes
Having a writeable field to zero or reset the I or D for that matter might help. I have used other products where you could reset the I bias value to wherever you wanted.
There is a workaround, set the setpoint to the actual temperature in your program. During the off-hours the PID will not wind up at all. Or just dont use I and D and let P take care of it. If you can show me some good use-cases of how this will help then we can have a closer look at adding more features… !
