FB_BA_FnctSel
Automatic selection of heating or cooling controller
Functional description
The function block is used for room heating/cooling controller activation as part of an air-conditioning plant. The distribution network type plays a significant role: In a two-pipe system, all rooms served by the plant can either be heated or cooled at any one time. In a four-pipe system, the room conditioning can be demand-based, i.e. some rooms can be heated, while other rooms can be cooled by the same plant.
The function block used for each room, as already mentioned, selects its controllers, depending on which type of piping system is available:
Two-pipe network
The two-pipe system is selected if the function block has a FALSE entry at input bPipeSys. Since all rooms served by the plant can only either be heated or cooled, the choice is specified centrally for all rooms via the input bMedium. If bMedium is FALSE, the room heating controller is selected. If the input is TRUE the cooling controller is selected. The controller enable states bEnHtg and bEnCol are always issued with a delay of uiChgOvrDly [s]. In other words: The heating cannot be enabled until the cooling enable state bEnCol for uiChgOvrDly is FALSE. In addition to the elapsing of this switching time, the system checks that the output from controller to be switched off is 0.0. This is based on feedback at the inputs lrCtrlValHtg and lrCtrlValCol. In this way, a drastic change from heating to cooling and vice versa is avoided.
Four-pipe network
The four-pipe system is selected if the function block has a TRUE entry at input bPipeSys. In this case, the choice of controller can be different for the individual rooms as required, based on the room temperature lrRmT and the set values lrSpHtg for heating and lrSpCol for cooling. If the room temperature exceeds the cooling setpoint, the cooling controller is activated (bEnCol), if it falls below the heating setpoint, the heating controller is activated (bEnHtg). If the temperature is between the two setpoints, both controllers are switched off (energy-neutral zone). Here too, the output of the controller enable states bEnHtg and bEnCol is delayed by uiChgOvrDly [s] (see two-pipe network). In addition to the elapsing of this switching time, the system checks that the output from controller to be switched off is 0.0. This is based on feedback at the inputs lrCtrlValHtg and lrCtrlValCol. In this way, a drastic change from heating to cooling and vice versa is avoided, if the switching time is inadequate.
Dew-point monitor (bDewPnt)
In both systems (two- and four-pipe) the dew-point monitor has the task of deactivating cooling immediately, if required. Since this is a safety function, the respective input bDewPnt is configured based on the quiescent current principle, i.e. inverted: bDewPnt = FALSE: Cooling controller is locked.
Program sequence
The function block can have 3 possible states:
- Waiting for heating or cooling enable
- Heating enable
- Cooling enable
In the first step, the function block waits for compliance with the conditions required for heating or cooling:
Heating | Cooling |
---|---|
Cooling controller output = 0 (lrCtrlValCol) | Heating controller output = 0 (lrCtrlValHtg) |
Room temperature (lrRmT) < heating setpoint (lrSpHtg) | Room temperature (lrRmT) > cooling setpoint (lrSpCol) |
Cooling controller enable (bEnCol) is FALSE over at least the switching time udiChgOvrDel [s] | Heating controller enable (bEnHtg) is FALSE over at least the switching time udiChgOvrDel [s] |
Four-pipe system is selected (bPipesys=TRUE) | Four-pipe system is selected (bPipesys=TRUE) |
| The dew point sensor (quiescent current principle) does not respond (bDewPnt=TRUE) |
If a chain of conditions is met, the function block switches to the respective state (heating or cooling) and remains in this state until the corresponding controller issues 0 at the function block input (lrCtrlValHtg/lrCtrlValCol). This ensures that only one controller is active at any one time, even if a high heating controller output, for example, would call for a brief cooling intervention (overshoot). Heating or cooling continues until there is no longer a demand.
There are 3 exceptions, for which heating or cooling is immediately interrupted:
- A two-pipe system (bPipeSys=FALSE) is in heating mode (bEnHtg), but a switch to cooling medium occurred bMedium=TRUE
- A two-pipe system (bPipeSys=FALSE) is in cooling mode (bEnCol), but a switch to heating medium occurred bMedium=FALSE
- The dew point sensor was triggered (bDewPnt=FALSE) in cooling mode (two- or four-pipe system)
In these cases the heating or cooling enable states are cancelled, and the plant switches to standby.
Demand message (udiReqdMedium)
To notify the plant of the current demand for heating or cooling, a demand ID is issued at the function block output, i.e. for each room, depending on the actual and set temperature. These can be collected and evaluated centrally. The evaluation always takes place, irrespective of the network type (two- or four-pipe).
udiReqdMedium | Medium | Room temperature |
---|---|---|
1 | No medium is requested | rTRm > SpHtg AND rRTm < SpCol |
2 | Heating medium is requested | rTRm < SpHtg |
3 | Cooling medium is requested | rTRm > SpCol |
Error handling
The heating setpoint must not be greater than or equal to the cooling setpoint, since this would result in temperature range with simultaneous heating and cooling demand. However, since the function block only issues one enable state at a time (i.e. heating or cooling), the case is harmless from a plant engineering perspective. In this case only a warning message is issued (bErr=TRUE, udiErrId=gBA_WarnIdFnctSel); the function block does not interrupt its cycle.
Inputs/outputs
VAR_INPUT
bPipeSys : BOOL;
bMedium : BOOL;
bDewPnt : BOOL;
lrRmT : LREAL;
lrSpHtg : LREAL;
lrSpCol : LREAL;
lrCtrlValHtg : LREAL;
lrCtrlValCol : LREAL;
udiChgOvrDel : UINT;
bPipeSys: in two-pipe system bPipeSys is FALSE, in four-pipe systems it is TRUE
bMedium: current supply of the whole two-pipe network with cooling or heating medium. If heating medium is active, bMedium is FALSE.
bDewPnt: dew point sensor based on quiescent current principle (negative logic): if bDewPnt = FALSE, the cooling controller is locked.
lrTRm: room temperature
lrSpHtg: heating setpoint value
lrSpCol: cooling setpoint
lrCtrlValHtg: current output value of the heating controller. Used internally as switching criterion from heating to cooling: lrCtrlValHtg must be 0.
fCtrlValCol: current output value of the cooling controller. Used internally as switching criterion from cooling to heating: lrCtrlValCol must be 0.
udiChgOvrDel: switchover delay [s] from heating to cooling or vice versa
VAR_OUTPUT
bEnHtg : BOOL;
bEnCol : BOOL;
udiReqdMedium : UDINT;
udiRemTiChgOvrDlyHtg : UDINT;
udiRemTiChgOvrDlyCol : UDINT;
bErr : BOOL;
udiErrId : UDINT;
udiErrArg : UDINT;
bEnHtg: enable of the heating controller
bEnCol: enable of the cooling controller
udiReqdMedium:
udiReqdMedium | Medium | Room temperature |
---|---|---|
1 | No medium is requested | rTRm > SpHtg AND rRTm < SpCol |
2 | Heating medium is requested | rTRm < SpHtg |
3 | Cooling medium is requested | rTRm > SpCol |
udiRemTiChgOvrDlyHtg: countdown [s] switchover delay from cooling to heating
udiRemTiChgOvrDlyCol: countdown [s] switchover delay from heating to cooling
bErr: in case of a fault, e.g. if warning states are active, this output is set to TRUE.
udiErrId / udiErrArg: contains the error number and the error argument. See error codes.
Requirements
Development environment | Target system | required library | required supplement |
---|---|---|---|
TwinCAT 2.11 R3/x64 from build 2244 | PC/CX | TcBA library from V1.0.0 | TS8040 | TwinCAT Building Automation from V1.0.0 |