FB_HVACOptimizedOff

Calculation of the pre-stop time

Buildings and parts of buildings that are occupied at a specific and predictable time, such as schools or conference rooms, do not need to be heated for the entire occupancy period. Due to the fact that the buildings store heat, it is possible to turn off the heating a little earlier. The room temperature then drops to a barely noticeable lower temperature level by the end of occupancy. This is a deliberate drop to a target temperature - the drop difference is an input parameter of the function block and is called rRequestedTempDeviation.

The flow temperature of the heating boiler depends on the outside temperature. Thus, different outside temperatures result in different cooling curves, which essentially correspond to an exponential function:

To determine the pre-stop time it is assumed that the area of the functions between the room temperature start value and room temperature setpoint is linear. This results in a characteristic temperature change ΔT/Δt for each outside temperature, which is shown here by the dotted line.

With the structure variable stTempChangeFunction, the function block FB_HVACOptimizedOff is based on a table in which the respectively expected room temperature change is assigned for 10 discrete outside temperatures. During the commissioning or the initial starting of the system, the pre-start function must be coarsely predefined - firstly to define the outside temperature range and secondly to accelerate the adaptation procedure. This entry is done with the function block FB_HVACTempChangeFunctionEntry. The pre-stop time can be determined approximately with these values. This temperature change function f(AT) typically takes the following course, where the change is shown as magnitude, i.e. positive:

Function values within these 10 points are defined by linear equations, while values outside correspond to the function value f( AT₁ ) or f(AT₁₀) respectively:

• AT < AT₁: f(AT) = f(AT₁)
• AT > AT₁₀: f(AT) = f(AT₁₀)

The pre-stop time is then determined in accordance with the following sequence:

The input and output variables of the function block are shown here in red. Shown in purple here is the internal flag uiActualPrestopTime which contains the current pre-stop time at each point in time. The output uiPrestopTime corresponds to this flag, but is "frozen" during the pre-stop phase. This is explained in more detail below.

Function block linking and pre-stop phase

From these parameters the function block will then continuously calculate a pre-stop time, which it specifies to the timer function block. Then if, for example, a heating boiler is to be switched off at 8 pm and the pre-stop function block determines at 7 pm that the temperature level would drop by the desired value rRequestedTempDeviation on switching off the boiler in 60 minutes, the boiler is switched off immediately. The cooling behavior is then observed in a reference room over the pre-stop phase and the temperature change curve is corrected accordingly.

The pre-stop function block specifies a pre-stop time for the timer. If the timer switches the output bOutput back to FALSE, this is indicated to the pre-stop function block via its input bSchedulerOff. Internally the pre-stop function block then starts a countdown with the previously output pre-stop time uiPrestopTime [min]. The countdown either runs to the end or is prematurely ended on reaching the requested or tolerated room temperature. During the countdown, the bPrestopActive output is set.
The uiPrestopTime output continuously follows the above calculation - however, during a started countdown it is kept constant so that a fluctuation in the outdoor temperature does not indicate a lower pre-stop time and suddenly turn the boiler back on.

If, in the case of a pre-stop, the timer function block still sends the adaptation order as an edge (red line) to the optimization function block, then the latter will decide following the pre-stop phase whether the previously determined pre-stop time was precisely within a tolerance, or too short or too long, and correct the temperature change function accordingly. In doing so the pre-stop time of the point whose outside temperature was nearest to the actual one at the beginning of the countdown is corrected upwards or downwards respectively. This process is called "adaptation".

Temperature changes are only corrected if the outside temperature was within the interpolation points, i.e. the function range, at the beginning of the pre-stop; see "Adaptation".

If adaptation is desired, the inputs bWithAdaption and bSchedulerOff must be set simultaneously. A pure trigger pulse is sufficient for bWithApation. A previously started countdown is interrupted immediately if the input bSchedulerOff releases. The adaptation can be suppressed by the input bDisableAdaption. This option should be selected if the temperature change function is no longer to be changed after a certain number of adaptation procedures.

