Page 1 of 3 123 LastLast
Results 1 to 13 of 39

Thread: Hot Water Reset

  1. #1
    Join Date
    Jun 2006
    Location
    New Jersey
    Posts
    4,340

    Hot Water Reset

    I have always done my hot water reset based on outdoor air. Which seems to work and I never had any complaints. But I was thinking why do I reset HW off OA temps and I reset DA temps off terminal load.

    Wouldn't it be better to reset hot water based off terminal load or valve position? What are you guys doing?

  2. #2
    Join Date
    Jan 2012
    Location
    California
    Posts
    90
    Terminal load is best IMOP. Outside air works good and I did it for years before working with a product (ALC) that has good optimization tools. Even today however some engineers require OSA reset as a spec item. We will put in a switch for the customer to check performance and compare what works better and uses less energy. Terminal load is actual demand in the space we are trying to control.

  3. #3
    Join Date
    Jul 2008
    Posts
    1,479
    Depends how you derive TerminalLoad ...which, depending on the field controllers, may not even be published.

    if PI is available on your pre-canned field controllers then it may well be that TerminalLoad has very little to do with whether a zone is satisfied or not and more to do with the positioning of the terminal equipment's HHWV or Volume Damper, or the output of its PID loop. In this case, using terminalLoad is a common mistake that will make your whole system hunt up and down all day and then require all sorts of ramps and delays to stop it (hello ALC :-) )

    So terminalLoad can be used as long as yr field controllers are set to P only otherwise what you really need is 'deviation' from setpoint.(granted, some do call this terminalLoad)

    TerminalLoad doesnt always take into account individual field setpoints either unless you calculate it as a 'deviation' from SP.

    Also, using you need to be able to decide which zones terminalLoads to use, and which not to use.

    This also feeds into an earlier discussion in these forums about separations between htg and clg setpoints ( or what some people call deadBands)

    My point of view is that separations between htg and clg in zone controllers (particularly with P-only) guarantees that
    1. temperatures will never be at setpoint (which setpoint ? htg? clg?)
    2. the graphics will always show temperatures not at setpoint
    3. adjacent zones in the field may well be at 2 different setpoints ..the people in the cool zone will complain its too cold and the people in the warm zone will complain its too warm, and there will be a general feeling that temperatures in the building are all over the place (which is because they are all over the place!)

    So ...
    P+I in the field,
    virtually zero deadband around the field setpoint.
    use deviation from setpoint. as your measure
    do calculations on ALL the deviations at floor level, AHU level, or whole building level to ignore rogues, apply the 'DeadBand' etc ... to decide ...
    when a call for heat or cool exists, and what the HHW or CHW or SupplySP will be.
    Terminal Load becomes the feedback to establish 'how satisfied' the field is
    high TerminalLoads means 'need more heating'... it doesnt necessarily mean 'need hotter water' ... 15 °C across a reheat coil is 15° no matter what the HHW temp is
    In my opinion raising the HHW setpoint more than necessary is quite likely to only contribute to greater losses in the HHW system without having the net effect of raising zone temps

    ...anyway this probably depends on where in the world you are and whether or not yr boiler plant is running day-and-night ...(it really isnt that critical here)
    IF it does run 24/7, then I imagine that terminal loads would indeed be the best metric to use for setpoint reset of yr HHW temp

    consider summing Reheat valve positions as a metric too ...
    The only thing that counts here as a measure of whether or not the HHW system is energy efficient ... is boiler run-time ... or energy into the boiler.
    measure it, count it, graph it ... work out the best compromise.

    For the punters? ... the measure is are most of the zones satisfied most of the time? ... and is the complaints line buzzing??

    Use OA temp to ...
    adjust lowest/ highest limits for Setpoint Resets and for adjusting on/off points for the HeatCall or CoolCalls
    Avg OA temp is warm ... then it takes XXX - summed-hhw-position% to generate a CALL
    Avg OA temp is cool... then it takes YYY- summed-hhw-position% to generate a CALL
    Forget field dead bands ... Shift everybody's field setpoint ( or the limits they're allowed to adjust by) up and down seasonally
    Change delay and linger times for heat and cool calls

    Field DeadBands DO NOT save energy (they waste it and generate temperature complains) ... DeadBands and Resets at the Boiler/Chiller/AHU will definitely save energy because this is where the energy is consumed and where that consumption can be limited / adjusted / stopped.

    ...this should generate some good discussion...
    1 + 1 = 3 ( *** for very large values of 1)

    ...everybody wants a box of chocolates and long stemmed rose

  4. #4
    Join Date
    Jan 2003
    Location
    USA
    Posts
    1,744
    Quote Originally Posted by MatrixTransform View Post
    Field DeadBands DO NOT save energy (they waste it and generate temperature complains)
    Let's start this really simple...

    So CV package RTU with DX/Gas on a stat serving a large space, whatever. No deadband between heat/cool and I'm going to save energy and reduce complaints?
    Propagating the formula. http://www.noagendashow.com/

  5. #5
    Join Date
    Jul 2008
    Posts
    1,479
    Quote Originally Posted by orion242 View Post
    So CV package RTU with DX/Gas on a stat serving a large space, whatever. No deadband between heat/cool and I'm going to save energy and reduce complaints?
    not the best example ... c'mon a bit a bit of a no-brainer

    DX and GAS ... means all heating or all cooling ... so probably not !

    ...a real problem in the controls inductry is that there is a never a "one-size-fits-all" store when you want one


    here's a challenge ... show me how dead bands in terminal equipment save energy and give better comfort conditions ... Im all ears
    1 + 1 = 3 ( *** for very large values of 1)

    ...everybody wants a box of chocolates and long stemmed rose

  6. #6
    Join Date
    Jan 2003
    Location
    USA
    Posts
    1,744
    You put a big target out there with that statement... I'll spare you heat pumps, how about VAVs...

    VAV box with HW or electric reheat? Still no deadband, and saving energy?
    Propagating the formula. http://www.noagendashow.com/

  7. #7
    Join Date
    Jul 2008
    Posts
    1,479
    Quote Originally Posted by orion242 View Post
    You put a big target out there with that statement...
    heheh ... yeah I know!

    Quote Originally Posted by orion242 View Post
    ... VAV box with HW or electric reheat? Still no deadband, and saving energy?
    yep ... energy is total consumed by the building envelope.

    ...so, yr telling me that some how with approximately the same zone setpoints (plus a small dead band) that this is magically going to reduce runtime and consumption?

    hmm ... i wonder how? does a deadband stop heat loss? does a dead band stop air infiltration? ... or does a dead band just let it get a degree colder in the space?

    and having temps in zones that could vary between zones by up to a degree or so ... er... improves comfort?

    I love conventional wisdom ... its so .. er...conventional.

    The ONLY way to stop energy consumption is to reduce runtime ... please illuminate me as to how in diverse system that dead-bands on zones does this?
    ...perhaps there is some voodoo that only works north of the equator?
    1 + 1 = 3 ( *** for very large values of 1)

    ...everybody wants a box of chocolates and long stemmed rose

  8. #8
    Join Date
    Dec 2007
    Location
    Connecticut
    Posts
    924
    Quote Originally Posted by MatrixTransform View Post
    Depends how you derive TerminalLoad ...which, depending on the field controllers, may not even be published.

    if PI is available on your pre-canned field controllers then it may well be that TerminalLoad has very little to do with whether a zone is satisfied or not and more to do with the positioning of the terminal equipment's HHWV or Volume Damper, or the output of its PID loop. In this case, using terminalLoad is a common mistake that will make your whole system hunt up and down all day and then require all sorts of ramps and delays to stop it (hello ALC :-) )

    So terminalLoad can be used as long as yr field controllers are set to P only otherwise what you really need is 'deviation' from setpoint.(granted, some do call this terminalLoad)

    TerminalLoad doesnt always take into account individual field setpoints either unless you calculate it as a 'deviation' from SP.

    Also, using you need to be able to decide which zones terminalLoads to use, and which not to use.

    This also feeds into an earlier discussion in these forums about separations between htg and clg setpoints ( or what some people call deadBands)

    My point of view is that separations between htg and clg in zone controllers (particularly with P-only) guarantees that
    1. temperatures will never be at setpoint (which setpoint ? htg? clg?)
    2. the graphics will always show temperatures not at setpoint
    3. adjacent zones in the field may well be at 2 different setpoints ..the people in the cool zone will complain its too cold and the people in the warm zone will complain its too warm, and there will be a general feeling that temperatures in the building are all over the place (which is because they are all over the place!)

    So ...
    P+I in the field,
    virtually zero deadband around the field setpoint.
    use deviation from setpoint. as your measure
    do calculations on ALL the deviations at floor level, AHU level, or whole building level to ignore rogues, apply the 'DeadBand' etc ... to decide ...
    when a call for heat or cool exists, and what the HHW or CHW or SupplySP will be.
    Terminal Load becomes the feedback to establish 'how satisfied' the field is
    high TerminalLoads means 'need more heating'... it doesnt necessarily mean 'need hotter water' ... 15 °C across a reheat coil is 15° no matter what the HHW temp is
    In my opinion raising the HHW setpoint more than necessary is quite likely to only contribute to greater losses in the HHW system without having the net effect of raising zone temps

    ...anyway this probably depends on where in the world you are and whether or not yr boiler plant is running day-and-night ...(it really isnt that critical here)
    IF it does run 24/7, then I imagine that terminal loads would indeed be the best metric to use for setpoint reset of yr HHW temp

    consider summing Reheat valve positions as a metric too ...
    The only thing that counts here as a measure of whether or not the HHW system is energy efficient ... is boiler run-time ... or energy into the boiler.
    measure it, count it, graph it ... work out the best compromise.

    For the punters? ... the measure is are most of the zones satisfied most of the time? ... and is the complaints line buzzing??

    Use OA temp to ...
    adjust lowest/ highest limits for Setpoint Resets and for adjusting on/off points for the HeatCall or CoolCalls
    Avg OA temp is warm ... then it takes XXX - summed-hhw-position% to generate a CALL
    Avg OA temp is cool... then it takes YYY- summed-hhw-position% to generate a CALL
    Forget field dead bands ... Shift everybody's field setpoint ( or the limits they're allowed to adjust by) up and down seasonally
    Change delay and linger times for heat and cool calls

    Field DeadBands DO NOT save energy (they waste it and generate temperature complains) ... DeadBands and Resets at the Boiler/Chiller/AHU will definitely save energy because this is where the energy is consumed and where that consumption can be limited / adjusted / stopped.

    ...this should generate some good discussion...
    Thanks Matrix. This is great information. I just took all deadbands out of a building that I took over because all zones wouldn't meet set point. You could feel major temp swings and the customer was not happy. Every zone met set point after the fact which has never happened before. We are now focusing on proper resets on the boilers and chillers.

  9. #9
    Join Date
    Dec 2007
    Location
    Connecticut
    Posts
    924
    Quote Originally Posted by ascj View Post
    I have always done my hot water reset based on outdoor air. Which seems to work and I never had any complaints. But I was thinking why do I reset HW off OA temps and I reset DA temps off terminal load.

    Wouldn't it be better to reset hot water based off terminal load or valve position? What are you guys doing?
    The last job I did, we looked at zone error. We first incrementally reset the HW loop DP set point 1 psi every 15 minutes while respecting a minimum set point based on min flow requirements for the building. If we were at min DP set point for 30 minutes after that, then we started knocking 5 degrees off the loop every 15 minutes. If the zones started requiring more heat, we reversed the sequence. Seems to work pretty well. This works really well if you have separate loops for reheats and AHU's. I always run my AHU loops much cooler than my reheats and base that off of OAT. This will reduce nuisance freeze stat trips and will provide a stable discharge air temp.

  10. #10
    Join Date
    Jan 2008
    Location
    Near Philly
    Posts
    524
    Quote Originally Posted by ascj View Post
    I have always done my hot water reset based on outdoor air. Which seems to work and I never had any complaints. But I was thinking why do I reset HW off OA temps and I reset DA temps off terminal load.

    Wouldn't it be better to reset hot water based off terminal load or valve position? What are you guys doing?
    Personally, I like to keep all of the factors at the controller level. Meaning I really don't want the terminal loads or deviations of remote controllers coming into a BAS device then calculated and sent back out to the boiler room controller. First, when dealing with multiple terminals devices you can have multiple terminal errors. Anywhere from overrides, non functional devices or valves, bad sensors, and network failures. While OA temperature reset has been successfully for many years with a couple more factors included it can be optimized. Variable pump speeds, Flow meters, System and boiler delta Ts, Bypass valve positions, and boiler firing rates. Depending what information is available, usually a pretty efficient control strategy can be developed all within the boiler room controller with only a few items subject to error or failure.

  11. #11
    Join Date
    Jun 2006
    Location
    New Jersey
    Posts
    4,340
    Thanks for the responses.......gives me some stuff to think about.

    I don't use terminal load from application specific controllers. As Matrix stated.......they almost always seem to represent the modes PID. Also, we do 90% integration/retrofits and alot of controllers don't have terminal load. So I have always just laid my own on them. It's really deviation from effective setpoint, but I always call it cpTermLoad. I was thinking about still using reset based on OA, but then adding in a bump from Terminal Load.

    So initial setpoint is based off OA temp. Then avg terminal load can raise or lower it 20 degrees.

    As far as deadband.......I always look at it as protecting equipment, not occupant comfort or energy savings. For example.....we just did a retrofit at a office building. It had parallel VAV's with single stage electric reheat. Yes they have a single setpoint for zone temperature. But there are deadbands behind the scenes to keep the dampers from hunting, the fans from short cycling, and the electric reheat from short cycling. We try to keep temps with 1-2 degrees of setpoint. 1-2 degrees temperature swing is not felt. I don't care what the ladies in the offices say!

    I don't know how I could possibly keep all factors at the control level. Wait I probably could, but it would really limit me of what I could do. They way I approach it is.........will the controller be able to keep running with out the network. So with that, I see no reason to not have reset programming or variables for reset come from the network. I just make sure that if network goes down, I run a standard setpoint. Also 98% of our front ends these days are Tridium. There is so much amazing stuff you can do, so that a bad sensor or a down device doesn't screw up your average/min/max programming.

    An example of this is pump programming. We deal with alot of legacy controllers and install a variety of new controllers. It's tough to be on top of the different proprietary programming. So I will adjust programming or create programming that just lead/lags the pumps based off of pump proving. Then I will lay my fancy lead/lag with runtimes and overrides over them in Niagara. They get all the fancy fluff and if the network is down, then I still have pump control and they will switch on a failure.

  12. #12
    Join Date
    Jul 2008
    Posts
    1,479
    Quote Originally Posted by ascj View Post
    . . . There is so much amazing stuff you can do, so that a bad sensor or a down device doesn't screw up your average/min/max programming...
    try the BQL objects in vykonPro which are lightweight on CPU time...

    and add some of this in a Program to deal with null and NaN on the outputs

    -- BStatusNumeric in
    -- BStatusNumeric default
    -- BStatusNumeric out

    public void onExecute() throws Exception
    {

    if (!getIn().getStatus().isValid())
    {
    getOut().setValue(getDefault().getValue());
    return;
    }

    double value = getIn().getValue();

    if (Double.isNaN(value))
    {
    getOut().setValue(getDefault().getValue());
    return;
    }

    if (value == Double.NEGATIVE_INFINITY || value == Double.POSITIVE_INFINITY)
    {
    getOut().setValue(getDefault().getValue());
    return;
    }

    getOut().setValue(getIn().getValue());

    }
    1 + 1 = 3 ( *** for very large values of 1)

    ...everybody wants a box of chocolates and long stemmed rose

  13. #13
    Join Date
    Jul 2008
    Posts
    1,479
    Quote Originally Posted by ascj View Post
    ... But there are deadbands behind the scenes to keep the dampers from hunting...
    If you use PI on loops in the field there wont be any hunting

    Quote Originally Posted by ascj View Post
    ... 1-2 degrees temperature swing is not felt...
    Hmmm, I disagree

    women in the cool zone walk into the warm zone and say "wow, its lovely here"
    blokes in the warm zone walk into the cool zone and say 'wow, its beautiful here"

    ...both ring the building manager and complain about the temp.

    ... but anyway if you use PI on loops in the field then the temps will be very close to SP ... and probably very close to adjacent zones too


    .... all of it is dependent on using dev from SP as feed back


    and for those here that still maintain that a DB saves energy ... why not simply move everybody's relative SP up and down seasonally?
    I like using the monthly mean max temperature for this ... cooler in winter and warmer in summer.
    let each zone SP be adjustable by a degree or 2 around this global SP.
    and deal with special cases individually where necessary.
    1 + 1 = 3 ( *** for very large values of 1)

    ...everybody wants a box of chocolates and long stemmed rose

Page 1 of 3 123 LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
Comfortech Show Promo Image

Related Forums

Plumbing Talks | Contractor Magazine
Forums | Electrical Construction & Maintenance (EC&M) Magazine
Comfortech365 Virtual Event