Blocks: AO, BO, MO, AVAL, BVAL, MVAL

This section describes the general functional scope shared by many of the I/O blocks. Each subsection includes a list of the blocks to which that subsection applies. Any block-specific details which are not shared by other blocks are described together with the block concerned.

Priority mechanism

Basic function

In order to evaluate the various defined setpoints received from the BACnet command system and via the data flow connections, the AO, BO, MO, AVAL, BVAL and MVAL blocks each incorporate a priority array [PrioArr].

All external sources write their defined setpoint and information bit (enable signal) into this [PrioArr]. The block then evaluates these entries continuously, in order to determine the valid present value [PrVal].

The [PrioArr] holds up to 16 different entries, each consisting of a setpoint definition and the associated information bit (enable signal). The input number also indicates the priority of the entry, where 1 is the highest and 16 the lowest priority. Each priority level has a predefined meaning.

Determining [PrVal]

The block continuously evaluates the valid present value at the output [PrVal]. It selects the value that has the highest priority of those whose information bit (enable signal) is also set. If none of the information bits is set, the default value [DefVal] is processed.

Structure of the Priority Array [PrioArr]

Each priority level has a predefined meaning.

In the [PrioArr], two adjacent priority levels each are reserved for life safety, manual operation and plant operation.

  • The higher priority (lower number) of each pair is reserved for local control and monitoring, close to the plant (priority 1, 4, 7 and 15).
  • The lower priority (higher number) of each pair is reserved for higher level control and monitoring (priority 2, 5, 8 and 16).
  • Priority level 6 is specifically designed for switch-on and switch-off delays and to maintain minimum ON and OFF times.

This ensures that, e.g., an on-site EMERGENCY OFF command, initiated at the plant level, takes priority over a safety function from a higher-level subsystem.

Priority 6

Priority entry 6 is used to forward the switch commands resulting from [PrioArr] to the [PrVal] output after a delay. This enables you to implement both switch-on and switch-off delays and minimum ON and OFF times.

For this purpose, the internal block logic imports the Present value [PrVal] into the priority 6 entry. While the delay times referred to above are running, priority 6 is set to active and so takes priority over priority levels 7…16. Outside these delay times, priority 6 is always inactive.

Locating this function in the [PrioArr] between priorities 1…5 and 7…16 has the following consequences:

  • Commands with a priority level of 1…5 are always carried out immediately, irrespective of any currently active delay times.
  • Commands with a priority level of 7…16 are always overridden by any currently active delay times.

Unlike all the other entries in [PrioArr], the commands and information bit for priority 6 are generated exclusively by the BO, MO, BVAL and MVAL blocks. A priority 6 entry cannot be written from an external source.

The switch-on and switch-off delay

As soon as one of the commands with a priority of 7…16 determines the [PrVal] which will therefore cause the present state of [PrVal] to change, the entry for priority 6 is set up as follows:

If the switch-on delay [DlyOn] or switch-off delay [DlyOff] is greater than 0:

  1. Priority 6 adopts the still unchanged present value [PrVal].
  2. Priority 6 is set to active.
  3. The switch-on or switch-off delay timer starts.
  4. After expiry of [TiOnMin] or [TiOffMin], priority 6 is set to inactive.

If the delay times [DlyOn] or [DlyOff] are equal to 0, no action is taken.

If the new value which determines [PrVal] is the same as the current [PrVal], then, here too, no action is taken.

The minimum on/off time

For each change at the output [PrVal] from OFF to Stage n or from Stage n to OFF, the entry for priority 6 is set up as follows:

If the minimum ON-time [TiOnMin] or OFF-time [TiOffMin] is greater than 0:

  1. Priority 6 adopts the new present value [PrVal].
  2. Priority 6 is set to active.
  3. The timer for the minimum on-time or off-time is started.
  4. After expiry of [TiOnMin] or [TiOffMin], priority 6 is set to inactive.

If the minimum switch-times [TiOnMin] / [TiOffMin] are set to 0, no action is taken.

