General functions - Basic Documentation - DXR2.E09-101A - DXR2.E09-101A/BP - DXR2.E09-101A/TB - DXR2.E09-301A - DXR2.E09T-101A - DXR2.E09T-101A/BP - DXR2.E09T-301A - DXR2.E10-101A - DXR2.E10-101A/BP - DXR2.E10-301A - DXR2.E12P-102A - DXR2.E12P-102A/BP - DXR2.E12P-102B - DXR2.E12P-102K - DXR2.E12P-302A - DXR2.E12PX-102A - DXR2.E12PX-102B - DXR2.E12PX-102K - DXR2.E18-101A - DXR2.E18-101A/BP - DXR2.E18-101B - DXR2.E18-101K - DXR2.E18-102A - DXR2.E18-102A/BP - DXR2.E18-301A - DXR2.M09-101A - DXR2.M09-301A - DXR2.M09T-101A - DXR2.M09T-301A - DXR2.M10-101A - DXR2.M10-301A - DXR2.M11-101A - DXR2.M11-101B - DXR2.M11-101K - DXR2.M11-301A - DXR2.M12P-102A - DXR2.M12P-102B - DXR2.M12P-102B-GDE - DXR2.M12P-102K - DXR2.M12P-302A - DXR2.M12PX-102A - DXR2.M12PX-102B - DXR2.M12PX-102K - DXR2.M18-101A - DXR2.M18-101B - DXR2.M18-101K - DXR2.M18-102A - DXR2.M18-301A - DXR2.T12P-102B - DXR2.T18-101B - PXC

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.

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

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

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.

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.