The following program flowchart is intended to better illustrate the behavior; the input and output variables of the function block are shown in red here:

The internal flag "Current pre-stop time" is the continuously refreshed result of the calculation in accordance with the diagram shown above.

The input bEnable, the function of which is not shown here, effectively disables the function block if it is set to FALSE: "0" is output as the pre-stop time uiPrestopTime and the sequence shown above is not started or is immediately reset.

Adaptation

Adaptation

The goal of the adaptation is to adapt the temperature change function so precisely that the requested or tolerated temperature decrease rRequestedTempDeviation is reached in the determined pre-stop time (in cooling mode it would be the temperature increase after switching off the cooling devices).

If an adaptation is selected and the pre-stop phase has ended (countdown = 0 or room temperature reached), then three cases can occur:

1. The countdown has elapsed and the requested deviation rRequestedDeviation is exhausted up to a tolerance rAdaptionTolerance -> no adaptation takes place.
2. The countdown has not yet elapsed, but the requested deviation rRequestedDeviation has been exceeded -> the pre-stop time uiPrestopTime was too long.
3. The countdown has elapsed, but the requested deviation rRequestedDeviation is not yet fully exhausted -> the pre-stop time uiPrestopTime was too short, i.e. switch-off can take place even earlier.

The value ΔT/Δt can now be re-determined on the basis of the elapsed countdown time and the change in the room temperature difference that has taken place

1. no change.
2. too much time was calculated - new value: "desired deviation rRequestedDeviation" / "time elapsed so far"
3. too much time was calculated - new value: ("requested deviation rRequestedDeviation" - "Deviation at the end") / "Countdown time"

The temperature change function is now corrected at the interpolation point whose outside temperature value was closest to that at the start of the pre-stop phase. The relevant point for this was saved before the start of the countdown, see program flow chart.

However, the previously calculated value ΔT/Δt is not necessarily adopted 100% as the new value at the interpolation point. In fact there is an option to mix the new value from a weighting of old and calculated value. This weighting takes place with the aid of the so-called adaptation factor rAdaptionFactor:

With an adaptation factor of 100% the newly calculated value is adopted fully, while with 0% the old value is retained.

Note: Because the pre-stop time is always changed at the nearest point, an adaptation can only take place if the outside temperature at the beginning of the pre-stop phase lies inside AT₁ to AT₁₀.

VAR_INPUT

eDataSecurityType      : E_HVACDataSecurityType;
eCtrlFct               : E_BARCtrlFct;
bEnable                : BOOL;
bSchedulerOff          : BOOL;
bWithAdaption          : BOOL;
bDisableAdaption       : BOOL;
rOutsideTemperature    : REAL;
rRoomTemperature       : REAL;
rRequestedTempDeviation: REAL;

eDataSecurityType:if eDataSecurityType:= eDataSecurityType_Persistent, the persistent VAR_IN_OUT variables of the function block are stored in the flash of the computer if a value changes. For this to work, the function block FB_HVACPersistentDataHandling must be instanced once in the main program, which is called cyclically. Otherwise the instanced FB is not released internally.

A change of value can be initiated by the building management system, a local operating device or via a write access from TwinCAT. When the computer is restarted, the saved data are automatically read back from the flash into the RAM.

Application example: Example_PERSISTENT.zip

If eDataSecurityType:= eDataSecurityType_Idle the persistently declared variables are not saved in a fail-safe manner.

eCtrlFct : eCtrlFct = eBARCtrlFct_Heating indicates to the function block that it is to be used in heating mode. Cooling mode is indicated by eCtrlFct = eBARCtrlFct_Cooling. Any other entry at this input is impermissible and leads to an error message. The two possible entries are for the different evaluation of the deviation rRequestedTempDeviation.

bEnable : a FALSE signal at this input suppresses the optimized switch-off of the connected timers. The output value of the pre-stop time is also set directly to "0". No countdown starts, nor is an adaptation carried out – the function block is reset.