Constraints

  • The functions described above are supported only by the BO, MO, BVAL and MVAL blocks.
  • With multistage switch commands, the monitoring periods are enabled only when switching from OFF to Stage n or from Stage n to OFF. When switching from one stage to another (e.g., Stage 1 to Stage 2), the timer times are not enabled.
  • However, any timer times already running will continue to run.

Application

  • Unnecessary on/off switching operations can be prevented by activating minimum switch-on or switch-off times.
  • Activating switch-on or switch-off delays ensures that run-on time delays are maintained.

Information bit

In order for a given value to be included in the evaluation of [PrioArr], its information bit must be set.

The following applies to priority 1,4,7 and 15 (data flow connection): The relevant information bit is set via pins [EnSfty], [EnCrit], [EnSwi] and [EnPgm].

The following applies to priority 2, 5, 8, 14 and 16 (BACnet command system): When a given value is commanded via BACnet, the value concerned is entered in the [PrioArr] and the associated information bit is set automatically.

The following applies to priority level 6: Both the value and the information bit are handled by the block concerned.

Prio

Meaning

Use

Access via

1

Safety value (life safety)

Reserved for the initiation of safety functions (1 = highest priority).

If priority 1 or 2 becomes the determining value for [PrVal], then the value concerned is transmitted immediately to the [PrVal] output. It is not subject to the delay times defined for priority 6.

Local safety function, e.g.:

- Fire

- EMERGENCY OFF

- Service switch

- Gas alarm

- Thermal package

Data flow interconnection via pins: [ValSfty] and [EnSfty].

Normally, [ValSfty] is a constant and [EnSfty] can be enabled/disabled.

2

Higher-level safety function, e.g.:

- Smoke extraction

BACnet command system.

Access via the CMD_CTL block.

3

Not used in Desigo.

4

Critical value (plant protection)

Reserved for monitoring critical plant states.

If priority 4 or 5 becomes the determining value for [PrVal], then the value concerned is transmitted immediately to the [PrVal] output. It is not subject to the delay times defined for priority 6.

Local monitoring of critical plant states, e.g.:

- Frost protection (protection from excess cooling)

- Interlock of aggregates

- Icing protection

Data flow interconnection via pins: [ValCrit] und [EnCrit].

Normally, [ValCrit] is a constant and [EnCrit] is enabled/disabled.

5

Higher-level monitoring of critical plant states:

- Frost in ventilation system (close dampers, stop fans, switch pump on and open valve)

BACnet command system.

Access via the CMD_CTL block.

6

Minimum switch-on/off time

Prevent unnecessary switching operations.

Switch-on/off delay

Can be used to ensure that run-on delay times are implemented.

No access!

Commands are only generated internally in the block.

The timer periods [TiOnMin], [TiOffMin], [DlyOn] and [DlyOff] can be configured in blocks BO, MO, BVAL and MVAL.

7

Operating value

Reserved for manual operation.

Local manual operation, e.g.:

- Manual switch

- Mode selector switch

Data flow interconnection via pins: [ValSwi] und [EnSwi].

8

Higher-level manual operation, e.g.:

- Desigo CC

- Operating unit

- Web client

BACnet command system. Access via:

- Desigo CC

- Operating unit

- Web client

9...13

Not used in Desigo.

14

Program value

Reserved for normal plant operation with monitoring and control.

Superposed control and monitoring of the plant.

BACnet command system. Access is via blocks:

- CMD_CTL

- PWR_CTL (if control enable signal = Fixed)

15

Local control of plant.

Data flow interconnection via pins: [ValPgm] and [EnPgm].

If the program value is a controller variable, then [EnPgm] = True and [ValPgm] = controller variable.

If the program value is not a controller variable, then [EnPgm] = False.

16

Program value

Reserved for general cross-PX commands via BACnet references.

 

BACnet command system. Access via blocks:

CMD_CTL

PWR_CTL (if control enable signal is = Released)

Cross-PX via various blocks, e.g., ASCHED, BSCHED, MSCHED (name reference list).

17

Default value [DefVal]

If none of priorities 1…16 is active, then the default value [DefVal] is processed instead.

