Hardware independence

Logical I/O blocks allow the standardization of the inputs and outputs irrespective of the hardware. The relationship between a given logical I/O and its physical equivalent is established by assigning the address of the I/O system concerned.

This independence has the advantage that the functions of the block, as defined by the BACnet standard and the specific Desigo PX enhancements, do not change. The number of different I/O systems or physical I/Os can be expanded freely.

Identical compound libraries

Another advantage is that the compound libraries are always identical. In the engineering phase, they are adapted to the I/Os in the project by assigning the appropriate addresses. The process values (0…10V, 0…25mA, signal contacts, etc.) from the connected field devices are registered directly at the physical inputs. The physical outputs deliver the process values (0…10V, switching stages 0 / I /II / III, etc.) directly to the connected field devices.

The process values are transmitted in the form of raw data via the relevant medium (e.g., PPS2); the conversion of the raw value takes place within the block.

Rules:

  • Values from the plant are measured and processed in Input blocks (Analog, Binary or Multistate).
  • Values to the plant are processed and transmitted by Output blocks (Analog, Binary or Multistate).

I/O systems

To enable the process value of the logical I/O block to be allocated to the appropriate physical I/O, the relevant address must be assigned. The address is assigned as follows:

  • Via automated assignment by the Point Configurator to the CFC
  • Direct allocation to the I/O block in Xworks Plus (XWP)

The logical I/O blocks are designed for universal use in various I/O systems. The specific address structures and hardware definitions are determined by the I/O system, e.g., the failsafe control value for the island bus.

In Desigo, they are as follows:

  • Physical I/Os
  • Values in a Desigo room unit, accessible via the PPS2 interface
  • Data in the same or in another automation station, referenced by its Technical Designation and accessed without a connection, peer-to-peer via BACnet services.

Address prefix

The addressing syntax indicates the origin of the raw value. The syntax must correlate with the actual physical inputs.

The prefixes for the various subsystems are as follows:

  • "T=" for TX-I/O modules on an island bus-capable automation station PXC....D
  • "C=" for on-board I/Os of the Desigo PX compact automation stations
  • "B=" for referencing to BACnet objects
  • "Q=" for QAX room units
  • "L=" for LonWorks addressing
  • "M=" for PX-OPEN addressing
  • "D=" for PX Open Diagnostic Addressing

For addressing with "P=", see Addressing Entries for PXC…-U, PTM and P-Bus.

For addressing with "S=", "M=" and "D=", see the corresponding expert documentation.

For more information on TX-I/O, see TX-I/O Assortment overview (CM2N8170) and TX-I/O Functions and operation (CM110561).

Addressing entries PX Modular (PXC100/200..D)

For PX compact, the TX-I/O module at the [IOAddr] pin start with a "T" (prefix: "T=").

Address syntax:

T= Module.I/O point (signal type)

Example: T=2.1 (Y10S)

The parameters no longer appear in the I/O address string for direct island bus integration, but rather in the IOC (I/O configuration).

The only exception is the Info LED which must have the prefix "C=", because the fixed address, 8.1, which is used for the Info LED may also be used by an I/O module.

The Info LED for PX KNX and PX Open can also be addressed with C=8.1.

Required address entries when using the modular series automation station in conjunction with TX-I/O-I/O modules

Signal types shown in italics are used to map virtual modules for use with TX OPEN at module level. Signal types AIS, AOS, DIS and DOS deliver a 16 bit value with status information, while signal types AISL, AOSL, DISL and DOSL deliver a 32 bit value with status information. All other signal types deliver a 16/32 bit value without status information.

While all the module types listed may be connected to any island bus addresses, not all module types have 16 points.

Type

Module addressing

I/O point

Desigo TX-I/O

1...120

1...16

PX Info LED

8

1

Module type

Signal type

Example

Analog Input

R1K, P1K, P100, U10, I25, I420
R2500, R250 (only TX-I/O)

T1, NTC10K, NTC100K (only TX-I/O)

T=1.1 (R1K)

AI, AIS, AIL, AISL

T=2.1 (AIS)

Analog Output

Y10S

T=2.1 (Y10S)

Y250T

PWM

T=3.1 (Y250T)

Y420

AO, AOS, AOSL, AOL

T=34.1 (Y420)

T=36.1 (AOS)

Binary Input

D20, D20S

D42, D250 (only PT-I/O)

T=25.2 (D20)

DI, DIS, DIL, DISL

T=26.3 (DIS)

Counter Input

C

T=38.1 (C)

Info LED