bSchedulerOff : a rising edge at this input starts the internal countdown of the pre-stop time. The output bPrestopMode is set to TRUE while the countdown of a pre-stop time is running down. If the output bSchedulerOff is switched to FALSE again during the countdown, the countdown is interrupted immediately and the output bPrestopMode is set to FALSE. The countdown is also stopped and bPrestopMode set to FALSE when the room set value is reached.

bWithAdaption : if this input is set simultaneously with the input bSchedulerOff, an adaptation takes place after the expiry of the countdown. A trigger pulse together with the rising edge of bSchedulerOff is sufficient for this. This input can only be used in conjunction with bSchedulerOff; setting it alone has no effect at all.

bDisableAdaption : a TRUE signal at this input merely suppresses the adaptation that follows the countdown.

rOutsideTemperature : outside temperature in degrees Celsius.

rRoomTemperature : room temperature in degrees Celsius.

rRequestedTempDeviation : tolerated downward (heating mode) or upward (cooling mode) temperature deviation after switching off the boiler or the air conditioning system respectively until leaving the room.

VAR_OUTPUT

uiPrestopTime   : UINT;
bPrestopActive  : BOOL;
udiCountdownTime: UDINT;
bError          : BOOL;
udiErrorID      : UDINT;

uiPrestopTime : output value of the optimized pre-stop time to the timers concerned in minutes. This value is formed continuously from the pre-stop function that is dependent on the outside temperature. Conversely, if the input bDisableOptimization is set to TRUE, then this output is set to "0".

bPrestopActive : the function block is in pre-stop mode as long as the internal countdown is running and has not been ended by the expiry of the pre-stop time, by the reaching of the room temperature setpoint or by an interruption (bSchedulerOff = FALSE). This is indicated by a TRUE signal at this output.

udiCountdownTime : this output indicates the elapsing of the internal countdown in seconds. This output is set to "0" if the function block is no longer in pre-stop mode (see bPrestopMode).

bError: this output is switched to TRUE if the parameters entered are erroneous.

udiErrorId : contains the error code if the values entered should be erroneous. See error codes.

VAR_IN_OUT

The need for entered parameters to be preserved across a control failure makes it necessary for them to be declared as IN-OUT variables. A reference variable is then assigned to them in the program. Each change in the value of this reference variable is persistently saved in the function block and written back to the reference variable after a controller failure and restart. If the parameters were only declared as input variables, they would not be able to write a reference variable.
Application example: Example_PERSISTENT.zip.

uiMaxPrestopTime      : UINT;
rAdaptionFactor       : REAL;
rAdaptionTolerance    : REAL;
stTempChangeFunction  : ST_HVACTempChangeFunction;

uiMaxPrestopTime : due to the adaptation the pre-stop times are shortened and lengthened within the temperature change function. While they are logically automatically limited to 0 minutes in the downward direction, the upward limit in minutes can be defined by this input.

rAdaptionFactor : in the adaptation step the temperature change ΔT/Δt that has taken place is calculated for the nearest outside temperature interpolation point. However, this is not necessarily adopted 100% as the new value. In fact there is an option to mix the new value from a weighting of old and calculated value. The adaptation factor (in percent) thereby represents the weighting.

With an adaptation factor of 100% the newly calculated value is adopted fully, while with 0% the old value is retained.

rAdaptionTolerance : if the countdown has elapsed and the requested deviation rRequestedDeviation is exhausted, no adaptation is carried out because the pre-stop time is precisely right. The value rAdaptionTolerance defines an additional tolerance range:

stTempChangeFunction : structure variable of type ST_HVACTempChangeFunction, which contains the 10 value pairs (outside temperature, internal temperature change). These value pairs, which have to be entered in the field variable in ascending order of the outside temperature, define the 9 pitch lines of the temperature change function. Initial entry through FB_HVACTempChangeFunctionEntry.