The influence of [DefVal] depends on the state of the block concerned:

Out-of-service [OoServ=False]:

[DefVal], like the values of priorities 7…16, is subject to the delay times of priority 6.

[OoServ=True]:

[DefVal] is transmitted immediately to the [PrVal] output.

BACnet command system. Access via:

- CFC

- PXM20

- Web client

Example: Effect of priorities 7...16 on [PrVal]

Prio

Use

1

Prio 7…16

Assumption: The effective switch command from priority (7…16) is Off and is set to active.

Prio 6

Assumption: Priority 6 is not active.

[PrVal]

Assumption: The [PrVal] output is set to Off.

2

Prio 7…16

The effective switch command from priority (7…16) switches from Off to Stage 2.

Prio 6

Priority 6 adopts the (still unchanged) present value [PrVal=Off] and is set to active.

At the same time, the switch-on delay [DlyOn] starts. Throughout the delay time, priority 6 remains active – the associated value remains Off.

[PrVal]

Since priority 6 overrides the effective switch command from priority (7…16), the [PrVal] output remains Off.

3

Prio 7…16

n/a

Prio 6

1. After expiry of the switch-on delay [DlyOn], priority 6 is released.

2. The effective switch command Stage 2 from priority (7…16) is transmitted to the [PrVal] output.

3. Priority 6 adopts the new value of [PrVal] and is set to activeagain. At the same time, the minimum switch-on time [TiOnMin] is started. Priority 6 remains active throughout this monitoring time.

[PrVal]

The [PrVal] output changes from Off to Stage 2.

4

Prio 7…16

n/a

Prio 6

The minimum switch-on time [TiOnMin] has expired. Priority 6 is released.

[PrVal]

When priority 6 ceases to take effect, the [PrVal] output is once again determined by the effective switch command from priority (7…16).

[PrVal] remains at Stage 2.

5

Prio 7…16

None of the information bits for priorities (7…16) is active.

The resulting switch command is therefore determined by the default value [DefVal].

Prio 6

The block starts the switch-off delay [DlyOff].

Throughout this monitoring time, priority 6 is set to active – the associated value remains at Stage 2.

[PrVal]

Since priority 6 overrides the effective switch command [DefVal], the [PrVal] output remains at Stage 2.

6

Prio 7…16

n/a

Prio 6

1. After expiry of the switch-off delay [DlyOff], priority 6 is released.

2. The effective switch command Off from [DefVal] is transmitted to [PrVal].

3. Priority 6 adopts the new value of [PrVal] and is set to activeagain. At the same time, the minimum switch-off time [TiOffMin] is started. Priority 6 remains active throughout this monitoring time.

[PrVal]

The [PrVal] output changes from Stage 2 to Off.

7

Prio 7…16

n/a

Prio 6

The minimum switch-off time [TiOffMin] has expired. Priority 6 is released.

[PrVal]

Since neither priority 6 nor any of the information bits for priority entries (7…16) is active, the effective switch command is determined by [DefVal].

The output value [PrVal] remains at Off.

8

Prio 7…16

At least one of the information bits for priorities (7…16) is active again.

The effective switch command from priority (7…16) is Stage 1.

Prio 6

Priority 6 adopts the (still unchanged) present value [PrVal=Off] and is set to active.
At the same time, the switch-on delay [DlyOn] starts. Throughout the delay time, priority 6 remains active – the associated value remains Off.

[PrVal]

Since priority 6 overrides the effective switch command from priority (7…16), the [PrVal] output remains Off.

9

Prio 7…16

n/a

Prio 6

1. After expiry of the switch-on delay [DlyOn], priority 6 is released.

2. The effective switch command Stage 1 from priority (7…16) is transmitted to the [PrVal] output.

3. Priority 6 adopts the new value of [PrVal] and is set to activeagain. At the same time, the minimum switch-on time [TiOnMin] is started. Priority 6 remains active throughout this monitoring time.

[PrVal]

The [PrVal] output changes from Off to Stage 1.

10

Prio 7…16

The effective switch command from priority (7…16) switches from Stage 1 to Stage 2.