Q_LED

C=8.1(Q_LED)

Binary Output

Q250_P, Q250A_P

T=12.1 (Q250_P)

Q250

QD, Q250B, (only PT-I/O)

T=1.1 (250)

T=14.1 (Q250) + T =15.1(D20)

DO, DOS, DOL, DOSL

T=15.2 (DOS)

Multistate Input

D20

D42, D250 (only PT-I/O)

T=1.1 (D20) + T=1.2 (D20)

--

DI, DIS, DIL, DISL

T=7.1 (DIS)

Multistate Output

Q250-P1 ... Q-P5

T=1.1 (Q250-P3)

Q-M1 ... Q-M4

QD-M2 (only PT-I/O)

T=1.1 (Q-M3)

--

DO, DOS, DOL, DOSL

T=26.3 (DIS)

Parameter values

Parameters are entered in the I/O address editor.

See Automation stations modular series PXC..D, PXC..-E.D, PXA40.. (CM1N9222).

Addressing entries PX Compact (PXC…)

The addressing procedure is almost identical for Desigo PX compact and for Desigo PX modular. However, the valid address ranges and signal types are not the same as those used for the addressing of individual TX-I/O modules.

For PX compact, the "on-board" I/O modules at the [IOAddr] pin start with a "C" (prefix: "C="). Address syntax:

C=Module.Channel (signal type, parameter)

Example: C=2.1 (Y10S, NO)

The table below shows the available address ranges and signal types, which vary according to the Desigo PX compact automation station (each with its own integrated, fixed configuration of I/Os) type.

The existing UI and AO can be configured as AI, DI, CI, or AO.

Signal type of no application is loaded (wiring test):

PXC12..D, U1…U4: xx = Y10S, U5…U8: xx = R1K

PXC22..D, U1…U4: xx = Y10S, U5…U16: xx = R1K

PXC36..D, U1…U6: xx = Y10S, U7…U24: xx = R1K

Addressing entries PX compact

PX compact

PXC12.D

PXC12-E.D

PXC22.D

PXC22-E.D

PXC36.D

PXC36-E.D

Signal type

 

Module

Channel

Module

Channel

Module

Channel

 

UIO

Universal I/O

1

1..4

U5..U8

1

1..12

U5..U16

1

1..18

U7..U24

R1K, U10, T1, N1K, P1K, C, D20, D20S

UIO

Universal I/O with Q250

4

1..4

U1..U4

4

1..4

U1..U4

4

1..4

U1..U6

R1K, U10, T1, N1K, P1K, C, D20, D20S, Q250

Layout of PXC36.D housing with address ranges

See Automation stations, compact model PXC..D (CM1N9215).

Multiple use of sensors

Multiple use of I/O signals

Multiple use by addressing the physical I/Os in two or more logical I/O blocks (as shown in the following figure) is not allowed.

If you wire it as in the figure above, Xworks Plus (XWP) determines multiple use and generates an error message.

For the multiple use of output blocks, the plant will malfunction, because there will then be two or more sources acting on one switching command. The effective switching command (at the output) is the last one received (determined by the rule "the last command takes precedence"). In other words, the order of processing determines which source or origin will be linked to the output.

In CFC the same address can be allocated to two or more input or output blocks. This multiple address allocation goes undetected when the program is compiled; the automation station also fails to recognize the error (a reliability error is generated and an error message is transmitted only in the case of multiple address allocation with two different signal types).

Solution 1

Many systems include a requirement for the multiple use of sensors. A typical example of this is an outdoor air temperature sensor shared across systems. The following example illustrates the simplest form of the multiple use of sensors:

In CFC the current value is transmitted for further use in the program by interconnecting the blocks. The logical I/O block (Analog Input, {AI}) occurs in the program once only, and its hardware-specific parameters only need to be set once.

Solution 2

The multiple use function can be implemented with a BACnet reference to the first analog input block (Partial plant 1). In other words, the first block will receive the island bus address at the [IOAddr] pin. The second analog input block (Partial plant 2) references the first AI (B=…) via the technical designation.

Addressing multistate I/Os

Multistate input

The multistate value is made up of several separate binary measured values.

Addressing is via the input/output address [IOAddr]. In both the modular and the compact series, the logical and physical I/O must be "located" in the same automation station, but they do not need to be contiguous (e.g., C=5.1;5.3;5.5;5.6(Q250) is valid). The addressing cannot extend across automation stations. The addresses must be on the same module for TX-I/O.

For information about adressing multistate I/Os with PTM, see Addressing Multistate I/Os with PTM.

