User Manual
Table Of Contents
- 1 Cyber security disclaimer
- 2 Preconditions of this document
- 3 System overview
- 4 Desigo workflow, tools and programming
- 4.1 Coverage of the technical process
- 4.2 Coverage of the system
- 4.3 Main tasks
- 4.4 Tools for different roles
- 4.5 Working with libraries
- 4.6 Working in parallel and subcontracting
- 4.7 Workflow for primary systems
- 4.8 Workflow for room automation classic
- 4.9 Workflow for Desigo room automation
- 4.10 Desigo Configuration Module (DCM)
- 4.11 Desigo Xworks Plus (XWP)
- 4.12 Desigo Automation Building Tool (ABT)
- 4.13 Programming in D-MAP
- 5 Control concept
- 6 Technical view
- 7 Global objects and functions
- 8 Events and COV reporting
- 9 Alarm management
- 9.1 Alarm sources
- 9.2 Alarm example
- 9.3 Effects of BACnet properties on alarm response
- 9.4 Alarm response of the function blocks
- 9.5 Alarm functions
- 9.6 Alarm management by notification class
- 9.7 Alarm routing over the network
- 9.8 Alarm queuing
- 9.9 Common alarms
- 9.10 Alarm suppression
- 9.11 Alarm message texts
- 10 Calendars and schedulers
- 11 Trending
- 12 Reports
- 13 Data storage
- 14 Network architecture
- 15 Remote access
- 16 Management platform
- 17 Desigo Control Point
- 18 Automation stations
- 19 Logical I/O blocks
- 20 Room automation
- 21 Desigo Open
- 22 System configuration
- 22.1 Technical limits and limit values
- 22.2 Maximum number of elements in a network area
- 22.3 Desigo room automation system function group limits
- 22.4 Devices
- 22.4.1 PXC..D automation stations / system controllers
- 22.4.2 LonWorks system controllers
- 22.4.3 Automation stations with LonWorks integration
- 22.4.4 PX Open integration (PXC001.D/-E.D)
- 22.4.5 PX Open integration (PXC001.D/-E.D + PXA40-RS1)
- 22.4.6 PX Open integration (PXC001.D/-E.D + PXA40-RS2)
- 22.4.7 PX KNX integration (PXC001.D/-E.D)
- 22.4.8 TX Open integration (TXI1/2/2-S.OPEN)
- 22.4.9 Number of data points on Desigo room automation stations
- 22.4.10 Number of data points for PXC3
- 22.4.11 Number of data points for DXR1
- 22.4.12 Number of data points for DXR2
- 22.4.13 PXM20 operator unit
- 22.4.14 PXM10 operator unit
- 22.4.15 Desigo Control Point
- 22.4.16 PXG3.L and PXG3.M BACnet routers
- 22.4.17 SX OPC
- 22.4.18 Desigo CC
- 22.4.19 Desigo Insight
- 22.4.20 Desigo Xworks Plus (XWP)
- 22.4.21 Desigo Automation Building Tool (ABT)
- 22.5 Applications
- 23 Compatibility
- 23.1 Desigo version compatibility definition
- 23.2 Desigo system compatibility basics
- 23.2.1 Compatibility with BACnet standard
- 23.2.2 Compatibility with operating systems
- 23.2.3 Compatibility with SQL servers
- 23.2.4 Compatibility with Microsoft Office
- 23.2.5 Compatibility with web browsers
- 23.2.6 Compatibility with ABT Go
- 23.2.7 Compatibility with VMware (virtual infrastructure)
- 23.2.8 Compatibility of software/libraries on the same PC
- 23.2.9 Hardware and firmware compatibility
- 23.2.10 Backward compatibility
- 23.2.11 Engineering compatibility
- 23.2.12 Compatibility with Desigo Configuration Module (DCM)
- 23.2.13 Compatibility with Desigo PX / Desigo room automation
- 23.2.14 Compatibility with Desigo RX tool
- 23.2.15 Compatibility with TX-I/O
- 23.2.16 Compatibility with TX Open
- 23.3 Desigo Control Point
- 23.4 Upgrading from Desigo V6.2 Update (or Update 2) to V6.2 Update 3
- 23.5 Siemens WEoF clients
- 23.6 Migration compatibility
- 23.7 Hardware requirements of Desigo software products
- 24 Desigo PXC4 and PXC5
- 25 Compatibility of Desigo V6.2 Update 3 with PXC4 and PXC5
Logical I/O blocks
Addressing the I/O blocks
19
270 | 351 CM110664en_07
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).