Prio 6

The minimum switch-on time [TiOnMin] is still active.

Changeover from Stage m to Stage n.

With multistage switch commands, the monitoring periods are enabled only when switching from OFF to Stage n or from Stage n to OFF. When switching from one stage to another (e.g., Stage 1 to Stage 2), the monitoring periods are not enabled. However, monitoring periods which have already started remain active –priority 6 adopts the new target value.

[PrVal]

A change from Stage 1 to Stage 2 would not activate priority 6.

However, since the minimum switch-on time [TiOnMin] is still active, priority 6 still overrides the effective switch command from priority (7…16).

The [PrVal] output changes from Stage 1 to Stage 2.

11

Prio 7…16

n/a

Prio 6

The minimum switch-on time [TiOnMin] has expired. Priority 6 is released.

[PrVal]

When priority 6 ceases to take effect, the [PrVal] output is once again determined by the effective switch command from priority (7…16).

The [PrVal] output remains at Stage 2.

Example: Effect of priorities 1...5 on [PrVal]

Prio

Use

1

Prio 1…5

Assumption: All information bits for priorities 1…5 are inactive.

Prio 6

Assumption: Priority 6 is not active.

[PrVal]

Assumption: The [PrVal] output is set to Off.

2

Prio 1…5

At least one of the information bits for priorities (1…5) is active again. The effective switch command from priority (1…5) is Off.

Prio 6

Since the effective switch command for priority (1...5) does not cause a change in the [PrVal] output, priority 6 remains inactive.

[PrVal]

The output value [PrVal] remains at Off.

3

Prio 1…5

The effective switch command from priority (1…5) switches from Off to Stage 1.

Prio 6

Priority 6 adopts the new present value [PrVal=Stage 1] and is set to active. At the same time, the minimum switch-on time [TiOnMin] starts without waiting for the delay time [DlyOn].

Note:Entries for priorities (1…5) initialize only the minimum switch-on or switch-off times [TiOnMin] and [TiOffMin] respectively, but not the switch-on and switch-off delays.

[TiOnMin] and [TiOffMin] times for which the timer has already started only take effect when all priorities (1…5) are inactive, that is, when the [PrVal] will be determined by one of priorities (7…16).

[PrVal]

Priorities 1…5 are reserved to implement safety functions, and are carried out immediately, irrespective of any priority 6 monitoring periods which may already be running.

The [PrVal] output is switched immediately from Off to Stage 1.

4

Prio 1…5

None of the information bits for priority entries (1…5) is active.

Prio 6

The minimum switch-on time [TiOnMin] is still active. Priority 6 adopts the new target value from priority (7…16).

[PrVal]

The effective switch command is determined from priority 6.

The [PrVal] output changes from Stage 1to Stage 2.

5

Prio 1…5

n/a

Prio 6

The minimum switch-on time [TiOnMin] has expired. Priority 6 is released.

[PrVal]

Since neither priority 6 nor any entries for priorities (1…5) are active, the output [PrVal] is now again determined by the effective switch command from priorities (7…16).

The [PrVal] output remains at Stage 2.

Note:Switching from Stage 1 to Stage 2 does not re-start the minimum switch-on time [TiOnMin].

6

Prio 1…5

Assumption: All information bits for priorities 1…5 are inactive.

Prio 6

Assumption: Priority 6 is not active.

[PrVal]

Assumption: The [PrVal] output is set to Off.

7

Prio 1…5

At least one of the information bits for priorities (1…5) is active again. The effective switch command from priority (1…5) is Off.

Prio 6

Since the effective switch command for priority (1...5) does not cause a change in the [PrVal] output, priority 6 remains inactive.

[PrVal]

The output value [PrVal] remains at Off.

8

Prio 1…5

The effective switch command from priority (1…5) switches from Off to Stage 2.

Prio 6

Priority 6 adopts the new present value, [PrVal=Stage 2] and is set to active. At the same time, the minimum switch-on time [TiOnMin] starts without waiting for the delay time [DlyOn].