Simple mapping

Syntax: T=Module.I/O point;Module.I/O point;Module.I/O point;Module.I/O point

Examples:

  • T=1.1
  • T=1.1;1.2
  • T=1.1;1.2;1.3
  • T=1.1;1.2;1.3;1.4
  • T=10.3

Up to four binary status values (e.g., Off/St1/St2/St3/St4) can be registered. The signals to be registered, which are addressed via Module.Channel, must always be of the same hardware signal type. With the simple mapping procedure, to enable the multistate input to interpret the current binary signals correctly, only one binary signal may be present at any one time. If several binary signals are present at once, this is displayed as an error at the [Rlb] pin.

The examples below show a possible application for multistate input blocks in conjunction with the physical I/O modules. The example on the left of the diagram is a multiple I/O module, while the one on the right shows the mapping of several individual I/O modules in one multistate input block.

Multistate output

The multistate value from the program is converted in the Multistate Output block into a switching command. Addressing is via [IOAddr]. For PX modular, the syntax is as follows:

Syntax: T=Module.channel

Examples:

  • Q-M1: T=1.1
  • Q-M2: T=1.1
  • Q-M3: T=1.1
  • Q-M4: T=1.1
  • Q250-P3: T=10.1
  • DOS: T=24.7

Values with up to four stages can be processed. The signals to be registered, which are addressed via Module.Channel, must always be of the same hardware signal type. In the case of a multistate output on the hardware side, there is one address only (this is only possible with PXC modular automation stations).

Error handling

If an automation station does not support a given address (e.g., incorrect syntax) or a given I/O system, this will lead to a reliability error, which will be displayed at the [Rlb] pin.

Advanced mapping (Multistate Input)

The manual switch can be encoded on the PX Compact in various ways, e.g.:

  • (Auto/Off/On) or (Off/Auto/On)
  • (Auto/Off/S1/S2) or (Off/Auto/S1/S2)

So avoid having to keep adapting the data types and text groups in the system, the manual switch must always be represented in the same way within the system:

  • (Auto/Off/On)
  • (Auto/Off/S1/S2)

A prerequisite for this approach is that it must be possible in the multistate input block to configure the hardware coding and mapping to the standardized manual switch. This is made possible with parameters in the address.

1_n-Mapping (Multistate Input and Output)

Syntax:

T = Module.channel

C=Module.channel;Module.channel;Module.channel;Module.channel (signal type, a,b,c,d,e)

a represents [PrVal] for HW-I/O (0,0,0,0)

b represents [PrVal] for HW-I/O (1,0,0,0)

c represents [PrVal] for HW-I/O (0,1,0,0)

d represents [PrVal] for HW-I/O (0,0,1,0)

e represents [PrVal] for HW-I/O (0,0,0,1)

Example: T=2.1

For the TX I/O addressing no additional information in the address string is added. All information (signal type, mapping table, mapping rules, e.g., up-down, etc.) is configured in the I/O Address Editor and loaded in the automation station with the IOC file.

Example: C=2.1;2.2;2.3;2.4 (D20, 2, 1, 3, 4, 5)

[PrVal]

Addr1

Addr2

Addr3

Addr4

Comment / Text group

2

0

0

0

0

Off

1

1

0

0

0

Auto

3

0

1

0

0

Stage 1

4

0

0

1

0

Stage 2

5

0

0

0

1

Stage 3

Example: C=2.1;2.2;2.3;2.4 (D20, 2, 1, 5, 7, 9) ;-- with holes

[PrVal]

Addr1

Addr2

Addr3

Addr4

Comment / Text group

2

0

0

0

0

On

1

1

0

0

0

Off

5

0

1

0

0

Comfort

7

0

0

1

0

Eco

9

0

0

0

1

StandBy

UpDown Mapping (Multistate Input and Output)

Syntax:

Application: Connecting/disconnecting further stages.

Example: Electric heating registers, multi-stage burners.

T=Module I/O point

C=Module.channel;Module.channel;Module.channel;Module.channel (signal type, UPDOWN)

Example: T=2.1

For the TX I/O addressing no additional information in the address string is added. All information (signal type, mapping table, mapping rules, e.g., up-down, etc.) is configured in the I/O Address Editor and loaded in the automation station with the IOC file.

Example: C=5.1;5.2;5.3;5.4(Q250,UPDOWN)

Example: C=2.1;2.2;2.3;2.4(D20,UPDOWN)

[PrVal]

Addr1

Addr2

Addr3

Addr4