Note:Entries for priorities (1…5) initialize only the minimum switch-on or switch-off times [TiOnMin] and [TiOffMin] respectively, but not the switch-on and switch-off delays.

[TiOnMin] and [TiOffMin] times for which the timer is already running only take effect when all priorities (1…5) are inactive, that is, when the [PrVal] will be determined by one of priorities (7…16).

[PrVal]

Priorities 1…5 are reserved to implement safety functions, and are carried out immediately, irrespective of the switch state and of any priority 6 monitoring periods which may already be running.

The [PrVal] output is switched immediately from Off to Stage 2.

9

Prio 1…5

The effective switch command from priority (1…5) switches from Stage 2 to Off.

Prio 6

Priority 6 adopts the new present value [PrVal=Off].

The still-running minimum switch-on time [TiOnMin] is cancelled.
The block re-starts the minimum switch-off time [TiOffMin].

[PrVal]

Priorities 1…5 are reserved to implement safety functions, and are carried out immediately, irrespective of the switch state and of any priority 6 monitoring periods which may already be running.

The [PrVal] output is switched immediately from Stage 2 to Off.

10

Prio 1…5

All information bits for priorities 1…5 are inactive.

Prio 6

The minimum switch-off time [TiOffMin] is still active.

[PrVal]

The effective switch command is determined from priority 6.

The output value [PrVal] remains at Off.

11

Prio 1…5

n/a

Prio 6

The minimum switch-off time [TiOffMin] has expired. Priority 6 is released.

[PrVal]

Since neither priority 6 nor any entries for priorities (1…5) are active, the output [PrVal] is now again determined by the effective switch command from priorities (7…16).

The output value [PrVal] remains at Off.

Switch types [SwiKind]

Blocks: BO, MO, BVAL, MVAL

All switching I/O blocks have a configurable switching response. The switching response determines the functioning of the block. The switching functions are subject to the priority mechanism in the [PrioArr] and the switch command delay.

  • Normal: Direct switching in stages taking into account runtimes (e.g., motors, burners, dampers, etc.).
  • Motor: Switching in stages for rotating aggregates taking into account ramp-up and ramp-down times (fan-belt protection).
  • Trigger: Event-driven switching, last command takes precedence; integration of a data point (EIB, LONMARK)
  • Switch: Generation of an ON/OFF pulse of a defined duration.
  • Push button with delay: Generation of an ON/OFF pulse of a defined duration. The pulse can be extended whenever required.
  • Release (Release Command): Issuance of a subsystem-specific release value instead of Present_Value (=Relinquish_Default), if no priority is active in the output object.

[SwiKind]

BO

MO

BVal

MVal

Normal

Motor

 

 

 

Trigger

 

 

Switch

 

 

Pushbutton with delay

 

 

Release

 

 

 

Normal

Normal handling of the process values in the [PrioArr]. The configured runtimes are active. The outputs can be switched directly or in stages.

Motor

The Motor setting is used when there is a need to allow for ramp-up and ramp-down times due to a rotating centrifugal mass. The programmed times in this setting can be used, e.g., to avoid overloading the fan belt when starting a fan motor.

When the motor is switched down, the system checks on the basis of the ramp-up time whether or not the current motor speed has been reached. The switch-down command is not carried out until the motor speed is stable. During the ramp-down period, the effective command to the hardware is Off. When the ramp-down time has elapsed, the new command is transmitted to the hardware.

Trigger

In the Trigger setting, the source of the last command takes precedence. The valid value is written from the [PrioArr] to the [DefVal] and transmitted to the output. The priority is then released again.

In this setting, Priorities 7…16 are treated equally; Priorities 1…5 have a blocking effect.

The trigger function is used, e.g., for the integration of LON data points. Owing to the event mechanism, this function is not used for P-bus objects.

Switch

The Switch setting is used to generate an ON or OFF pulse of a predefined duration. A command via BACnet, or the activation of an Enable signal in one of Priorities 7…16 via the data flow connection initiates an associated pulse (event). The minimum switch-on time [TiOnMin] and/or minimum switch-off time [TiOffMin] must be set. Setting both times can prevent fast switching operations. Priorities 1…5 have a blocking effect.

Pushbutton with delay (time extension)

The Pushbutton with delay function is like the Switch function, except an active pulse can be extended by another pulse at any time.

Runtimes and monitoring periods

The I/O function blocks are designed for the runtimes and monitoring periods required in HVAC engineering, and can therefore be used directly as components (motors, dampers, fans, etc.).

Different runtimes and monitoring periods can be set, depending on the function concerned.

Runtimes:

  • Switch-on/off delay
  • Minimum switch-on/off time
  • Ramp-up/-down time

Monitoring periods:

  • Feedback time with switch-on/off
  • Feedback signal deviation during operation

Runtimes

Switch-on/off delay

Blocks: BO, MO, BVAL, MVAL

The switch-on/off delay when applied to the switching I/O blocks causes a delayed output if the switch command was written via Priority 7…16. The delay time affects Priority 6 as described. Switch commands via Priorities 1…5 are carried out without a delay.

Minimum switch-on/off time

When applied to the switching I/O blocks, the minimum switch-on/switch-off time causes the output to be blocked for a period of time if the switch command was written via Priority 7…16. The minimum switch-on/off time affects Priority 6 as already described in Section 24.2.1.3. However, switch commands via Priorities 1…5 are carried out immediately irrespective of the minimum switch-on/off time.

Ramp-up/down time

The ramp-up/down times (run-up/-down times) can be defined in a table for each stage. These times apply to the two switch types [SwiKind] Normal and Motor.

The ramp-up time is the time taken by a motor when changing from a lower speed to the next higher speed, to reach the new speed. This limits the current consumption of the motor.

The ramp-down time is the time taken by the motor when switching down from a higher speed, to reach the lower speed. This prevents feedback to the mains supply network and protects the fan belt and the motor.

As a rule, the ramp-up and ramp-down times depend on the centrifugal mass involved, and must be determined separately for each project.

Especially with single-speed motors, the times can be used as Open/Close runtimes (e.g., damper actuator from 0…100%). A moving damper can thus be mapped in the system and the transition signal can, if required, be used for control purposes.

Monitoring periods

Feedback monitoring / process value monitoring

Blocks: BI, MI, BO, MO, BVAL, MVAL

The I/O objects have a monitoring function. The output objects monitor the feedback signal from the plant. For this purpose, an address string must be entered for the [FbAddr] feedback parameter [FbAddr] and the alarm function must be enabled.

The input and value objects can monitor reference values. For this purpose, the relevant reference values must be configured and the alarm function must be enabled.

Deviation monitoring

If the feedback value deviates from the output value [PrVal], a deviation alarm is generated after a configurable time period, and the block status changes to In Alarm. When the two values match again, and the configured time period has expired, the alarm and status are reset. There is otherwise no automatic block reaction, that is, if a switch response in the plant is required as a reaction to this alarm, this response must be programmed in CFC via the Disturbance output [Dstb].

Switch-on/off feedback monitoring

It is also possible to configure the time period during which the maximum deviation of the feedback signal may occur after a switch-on/off operation. If the deviation persists after the monitoring time has expired, an alarm is generated and the status of the block changes to In alarm. When the two values match again, and the configured time period has expired, the alarm and status are reset. There is otherwise no automatic block reaction, that is, if a switch response in the plant is required as a reaction to this alarm, this response must be programmed in CFC via the Disturbance output [Dstb].

No feedback monitoring

If no feedback monitoring is required, and the address string is left blank, the monitoring periods are used by the block for the internal generation of the transient state [TraSta]. This means that the transient state signal for the switch-on/off operation is set for the preset period of time. This is how a moving actuator, e.g., a damper, is displayed in the system.

Limit monitoring

Blocks: AI, AO, AVAL

In the case of the analog I/O blocks, the present value [PrVal] can be monitored for a high/low limit. If the alarm monitoring feature is enabled, a deviation alarm is generated after a configurable time period, and the block status changes to In Alarm. When the present value is within the limits again and the configured time period has expired, the alarm and status are reset. There is otherwise no automatic block reaction, that is, if a switch response in the plant is required as a reaction to this alarm, this response must be programmed in Xworks Plus (XWP) via the disturbance output [Dstb].