Comment / Text group

1

0

0

0

0

Off

2

1

0

0

0

Stage 1

3

1

1

0

0

Stage 2

4

1

1

1

0

Stage 3

5

1

1

1

1

Stage 4

With Up/Down mapping, more than one hardware input or output may be active.

Binary Mapping (Multistate Input and Output)

Application: Output of an integer in binary form.

Example: Binary electric heating coil.

Syntax: C=Module.channel;Module.channel;Module.channel;Module.channel (signal type, BINARY)

Example: C=5.1;5.2;5.3;5.4(Q250,BINARY)

Example: C=2.1;2.2;2.3;2.4(D20,BINARY)

[PrVal]

Addr1

Addr2

Addr3

Addr4

Comment / Text group

1

0

0

0

0

Off

2

1

0

0

0

Stage 1

3

0

1

0

0

Stage 2

4

1

1

0

0

Stage 3

5

0

0

1

0

Stage 4

6

1

0

1

0

Stage 5

...

 

 

 

 

 

16

1

1

1

1

Stage 15

With binary mapping, more than one hardware input or output may be active.

BACnet addressing

Peer-to-peer communication

Data can be exchanged via peer-to-peer communication.

The exchange takes place using the BACnet services defined in the BACnet standard. The process employs mechanisms engineered in CFC which can be tracked in online test mode, but which are based on BACnet objects and BACnet services.

Engineering

When engineering the exchange of data in CFC, it is important to take note of the following:

  • Addressing is via [IOAddr].
  • Data is exchanged only between BACnet objects. The attributes of the I/O blocks and pins must be defined appropriately, and the information must also be made available in the form of a BACnet object. For this purpose, the attributes of this block or I/O must be defined correctly.
  • In BACnet terminology, the I/O block is a client which fetches the required value from an object defined as the server. This process is carried out using services defined by BACnet, e.g.: The client subscribes to the relevant object (the server) using the SubscribeCOV service. The server then supplies the value via the BACnet service COVReporting whenever it changes by the programmed value, COVIncrement. ReadProperty (polling) is another BACnet service. Here, the value is read at regular predefinable intervals.
  • Addressing is carried out via the Technical Designation (TD). Note, however, that this Technical Designation must first be made known to the client in the form of a reference address.
  • The data is exchanged both within a given automation stations, and across automation stations.

Address syntax

Addressing takes place via the input/output address [IOAddr] and always starts with the prefix "B=".

The BACnet reference address is the same as the Technical Designation (TD) of the value. The BACnet addressing syntax is as follows:

B=BACnetReference (BACnetConfig)

Example: B=Geb6'Lft3'FanSu'Mot'MntnSwi.PrVal(0)

Polling or COV procedure

The FB variable PollCyc is used instead of the prior BACnetConfig parameter in the I/O address syntax, to distinguish between COV or polling:

FB variable IOAddr. FB variable PollCyc

BACnetConfig = 0 -> COV (Change of Value)

BACnetConfig = 1…65535 -> Polling in seconds

In an automation station operating as a BACnet device, the maximum number of simultaneously supported COV subscriptions is limited to 400.

The BACnet Device as BACnet Server supports a maximum of 400 subscriptions from BACnet clients or from other BACnet devices via the BACnetReference.

A BACnet device operating as a BACnet client can also accommodate a maximum of 100 subscriptions to other values via the BACnetReference.

If the COV procedure is selected, COVIncrement is used for analog objects to define the value by which the present value must change to initiate a COV event.

Data output using WriteProperty

Output objects can write their Present_Value to the properties of other objects or command other value or output object.

Write without priority: Optional address string-Par(P=Number) no available.

Command with priority: Optional address string-Par(P=Number) available.

COV across sites

The value subscribed to must be available in the same BACnet network. Avoid a COV across sites.

The DeviceID is used to access and subscribe freely to values in different BACnet devices (especially in the case of third-party integration). The syntax is as follows:

B=[DeviceID]Objectname – where the object name can be any string required. The DeviceID is entered in decimal (instance number or entire ObjectID).

PPS2 addressing

A PPS2 address is required when values are to be transmitted via the PPS2 interface. Addressing takes place via the input/output address [IOAddr] and always starts with the prefix "Q=".

Address syntax

Up to five room units can be connected to one Desigo PX automation station and addressed via the PPS2 interface. The addressing syntax is as follows:

Q=RoomUnitNumber.Object(Profile)

Example: Q=1.40 (1)

The functions available in the room unit are mapped directly to the I/O blocks. The following elements of the address are predefined:

Type (standard BACnet objects)

Room unit number

Object

Object description

Profile1

Example

Analog input

1…5

24

Setpoint correction

Q=1.24

Analog output

1…5

24

Setpoint correction

Q=2.24

Analog input

1…5

40

Room temperature

0, 1…6

Q=1.401

Analog output

1…5

195

Room temperature display

Q=5.195

Multistate input

1…5

205

Mode

Q=4.205

Multistate output

1…5

205

Mode

Q=2.205

Multistate output

1…5

206

Heating/Cooling display

Q=3.206

Key

1

The Profile relates to the configuration number shown in the next table.

 

The room unit is configured with this configuration number and appended to the Room temperature object. Other objects are not assigned a configuration number. Only the relevant operating and process values are mapped in the I/O blocks, rather than all objects of a room unit.

Six profiles have been defined to keep both the memory requirements and the demands placed upon the user in practice to a reasonable level. If no profile information is supplied, the predefined device-specific default value [DefVal] is used. As an exception in the case of the QAX units, Profile No. 5 is used.

Configuration

Profile

 

1

2

3

4

5

6

Enable operating mode

StandBy

ON

ON

ON

ON

ON

ON

Auto

ON

ON

ON

ON

ON

ON

Fan1

ON

ON

ON

ON

ON

ON

Fan2

OFF

OFF

ON

ON

ON

ON

Fan3

OFF

OFF

OFF

OFF

ON

ON

KonfLCD

Symbol Standby

ON

ON

ON

ON

ON

ON

Symbol Auto

ON

ON

ON

ON

ON

ON

Symbol Fan1

ON

ON

ON

ON

ON

ON

Symbol Fan2

OFF

OFF

ON

ON

ON

ON

Symbol Fan3

OFF

OFF

OFF

OFF

ON

ON

TempUnit

°C

°F

°C

°F

°C

°F

This profile (or configuration number) is always valid for one room unit only. It is used to configure the objects ConfigLCD and EnableOperatingMode and to define how the room unit is to operate (e.g., °C or °F).

In principle, the profile can be attached to any other object.

This configuration applies only to the QAX33.1 (in phase-out) and QAX34.1 room units.

Configuration of the object ConfigLCD is only relevant in the case of the QAX34.1, as this is the only unit with a display in °C or °F.

The configuration of the object EnableOperatingMode is only relevant in the case of the QAX33.1 (in phase-out) or QAX34.1, as only these two room units have the option of selecting Fan1, Fan2 or Fan3.

Where QAX units without an address switch are still in use, only one room unit per automation station can be integrated. The room unit number in such cases is then "1".

LonWorks addressing

There are two ways to integrate data points from LonWorks devices:

  • via Discipline I/O
  • via standard inputs/outputs (the latter approach is only sensible with a small number of data points to be integrated, e.g., from third-party devices)

Address syntax

The block registers the control variables and output variables of the RX devices (outside the CFC chart) in accordance with the information in the [IOAddr] property (Input/output address).

Addressing starts with the prefix "L=".

Addressing via discipline I/O

L=DeviceType DeviceNo. GroupIndex(MappingTableNo.)

  • DeviceType: M (Manager), S (Subordinate)
  • DeviceNo: Field device identification number
  • GroupIndex: Group identification: Up to 4 similar groups of an application unit may exist in the field device (e.g., lighting or window-blind groups). The group index number is optional.
  • MappingTableNo: Number of the mapping table which is valid for that Discipline I/O.

More than one device can be specified for each [IOAddr] string. The devices are separated with a semicolon. However, the maximum [IOAddr] string length of 60 characters must not be exceeded.

Addressing via standard I/O

L= DeviceType DeviceNo.GroupIndex(3RD[NVIndex.FieldIndex])

  • DeviceType: M (Manager). There are no subordinates (S) with third-party devices There is only ever one device.
  • DeviceNo: Field device identification number
  • GroupIndex: Group identification: Up to 4 similar groups of an application unit may exist in the field device (e.g., lighting or window-blind groups). The group index number is optional.
  • ObjectType: Constant for third-party devices: 3RD.
  • NVIndex: Network variable referenced in the third-party device.
  • FieldIndex: Element number, if the network variable is structured

KNX addressing

You can integrate data points from KNX devices as follows:

  • See PX KNX, RXB integration - S-Mode (CM1Y9775)
  • See PX KNX, RXB/RXL integration - Individual addressing (CM1Y9776)
  • Address Info LED for PX KNX: D=1001