Override via client

The input, output and value blocks can be overridden via BACnet clients or in XWP (CFC) in online test mode.

User override of an input value

There are two options:

1. Override via a BACnet client:

A BACnet client is overridden with a BACnet service.

Input objects are overridden by setting the out-of-service parameter [OoServ] and writing the desired present value [PrVal]. The default value [DefVal] is automatically set to the same value as [PrVal]. (You can also overwrite [DefVal], in which case [PrVal] is automatically used instead).

There is no need to follow these rules when using the PXM20 to override a value, as the operator unit observes them automatically.

Overridden input objects are not reset automatically. To do this, reset [OoServ] first. [DefVal] remains at the last overridden value and [PrVal] is again derived from the physical input.

2. Override via online test mode in CFC:

Overrides with CFC are carried out via a proprietary service.

Outputs of a block cannot be overwritten.

To overwrite [PrVal] the out of service state in [OoServ] must be set to TRUE, after which the default value [DefVal] can be modified. This value is then adopted (or applied) as the present value and is made available under [PrVal].

User override of an output value

There are two options:

1. Override via a BACnet client:

The override of an output or value object is based on the priority array [PrioArr] in the object. Priority 8 is reserved for the operator, that is, an override from the PXM20 and Web client is written to the Priority 8 entry. Other BACnet clients can write to other priority entries.

The value (Value or Null) is stored in the [PrioArr]. After processing in the object, the value, other than NULL, with the highest priority is transmitted to [PrVal]. If there is no active priority, the [DefVal] is transmitted.

2. Override via the online test mode in Xworks Plus (XWP):

[PrVal] is an output and can therefore not be modified. In this case the value under [EnOp] must first be set, after which the modifiable value under [ValOp] is written to Priority 8 in [PrioArr]. After processing in the object, the value, other than NULL, with the highest priority is then transmitted to [PrVal]. If there is no active priority, the [DefVal] is transmitted.

Runtime totals

Runtime totalization can be implemented in the binary input, binary output and multistate input and output blocks (BI, BO, MI and MO). Part of the overall range of functions is defined by the BACnet standard. In order to provide the complete range of runtime totalizing functions required in the field of building automation and control, certain proprietary enhancements have been added here.

Function

With a binary input object, the operating hours are determined on the basis of the ON state of [PrVal] (that is, by measuring the time for which this value is active). For multistate blocks, you can configure how many states are to be totalized. These are combined and added in a totalizer (the various states cannot be evaluated individually). In contrast to the input object, the output objects of the ON state for [FbVal] is logged (not [PrVal]) to operating hours message of the output objects.

There are two separate totalizers for runtime totalization:

  • Runtime totalizer
  • Overall runtime totalizer

Release

Runtime totalization can be enabled via the [EnOph] pin (Enable operating hours count). This is a binary value for binary objects, for multistate objects a list of values released for counting.

Runtime totalizer

Maintenance messages (events) are generated via the runtime totalizers. These are typically reset when the maintenance has been carried out. The present operating hours [PrOph] output can be used to connect the runtime totalization feature for further use in the program (e.g., for changeover of pumps or boilers based on operating hours).

Resetting the runtime total

The operating hours [Oph] input is used to reset the current runtime total. In online test mode in Xworks Plus (XWP) via a BACnet client the present value can be reset by overwriting it with a new value (usually 0). This reset does not affect the total operating hours count (pins [OphTot] and [PrOphTot], total operating hours and present total operating hours respectively).

Overall runtime totalizer

The total operating hours count records the total hours run by an aggregate. It is only reset when the aggregate is replaced. The [PrOphTot] output is available for further interconnection in the program.

Resetting the operating hours total

The [OphTot] input is used to reset the total operating hours. In online test mode in Xworks Plus (XWP) or via a BACnet client, the present value can be reset by overwriting it with a new value (usually 0). This reset procedure simultaneously sets the runtime totalizer (pins [Oph] and [PrOph]) to the same value.

This is necessary, e.g., for an aggregate which is installed as a replacement item, but which has previously been in operation elsewhere for some time.

Maintenance message

A maintenance message (event) can be generated either after a specified period of operation or on a specified date. The operating hours limit value and the maintenance date [OphLm]/[MntnDate] can be configured for this purpose. An event message is generated when the limit value is exceeded or at 13:00 hours on the preset date. At the same time, the binary output [MntnInd] (maintenance indication) is set to active for further use in the program. After the operating hours reset, this output reverts to inactive. At the same time, the time stamp of the last reset is stored in the time stamp operating hours reset pin [TiStmOph].

Feedback value

The following applies to output blocks: When a feedback is configured, operating hours count is done based on the feedback value and not based on present value.

The maintenance interval can be further connected via the output present total operating hours limit [PrOphLm].

Value range for run time totalizing

The hours run are registered in 32-bit format, giving a maximum value of 4,294,967,296. With a resolution in seconds, this gives a value range of over 49,000 days (more than 136 years).

Out of Service [OoServ]

The physical input/output is disconnected from the I/O block via the out-of-service pin [OoServ]. This out of service function is normally used in cases where a hardware module is faulty or temporarily not required, e.g., sensor not connected or faulty. This is a way of suppressing reliability problems and the associated FAULT alarms.

Input block

If the out-of-service property of an input block is set [OoServ=True], the physical input is disconnected from the present value ([PrVal] = [DefVal]) and any changes in the physical input will not be transmitted to [PrVal]. Furthermore the reliability [Rlb] and status flag [StaFlg] are also disconnected from the physical input. In this state, the properties [PrVal] and [Rlb] can be modified for test purposes.

Output block

If the out-of-service property for an output block is set [OoServ=TRUE], the physical output is disconnected from [PrVal]. Changes in [PrVal] will not be transmitted to the physical output, which retains its last value. Furthermore, the reliability [Rlb] and status flag [StaFlg] are also disconnected from the physical output. In this state, [PrVal] and [Rlb] can be modified for test purposes. Other functions that depend on these properties are not dependent on the [OoServ] property. The [PrVal] is set in accordance with the priority array [PrioArr], but the value is not transmitted to the physical output.

Alarm and event functions

Each input, output and value block can be enabled and disabled as an alarm source. The blocks are configured by setting the relevant values at the block pins. See Alarm Strategy.

Reliability [Rlb]

The reliability of the present value and of the physical input/output is represented by the reliability pin [Rlb]. This makes it possible to detect and signal faults and errors, such as addressing errors, sensor problems (short-circuit or open circuit) and module faults (missing or incorrect modules). See Reliability Table.

Commissioning State [ComgSta]

The state of the I/O can be entered at [ComgSta], the commissioning state pin, in the commissioning phase. The setting does not affect the program; it merely serves as a kind of notepad for commissioning purposes.

The following states are available for selection:

  • Checked
  • Not Checked [DefVal]
  • Periphery Defect or Missing
  • Cable Defect or Missing
  • I/O Defect or Missing

As these states are static, they must be set manually during commissioning.

Status Flag [StaFlg]

The status flag [StaFlg] indicates the state of the I/O block. This pin consists of four Boolean values:

  • IN_ALARM: Logic 1 (TRUE) if the event state pin [EvtSta] does not display NORMAL as its value.
  • FAULT: Logic 1 (TRUE) if the [Rlb] pin does NOT display the value NO_FAULT_DETECTED.
  • OVERRIDDEN: Logic 1 (TRUE) if the block point was overridden locally (e.g., manual switch on I/O module). If this flag is set, [PrVal] and [Rlb] will no longer display any changes in the physical input/output.
  • OUT_OF_SERVICE: Logic 1 (TRUE) if the out-of-service pin [OoServ] is active.

Default Value [DefVal]

For an input block, [DefVal] is transmitted to [PrVal] when [OoServ] is set to TRUE.

For an output block, value [DefVal] is transmitted to [PrVal] when none of the priorities (1…16) is active.