TS8020 | TwinCAT BACnet Supplement

Documentation

TwinCAT BACnet/IP Supplement

BACnet/IP-Server and Client-Software

Version: 1.16
Date: 11.01.2013


Notes on the documentation

This description is only intended for the use of trained specialists in control and automation engineering who are familiar with the applicable national standards.
It is essential that the following notes and explanations are followed when installing and commissioning these components.

The responsible staff must ensure that the application or use of the products described satisfy all the requirements for safety, including all the relevant laws, regulations, guidelines and standards.

Disclaimer

The documentation has been prepared with care. The products described are, however, constantly under development.
For that reason the documentation is not in every case checked for consistency with performance data, standards or other characteristics.
In the event that it contains technical or editorial errors, we retain the right to make alterations at any time and without warning.
No claims for the modification of products that have already been supplied may be made on the basis of the data, diagrams and descriptions in this documentation.

Trademarks

Beckhoff®, TwinCAT®, EtherCAT®, Safety over EtherCAT®, TwinSAFE® and XFC® are registered trademarks of and licensed by Beckhoff Automation GmbH.
Other designations used in this publication may be trademarks whose use by third parties for their own purposes could violate the rights of the owners.

Patent Pending

The EtherCAT Technology is covered, including but not limited to the following patent applications and patents:
EP1590927, EP1789857, DE102004044764, DE102007017835
with corresponding applications or registrations in various other countries.

The TwinCAT Technology is covered, including but not limited to the following patent applications and patents:
EP0851348, US6167425 with corresponding applications or registrations in various other countries.

Copyright

© Beckhoff Automation GmbH.
The reproduction, distribution and utilization of this document as well as the communication of its contents to others without express authorization are prohibited.
Offenders will be held liable for the payment of damages. All rights reserved in the event of the grant of a patent, utility model or design.


Safety instructions

Safety rules

Consider the following safety instructions and descriptions!
Product specific safety instructions are to be found on the following pages or in the areas mounting, wiring, commissioning etc.

Disclaimer

All the components are supplied in particular hardware and software configurations appropriate for the application. Modifications to hardware or software configurations other than those described in the documentation are not permitted, and nullify the liability of Beckhoff Automation GmbH.

Personnel qualification

This description is only intended for the use of trained specialists in control, automation and drive engineering who are familiar with the applicable national standards.

Description of symbols

The following symbols with a adjoining safety advise or notice are used in this documentation. You have to read the safety advices carefully and adhere them strictly!

DANGER 		Acute risk of injury!
If you do not adhere the safety advise adjoining this symbol, there is immediate danger to life and health of individuals!

WARNING 		Risk of injury!
If you do not adhere the safety advise adjoining this symbol, there is danger to life and health of individuals!

CAUTION 		Hazard to individuals!
If you do not adhere the safety advise adjoining this symbol, there is obvious hazard to individuals!

Attention 		Hazard to devices and environment
If you do not adhere the notice adjoining this symbol, there is obvious hazard to materials and environment.

Note 		Note or pointer
This symbol indicates information that contributes to better understanding.


Data Types

TS8020 | TwinCAT BACnet Supplement

Introduction

BACnet (Building Automation Control Network) is a standardised, manufacturer-independent communication protocol for building automation. Areas of application include HVAC, lighting control, safety and fire alarm technology. Implementation of this protocol is carried out as server as well as client and can be run on all Beckhoff Industrial PCs and Embedded PCs. All services of a BBC (BACnet Building Controller) are supported such as for example, common data use (DS), alarm and event processing (AE), schedule (SCHED), trend recording (T) as well as device and network management (DM).

This documentation explicitly refers to the technical specification of TwinCAT BACnet/IP and therefore the implementation of the BACnet standard in the TwinCAT runtime and configuration environment. Sound knowledge of BACnet is a prerequisite. There is plenty of literature users may wish to consult in advance:

  • Book: BACnet Gebäudeautomation 1.4, Hans R. Kranz, published by CCI Promotor, 2nd edition, ISBN: 3-922420-09-5
  • Book: BACnetandBACnet/IP - A Clear Description, F. Tiersch, C.Kuhles, published by Desotron ISBN 978-3-932875-31-1
  • External link: ASHRAE BACnetBibliography
  • External link: BACnet Interest Group - BACnet Literature


Introduction

TS8020 | TwinCAT BACnet Supplement

BACnet device

BACnet/IP is an Ethernet based protocol and can therefore be configured in TwinCAT in the "Ethernet" category. A BACnet device can be added to a configuration via the configuration element "I/O Devices". The BACnet device establishes the connection with a network adapter.

BACnet device settings

IP settings

The IP address of a BACnet device can be displayed and modified via the Settings tab. The IP address is read from the selected network adapter when the device is created. The IP address used for BACnet does not have to match the IP address of network adapter. It can be from a separate IP address space. A TwinCAT system can accommodate several BACnet devices, if several network adapters are available. The IP settings of the operating system can be acquired via the option "Use operating system settings". This option lends itself if a device obtains its IP address via DHCP, for example.

AmsNetID settings

Once a BACnet device has been created, further settings can be made via the Settings tab. Each BACnet device has an AmsNetID, which is used as access point for acyclic services. The AmsNetID has 6 digits. The first 4 digits are taken from the system NetID, the 5th is determined by the item ID (1st device: 2, 2nd device: 3, etc.), the 6th is always 1. To activate the BACnet configuration on another target system, the first 4 digits of the AmsNetID have to be adjusted accordingly. A corresponding dialog appears during connection with the new target system. Generally we recommend activating mode "Use relative NetID". In this case the first 4 digits of the NetID are initialised with 0 and replaced with the current system NetID when the BACnet device is loaded. In this way it is possible to transfer an active system configuration to another target system by copying corresponding files (CurrentConfig.xml).

Task configuration

A BACnet device is linked with a task through asynchronous mapping. The corresponding task can be set in the field "Task Configuration". For a BACnet device any task with port >350 can be used. When a BACnet device is created, a default task with priority 58 is automatically created and allocated to the BACnet device.

Import/Export

The "Settings" tab of the BACnet device can also be used to import and export various file formats. A .exp file export, for example, makes a BACnet configuration available in a PLC. Declarations of function blocks of the TcBACnet.lib are created for all configured BACnet server and client objects, which can then be used in the PLC program. This enables convenient access to remote BACnet objects, for example, since process data variables are automatically linked during PLC automapping.

During XML export and import BACnet configurations are processed in a manufacturer-specific format.

Version 2.2 also supports Engineering Data Exchange (EDE) import and export. The EDE format is a comma- or semicolon-separated list with fixed and optional columns. Whether comma or semicolon is used as separator depends on the country-specific setting. The list separator specified in the operating system (Regional and Language Options) is used. Additional optional columns can be selected during export ("Include optional columns"). The optional column "vendor-specific address" can be used to copy information relating to the linked variables of the TwinCAT configuration to the EDE file. During EDE export of a BACnet server the user can choose whether offline data (settings dialogs) or online data are used for the export.

Time management

The "Time Management" group in the "Settings" tab of the BACnet device has an option to specify whether the time of the underlying operating system should be used. Summer and winter time is updated automatically, if configured accordingly in the operating system. For manual time setting the UTC offset and the DayLightSavingsStatus (summer/winter time) can be specified in this dialog. During the manual configuration of the time parameters the UTC offset and DayLightSavingsStatus can be modified via BACnet. Switching between summer and winter time leads to a 60-minute time switch.

Further BACnet device setting options are presented in the sections below.

BACnet server/client

Under a BACnet device BACnet clients and server can be configured (see also example: "Create BACnet adapters and servers"). A server makes BACnet objects available. A BACnet client enables access to BACnet objects of other BACnet devices (servers) in the network.

BACnet clients can be detected automatically by scanning the network. To this end a BACnet device is created and the Scan function of the TwinCAT System Manager is used to find other devices (servers). For each found device the loaded BACnet objects are detected and created in the System Manager. Clients can also be configured manually with suitable BACnet device IDs, whereby the IP address is automatically determined with the BACnet service Who-Is. If the Scan function of the System Manager is used for a select client, the objects are detected so that no manual configuration is required.

Scanning of clients and their objects and properties requires an existing BACnet installation.

BACnet notification sink

The notification sink is a special feature of BACnet modules. It can be used to collect events and facilitate COV subscription. Functionally it is not a BACnet object, so that the notification sink is not visible for other clients from BACnet. However, the notification sink can be accessed via ADS services (e.g. TCP/IP, see section "ADS interface").

Attention 		Notification sink and certification

The notification sink is not included in the certification. Application of the notification sink is the responsibility of the user.

For each BACnet device several notification sinks can be configured (with different process IDs), for example to distinguish different weightings of event priorities. For each notification sink a unique ADS port is generated and displayed under "Identification". The size of the queues for COV and event notifications can be specified via the Configuration field. If a queue is full, further notifications are discarded. Via the ADS interface the user must ensure that the queues are processed suitably quickly and entries are cleared (via ADS). Regarding the queues it should be noted that in the current implementation router memory is used for the notifications. The memory allocation for each notification is approx. 3 kbytes. The size of the router memory should match the queue configuration.

The functions Event and COV auto-acknowledge are currently not used. Acknowledgement of individual notifications is also not implemented at present.

The main use of notification sinks is processing and visualisation of alarm messages (event notifications). COV notification subscriptions should only be used if state changes of complex BACnet properties have to be implemented. This can be used to monitor whether new BACnet objects were dynamically added to a device, for example. For properties with simple data types process data of remote objects should be used, since here too efficient COV notifications are implemented.

A different configured client can be set as target for COV subscriptions by double-clicking on the Identification field.

Received notifications (including receive time stamp) can be viewed in the Online tab. Individual event and COV notifications can be cancelled and all queues can be cleared with a command available in the context menu of the Online tab.

The figure shows an EventNotification in the Online tab of a notification sink. TwinCAT BACnet/IP devices read the message text of an EventNotification from the Description property of the BACnet object sending the event.

EventNotifications can also be deleted via the function block FB_BACnet_NotificationSinkDelEntry of the PLC library TcBACnet.lib.

An example that illustrates the application of the NotificationSink and generation of EventNotifications can be found in section Application: Example: NotificationClass and NotificationSink.


Setting up a BACnet Supplement Key

In order to be able to execute a TwinCAT BACnet/IP installation in RUN mode, it is necessary to obtain a supplement key. This key is linked to the MAC address of the network adapter. Supplement keys for several network adapters can be set up on the same computer.

Notice 		Windows CE images
For Windows CE-based images the supplement key is already pre-installed in corresponding BACnet versions (special order number) and does not have to be entered retrospectively.

To add a supplement key a BACnet device has to be created and loaded ("Reload Devices"). The key can then be added with the button "Insert Key" in the Settings tab of the BACnet device.

Notice 		Image updates
If a valid key has been entered, it can subsequently be displayed with the button "View Key". In Windows Embedded-based devices (CX5010,CX5020) a image update may result in the supplement key being lost. It is advisable to make a note of the supplement key before the update.


BACnet objects and properties

General information on handling

Each BACnet object has a defined number of properties associated with it. These properties are configured offline on the BACnet server side and made available to other BACnet devices in the BACnet network during operation (RUN or Free RUN). These offline data, or the initial values of the object properties are displayed in the Settings tab. The Online tab shows the current values of the object properties at runtime. Some properties are read-only (and identified as such by a lock symbol [image]) and cannot be changed.

Each object property has a unique number. In TwinCAT BACnet/IP properties are subdivided into groups, which are identified by numbers as follows:

  • Property ID 0...511: BACnet standard-compliant properties
    • defined in ISO 16484-5
    • specified, defined manufacturer-spanning behaviour
    • can be configured offline in part, in some cases only representation of an online state
  • Property ID 512...799: manufacturer-specific properties with BACnet visibility
    • visible in the BACnet network as properties of the corresponding objects
  • Property ID 800...1000: manufacturer-specific properties without BACnet visibility
    • used for configuring internal parameters that are not relevant for BACnet but are allocated to objects as parameters
    • configurable in the Settings tab of corresponding objects; not visible in the Online tab
    • includes fall-back values for I/O modules
  • Property ID > 1000: internal properties without BACnet visibility
    • not visible in the Settings or Online dialog
    • used internally for special process data (e.g. "RawIo*")
    • used in PLC automapping for priority-based links and a device ID

In Online view a context menu can be opened by right-clicking

The menu item "Read Property Data" can be used to read the value of an individual property.

Notice 		ReadPropertyAll
The overall view is read with the BACnet service ReadPropertyAll. If a device does not support this service, the properties are read individually.

If the function Auto Update is activated, all properties are read and displayed at 1-second intervals. In this case the individual properties no longer have to be read explicitly via the menu option "Read Property Data".

List and array property elements can be added/removed with the Add/Remove function.

By default, changes in the property data are written immediately. Data can be manipulated without triggering immediate writing by deactivating the function "Auto Commit". This enables to make complex changes in the properties (e.g. in the property ExceptionSchedule), and the changes can subsequently be written in a single operation. The edited properties are identified with a pen symbol [image] on the left-hand side until the changes have been written. The context menu option "Write Property Data" can be used to write the changes. Caution: The option WritePropertyMultiple is currently not implemented. Instead, individual WriteProperty calls are used.

CAUTION 		Deactivate auto update!
If "Auto Commit" is deactivated, the function "Auto Update" should also be deactivated in order to prevent overriding of edited data on reading.

Certain objects have commandable properties. In these cases a write access priority can be specified. This value is written to the PriorityArray via the index linked with the priority.

The PriorityArray also offers direct write access. All entries with the value "(Null)" are ignored. Depending on the priority, entries with a concrete data type and a valid value act on the corresponding, commandable property or are overridden by another entry with higher priority. The entries from the PriorityArray determine the value of the PresentValue of a BinaryOutput object, for example.

To remove an entry from the PriorityArray, set its type to NULL in the Type column. Entries can also be deleted from the PriorityArray via the context menu of the commandable property. To this end select NULL as type and write it to the corresponding priority with "Write Property Data" or automatically with "Auto Commit".

Configuration of optional properties and property write protection

The BACnet standard defines the standard objects and their properties (property ID 0 - 511). Some properties are identified as optional, other as obligatory. In order to achieve maximum flexibility in the configuration of objects, optional properties can be set to be in view or hidden and the access type can be limited, if permitted (read-only or read/write) in the Object view under the "Optional Properties" tab.

Notice 		Information shown after the property name (R/W/O)
The letter after the property name (R/W/O) indicates the minimum access right according to the BACnet specification. "R" stands for 'read' (or higher), "W" for 'write/read', "O" indicates an optional property with read and/or write permission. The identification number of optional properties indicates their interdependence. Optional properties with the same number can only be activated or deactivated as a group. Notwithstanding the BACnet specification some normally optional properties are obligatory in TwinCAT BACnet/IP and can therefore not be disabled. This due to the internal implementation. Examples are the properties Reliability and PriorityArray.

For some properties write access can be specified. The green, open lock symbol [image] indicates write access. The red, closed lock symbol [image] indicates read only access. Click on the symbol to toggle the state. In case of greyed out symbol the permission cannot be changed. The access permission is indicated by "W" or "R" or the greyed out lock symbol ("W" and open, grey lock = write/read access, "R" and closed, grey lock = read only access).

The availability of optional properties can be controlled by clicking on the symbol checkbox [image]. Deselecting the checkbox disables the corresponding property.

Special features

The object type "BACnet Structured View Object" is only used as a hierarchy object and is not visible for other devices in the BACnet network.

Manufacturer-specific properties

TwinCAT BACnet/IP uses a number of manufacturer-specific properties, which are explained below. Manufacturer-specific properties are distinguished through their property IDs. Properties with IDs between 512 and 799 are visible across the BACnet network. Properties with higher IDs are used for the configuration within TwinCAT BACnet/IP and are not displayed via BACnet. These properties are visible in the Settings tab, but not yet in the Online tab.

ScaleOffset (512) ScaleOffset is used for AnalogInput and AnalogOutput objects and determines the offset for the conversion between the hardware range to BACnet and vice versa.

For AnalogInput objects the following applies: PresentValue = RawIoSingedValue * Resolution + ScaleOffset
For AnalogOutput objects the following applies: RawIoSingedValue = PresentValue / Resolution - ScaleOffset

The same calculation algorithms apply for the process data properties RawIoUnsingedValue.
IoBusNr (513) | IoBusNr is used for mapping a fieldbus state, e.g. during K-bus I/O automapping. Further details can be found in sections IO Automapping and Process data. 255 indicates that a BACnet object is not allocated to any IoBus.
IoModuleNr (514) | IoModuleNr indicates the position of a terminal within an I/O bus. For I/O automapping consecutive numbers are used, starting with 1. This property is for information purposes only and is not used in the BACnet stack.
IoModuleChn (515) | IoModuleChn indicates the channel number of an I/O terminal. For I/O automapping consecutive numbers are used, starting with 1. This property is for information purposes only and is not used in the BACnet stack.
PersistentData (516) | Persistent Data indicates whether changes have occurred since the last saving of persistent data. In addition, this property can be used to trigger saving of persistent data via BACnet. Details relating to this property can be found in section Persistent data. This property is only visually if persistent data were activated and the configuration was loaded in RUN mode.
ActivePriority (517) | ActivePriority indicates the active priority level for objects with commandable PresentValue properties. If all entries in PriorityArray are NULL, the value of Active Priority is 17, and ReliquishDefault is used as value for PresentValue.
FaultFallbackRealValue (802) FaultFallbackRealValue can be used for AnalogInput objects, so that valid values are provided in the event of an I/O bus error in the higher-level PLC or BACnet. If an IoBus error is detected, TwinCAT BACnet/IP no longer copies the corresponding process data of the fieldbus, but the configured fall-back values.

The fall-back value can be activated in the Settings tab by ticking the box for the optional value. If no fall-back value is active, in the event of an IoBus error no process data are copied, and the last valid value remains active.
FaultFallbackBinaryValue (803) | FaultFallbackBinaryValue has the same purpose as FaultFallbackValueReal and is used for BinaryInput objects.
OutOfServiceFallbackRealValue (804) | OutOfServiceFallbackRealValue can be used for generating valid output process data if an AnalogOutput object is in OutOfService mode. If OutOfServiceFallbackRealValue is active, the corresponding value for the I/O process data is used. Otherwise, if OutOfService is active, the last valid PresentValue value is used.
OutOfServiceFallbackBinaryValue (805) | OutOfServiceFallbackBinaryValue has the same purpose as OutOfServiceFallbackRealValue and is used for BinaryOutput objects.
TimeSynchronizationUseUTC (806) TimeSynchronizationUseUTC is used for configuring a TimeMaster and indicates whether the TimeSynchronization service or the UTCTimeSynchronization service is used for sending synchronization telegrams to the TimeSynchronizationRecipients.

Revision 6, which is implemented in TwinCAT BACnet/IP, does not yet make provision for TimeMaster-specific properties. In this context TwinCAT BACnet/IP implements the standard-compliant properties AlignIntervals, IntervalOffset and TimeSynchronizationInterval without BACnet visibility.

The property TimeSynchronizationInterval (204) indicates the interval (in minutes) at which time synchronisation telegrams are sent. If the value of this property is 0 the TimeMaster function is disabled.

The property AlignIntervals (193) can be used to enable the property IntervalOffset (195), which can be used to specify when exactly time synchronisation telegrams are sent. If the property TimeSynchronizationInterval has a value that is divisible by 60, time synchronisation messages are sent when the current time in minutes modulo matches the value of TimeSynchronizationInterval and IntervalOffset . The following example explains the configuration of a Timemaster, which sends UTC time synchronisation telegrams to all BACnet devices in the network every day at 2 am:

TimeSynchronizationUseUTC = TRUE
AlignIntervals = TRUE
TimeSynchronizationInterval = 1440
IntervalOffset = 120
TimeSynchronizationRecipients = {((FF:FF:FF:FF:FF:FF;0))}


Wizards

TS8020 | TwinCAT BACnet Supplement

Help functions and wizards

Wizards were implemented to simplify the configuration of TwinCAT BACnet/IP and make it more transparent. They are briefly described in this section. The availability of a wizard is indicated by a small triangle ( [image]) on the bottom right of the Property view in the Setting and Online tabs of the objects. The wizards can be used for client and server objects.

Object overview

An Objects tab can be found under BACnet client and BACnet server. In this view selected properties of the objects of a BACnet client or server are shown. BACnet objects can be sorted based on different criteria by clicking on the table header. In this way it is possible to show all objects with fault state at the top, for example. It is currently not possible to change property values in this view.

Right-clicking on the object overview opens up a context menu through with the Process Data wizard for BACnet clients or the Property wizard for BACnet servers can be activated.

Property wizard

The Property wizard enables activation/deactivation of process data, activation/deactivation of optional properties and activation/deactivation of the write protection for several properties of several objects. This makes it very easy to deactivate Intrinsic Reporting (alarms) for all BinaryValue objects, for example, by deactivating the corresponding optional properties.

First, the objects ( Select Objects tab ) and the properties ( Select Properties tab ) for which the actions should be executed have to be selected. Click on "Apply" to execute the selected operations.

Process Data wizard

The Process Data wizard for BACnet clients enables the configuration of process data-specific settings of client objects. Parameters that can be configured include the data processing mode (COV etc.), cycle times, COV increment etc.

For very large BACnet client configurations ( with many COV process data ) we recommend executing the function "Optimize Process Data Access" on all objects and properties. The corresponding TickModulo factors for the client interactions are then calculated automatically. The space available for modulo factors is determined automatically through the BACnet cycle time and the "cycle time" of the process data. With a BACnet cycle time of 10ms and a process data "cycle time" of 1000 ms the client interactions can be apportioned to 100 cycles. For large configuration the cycle times should be adjusted in order to produce a modulo factor that is as large as possible. The maximum number of cycles over which client interactions can be distributed is 255. The "cycle time" is also used in COV mode. In conjunction with the TickModulo the login (COV subscription) is sent in the assigned cycle. In systems with many COV process data, bursts can be reduced by distributing the COV subscriptions over several cycles.

Property Reference wizard

In order to facilitate the handling of property and object references, it is possible to configure these properties by double-clicking on Value. This opens the wizard dialog. The availability of the wizard is indicated by a triangle symbol in the bottom right corner of the Value field [image]. Examples are the ListOfObjectPropertyReferences property in the Schedule object or the LogDeviceObject property in the TrendLog object. The wizard dialog simplifies the selection of the corresponding properties and objects.

Filter options can be used to simplify the selection of several properties and objects. If the filter settings are changed, the options for selecting properties and objects are adjusted dynamically.

Calendar wizard

Properties with data type BACnetDate can be configured via the Calendar wizard. A day can be selected via a displayed calendar. The corresponding day of the week is determined automatically. For data with data type BACnetDateRange the wizard also enables configuration of date ranges.

Schedule Object wizards

Wizards for the properties WeeklySchedule and ExceptionSchedule are available for configuring timer-based switching schedules. Currently these wizards are only available if a property of data type BinaryPV or Boolean is set as property reference. Wildcards ("*") are not allowed in the time entries.

The WeeklySchedule wizard supports editing of several day entries at the same time. Several weekdays can be selected by selecting "Mo-Su", "Mo-Fr" or "Sa-Su". Changes in an entry are then automatically transferred to all select entries. Other entries can be selected or deselected by clicking on them.

The ExceptionSchedule wizard can be used to edit exceptions. Four modes are available for selection: Calendar reference, Date, DateRange and WeekNDay. Further entries can be added by clicking on the "+" symbols.

Calendar iCal/.ics import

.ics import was implemented for efficient development of holiday calendars. Suitable .ics holiday files can be downloaded from the Internet and imported. The .ics import can be activated via a wizard of the Datelist property in the Calendar objects. In addition, .ics can be selected via the "Import" button of the BACnet device, and the entries can either be stored in a new or an existing calendar.

TrendLog-LogBuffer wizard

The property LogBuffer of the TrendLog objects contains the log entries. A diagram view for TrendLog objects was integrated as a wizard in order to provide a better overview. In addition to mean, min. and max. values, the diagram shows the entries of the LogBuffer as lines. Special entries (Start - B, Stop - E, Time synchronisation - S) are shown on the x axis of the diagram. A special feature of this wizard is that several windows can be shown in parallel. In conjunction with the function "Auto Update" this enables certain features to be visualised in a BACnet configuration.

Group Object wizards

Group objects enable consolidation of several property values of multiple BACnet objects. The Property wizard described in section "Objects and Properties" can be used to configure the property ListOfGroupMembers of the Group objects.

At runtime the property PresentValue of a Group object contains the values of the configured properties. The Group-PresentValue wizard displays the included property values in a window. In addition it is possible to change the property values. For properties of data type Boolean and BinaryPV the buttons "On" or "Off" and the current state are displayed. Properties of type Real are shown as sliders and value input fields. The states of MultiState* objects and enumerator properties (except BinaryPV) are visualised as a combo box. If the property StatusFlags of an object was configured in addition to a PresentValue, the state Offnormal becomes orange and the Fault state is highlighted in red.

Clicking on the property name of a GroupBox in the Group PresentValue-wizard while pressing the SHIFT key results in dynamic generation and starting of a TrendLog object on the associated BACnet client/server. In this way certain properties can conveniently monitored during commissioning. When the diagram windows is closed, the dynamically generated TrendLog object is deleted again.


Process data

This section describes the process data variables of the individual TwinCAT BACnet/IP elements. In general, process data of a BACnet/IP device are linked with the PLC and a fieldbus via asynchronous mapping. This is necessary since BACnet has acyclic characteristics, and certain services may trigger many changes in other BACnet properties and therefore the sending of many BACnet Ethernet frames. Asynchronous mapping is used to prevent links with BACnet process data resulting in cycle time violations in the PLC or watchdog timeouts of the fieldbuses. It means that BACnet, PLC and fieldbus tasks run independent of each other.

Linking to a task takes place under the BACnet device via the Settings tab and "Task Configuration". This is where a task can be selected. The selection dialog shows all tasks with a port greater than 350. The bottom left of the screenshot shows a PLC task ("BACnet_Demo") that is linked asynchronously with the BACnet task, which by default is created with priority 58 when a BACnet object is added.

BACnet Device

Under a BACnet device the process data variables are the Device Status, which includes the link status of the linked Ethernet adapter, and the state of the internal state machine. The device status is explained in the following table.

In addition the AmsNetID of the BACnet device can be linked with a PLC that accesses BACnet functions via ADS.
Bit Description
0 Ethernet link status: Represents the current link status of the linked Ethernet adapter:
  • 0 - link is present.
  • 1 - no link is present.
8 - 15 Device state machine: Reflects the state of the internal BACnet device state machine:
  • Init (0) - initial state
  • CheckIpAddress (1) - Initialising the IP address (including waiting for DHCP address)
  • CheckParameter (2) - verification of gateway and BBMD parameters
  • GetGatewayMAC (3) - If a gateway was configured an ARP request is sent
  • WaitForGatewayMAC (4) - waiting for resolution of the gateway MAC address (ARP reply)
  • Complete (8) - initialisation complete

BACnet Server

ServerStatus is currently not used in the BACnet server. The internal server status can be determined using the property SystemStatus, which can be linked cyclically.

The state of an I/O link can be monitored centrally via the IoBusState process data variables. When linking a K-bus or a BK9000, for example, CouplerState or BoxState maps the state of several I/O modules. Fieldbuses that are linked with BACnet via I/O automapping can map Reliability automatically with the aid of these process data. Each fieldbus strand is allocated an IoBusNr, which is also a manufacturer-specific BACnet property. If the value of the process data variable couplerState or BoxState is not equal 0, all relevant (I/O) BACnet objects of the server with the corresponding IoBusNr are notified, and the Reliability is set to NO_SERVER or NO_OUTPUT. By default 8 IO busses are available.

BACnet Server Control

Bit | Description
0 | Backup PLC feedback Enable: When backing up data generated by the PLC through a BACnet backup, this bit ensures that the PLC initially has write access to the backup-relevant files (configuration files). If this bit is set, the BACnet stack waits for bit 1 of the server control word being set before acknowledging the backup request. If this bit is not set, the BACnet stack omits this handshake procedure. Further information on backup and restore can be found in the corresponding section of this documentation.
1 | Backup PLC feedback Complete: Once the backup-relevant PLC data were backed up, this bit instructs the BACnet stack to continue with the backup.

BACnet Client

In addition to monitoring the client status, the SystemStatus of the device object of the client should always be activated as process data. Since errors in the client communication are only shown in the client status if errors in the communication occur, regular communication should be ensured. To this end it is advisable to read or poll the property SystemStatus cyclically (with a suitably low cycle time).

The process data SystemStatus is a enumeration with the name BACnetDeviceStatus and is defined in the BACnet standard. BACnet makes provision for the following values:

  • operational (0)
  • operational-read-only (1)
  • download-required (2)
  • download-in-progress (3)
  • non-operational (4)
  • backup-in-progress (5)
  • ...

BACnet Client Status

Bit | Description
0 | Client TimeOut: A timeout has occurred in a BACnet service request. ( as calculated ... )
1 Client Service Failure: A service with the configured client could not be carried out successfully. This error bit is set if:
  • A client cannot be reached.
  • A COV subscription could not be completed successfully.
  • A WriteProperty/ReadProperty request had a negative result.
2 Client WriteOnChange State: Activation control for WriteOnChange, which is specified under client control.
  • 0 - WriteOnChange is active. If the client process data change, corresponding BACnet network services are triggered.
  • 1 - WriteOnChange is disabled. Process data can be changed without triggering BACnet network services.
3 | Client COV Subscription Control State: Shows the state of the COV subscription control. If the Client COV Subscription Control bit is set, this bit is set to 1 when the COV subscription data structures were reset. If the Client COV Subscription Control bit is not set, the state is 0. This bit does not indicate whether all COV subscriptions were completed successfully, it only indicates that all COV subscription will be executed again in future.
8 - 15 Client Remote State: Reflects the state of the internal client-state machine:
  • Init (0) - initial state
  • Connecting (1) - sending of a WhoIs request for the client ID
  • WaitingForConnection (2) - waiting for I-Am and IP address of the client. The system waits 10 seconds for a response, then the WhoIs request is repeated (connecting).
  • RequestDeviceInformation (3) - reading of the properties ApduTimeout and
  • NumberOfApduRetries, if segmentation is supported additionally MaxSegmentsAccepted, ApduSegmentTimeOut
  • Complete (4) - client is fully initialised. Interaction with the BACnet client can take place.

BACnet Client Control

Bit | Description
0 | Client TimeOut Reset: Resetting of the client timeout bit in client status.
1 | Client Service Failure Reset: Resetting of the service failure bit in client status.
2 Client WriteOnChange Control: Activation control for WriteOnChange. WriteOnChange is disabled if the corresponding bit is set in Client Status.
  • 0 - WriteOnChange is active. If the client process data change, corresponding BACnet network services are triggered.
  • 1 - WriteOnChange is disabled. Process data can be changed without triggering BACnet network services.
3 | Client COV Subscription Control: Resets the status of the COV subscriptions and triggers the new registration of COV subscriptions. The internal data structures are reset once (which triggers the COV subscriptions) if a change of value 0 -> 1 is detected.

Notification Sink

The TwinCAT BACnet/IP notification sink enables the receipt of COV and event notifications. The number of received notifications can be determined via the process data CovNotifications and EventNotifications. Notifications can be deleted and read via the ADS interface of the notification sink.

BACnet objects - properties as process data

Properties with non-complex data types (Signed Integer, Unsigned Integer, BitField, Boolean, Real, Enumerated) can be configured as cyclic process data. In the property process data a distinction has to be made between objects under a server (local objects) and objects under a client (remote objects).

  • The properties of local objects reside on the server. The dialog "Cyclic Data" can be used to configure which properties can be linked as process data. Connectable properties appear under an object as process data variables and can be linked with variables of a PLC or with other I/O devices (e.g. EtherCAT terminals or K-bus terminals).
  • For local objects output data (PLC/IO -> BACnet) are data that are copied from a PLC to a BACnet object. They are shown as red variables.
  • Input data (BACnet -> PLC/IO), shown in yellow, are copied to a PLC. These include the StatusFlags of an object, which can be processed in the PLC.

For remote objects the properties of a remote device can be made available as cyclic process data. The data of the properties can either be transferred acyclically via COV (Change of Value) or cyclically at a fixed interval. In remote objects data that are consumed by a PLC are shown in yellow, produced data in red.

The schematic diagram illustrates the application of process data in client and server objects. The example shows a BinaryOutput object created on a server. The property PresentValue is linked as a process data variable. The PresentValue can be used in a PLC on the server in order to influence a functionality in a PLC program, for example, or it can be linked with an EtherCAT terminal to activate lighting, for example. In this case PresentValue is a yellow PLC input variable on the server side. On a second computer the object is configured as a remote object. In this example the value of PresentValue of the server object is to be changed with the aid of a PLC on the client. To this end the PresentValue is mapped as a red output variable on the client and can be linked with the PLC.

The values of the properties linked as process data have to be transferred to the server (with the aid of the BACnet WriteProperty service). TwinCAT BACnet/IP offers two data transfer options. Data can be written "On Change", i.e. when changes occur. During processing of the process data within TwinCAT BACnet/IP, write access to the corresponding BACnet property is triggered if a change in the process data is detected. As a second option the data can be written cyclically. Attention: If "Write On Change" is active the data are written once when a change occurs. If another BACnet instance subsequently overrides the value, the value of the client PLC may differ from the property value. It may be advisable to feed the BACnet properties back as input variable. With "Write On Change" data are transferred at most with the set cycle time.

For commandable properties a priority can be selected for the write access.

On the other side PLC input variables on the client device have to be transferred by the server. Here too, two options are available. Property data can be transferred asynchronously via the BACnet mechanism COV. To this end a COV subscription is set up for the corresponding property when TwinCAT starts up. When the property changes the server sends corresponding messages. The process data variables are updated based on these COV notifications. The second option involves cyclic data polling. This can be useful in situations where a BACnet device does not support COV.

In BACnet the problem is that certain properties are potential written by several sources. Commandable properties were introduced in order to distinguish the importance of different entities. When a PLC is linked to output data, the values of the process data are copied cyclically, i.e. the corresponding property value is written continuously. It therefore makes sense to link process output data based on priority. In this case the data are copied to the corresponding location in the PriorityArray of a commandable property, so that the possibility of overwriting the PLC value with a higher priority is maintained.

To activate a lower priority level, a priority level with the value NULL can be written.

  • From the PLC this is possible for BinaryOuput/Value objects. If a value not equal 0/1 is written to the PresentValue of a linked priority level of a BinaryValue or BinaryOutput object, the value NULL is copied to the PriorityArray.
  • For AnalogOutput/Value objects the value NULL is assumed in the PriorityArray, if the special coding of REAL values NaN (not a number) is used as process data. For server objects NULL is also written if the REAL value of the process data variable is outside the Min/MaxPresValue range.
  • In MultistateOuput/Value objects the value NULL is assumed in the PriorityArray, if 0 is written as process data. For server objects NULL is also assumed if the process data takes on a value greater than NumberOfStates.

The following table shows the relationship between BACnet data types and PLC data types:

BACnet data type | PLC data type
Boolean | BOOL
Unsigned Integer | UDINT
Signed Integer | DINT
Real | REAL
Double | not used
Bit string ( StatusFlags, EventEnable, LimitEnable etc. ) | WORD (For bit strings it should be noted that the lowest-order byte is used to display the number of unused bits of the highest-order byte. An example is 0xE005 of an EventEnable property: 5 indicates that 3 bits are used in the highest-order byte [to_offnormal, to_fault, to_normal]. 0xE0 indicates that all 3 bits are TRUE. If a bit string property is written cyclically from the PLC to BACnet, these bits have to be coded accordingly. Valid values can be found in the Online tab of the BACnet objects.)
Enumerated (EventState, Reliability, Polarity, BinaryPV etc.) | WORD

RawIoProperties

Process data properties from this category are used for linking of BACnet objects with I/O modules and PLC variables. These properties do not directly represent properties that are visible in BACnet, but they act on standardised properties of the corresponding objects or are formed from them. The general rule for RawIo properties is that the BACnet property OutOfService takes effect. An object is then referred to as OutOfService, since the BACnet property OutOfService has the value TRUE.

Property | Description
RawIoSignedValue | Signed 16-bit value (INT) used for analog* objects. If an AnalogInput object is not OutOfService, the value of this process data variable forms the value of PresentValue. The value of RawIoSignedValue is converted to a REAL data type, the result is multiplied with the property Resolution and then added to the property ScaleOffset. For AnalogOutput objects the value of RawIoSignedValue is formed from PresentValue based on the inverse procedure. If the value of PresentValue exceeds the value range of the data type INT (-32768 to 32767), RawIoSignedValue has the value 0. If an object is OutOfService, the last value or the configured value is used, depending on the configuration of the properties FaultFallbackValue or OutOfServiceFallbackValue.
RawIoUnsingedValue | Unsigned 16-bit value (UINT) that is used for analog* objects. If an AnalogInput object is not OutOfService, the value of this process data variable forms the value of PresentValue. The value of RawIoSignedValue is converted to a REAL data type, the result is multiplied with the property Resolution and then added to the property ScaleOffset. For AnalogOutput objects the value of RawIoSignedValue is formed from PresentValue based on the inverse procedure. If the value of PresentValue exceeds the value range of the data type UINT (0 to 65535), RawIoSignedValue has the value 0. If an object is OutOfService, the last value or the configured value is used, depending on the configuration of the properties FaultFallbackValue or OutOfServiceFallbackValue.
RawIoBinaryEnumValue Enumeration type (in the PLC processed as WORD) that is used for binary* objects. Applies if OutOfService is not TRUE.

For BinaryOutput objects the value of the property RawIoBinaryEnumValue is formed as follows:

  • RawIoBinaryEnumValue is 0 if PresentValue is ACTIVE and the polarity is NORMAL, or if PresentValue is INACTIVE and the polarity is REVERSE.
  • RawIoBinaryEnumValue is 1 if PresentValue is INACTIVE and the polarity is NORMAL, or if PresentValue is ACTIVE and the polarity is REVERSE.

If OutOfService is TRUE, for BinaryOutput objects the property RawIoBinaryEnumValue assumes the value of the property OutOfServiceFallbackValue if this is activated, otherwise the last valid value is maintained.

For BinaryInput objects the PresentValue is formed from the property RawIoBinaryEnumValue.

  • PresentValue is Active if RawIoBinaryEnumValue is 0 and the polarity is NORMAL or if RawIoBinaryEnumValue is greater than 0 and the polarity is REVERSE.
  • PresentValue is INACTIVE if RawIoBinaryEnumValue is greater than 0 and the polarity is NORMAL or if RawIoBinaryEnumValue is 0 and the polarity is REVERSE.

If OutOfService is TRUE, PresentValue always assumes the value of FaultFallbackValue if this is active, otherwise PresentValue assumes the last value when OutOfService was FALSE.
RawIoBinaryBoolValue Binary value (BOOL) that is used for binary* objects. The property PresentValue of the binary* objects in BACnet is an enumeration type. The property RawIoBinaryBoolValue was introduced to optimise the handling of binary objects. It can be used instead of RawIoBinaryEnumValue.

For BinaryOutput objects the value of the property RawIoBinaryBoolValue is formed as follows:

  • RawIoBinaryBoolValue is FALSE if PresentValue is ACTIVE and the polarity is NORMAL, or if PresentValue is INACTIVE and the polarity is REVERSE.
  • RawIoBinaryBoolValue is TRUE if PresentValue is INACTIVE and the polarity is NORMAL, or if PresentValue is ACTIVE and the polarity is REVERSE.

If OutOfService is TRUE, for BinaryOutput objects the property RawIoBinaryEnumValue assumes the value of the property OutOfServiceFallbackValue if this is activated, otherwise the last valid value is maintained.

For BinaryInput objects the PresentValue is formed from the property RawIoBinaryBoolValue.

  • PresentValue is ACTIVE if RawIoBinaryBoolValue is FALSE and the polarity is NORMAL, or if RawIoBinaryBoolValue is TRUE and the polarity is REVERSE.
  • PresentValue is INACTIVE if RawIoBinaryBoolValue is TRUE and the polarity is NORMAL, or if RawIoBinaryBoolValue is FALSE and polarity is REVERSE.

If OutOfService is TRUE, PresentValue always assumes the value of FaultFallbackValue if this is active, otherwise PresentValue assumes the last value when OutOfService was FALSE.
RawIoStatus Analog input modules can have a process data that indicates the state of the physical connection (e.g. open-circuit detection, range violation). If the property RawIoStatus (data type USINT) is active, it influences the property Reliability.

The property Reliability is formed from RawIoStatus if the object is not OutOfService, no IoBus error is pending (see RawIoECATState, IoBusState) and no status override is active, (see RawIoStateOverride*) as follows:

  • If bit 0 is set, Reliability is UNDER_RANGE
  • Otherwise Reliability is OVER_RANGE, if bit 1 is set
  • Otherwise Reliability is UNRELIABLE_OTHER, if bit 6 is set
RawIoECATState EtherCAT modules have an operation status that maps the current operating state. BACnet objects that are linked with EtherCAT modules can form their Reliability via this operation status. RawIoECATState enables unplugged modules (module plug) and partial bus failures to be detected and mapped to BACnet. The property Reliability is formed as follows from RawIoECATState if the object is not OutOfService:
  • For output objects (BO, AO, MO) the following applies: If the value of bits 0 - 3 is not equal 8 (OP), Reliability is NO_OUTPUT.
  • For input objects (BI, AI, MI) the following applies: If the value of bits 0 - 3 is not equal 8 (OP), Reliability is NO_SENSOR.
RawIoWcState | WcState monitoring is currently not supported.
RawIoStateOverride | Some I/O modules have a mechanical manual mode for overriding the fieldbus process data locally. Manual override can be mapped in BACnet via the property StatusFlags with the bit OVERRIDE. If the process data variable RawIoStateOverride is TRUE, in the allocated BACnet object the bit OVERRIDE is set in the property StatusFlags, otherwise not, when the BACnet object is not OutOfService.
RawIoStateOverrideInverted | Some I/O modules have a mechanical manual mode for overriding the fieldbus process data locally. Manual override can be mapped in BACnet via the property StatusFlags with the bit OVERRIDE. If the process data variable RawIoStateOverride is FALSE, in the allocated BACnet object the bit OVERRIDE is set in the property StatusFlags, otherwise not, when the BACnet object is not OutOfService. Examples for using RawIoStatusOverrideInverted can be found in modules KM2642 and KM4602.

Special data versions of PresentValue

Property | Description
PresentValueBool | Schedule object: If the PresentValue of a schedule object of the BACnet data type is Boolean, the process data property PresentValueBool reflects the current value of the property PresentValue. Binary* objects: In BACnet the property PresentValue of binary* objects is of data type BinaryPV and therefore an enumeration. The corresponding PresentValue process data is therefore of data type WORD, since enumerations are processed in the PLC as 16-bit values. As an optimised version the process data PresentValueBool of data type BOOL can be used. PresentValueBool is TRUE if PresentValue is ACTIVE and FALSE if PresentValue is INACTIVE.
PresentValueEnumerated | If the PresentValue of a schedule object is a BACnet enumeration, the process data property PresentValueEnumerated reflects the current value of the property PresentValue.
PresentValueReal | If the PresentValue of a schedule object is of BACnet data type Real, the process data property PresentValueBool reflects the current value of the property PresentValue.
PresentValueSigned | If the PresentValue of a schedule object is of BACnet data type SignedInteger, the process data property PresentValueBool reflects the current value of the property PresentValue.
PresentValueUnsigned | If the PresentValue of a schedule object is of BACnet data type UnsignedInteger, the process data property PresentValueBool reflects the current value of the property PresentValue.


Managing dynamic objects

Dynamic objects are BACnet objects that can be created during runtime (RUN or Free RUN) on a server (local) or a client (remote), without having to activate/start TwinCAT. Dynamic objects of a local server are accessed via the Settings tab of the BACnet server. In the Settings tab the dynamic objects can be displayed, created or deleted. In addition, the Scan button can be used to scan existing objects that are not displayed and integrate them into the tree diagram under the server (e.g. dynamic objects that were generated by a remote system). To create an object the corresponding Object Type and an Instance ID (object number) have to be entered. To delete, enter an existing object number with associated object type, or conveniently select it with the button "Dynamic Objects".

The procedure for accessing the dynamic objects of a client (remote access) is similar. The management function can be found in the Settings tab of the associated BACnet client. The difference in the management of a server is in the distinction between dynamic and static (configured offline) objects. In general all dynamic objects can be created/deleted, except loop, device and program objects. Static objects can neither be created nor deleted at runtime. However, since the BACnet communication makes no distinction between dynamic and static objects, there is no difference in how the objects are displayed in the tab "Settings" → "View Objects" of the BACnet client. The "Online Objects" dialog therefore lists all objects that the client side makes available. An attempt to delete a static object is acknowledged with fault feedback from the BACnet client (error result). The Settings tab of the BACnet client offers an option to create several dynamic objects simultaneously. To this end press the shortcut CTRL+SHIFT when pressing the Create button.

Dynamic objects are indicated with a green symbol under a BACnet server. Due to the client behaviour mentioned above, on the client side there is no distinction in the tree view.

During the dynamic creation of client objects the user can specify whether or not an object ID has to be specified in the CreateObject service. It should be noted that the devices from some manufacturers only support dynamic object creation without specification of an object ID. In this case the "Instance ID" option can be deselected.

Since dynamic objects are only created at runtime, there is no process data mapping option. The linking of process data must be known during loading of the TwinCAT configuration. This in turn precludes offline configuration of dynamic objects. The configuration therefore always takes place under the Online tab. Please note that the configuration of all dynamic objects and their properties is only retained after a restart if data persistence is activated (For information on data persistence please refer to section "Persistent data")


Backup and restore

BACnet enables the creation of backup for the configuration of a BACnet controller. In TwinCAT BACnet/IP the configuration may consist of a number of files. One of the main files is CurrentConfig.xml, which contains the general TwinCAT configuration. In addition TwinCAT BACnet/IP uses a further BACnetOnline file which contains the relevant data that were modified during runtime and differ from the original configuration of CurrentConfig.xml. Further files may be used to determine a configuration, e.g. a PLC boot project or project-specific files.

The BACnet backup and restore mechanism enables a customisable number of files to be backed up and restored using the file services. Once a backup was selected via the corresponding BACnet services, a BACnet client can determine which BACnet file objects belong to a backup configuration belong by reading the device object property ConfigurationFiles. The BACnet file objects refer to the corresponding file names. Please note that TwinCAT BACnet/IP treats all files relative to the boot project folder (default: "C:\TwinCAT\Boot"). Backup-relevant files should therefore be stored in this folder.

Creating a BACnet server automatically creates two file objects, which refer to the file CurrentConfig.xml and the BACnetOnline file.

BACnet TwinCAT/IP enables further files to be included in a backup configuration. To this end can a new BACnet file object can be added. The file name can be configured in the property ObjectName. If the property FileType is initialised with the string "TwinCAT Configuration File", during a backup request this file object is included in the property ConfigurationFiles so that it can be backed up by a BACnet client and subsequently restored. The screenshot illustrates how the boot project for PLC runtime 1 can be included in the backup configuration.

Backup-relevant data can also be stored in the PLC. A feedback mechanism between BACnet and a PLC ensures that the PLC backup data are written to the storage medium during a backup operation. Cyclic monitoring of the property SystemStatus of the server device object enables the timing of a backup to be detected (BackupInProgress (5)). A feedback procedure can be activated via the server control status word (ServerControl) by setting bit 0. If bit 0 is set in the control status word, the BACnet stack waits for the PLC data to be written before processing the backup request of a BACnet client (once bit 1 is set in the control status word). A corresponding PLC sequence is shown below:

  1. Set bit 0 in the control status word
  2. Monitor SystemStatus - when value BackupInProgress (5): writing the relevant data
  3. After the write operation set bit 1 in the control status word
  4. When SystemStatus has the value operational (0) again: delete bit 1

A further backup-relevant file is "BACnet_LastRestoreTime.wbp", which is stored in the boot folder of TwinCAT. This file contains data that have to survive a restore. They include the properties LastRestoreTime and DatabaseRevision.

TwinCAT BACnet/IP currently does not support triggering of a backup or restore operation. A corresponding building management tool can be used to backup and restore the Beckhoff controllers. In other words, only the server is supported in this case, not the client side.


Persistent data

If BACnet properties are changed via BACnet or the online dialog of server objects, the changes are initially lost when TwinCAT is restarted, since the corresponding values from the Settings dialog are used for initialisation. In order to retain the data persistently during a device restart, the function Persist Server Online Data can be used in the Settings tab of the BACnet server. If this function is activated, during shutdown and perhaps cyclically the values of all BACnet properties that have changed compared with the initial configuration are saved in a file and reloaded when a configuration is loaded. The file is created in the boot folder of the TwinCAT installation ("C:\TwinCAT\Boot") and has the name "BACnetOnline_1010010.wbp". The number code identifies the server via a TwinCAT(TcCOM) object ID.

Devices with UPS can be shut down even if the supply voltage is lost, so that the storage of persistent data is ensured. For devices without UPS the data have to be stored cyclically or in the event of changes. The "Use UPS" option in the Settings tab of the BACnet server can be used to specify whether data should be stored at a specified interval during operation. The dialog box "Backup Interval" can be used to specify the interval (in minutes) at which modified BACnet properties should be saved. Data are only saved if a BACnet property has been changed since the last backup.

The option "Use UPS" does not result in automatic shutdown of the device in the event of a power failure. Monitoring of the UPS status and associated tasks can be implemented in the PLC with the aid of corresponding libraries. The option "Use UPS" only disables periodic saving of persistent data. Writing of persistent data has to be affected manually or through the PLC via ADS or the property PersistentData.

Attention 		Note the maximum number of write cycles
If data are cyclically saved to a flash medium, the storage medium may be damaged or destroyed if the backup intervals are too short. It is therefore important to ensure that the number of write cycles specified by the flash manufacturer is not exceeded over the expected operating period.

Note that with this functionality all settings that were made in the Settings tabs of the objects after the current TwinCAT configuration has been activated become invalid, since all settings are taken from the BACnetOnline file. If a configuration has to be changed, first deactivate the function and delete the BACnetOnline file with the Windows Explorer. Attention: Once the function has been disabled, the configuration is still loaded with activated persistence function, i.e. the BACnetOnline file is generated again when the system is shut down. Writing of the file is only disabled when the configuration is activated without the persistence function.

Dynamically generated BACnet objects are also included in the persistent data and re-generated during a restart.

When a new TwinCAT BACnet/IP configuration (or a BACnet server, to be more precise) is created, a unique Config ID is generated within the project, through which the BACnetOnline files are allocated to a configuration (CurrentConfig.xml). This is checked when the online data are loaded. If the Config ID does not match the loaded project, the online data are not applied. In this case the data from the Settings tabs are used.

Loading and saving persistent data

This section describes the procedure for loading and saving the online data. It ensures that a valid version of the persistent data is always available, even in the event of a power failure. Loading and saving of persistent data always takes place in RUN mode, and only when persistent data were activated.

Sequence: Loading the BACnetOnline file

  1. If present: load the file "BACnetOnline_XXXXXXXX.wbp"
  2. After successful loading: rename the file "BACnetOnline_XXXXXXXX.wbp" to "BACnetOnline_XXXXXXXX.wb~"
  3. If "BACnetOnline_XXXXXXXX.wbp" is not present: load the file "BACnetOnline_XXXXXXXX.wb~"

Sequence: Writing the BACnetOnline file:

  1. Rename an existing file "BACnetOnline_XXXXXXXX.wbp" to "BACnetOnline_XXXXXXXX.wb~"
  2. Write the modified property and object data to the file "BACnetOnline_XXXXXXXX.wbp.tmp"
  3. After the write operation: rename the file "BACnetOnline_XXXXXXXX.wbp.tmp" to "BACnetOnline_XXXXXXXX.wbp"

Please note that the described procedure requires twice the memory on the flash memory.

Relevant changes

As already mentioned, online data are only saved if appropriate changes were made. Changes can be triggered by:

  • Writing of a BACnet property via WriteProperty or WritePropertyMultiple
  • List manipulation via AddListElement, RemoveListElement
  • Creation of dynamic objects via CreateObject
  • Deleting of dynamic objects via DeleteObject
  • Changing of BACnet properties through state machines within objects (e.g. ElapsedActiveTime of binary objects, LogBuffer in the TrendLog object)
  • Changing of the Broadcast Distribution Table (BDT) if BBMD is activated

Changes in the following BACnet properties generally do not lead to persistence-relevant changes:

  • Permanently write-protected BACnet properties (e.g. Protocol Revision, Object Type, ObjectIdentifier)
  • ActiveCOVSubscription: COV subscriptions are not made persistent, as specified in the BACnet specification
  • BACnet properties resulting from other BACnet properties or internal system states (LocalDate, LocalTime, StatusFlags, EventState, DeviceAddressBinding, ObjectList, ModificationDate, SystemStatus, PersitentData, ActivePriority)
  • DaylightSavingsStatus and UtcOffset if operating system time settings are used (Time management "Use operating system settings")

Manual saving of persistent data

Saving of persistent data can be triggered manually/programmatically. An acyclic (ADS) interface is available via which writing of the BACnet online data can be triggered:

IndexGroup | IndexOffset | Description
0x80C00000 | always 0 | Triggering saving of the persistent data. Only valid for BACnet servers if Persist Online Data is active.

Saving can be triggered via ADS with the aid of the System Manager (BACnet server Settings tab, "Save" button).

Saving of the persistent data can also be triggered via the BACnet network and the manufacturer-specific BACnet property PersistentData (of the device object). A state diagram for the BACnet property PersistentData is shown below.

The BACnet property PersistentData is only visible if the persistent data are activated and the configuration is executed in RUN mode. After the initialisation the property of the BACnet-data type Enumerated indicates whether a relevant BACnet property has changed or whether dynamic objects were created since the persistent data were last saved. If the data are unchanged the property PersistentData has the value NOCHANGE (2). If data are changed via BACnet (WriteProperty, WritePropertyMultiple, CreateObject, DeleteObject, WriteBDT), via ADS Write or through an object state machine, this is indicated by the property PersitentData with the value Ready (3).

If the property PersistentData has the value Ready (3), writing can be triggered via BACnet by writing the value Write (4). During writing PersitentData has the value Writing (5). After successful writing of the persistent data PersistentData enters the state NoChange (2) or Ready (3), depending on whether relevant data have changed during writing.

If persistent data are saved through manually triggering of the write operation, it is advisable to set the backup interval to a suitably high value.

Diagnosis persistent data

The diagnostic functions of the BACnet device enable information relating to the processing of persistent data to be viewed.

Persistence-specific information can be found under ServerInfo:

  • nPropChanges: Indicates how often BACnet properties were modified since the system startup.
  • nPersistWrites: Indicates how often the BACnetOnline file was written since the system startup.
  • persistChangeSetId: After each writing of the online file a ChangeSet ID is incremented in the BACnet driver, in order to enable detection of changes of BACnet properties since the last writting. This ChangeSet ID is written to the online file and indicates how often a project was saved since the first start. During a BACnetrestore the ChangeSet ID of the written online file is used.
  • secPersistNextWrite: Indicates in how many seconds the next cyclic writing of persistent data is triggered.
  • persistLastWrite: Indicates when the online file was last written. If it has not been written since the system startup, this timestamp is initialised with *.*.*.* *.*.*.* .


PLC automapping

Introduction

Special comments that are added after the PLC variable declaration can be used for automated configuration of BACnet objects from the PLC program. The procedure can be used to configure BACnet objects, link BACnet property variables with PLC variables and initialise BACnet properties.

PLC automapping can be carried out via the BACnet server in the Settings tab, once the PLC project has been added to the hardware configuration. Automapping is triggered by pressing the Map button once the required PLC program has been selected:

PLC automapping for BACnet servers

The following source code extract illustrates the application of automapping comments. An allocated variable "av0" of type REAL created. The used comments define BACnet properties for use with automapping. The general comment syntax is defined by the PLC. Comments start with "(*" and end with "*)". Comments with the special prefix "~" are transferred by the PLC compiler into the TPY file for the respective symbols. These special comments, referred to as property, always have the following structure: "( NAME : VALUE : COMMENT )". For BACnet automapping the name is composed of "BACnet_[BACnet-Property-Name]". "VALUE" depends on the BACnet property and is explained accordingly.

In the example the symbol "av0" is annotated with 3 BACnet properties, which specify that it is an AnalogValue object (AV). The object instance is 100. For the property ObjectIdentifier it should be noted that in the PLC comment it only contains the instance number, not the coded object type, as in BACnet. In the example, automapping creates a BACnet object of type AnalogValue with the instance number 100. For each symbol a link can be made with a cyclic BACnet property variable. For variables that are not to be linked the comment "NOLINK" (see note in the appendix) can be used. For each symbol only one property may exist for linking. In the example the property PresentValue of the AnalogValue object is linked with the PLC variable "av0".

av0 AT %I* : REAL;             (* ~ (BACnet_ObjectType         :
AV             : NOLINK)

                                    (BACnet_ObjectIdentifier   :
100            : NOLINK)

                                    (BACnet_PresentValue
:                : )

                                *)

A further example is provided below. In this case a BACnet object of type BinaryInput is created. No object instance is defined. During automapping an available object instance number is generated automatically. The example demonstrates how the values of certain BACnet properties can be pre-initialised. The BACnet properties Description and ObjectName are initialised with the values "Hello, BACnet" and "BinaryInput_1". After automapping the corresponding values appear in the generated BACnet object (Settings tab) when the configuration is activated "Online". In addition the object name is used in the System Manager tree. In the example a variable of type BOOL is linked with the property PresentValueBool. Although the BACnet data type of the PresentValues of binary objects is an enumeration type, the auxiliary property PresentValueBool was introduced for efficient handling of the PLC, in order to be able to link Boolean variables. For further details please refer to section "Process data".

bi0 AT %I* : BOOL;             (* ~ (BACnet_ObjectType         :
BI             : NOLINK)
(BACnet_Description        : Hello, BACnet  : NOLINK)

                                    (BACnet_ObjectName         :
BinaryInput_1  : NOLINK)(BACnet_PresentValueBool   :
:)*)

Even if variables of primitive type are used, several variables can be linked with a BACnet object. To this end identical object type and object instance parameters should be specified for two variables. In the example the BACnet properties PresentValue and StatusFlags are linked with AnalogValue object "100".

av0 AT %I* : REAL;             (* ~ (BACnet_ObjectType         : AV             :
NOLINK)

                                    (BACnet_ObjectIdentifier   :
100            : NOLINK)

                                    (BACnet_PresentValue
:                :)

                                *)
av0_StatusFlags AT %I* : WORD; (* ~
(BACnet_ObjectType         : AV             : NOLINK)

                                    (BACnet_ObjectIdentifier   :
100            : NOLINK)

                                    (BACnet_StatusFlags
:                :)

                                *)

Commandable properties

BACnet objects can also be accessed in write mode from the PLC. We recommend to only link commandable BACnet properties in this way. Commandable BACnet properties are linked with a PriorityArray and support write access with priorities 1 to 16. For BACnet properties without support of priorities, which are linked to the PLC, the behaviour for BACnet network write access via BACnet WriteProperty is undefined, since the property value is overridden cyclically by the PLC.

In the example a "Q"-allocated variable is defined, which is linked with the PresentValue of an AnalogOutput object. Writing from the PLC results in an entry with priority level "8" in the PriorityArray. The PresentValue properties of BinaryValue, BinaryOutput, AnalogValue, AnalagOutput, MultistateValue and MultistateOutput objects are commandable. The highest active priority (1=highest, 16=lowest) is set as PresentValue. A priority in the PriorityArray is active if it is not NULL.

ao0_PresentValue8 AT %Q* : REAL;(*~ (BACnet_ObjectType         : AO             :
NOLINK)

                                    (BACnet_PresentValue_Priority8
:            :)

                                *)

A special feature of commandable properties is the entry NULL in the PriorityArray, which in BACnet represents a distinct data type that is different from the respective value data types (REAL, BINARY_PV, UNSIGNED). The value NULL, which deactivates a priority level in the PriorityArray, can be written for the respective objects via the linked variable as follows:

  • BinaryValue, BinaryOutput : Priority-based PresentValues are linked as WORD (or an enumeration type, e.g. E_BACNET_BINARYPV). A 0 entry results in an INACTIVE entry in the PriorityArray, 1 results in ACTIVE and values greater than 1 result in NULL.
  • AnalogValue, AnalogOutput: To generate a NULL entry in the PriorityArray a special bit coding of REAL values can be used, which are defined as NaN (not a number). This value can be generated via the function "F_BACnet_NAN()" in the BACnet PLC library "TcBACnet.lib". Note that this value is not used for calculations in the PLC, since they would trigger a floating-point exception. A value of 0.0 also results in a value of 0.0 in the PriorityArray. In addition, the following applies for AnalogOutput objects: writting values outside the Min/MaxPresValue range leads to NULL in the PriorityArray.
  • MultistateValue, MultistateInput: Is the value 0 or a value that is greater than the BACnet property NumberOfStates is written, a NULL entry is generated in the PriorityArray.

Structuring

Function blocks (FBs) are also supported for structured linking of BACnet objects during automapping. The source code extract shown below illustrates the declaration of a BACnet function block. In order to be considered in automapping, these blocks must begin with the prefix "FB_BACnet". The example defines an FB for an AnalogOutput object, which is available as a template in the BACnet PLC library "TcBACnet.lib". The properties PresentValue, StatusFlags, Reliability and OutOfService are linked as input variables to the PLC, the property PresentValue with write-access, priority 8.

FUNCTION_BLOCK FB_BACnet_AnalogOutput
VAR_OUTPUT
    ObjectType: E_BACNETOBJECTTYPE;           (* ~ (BACnet_ObjectType       :AO    : NOLINK) *)
    PresentValue AT%I*: REAL;                 (* ~ (BACnet_PresentValue     :      :) *)
    StatusFlags AT%I*: UINT;                  (* ~ (BACnet_StatusFlags      :      :) *)
    Reliability AT%I*: E_BACNETRELIABILITY;   (* ~ (BACnet_Reliability      :      :) *)
    OutOfService AT%I*: BOOL;                 (* ~ (BACnet_OutOfService     :      :) *)
END_VAR
VAR_INPUT
    PresentValue_Priority8 AT%Q*: REAL;       (* ~ (BACnet_PresentValue_Priority8 ::) *)
END_VAR

This FB can be instantiated in the main program (or another FB, program). Additional comments can be specified during instantiation. Comments at the instantiation level have higher priority than comments at FB declaration level. In the example an AnalogOutput object is created, and the object instance and the BACnet property Description are initialised at instantiation level. Through the FB declaration the properties PresentValue, StatusFlags, Reliability, OutOfService and PresentValue_Priority8 are linked in the generated BACnet object.

ao1 : FB_BACnet_AnalogOutput;                 (* ~ (BACnet_ObjectIdentifier : 100 : NOLINK) *)
ao1 : FB_BACnet_AnalogOutput;                 (* ~ (BACnet_ObjectIdentifier : 100   : NOLINK)
                                                   (BACnet_Description      : hi,ao : NOLINK)
                                              *)

BACnet FBs can be used hierarchically, i.e. an "FB_BACnet_Pump" containing several FB_BACnet_AnalogOutput instances can be defined, for example. For nesting depths greater than one a StructuredView object is created in the System Manager. BACnet comments are not handed down to several hierarchical levels. Only the instantiation and declaration levels are supported. An exception is the BACnet comment BACnet_ObjectIdentifier, which is resolved over several hierarchical levels, in order to support ID allocation for nested FBs.

If an object instance is specified at a higher level, it may potentially affect many objects of the same type. The starting point for generating an object ID is the specified ID (if, for example, 1000 is specified as the object instance, a new free ID above 1000 is identified). An FB_BACnet_Room with 2 AV and 2 BV objects and a start ID of 1000 will therefore generate BACnet objects AV:1000, AV1001, BV:1000 and BV:1001. The resulting object IDs are calculated before the actual mapping operation. If objects with the determined IDs already exist, e.g. from an IO mapping, the existing objects are used/linked, and no new objects are created.

In addition to nested FBs, one-dimensional arrays are also supported. The following example shows the declaration of an array raume of type FB_BACnet_Raum that contains further BACnet objects. In this way systematic units with identical functionality can be managed. Arrays at different nesting levels are also supported, so that a BACnet object fbHaus[1].EtageU.Raum[10].tmpSollt can be generated, for example.

raume : ARRAY[0..10] OF FB_BACnet_Raum;

Configuration function block instances

BACnet comments on function block declaration level are used for all instances of the function block in common. For certain BACnet properties it is important to be defined per instance. As one example, this feature allows to define object identifiers of sub function block BACnet objects. It is also possible to link hardware modules on an instance level. In the following example, BACnet properties are defined per function block instance.

      FUNCTION_BLOCK FB_BACnet_SubSub
VAR
bi : FB_BACnet_BinaryInput; (*~(BACnet_OutOfService : TRUE: NOLINK)*)
bi2 : FB_BACnet_BinaryInput;
END_VAR
FUNCTION_BLOCK FB_BACnet_Sub
VAR
sub1 : FB_BACnet_SubSub;
sub2 : FB_BACnet_SubSub;
subArr : ARRAY[0..1] OF FB_BACnet_SubSub;
END_VAR

      PROGRAM SIMPLE
VAR
s1 :FB_BACnet_Sub; (* ~   { BACnet_ObjectIdentifier<sub1/bi>                : 1017   : }
                        { BACnet_ObjectIdentifier<sub2>           : 1028   : }
                        { BACnet_ObjectIdentifier<subArr[0]/bi>   : 5555   : }
                        { BACnet_ObjectName<sub2/bi>              : biname : NOLINK }
                 *)END_VAR

By the annotation of an instance path after the BACnet property name comment, BACnet comments can be applied to sub elements of a function block instance. For this, the instance path can be given in "<" and ">". Within the example above, to the BACnet object bi of instance sub1, object identifier 1017 will be applied. Single sub levels can be separated using "/". BACnet property comments can also be applied to sub levels. In the example, object identifier 1028 is applied to the function block FB_BACnet_SubSub instance sub2, causing the generatin of object identifiers 1028 for object s1.sub2.bi and 1029 for object s1.sub1.bi2. The instance path is also allowed to contain array elements.

Write protection and optional properties

Special comment options were introduced for controlling write protection and optional properties. Additional options can be specified in the form of a comma-separated list in the comment part of the PLC comments. DISABLE deactivates an optional property. WRITEPROTECT activates write protection for a writeable property. Make sure that the option NOLINK is specified when configuring multiple properties. The following example shows the configuration of write protection and optional properties.

bo1: FB_BACnet_BinaryOutput; (* ~(BACnet_NotifyType             :        : DISABLE,NOLINK)
                                 (BACnet_ChangeOfStateTime      :        : DISABLE,NOLINK)
                                 (BACnet_ChangeOfStateCount     :        : DISABLE,NOLINK)
                                 (BACnet_ActiveText             : AN     : WRITEPROTECT,NOLINK)
                                 (BACnet_InactiveText           : AUS    : WRITEPROTECT,NOLINK)
                              *)

Property references

The REFERENCE option was introduced for configuring reference properties. Automatic generation of object IDs means that value initialisation of properties cannot be used for referencing properties of other PLC BACnet objects, since the object IDs are unknown when the PLC program is implemented. Specification of the REFERENCE option and property name as a suffix enables referencing of automatically generated objects. A simple heating system is described below as an example. Set values, actual values and control values are specified via analog* BACnet objects, which are linked with a Loop object via references.

fbSollwert   : FB_BACnet_AnalogValue;
fbStellwert  : FB_BACnet_AnalogOutput;
fbIstwert    : FB_BACnet_AnalogInput;
fbTempRegler : FB_BACnet_Loop; (* ~ (BACnet_ManipulatedVariableReference : ./fbStellwert : REFERENCE_PresentValue)
                                    (BACnet_SetpointReference            : ./fbSollwert  : REFERENCE_PresentValue)
                                    (BACnet_ControlledVariableReference  : ./fbIstwert   : REFERENCE_PresentValue)
                                *)

The REFERENCE option also works for Schedule and TrendLog objects:

bi       : FB_BACnet_BinaryInput;
bv      : FB_BACnet_BinaryValue;
tl      : FB_BACnet_TrendLog; (* ~(BACnet_LogDeviceObjectProperty  : ./bi : REFERENCE_PresentValue) *)
sched   : FB_BACnet_Schedule; (* ~(BACnet_ListOfObjectPropertyRefs : ./bv : REFERENCE_PresentValue) *)

View configuration

During PLC automapping, StructuredView objects are created for each nesting depth in the form of programs and function blocks, in order to map the PLC structure to BACnet. Depending on the component identification system used, it may be necessary to adapt the names BACnet objects and their structure with a name prefix. The PLC comment "BACnet_StructuredViewPath" can be used to define dedicated name prefixes for PLC automapping. "BACnet_StructuredViewPath" can be used to annotate any variable at the required structuring levels.

      PROGRAM MAIN
VAR
  viewDummy : BOOL; (* ~( BACnet_StructuredViewPath : \/Building1\/Floor2 : ) *)
  room1 : FB_BACnet_Room;
  room2 : FB_BACnet_Room;
END_VAR

In the example the name Building1.Floor2.room1.XXX is used for all BACnet objects within the function block FB_BACnet_Room, instead of the name MAIN.room1.XXX. In addition to the use for the names of BACnet objects, a StructuredView object is also created for each hierarchical level. Hierarchical levels are defined by the string "\/".

Facility identitication

Depending on the used facility identification system, it can be neccessary to adjust generated BACnet object names. As a default structure levels will be separated using ".". By annotating the key word "StructureSeparator" to any variable of a programm or global variable, the separator symbol can be exchanged or even totally eliminated. The following example demonstrates the annotation of the separator symbol "_". A new separator symbol should only be defined once within a project.

dummy : BOOL; (* ~( BACnet_StructureSeparator :_: ) *)

Initialisation of complex property values

The initialisation of property values via PLC automapping is limited by the PLC comment syntax. The reserved characters "(", ")", ":", "*" and " cannot be used. In addition, for BACnet properties with selection type (Choice) or optional fields it is not always possible to unambiguously analyse each string, if an optimised display form is used, as in the System Manager.

For certain properties special parsers were implemented, which enable simplified configuration of property values. The following example shows how the StateText property of a MultiStateValue object can be initialised.

mv : FB_BACnet_MultiStateValue;  (* ~(BACnet_StateText   : {Low;Medium;High}       : NOLINK )*)

BitField properties (EventEnable, AckRequired) can be initialised by specifying a hexadecimal number. In this case it is advisable to use the corresponding value from the System Manager:

bi : FB_BACnet_BinaryInput;      (* ~(BACnet_EventEnable : 0xE005                  : NOLINK )*)

The Priority property of the NotificationClass object can also be initialised in abbreviated form. In the example this array property is initialised with the values 12, 12 and 122. For the initialisation of BitField properties the more transparent form of array-like initialisation was implemented. In the example the bits for "to_offnormal" and "to_fault" are set in the property AckRequired. A BitField property without set bit can be initialised with the string "{}".

nc : FB_BACnet_NotificationClass;(* ~(BACnet_Priority    : {12;12;222}             : NOLINK)
                                     (BACnet_AckRequired : {to_offnormal;to_fault} : NOLINK)
                                  *)

Since it is not possible to implement dedicated parsers for all complex properties, the option of initialisation with the aid of XML was introduced. XML has the advantage that it is not necessary to use the reserved comment syntax characters, so that there are no restrictions for initialisation of the property values. The XML values for the property initialisation can simply be created via the Copy&Paste function for the property values. A property can be created in the System Manager using wizards. Via the context menu in the property view ("Online" or "Settings") the current value of a property can be added to the clipboard via "Copy Value" (or via the shortcut CTRL-C) and used in PLC Control via "Paste" or CTRL-V.

Is the SHIFT key is pressed while using the "Copy Value" function, the XML string is copied as a line. Otherwise a structured variant is generated in multi-line mode. Using single-line mode makes the variable declaration in the PLC program more transparent. The following example illustrates how the property StartTime of a TrendLog object is initialised via the XML syntax:

tl : FB_BACnet_TrendLog; (* ~(BACnet_StartTime :
<BACnetDateTime>
  <date>
    <year>112</year>
    <month>7</month>
    <day>16</day>
    <dayOfWeek>1</dayOfWeek>
  </date>
  <time>
    <hour>12</hour>
    <minute>30</minute>
    <second>0</second>
    <hundredths>0</hundredths>
  </time>
</BACnetDateTime>
: NOLINK )*)

Connecting hardware modules

In general, the connection to hardware modules can be done via Io-Automapping and the assignment of according object identifiers to BACnet objects defined within PLC code. To support an efficient generation of BACnet projects, it is possible to configure the connection to hardware modules directly within PLC code, without the requirement of an Io-Automapping. Using the key word LINKPATH, it is possible to link a BACnet property variable directly to an Io-variable. Despite linking a PLC variable to a BACnet property variable, in this case a BACnet property variable will directly be linked to a variable of another device ( device-device mapping).

Please pay attention to the comment start- and ending symbol. PLC comments can be started by "(" or "{" and closed by ")" or "}" respectively. If the content of a comment contains e.g. "(" start- and end-symbol should be "{" and "}" and vice e versa. Usually external link may contain "(" or ")". So togehter with the LINKPATH option "{" and "}" should be used.

The following example shows the connection of a BinaryInput BACnet object with the first channel of the third module (KL1002). Using the variable PresentValue of FB_BACnet_BinaryInput the PLC code can directly access the hardware value.

bi : FB_BACnet_BinaryInput;(* ~{ BACnet_RawIoBinaryBoolValue : TIID^Rt-Ethernet^BK9000^Term 3 KL1002^Channel 1^Input : LINKPATH } *)

By using additional parameters of the LINKPATH option: Offset1, Offset2 and the bit size of the link can be specified (LINKPATH<[Offset1],[Offset2],[bitsize]>). Using a bit size of 0, automatically the maximal possible number of bits will be linked. Without the specification of additional parameters Offset1 and Offset2 will be initialised to 0. Offset1 refers to the BACnet property variable. Offset2 refers to the external link.

bx : FB_BACnet_BinaryInput;(* ~{ BACnet_RawIoBinaryBoolValue : TIID^Rt-Ethernet^BK9000^Term 3 KL1002^Channel 1^Input : LINKPATH<0,0,1> } *)

In conjunction with function blocks, also sub elements of function block instances can be linked to hardware variables. By using the instance path syntax "<[]>", a BACnet property variable can be link to hardware.

      PROGRAM SIMPLE
VAR
s1 :FB_BACnet_Sub; (* ~   { BACnet_RawIoBinaryBoolValue<sub1/bi>  : TIID^Rt-Ethernet^BK9000^Term 3 KL1002^Channel 1^Input : LINKPATH }
                        { BACnet_RawIoBinaryBoolValue<sub2/bi>  : TIID^Rt-Ethernet^BK9000^Term 3 KL1002^Channel 2^Input : LINKPATH }
                        { BACnet_RawIoBinaryBoolValue<sub1/bi2> : TIID^Rt-Ethernet^BK9000^Term 2 KL1002^Channel 2^Input : LINKPATH }
                 *)END_VAR

In addition, PLC-automapping allows linking variables out of BACnet. Using the option "ExtLink", any (located) PLC symbol can be linked to an external variable (e.g. a hardware component). Using the option "ExtLink2" 2 external variables can be linked together. Using addional parameters as already introduces to LINKPATH, Offset1, Offset2 and the bit size can be defined for the link. In the following example the usage of this option is demonstrated.

b1 AT%I*        : BOOL;     (* ~{ ExtLink             : TIID^Rt-Ethernet^BK9000^Term 2 (KL1002)^Channel 2^Input       : } *)
bDummy  : BOOL;  (* ~{ ExtLink2              : TIID^Rt-Ethernet^BK9000^Term 5 (KL2012)^Channel 1^Output      : TIID^Rt-Ethernet^BK9000^Term 2 (KL1002)^Channel 2^Input } *)
b1 AT%I*        : BOOL;     (* ~{ ExtLink<0;0;1>        : TIID^Rt-Ethernet^BK9000^Term 2 (KL1002)^Channel 2^Input       : } *)
bDummy  : BOOL;  (* ~{ ExtLink2<0;0;1>         : TIID^Rt-Ethernet^BK9000^Term 5 (KL2012)^Channel 1^Output      : TIID^Rt-Ethernet^BK9000^Term 2 (KL1002)^Channel 2^Input } *)

As a good starting point for linking hardware modules the EXP-export of TwinCAT BACnet/IP can be used. Within the EXP-Export configuration dialog, the option "Export I/O configuration" enables the generation of function block definitions of hardware modules for TcBACnet.lib. For each found IO-Bus definitions for BACnet function blocks will be generated. The procedure EXP-Export together with a PLC automapping creates a similar configuration as an IO-Automapping. The advantage of the PLC procedure is that hardware modules can be integrated into the logic structure of the PLC-/facility. In addition hardware module, which are not desired to be visible via BACnet can be deleted easiely.

PLC automapping for BACnet clients

To link PLC variables with process data properties of remote BACnet objects, Device ID can be specified as a comment, in addition to the object type and instance. In this case the PLC variables are linked with previously created BACnet objects (e.g. through scanning of clients). Support for creating remote BACnet objects via PLC automapping is currently not offered (unlike for servers). Only automatic activation of process data and linking is supported.

In the following source text extract a variable of type REAL is created. During automapping it is linked with the property PresentValue of object AnalogValue:100 under the client with the BACnet-ID "42". The process data variable of the remote BACnet object is activated automatically.

av0 AT %I* : REAL;             (* ~ (BACnet_ObjectType             : AV    :
NOLINK)

                                    (BACnet_DeviceID
: 42    : NOLINK)

                                    (BACnet_ObjectIdentifier
: 100   : NOLINK)

                                    (BACnet_PresentValue
:       :)

                                *)

Auxiliary properties are available for the configuration of the process data-specific parameters of client properties, which enable all options that can be set in the System Manager to be configured automatically. These are write priority for PresentValue properties, cycle time, COV increment, COV resubscription interval for COV subscriptions and flags for configuring whether data are to be processed cyclically or via COV or OnChange. The following source code extract illustrates the application of these auxiliary properties.

ao0 AT %Q* : REAL;             (* ~
(BACnet_ObjectType             : AO     : NOLINK)

                                    (BACnet_DeviceID
: 42     : NOLINK)

                                    (BACnet_ObjectIdentifier
: 0      : NOLINK)

                                    (BACnet_RemotePriority
: 8      : )

                                    (BACnet_RemoteCycleTimeWrite
: 1000   : )

                                    (BACnet_RemoteFlagsWrite
: 1      : )

                                    (BACnet_PresentValue
:        : )

                                *)
ao1 AT %I* : REAL;             (* ~
(BACnet_ObjectType             : AO     : NOLINK)

                                    (BACnet_DeviceID
: 42     : NOLINK)

                                    (BACnet_ObjectIdentifier
: 0      : NOLINK)

                                    (BACnet_PresentValue
:        : )

                                    (BACnet_RemoteCycleTimeRead
: 1000   : )

                                    (BACnet_RemoteFlagsRead
: 1      : )

                                    (BACnet_RemoteCovincrement
: 0,5    : )

(BACnet_RemoteResubscriptionInterval : 60 : )

                                *)

The RemoteFlagsWrite have the following meaning for output variable (%Q), from the configured controller to the remote device:

  • Bit 0: enable WriteOnChange
  • Bit 1: enable cyclic writing
  • Bits 8 - 15: cycle modulo - if the RemoteCycleTimeWrite is greater than the cycle time of the BACnet task, this value specifies the cycle for writing (e.g. 1 sec. RemoteCycleTimeWrite and BACnet task 10 ms means cycle offset 10 for 100 ms writing, starting from the start time of the BACnet object)

For RemoteFlagsRead - input variable (%I) - reading from a remote device the following applies:

  • Bit 0: use COV
  • Bit 1: use polling (if bit 0 is set polling is only used if the COV subscription fails)
  • Bits 8 - 15: cycle modulo - if RemoteCycleTimeRead greater than the cycle time of the BACnet task, this value specifies the cycle for writing ( e.g. 1 sec. RemoteCycleTimeRead and BACnet task 10 ms means cycle offset 10 for 100 ms reading, starting from the start time of the BACnet object)

If no auxiliary properties are specified for remote objects, the default settings of the System Manager are used:

  • RemotePriority : 16
  • RemoteFlagsRead : 1
  • RemoteFlagsWrite : 1
  • RemoteCycleTimeRead : 1000
  • RemoteCycleTimeWrite : 1000
  • RemoteResubscriptionInterval : 240
  • RemoteCovIncrement : 0.0

For priority-based properties (PresentValue) a write priority can be configured, in order to enable access to higher priorities of the PriorityArray. As for servers, the value NULL can be written to the associated PriorityArray in order to disable this priority level. For analog and binary objects this is done in the same way as for servers (value > 1 for binary objects; NaN for analog objects). For AnalogOutput objects the Min/MaxPresValue range is not monitored, which means that NULL can only be generated via NaN. In contrast to servers, for multistate objects only writing of 0 results in NULL in the PriorityArray. For performance reasons the property NumberOfStates is not read by the remote device.

In conjunction with the TwinCAT BACnet PLC library "TcBACnet.lib" an efficient option for using client configurations in the PLC is available. Once the clients to be used have been added to the System Manager (e.g. through scanning of a BACnet network), the variable declaration and associated annotation with automapping comments can be generated by specifying a destination file with the extension "EXP" in the Export option of the Settings tab in the BACnet device. This can then be imported in a PLC project in PLC Control. The basis BACnet FBs of the library are used (e.g. "FB_BACnet_AnalogInput"). It is advisable to use the following approach:

  1. Create a new PLC project in PLC Control and add the library "TcBACnet.lib"
  2. Adjust the remote properties for automatic configuration of the client process data (comments after the instances of the library blocks)
  3. Compile and add the PLC project in the System Manager
  4. Via a BACnet server (not essential for running a client project) trigger PLC automapping (the BACnet server can then be deleted ...)
  5. The PLC variables are automatically linked with the client object properties, and the process data are set accordingly...

Appendix

  • Overview of "BACnet_ObjectType" object types: AI,AO,AV,BI,BO, BV, CAL,CMD,DEV,FILE,GROUP,LOOP,MI,MO,NC,PROG,SCHED,MV,TLOG
  • Note regarding NOLINK: The comment "NOLINK" is used to identify BACnet properties that are not to be linked with a variable, if multiple annotations exist for the variable. For selected BACnet properties "NOLINK" is set automatically, in cases where linking would not be meaningful. The following properties are implicitly annotated with "NOLINK": ObjectIdentifier, ObjectType and all remote* properties of the client-specific configuration.
  • In TwinCAT BACnet/IP an option was added to enable the property ObjectIdentifier as process data. Since this property is automatically treated as NOLINK, for compatibility reasons the LINK option was introduced, which overrides NOLINK for ObjectIdentifiers, so that this property can also be enabled as process data via PLC automapping.
  • Example for hierarchical FBs: see example "PLC automapping"


I/O automapping

TwinCAT BACnet/IP supports automated mapping of the modular IO systems K-bus and EtherCAT to BACnet. For each I/O channel a corresponding BACnet object of type BinaryInput, BinaryOutput, AnalogInput or AnalogOutput is configured automatically, process data are linked accordingly through Device2Device mapping, and the status of the I/O systems is transferred to the BACnet properties Reliability and StatusFlags, if applicable.

During mapping of I/O systems a distinction is made between I/O busses that consolidate a number of I/O modules and abstract an I/O strand in each case. By assigning a IoBusNr BACnet I/O objects are allocated to an I/O bus, via which the status is mapped, for example. If, for example, a K-bus strand is linked, the process data BusState can be used to detect whether the K-bus is ready for operation, and the property Reliability of all BACnet objects with the respective IoBusNr can be adjusted to the value NO_FAULT_DETECTED, otherwise NO_SENSOR or NO_OUTPUT. With TwinCAT BACnet/IP the I/O busses can also be linked to a K-bus, e.g. a BK9000, or further EtherCAT strands can be linked with a BACnet controller.

I/O bus automapping can be triggered via the "Settings" tab of a BACnet server. In the corresponding dialog box an I/O bus can be selected and the link can then be initiated via "Map" button:

The following I/O bus types are currently supported:

  • EtherCAT
  • BK1120, BK1250
  • K-BUS: CX1100-BK, CX5000-BK, CX-8000-BK
  • BK9000, BK9100, BK9050

In general, during I/O automapping the System Manager analyses all terminals under an I/O bus, creates corresponding BACnet objects and links process data. As an example, the figure shows how a digital output terminal (KL2114) at a CX9001-KBus is mapped to BACnet. The BACnet object "Terminal 2 (KL2114)_Chn1" of type BinaryOutput was created, and the output process data variable "Output" was linked with the BACnet process data variable "RawIoBinaryValue". This link ensures that the status of the digital output signal always matches the PresentValue of the BACnet object, as long as the object is not OutOfService. The polarity of the "BinaryOutput" is also taken into account. For further details please refer to section "Process data".

Automapping can be configured via an associated dialog, and the user can specify whether the bus status should be monitored automatically, or whether the process data can be linked automatically. In addition, the object ID allocation algorithm of the created BACnet objects can be specified. The following options are available:

  • "Use next available object identifier" - For each new BACnet object the next free object ID for the respective object type is used, starting from 0.
  • Module-based ID allocation - Based on a start ID the object ID for each new I/O module is incremented by a "Module increment". This can be used to ensure that the BACnet object ID can always be used to determine which terminal was linked. Example: With a start ID of 1000 and a module increment of 10, a BinaryInput object with ID 1113 is allocated to the third binary input channel of the eleventh terminal.

The other configuration options of I/O automapping are explained below:

  • "Create StructuredView object for mapping" - All BACnet objects generated for I/O mapping are created below a newly generated StructuredView object, in order to increase the transparency within a project
  • "Default Resolution" - Analog objects have a BACnet property resolution, which determines the scaling of I/O process data for the PresentValue of the BACnet object and vice versa. The parameter configured here is entered for all generated analog objects. To use the original hardware values, a resolution value of 0 should be set.
  • "Link raw PresentValue" - To link the PresentValue of the BACnet objects with the I/O modules, the corresponding RawIoPresentValue properties of the BACnet objects have to be activated and linked. This can be activated with this option.
  • "Link Status Byte" - Analog input terminals can use a status byte to indicate whether the respective process data value is valid or whether a limit was exceeded or a wire is broken, for example. If this option is activated, for analog input terminals (KX3XXX, EL3XXX) the data status of the terminal is linked with the BACnet I/O property "RawIoStatus". With EtherCAT the variables "Underrange" and "Overrange" are linked bit-based. If the corresponding status bits are set, the reliability is formed as follows during runtime:
    • If bit 0 is set, Reliability is UNDER_RANGE
    • Otherwise Reliability is OVER_RANGE, if bit 1 is set
    • Otherwise Reliability is UNRELIABLE_OTHER, if bit 6 is set
  • "Link coupler-/box state" - In a K-bus or Bus Couplers (BK9000) the process data BusState/couplerState and "BoxState" can be used to determine the communication and operating state of all terminals of the bus. Monitoring of the couplerState is realised centrally via the BACnet server. If this option is activated, available BusState/couplerState or "BoxState" are linked with the IoBusState process data of the BACnet server with the respective IoBusNr. The BusState of a K-bus is linked with the couplerState. If couplerState or "BoxState" for an I/O bus in the BACnet server is not equal 0, the reliability of all objects under the server with the corresponding IoBusNr is set to the value NO_SENSOR for input objects or NO_OUTPUT for output objects, provided the objects are not OutOfService.
  • "Link EtherCAT state" - For EtherCAT, a mechanism similar to Coupler/Box state for K-bus is available. In contrast to the K-bus, with EtherCAT the state of each terminal can be determined, which could enable disconnected terminals to be detected. With EtherCAT the status identification is therefore not realised centrally via the server, but takes place in each object by linking the process data property "RawIoECATState". Is the value of "RawIoECATState" is not equal 8 (OP), the reliability of the object is set to the value NO_SENSOR for input objects or NO_OUTPUT for output objects, provided the objects are not OutOfService.
  • "Link Wc state" - Monitoring of the EtherCAT Wc state is currently not supported.
  • "Link Status Override" - For terminals with manual operating mode the respective manual operation status can be mapped in BACnet to the StatusFlags via the override bit. For the terminals KM4602 and KM2652 a link with the process data property "RawIoStateOverride" is generated, if this option is activated.

Automatic mapping of EtherCAT and K-bus devices to BACnet objects is not always possible. In certain cases and with complex terminals it is in not always clear whether a BACnet object should be created for process data, or which BACnet object should be created. For a large number of basic input/output terminals the mapping is based on the following algorithm:

  • For all 1-series modules (KX-1XXX, EL-1XXX) a BACnet BinaryInput object is created for all input variables of type BIT that are found and the input data is linked, if the variable name is not equal "WcState" or "InputToggle".

  • For all 2-series modules (KX-2XXX, EL-2XXX) a BACnet BinaryOutput object is created for all output variables of type BIT that are found, and the process data is linked.

  • For all 3-series modules (KX-3XXX, EL-3XXX) a BACnet AnalogInput object is created for all input variables of type INT16 that are found, and the process data is linked.

  • For all 4-series modules (KX-4XXX, EL-4XXX) a BACnet AnalogOutput object is created for all output variables of type INT16 that are found, and the process data is linked.

The following terminals are treated in a special way:

  • KL1859 - 8 BinaryInput and 8 BinaryOutput BACnet objects are created.

With automapping the following BACnet properties are configured automatically:

  • ObjectIdentifier - is determined by the object ID allocation algorithm

  • ObjectName - is formed from the terminal name plus "_ChnX" for the channel number

  • IoBusNr - is incremented with each I/O automapping, starting from 0

  • IoModuleNr - indicates the number of the linked terminal, starting from 1

  • IoChannelNr - indicates the channel, starting from 1

  • Resolution - as specified in the configuration dialog


Data Types

TS8020 | TwinCAT BACnet Supplement

Diagnostics

This section explains how BACnet configurations can be analysed at runtime. Device status in the form of process data, and for BACnet clients the client status, are available for this purposes (see section Process data). Further details can be analysed via the "Diagnosis" tab of the BACnet device. This section describes the diagnosis via the "Diagnosis" tab and other troubleshooting strategies.

The diagnosis of the BACnet device is subdivided into several categories. These are described in detail in the following sections. Various options can be activated via a context menu:

"Auto Update" updates the diagnosis display in 1-second intervals. The category "Last Update" always shows the time at which the diagnosis was last read. The option "Enable Time Measurement" enables the category "ExecutionTime", through which the runtimes of the BACnet stack can be determined. For some values the option "Show Changes/s" activates an additional display showing the changes per second. It is formed over the last 10 read diagnostics and only works if "Auto Update" is activated. The option "Reset Values" resets all diagnostic values.

Notice 		Diagnostic data in the PLC
The diagnostic data presented in this section can also be accessed from the PLC via an ADS interface. The function block FB_BACnet_GetDiagInfo offers convenient access.

EthernetDevice category

The EthernetDevice category enables the number of sent and received messages (frames) and any receive and send errors to be determined. These data are read directly from the network driver, which means that they are not reset when a BACnet configuration is reloaded, although the option "Reset Values" deletes these values. This category counts all frames that are processed via the network driver, including non-BACnet frames.

The counter "sendFrames" indicates how many frames were used, "recvFrames" indicates the number of received frames. "txCnt" and "rxCnt" indicate the number of faulty received and sent frames. Unexpectedly high numbers may indicate network faults or overload (e.g. CRC errors, dropped frames).

ExecutionTime category

The option "Enable Time Measurement" enables runtime information forTwinCAT BACnet/IP to be determined. For each runtime a minimum (Min), maximum (Max) and current (Cur) value is determined. All run times are determined with a resolution of 100 ns. The following values are available as runtimes:

  • IoInXXXExecutionTime : Determines the runtime of the function InputUpdate of the BACnet device, which also executes the InputUpdate functions of all BACnet objects. This is where process data are copied from BACnet to the PLC/IO, among other tasks. In addition, the IoBusStatus is checked in the BACnet server and updated in the BACnet objects. For BACnet remote objects ReadProperty requests und CovSubscriptions for activated property process data are sent from this context.
  • IoOutXXXExecutionTime: Determines the runtime of the function OutputUpdate of the BACnet device, which also executes the OutputUpdate functions of all BACnet objects. In objects process data are copied from the PLC/IO and compared for changes. If a change has occurred, EventState machines can be executed and COV and event messages may be sent, depending on the BACnet property. For BACnet remote objects, write property requests are sent for activated property process data and detected in case of "WriteOnChange" modification of relevant properties (comparison).
  • CycleXXXExecutionTime: Determines the runtime of the function CycleUpdate of the BACnet device, which also executes the CycleUpdate functions of all BACnet objects. In the CycleUpdate context:
    • device, client, server state machines are executed,
    • received frames are processed,
    • Object EventState machines may be executed (in the event of property modifications),
    • COV and event messages are sent,
    • ADS requests are processed,
    • segmented frames are processed,
    • and persistent data are written.
  • InputXXXDistanceTime: Indicates the interval between two calls of function InputUpdate of the BACnet device. In the event of "Exceeds" of the BACnet task this can be used to determine at which maximum interval the BACnet stack is executed.

In the top row of the category Execution Time the values IoIn, IoOut and cycle XXXExecution time are consolidated in the form of minimum, maximum and current values (in microseconds).

ConfirmedServices category

This category can be used to determine statistics for sent and received (acknowledged) BACnet messages. Acknowledged services operate in BACnet based on the client-server principle. A client sends a request, the server receives the request, processes it and sends a response (acknowledgement). The client receives the response and can process it further accordingly. Depending on the services a TwinCAT BACnet/IP device can act as a client or a server. The following figure shows the procedure for acknowledged services.

In the ConfirmedServices category, a list with the number of sent and received requests and sent and received responses is maintained for each supported service. The list shows how many requests/responses were processed successful and how many errors occurred. The 8 values for each BACnet service shown in the screenshot below are derived from these combinations. The top row of each service shows the total number of successful requests and responses and errors.

In the classification of BACnet services a distinction is made between so-called A-services and B-services, depending on which role (client or server) a device assumes for a service. If a device acts as a client, i.e. if it uses a request and receives a response (Ack), it uses an A-service. If a device receives a request, processes it and sends a response (Ack), it provides the B-service. If, for example, a client reads the value of a property of another device, the service ReadProperty-A is used. In this case the server implements the service ReadProperty-B. For diagnostic purposes it is important to distinguish between A- and B-services. The following table is therefore subdivided into these service categories.

For acknowledged services an A-service is always associated with the counters ReqSend and AckRecv, a B-service always with ReqRecv and AckSend. The table indicates for the potential errors in which cases the error counter was incremented (e.g. ReqSendFail>0). In A-services an important error indicator may be a mismatch between the number of sent requests and received responses (Ack). Thus error type is referred to as (Req<>Ack).

Notice 		Service diagnosis
With BACnet it should be noted that increased error counters in the diagnosis not necessarily indicate a misconfiguration. In BACnet networks short load peaks and lost messages are not uncommon. Suitable repetition mechanisms have been implemented to deal with this (ApduRetries and ApduTimeout). However, if the error rate is excessive it is advisable to find the cause.

The following table provides an overview of relevant BACnet services and their diagnosis. The section explains which function the services perform, where the services are used in TwinCAT BACnet/IP, which possible causes of errors can be diagnosed and possible solutions.

AcknowledgeAlarm-B

(ReqRecv, AckSend)

 Use:

Acknowledging pending alarms

Possible errors:
 nReqRecvFail>0: incorrect request parameter (wrong EventState, wrong timestamp, Instrinsic Reporting for the object is disabled)
nAckSendFail: no frame memory, no router memory

Error handling:
Check remote station
ConfirmedCOVNotification-A

(ReqSend, AckRecv)

 Use:

Remote station has subscribed to change of value. Service sends message in the event of change.

Possible errors:
 ReqSendFail>0 : no frame memory, no router memory, no available invoke IDs
Req <> Ack: remote station not available or overloaded

Error handling:
Check/increase property COVIncrement for analog* objects. Reduce BACnet cycle time: for writing process data fewer modifications are then generated. Check configuration for continuously changing properties. Check whether remote station can use non--acknowledged COV subscriptions.
ConfirmedCOVNotification-B

(ReqRecv, AckSend)

 Use:

Receipt of a change of value

Possible errors:
 nReqRecvFail>0: Faulty request parameters (process ID not available, unknown object, unknown property, message does not contain the expected data type), no router memory

Error handling:
Check remote station
ConfirmedEventNotification-A

(ReqSend, AckRecv)

 Use:

Message for change in event state (Instrinsic Reporting)

Possible errors:
 ReqSendFail>0 : no frame memory, no router memory, no available invoke IDs
Req <> Ack: remote station not available or overloaded

Error handling:
Check whether sending of event notifications is meaningful for all objects. Perhaps deactivate Instrinsic Reporting properties, deactivate event notification via property EventEnable, or allocate a NotificationClass without recipients to all objects that should not send event notifications. Perhaps use unconfirmed event notifications (issueConfirmedNotifications in NotificationClass:RecipientList.)
ConfirmedEventNotification-B

(ReqRecv, AckSend)

Not covered by certification

Use:

Recepit of event messages in the notification sink

Possible errors:
 nReqRecvFail>0: Faulty request parameters (process ID not available, receive buffer for event notifications full), no router memory

Error handling:
Check remote station, increase buffer size for EventNotifications, increase delete interval for message buffer
GetAlarmSummary-B
(ReqRecv, AckSend)

Use:

Call up summary of all objects in alarm state

Possible errors:
 nReqRecvFail>0: no router memory
nAckSendFail: no frame memory, no router memory
GetEnrollmentSummary-B Use:

Call up a summary of event-specific information (with comprehensive filter options)

Possible errors:
 nReqRecvFail>0: no router memory
nAckSendFail: no frame memory, no router memory
SubscribeCOV-A

(ReqSend, AckRecv)

 Use:

Service for subscribing to a change of value (COV) of properties "PresentValue" and "StatusFlags" for analog*, binary* and MultiState* objects. With remote objects for process data in COV mode. TrendLog for remote objects with LogInterval=0. COV subscriptions configured in NotificationSink.

Possible errors:
 ReqSendFail>0 : Connection data cannot be resolved (client status not complete), no frame memory, no router memory, no available invoke IDs
Req <> Ack: remote station not available or overloaded.

Error handling:
Activate optimisation of the process data in the "PropertyWizzard", increase cycle times, subscribe to fewer properties, read properties cyclically that cannot be subscribed to via COV (polling)
SubscribeCOV-B

(ReqRecv, AckSend)

 Use:

Recepit of a subscription to a change of value (COV) of properties "PresentValue" and "StatusFlags" for analog*, binary* and MultiState* objects.

Possible errors:
 nReqRecvFail>0: Faulty request parameters (unknown object, unsupported property, invalid array index), maximum number of supported COV subscriptions for object reached, no router memory
nAckSendFail: no frame memory, no router memory

Error handling:
Increase number of supported COV subscription per object in Advanced Parameters (MAX_OBJ_SUBS_COV_entries)
AtomicReadFile-B

(ReqRecv, AckSend)

 Use:

Reading a file

Possible errors:
 nReqRecvFail>0: Faulty request parameters (unknown object, unsupported object, invalid FileStart position, access via record), no router memory
nAckSendFail: no frame memory, no router memory, local segment buffer full, too many data for supported segmentation of the remote station

Error handling:
Increase advanced parameter MAX_RECV_BAC_SEGM_FRAMES
AtomicWriteFile-B

(ReqRecv, AckSend)

 Use:

Writing a file

Possible errors:
 nReqRecvFail>0: Faulty request parameters (unknown object, unsupported object, invalid FileStart position, access via record), no router memory
nAckSendFail: no frame memory, no router memory

Error handling:
Increase advanced parameter MAX_RECV_BAC_SEGM_FRAMES
AddListElement-B

(ReqRecv, AckSend)

 Use:

Adding a list element

Possible errors:
 nReqRecvFail>0: Faulty request parameters (unknown object, unsupported property, property is not a list, property is read-only), property memory exceeded, no router memory
nAckSendFail: no frame memory, no router memory

Error handling:
Increase property list memory (LIST_ALLOC_MEM_BYTES). Some lists are managed in TwinCAT BACnet/IP as arrays (e.g. RecipientList, DateList). Increase MAX_PROPERTY_ARRAYELEMENTS.
RemoveListElement-B

(ReqRecv, AckSend)

 Use:

Removing a list element

Possible errors:
 nReqRecvFail>0: Faulty request parameters (unknown object, unsupported property, property is not a list, property is read-only, element not available), no router memory
nAckSendFail: no frame memory, no router memory
ServiceCreateObject-B

(ReqRecv, AckSend)

 Use:

Generating a dynamic object

Possible errors:
 nReqRecvFail>0: Faulty request parameters (unsupported object type, invalid property parameter data, object name or ObjectIdentifier already allocated, maximum number of objects exceeded), no router memory
nAckSendFail: no frame memory, no router memory

Error handling:
Increase advanced parameter MAX_OBJECTS
ServiceDeleteObject-B

(ReqRecv, AckSend)

 Use:

Unloading a dynamic object

Possible errors:
 nReqRecvFail>0: Faulty request parameters (unknown object, static object - only dynamic objects can be deleted), no router memory
nAckSendFail: no frame memory, no router memory
ReadProperty-A

(ReqSend, AckRecv)

 Use:

Reading a property of a remote device

Possible errors:
 ReqSendFail>0 : Connection data cannot be resolved (client status not complete), no frame memory, no router memory, no available invoke IDs
Req <> Ack: remote station not available or overloaded.

Error handling:
Activate optimisation of the process data in the "Property Wizard". Increase cycle times. Request fewer properties during polling: Use SubscribeCOV service
ReadProperty-B

(ReqRecv, AckSend)

 Use:

Reading a local property

Possible errors:
 nReqRecvFail>0: Faulty request parameters (unknown object, unknown property, no read access, invalid array index), no router memory
nAckSendFail: no frame memory, no router memory, local segment buffer full, too many data for supported segmentation of the remote station
ReadPropertyMultiple-B

(ReqRecv, AckSend)

 Use:

Reading several local objects and properties with one access

Possible errors:
 nReqRecvFail>0: Faulty request parameters (unknown object, unknown properties, no read access, invalid array index), no router memory
nAckSendFail: no frame memory, no router memory, local segment buffer full, too many data for supported segmentation of the remote station

Error handling:
In the event of excessive data, the remote station should use ReadProperty. Perhaps read list and array properties for each index. Increase advanced parameter MAX_SEND_BAC_SEGM_FRAMES
WriteProperty-A

(ReqSend, AckRecv)

 Use:

Writing a property of a remote device

Possible errors:
 ReqSendFail>0 : Connection data cannot be resolved (client status not complete), no frame memory, no router memory, no available invoke IDs
Req <> Ack: remote station not available or overloaded.

Error handling:
Activate optimisation of the process data in the "PropertyWizard". Increase cycle times. Subscribt to fewer properties. Activate WriteOnChange in the process data configuration (with WriteOnChange a maximum of WriteProperty per client property "cycle time" is executed.)
WriteProperty-B

(ReqRecv, AckSend)

 Use:

Writing a local property

Possible errors:
 nReqRecvFail>0: Faulty request parameters (unknown object, unknown property, no write access, invalid array index, invalid data type), no router memory
nAckSendFail: no frame memory, no router memory

Error handling:
Increase property list memory (LIST_ALLOC_MEM_BYTES). Increase advanced parameter MAX_PROPERTY_ARRAYELEMENTS. Perhaps remove write protection ("Optional Properties" tab). Examine remote station!
WritePropertyMultiple-B

(ReqRecv, AckSend)

 Use:

Writing several local objects and properties with one access

Possible errors:
 nReqRecvFail>0: Faulty request parameters (unknown object, unknown properties, no write access, invalid array index, invalid data type), no router memory
nAckSendFail: no frame memory, no router memory

Error handling:
Increase property list memory (LIST_ALLOC_MEM_BYTES). Increase advanced parameter MAX_PROPERTY_ARRAYELEMENTS. Perhaps remove write protection ("Optional Properties" tab). Use WriteProperty. Examine remote station!
DeviceCommunicationControl-B

(ReqRecv, AckSend)

 Use:

Communication control of a device (switching off message processing)

Possible errors:
 nReqRecvFail>0: Faulty request parameters (invalid password), no router memory
nAckSendFail: no frame memory, no router memory

Error handling:
Synchronise password configuration in remote station with password (BACnet server "Authentication"). Check password encoding.
ReinitializeDevice-B

(ReqRecv, AckSend)

 Use:

Initiates a device restart or changes the device status to backup or restore mode.

Possible errors:
 nReqRecvFail>0: Faulty request parameters (invalid password, device is not in operational state, device cannot restart since it is in backup or restore state), no router memory
nAckSendFail: no frame memory, no router memory

Error handling:
Synchronise password configuration in remote station with password (BACnet server "Authentication"). Check password encoding. Some functions of ReinitializeDevice-B (backup, restore, restart) function only in RUN mode. Check whether enough data memory is available for backup/restore.
ReadRange-B

(ReqRecv, AckSend)

 Use:

Reading of lists (in particular the property LogBuffer)

Possible errors:
 nReqRecvFail>0: Faulty request parameter (unknown object, unknown property, property is not a list, attempt to access unsupported properties with parameter "TimeRange" and "BySequence"), no router memory
nAckSendFail: no frame memory, no router memory
SubscribeCOVP-A

(ReqSend, AckRecv)

 Use:

Service for subscribing to a change of value (COV-P) with any objects and properties. With remote objects for process data in COV mode. For TrendLog for remote objects with LogInterval=0. COV subscriptions configured in NotificationSink.

Possible errors:
 ReqSendFail>0 : Connection data cannot be resolved (client status not complete), no frame memory, no router memory, no available invoke IDs
Req <> Ack: remote station not available or overloaded.

Error handling:
Activate optimisation of the process data in the "PropertyWizard". Increase cycle times. Subscribt to fewer properties. Read properties cyclically that cannot be subscribed to via COV-P (polling).
SubscribeCOVP-B

(ReqRecv, AckSend)

 Use:

Receiving of a subscription for a change of value (COV-P) with any objects and properties.

Possible errors:
 nReqRecvFail>0: Faulty request parameters (unknown object, unsupported property, invalid array index), maximum number of supported COV subscriptions for object reached, no router memory
nAckSendFail: no frame memory, no router memory

Error handling:
Increase the number of supported COV subscription per object in the Advanced Parameters menu (MAX_OBJ_SUBS_COV_ENTRIES).
GetEventInformation-B

(ReqRecv, AckSend)

 Use:

Call up summary of all objects in event state

Possible errors:
 nReqRecvFail>0: no router memory
nAckSendFail: no frame memory, no router memory

UnconfirmedServices category

Unlike confirmed services, unconfirmed services are unidirectional. A client will therefore send request, and a a server receives it. The following table provides a detailed description of the unconfirmed services of the BACnet diagnosis.

IAm-A

(ReqSend)

 Use:

Announcing the server in the network

Possible errors:
 ReqSendFail>0 : no frame memory, no router memory
IAm-B

(ReqRecv)

 Use:

Announcing a device from the network

Possible errors:
 nReqRecvFail>0: DeviceAddressBinding list is full, no router memory

Error handling:
Increase the number of supported AddressBindings in the advanced parameters (MAX_DEVICE_BINDINGS)
IHave-A

(ReqSend)

 Use:

Reports an object that was searched in the network

Possible errors:
 ReqSendFail>0 : no frame memory, no router memory
UnconfirmedCOVNotification-A

(ReqSend)

 Use:

Remote station has subscribed to change of value. Service sends unconfirmed message in the event of change.

Possible errors:
 ReqSendFail>0 : no frame memory, no router memory

Error handling:
Check/increase property COVIncrement for analog* objects. Reduce BACnet cycle time: for writing process data fewer modifications are then generated. Check configuration for continuously changing properties.
UnconfirmedCOVNotification-B

(ReqRecv)

 Use:

Unconfirmed receipt of a change of value

Possible errors:
 nReqRecvFail>0: Faulty request parameters (process ID not available, unknown object, unknown property, message does not contain the expected data type), no router memory
UnconfirmedEventNotification-A

(ReqSend)

 Use:

Unconfirmed message for change in event stage (Instrinsic Reporting)

Possible errors:
 ReqSendFail>0 : no frame memory, no router memory

Error handling:
Check whether sending of event notifications is meaningful for all objects. Perhaps deactivate Instrinsic Reporting properties, deactivate event notification via property EventEnable, or allocate a NotificationClass without recipients to all objects that should not send event notifications.
UnconfirmedEventNotification-B

(ReqRecv)

 Use:

Unconfirmed receipt of event notifications in the notification sink

Possible errors:
 nReqRecvFail>0: Faulty request parameters (process ID not available, receive buffer for event notifications full), no router memory
TimeSynchronisation-B

(ReqRecv)

 Use:

Receipt of a time stamp for time synchronisation

Possible errors:
 nReqRecvFail>0: System time could not be synchronised since synchronisation is already running or TwinCAT is in free-run state, no router memory

Error handling:
Switch TwinCAT to Run state
WhoHas-B

(ReqRecv)

 Use:

Search for certain objects in a network

Possible errors:
 nReqRecvFail>0: Device does not process notifications since this function was switched off via the service "DeviceCommunicationControl", no server created, no router memory
WhoIs-A

(ReqSend)

 Use:

Scanning of a network for devices and querying of the device communication parameters

Possible errors:
 ReqSendFail>0 : no frame memory, no router memory
WhoIs-B

(ReqRecv)

 Use:

Querying the server for device communication parameters

Possible errors:
 nReqRecvFail>0: Device does not process notifications since this function was switched off via the service "DeviceCommunicationControl", no server created, no router memory
UTCTimeSynchronisation-A

(ReqSend)

 Use:

Sending a UTC time stamp for time synchronisation

Possible errors:
 ReqSendFail>0 : no frame memory, no router memory
UTCTimeSynchronisation-B

(ReqRecv)

 Use:

Receipt of a UTC time stamp for time synchronisation

Possible errors:
 nReqRecvFail>0: System time could not be synchronised since synchronisation is already running or TwinCAT is in free-run state, no router memory

Error handling:
Switch TwinCAT to Run state

FrameStatistic category

This category consolidates counters of sent and received BACnet messages. In addition the system can detect how often during operation the physical link of the network adapter was lost.

The individual counters are described in more detail below, and possible problem indicators are listed.

nSegmSendTimeouts

Purpose:

Indicates how often timeouts occurred during waiting for confirmation of a segment.

Problem indicator:
 The remote station may be overloaded or no longer reachable.
nFrameAllocFailCnt

Purpose:

Indicates how often no memory for sending of BACnet messages could be allocated.

Problem indicator:
 The number of messages sent per cycle may be too high. It may be possible to activate the network adapter queues (see Advanced parameters). Check whether a connection to the network exists. A high value for this counter typically indicates a local overload situation.
nFrameSendCnt

Purpose:
 Indicates how many BACnet messages were sent successfully.
nFrameSendFailCnt

Purpose:

Indicates how many BACnet messages could not be sent.

Problem indicator:
 The number of messages sent per cycle may be too high. It may be possible to activate the network adapter queues (see Advanced parameters). Check whether a connection to the network exists. A high value for this counter typically indicates a local overload situation.
nFrameRecvCnt

Purpose:

Indicates how many BACnet messages were received without error.
nFrameRecvFailCnt

Purpose:

Indicates how many BACnet messages were received with error. This counter indicates the total of the AckRecvFail and ReqRecvFail counters for all services.

Problem indicator:
 The problem should be analysed in more detail via the categories ConfirmedServices and UnconfirmedServices.
nLinkStatusChangedCnt

Purpose:

Indicates how often the LinkStatus of the network adapter has changed.

Problem indicator:
 Normally this counter has the value 1 (link on system startup.)

MemoryInfo category

The MemoryInfo category consolidates memory-specific information. In the top row of Windows CE devices the available main and flash memory is indicated. The individual counters are explained in the following table.

nAmsAlloc

nAmsAllocCntMax
nAmsAllocFailCnt

Purpose:

These counters represent the allocation behaviour of the BACnet stack for the router. nAmsAlloc indicates the current number of allocations. nAmsAllocCntMax indicates the maximum number of activated allocations at one time. nAmsAllocFailCnt indicates how often it was not possible to allocate memory. These counters do not provide information about the size of the allocated memory.

Problem indicator:
 Router memory is used for temporary operations, e.g. for processing of messages and for saving EventNofitications and COV notification in the NotificationSink. A consistently high counter nAmsAlloc indicates an overload situation.
nCeAvailPhysMemBytes

nCeAvailFlashMemBytes

Purpose:

These counters are only implemented for Windows CE. They indicate how many RAM and flash memory is available.

Problem indicator:
 If not enough RAM (nCeAvailPhysMemBytes) is available, it may not be possible to allocate dynamic objects. Flash memory is important for saving persistent data and for backup and restore operations.
nRecvFrameFifoSize

nEmptyFrameFifoSize

Purpose:

If network adapter queues are used, these counters indicate the available list memory for received (nRecvFrameFifoSize) and to be sent messages (nEmptyFrameFifoSize).

Problem indicator:
 If the memory is inadequate, the size can be increased via the parameter dialog of the network adapter queues.
nRecvSegmUDPFramesListSize
nRecvSegmFramesListSize
nSendSegmFramesListSize 		Purpose:

These counters provide information about the messages segments currently stored intermediately. A distinction is made between IP segmentation (UDP) and BACnet NPDU segmentation, and between segments that are earmarked for delivery (Send) and received segments (Recv).

Problem indicator:
 In the event of problems with the segmentation, the advanced parameter MAX_RECV_BAC_SEGM_FRAMES and MAX_SEND_BAC_SEGM_FRAMES can be adjusted as required.
nClientScanListSize Purpose:

Indicates the size of the list of found devices in the network.
nAdsRequestListSize Purpose:

ADS requests to the BACnet stack are stored intermediately in a list and processed in the context of the BACnet task. This counter indicates the current number of pending ADS requests.

ServerInfo category

A detailed description of the category ServerInfo can be found in section Persistent data.


BBMD

TS8020 | TwinCAT BACnet Supplement

BACnet Broadcast Management Device

TwinCAT BACnet/IP supports the "BACnet Broadcast Management Device" (BBMD) functionality. BBMD can be used to transfer IP broadcast messages (e.g. 192.168.1.255), which are used by certain BACnet services, beyond the boundaries of local networks. One example is the Who-Is service, which is used to find other BACnet devices via an IP broadcast message. A Who-Is message sent by a BACnet device is relayed to the local network with a broadcast MAC address (FF:FF:FF:FF:FF:FF). All BACnet devices in this network receive the message and can respond accordingly. However, the message is not relayed by IP routers that communicate with other IP subnets. BBMD was introduced in order to resolve this issue. In a local network only one device with BBMD functionality can be configured, which relays the IP broadcast messages to remote IP subnets via a Broadcast Distribution Table (BDT).

Two procedures are available for transferring BBMD messages, referred to as One-Hop and Two-Hop. With the Two-Hop procedure a BBMD device transfers broadcast messages to a further BBMD in the remote IP subnet, which then distributes the messages in its local network as IP broadcast messages for its IP subnet. With the One-Hop procedure the local BBMD transfers the message directly to the remote devices. In this case the IP routers have to support the transfer of IP broadcast messages to remote IP subnets.

Notice 		Gateway configuration
The BBMD functionality requires a gateway to be entered in the IP configuration of a BACnet device, since IP messages have to be relayed to remote IP subnets. If no gateway is configured, the BBMD functionality is automatically disabled.

The "Foreign Device" procedure can be used to enable remote devices that dial in via an Internet connection, for example, to link dynamically with a BACnet configuration. Special BACnet services exist, which are also supported by TwinCAT BACnet/IP, for generating an entry in the Foreign Device Table (FDT). Similar to the BDT procedure, a BBMD IP broadcast relays messages to all FDT entries. In contrast to BDT, FDT entries have a limited lifetime. This means that login has to be refreshed after a time interval (Time To Live) has elapsed.

The BACnet device has a BBMD tab for configuring the BBMD. Each TwinCAT BACnet/IP device can therefore operate as a BBMD. Only one BBMD may exist for each subnet. The BBMD functionality can be activated with the option "Enable BBMD". In addition the size of the BDT and FDT can be configured. During runtime new entries can be added to the BDT and FDT. This should be taken into account when configuring the size. Entries that are added to the BDT at runtime are stored as persistent data if this option is activated. As for BACnet properties, BDT entries are distinguished between offline and online data. The "Initial BDT" describes entries that are used on startup. During runtime the state of the BDT can be monitored via the tab "Online BDT". The FDT can be viewed via the tab "Online FDT".

Via the submenu "Registration as Foreign Device" a TwinCAT BACnet/IP can register devices in an existing BACnet network. To this end the IP address of the remote BBMD has to be activated.

The above screenshot shows the configuration of the BDT in two-hop mode. A small examples will be used to describe the BBMD functionality. The following figure shows two IP subnets that are connected via a router. In the example the device 192.168.1.2 sends an IP broadcast message (in this case 192.168.1.255) to the local network. The BBMD (IP address 192.168.1.7) relays the message as forwarded NPDU via the router/gateway (192.168.1.1) to the BBMD of IP subnet 10.3.xxx.xxx. In this case it is the configured BBMD with the IP address 10.3.1.8. The remote BBMD distributes the relayed message as an IP broadcast (10.3.255.255) to the local network.

The following screenshot shows the BBDM configuration in one-hop mode. In contrast to the two-hop procedure, the subnet mask of the target system is entered to indicate that a target IP broadcast message should be generated directly. In this case the last two digits of the IP address are not relevant, since they are replaced with 255. In other words, it would make no difference if 10.3.0.0 was used, for example.

In this case the BBMD (192.168.1.7) sends the message with the MAC address of router/gateway to the IP broadcast address (10.3.255.255) of the remote IP subnet. In this mode the remote BBMD does not relay messages.


FAQ

  1. BACnet client does not provide current process data

    A BACnet client does not provide current process data, which were subscribed to via COV, to the PLC (process data connected with the PLC on the client side via mapping; the object itself runs on a remote server). What might cause this?

    1. The remote server which the client tries to access was restarted (reboot, TwinCAT restart or control voltage failure). Once the server is running again the client has to re-register all COV subscriptions, or the time defined under Resubscription Interval has elapsed (Resubscription Interval, see also section “Process data” under "Properties as process data").
      How can a restart of remote servers be detected? Under a client the process data SystemStatus can be mapped. Mapping of SystemStatus should be set to Polling with a period that should be as short as possible (between 1..5 s). If the remote server is switched off, timeout of the polling query is triggered (server cannot be reached, client status bit 1 = TRUE → acknowledgement via ClientControl ). Once the remote server commences a restart, the SystemStatus assumes state “4” (non-operational). Once the SystemStatus changes from “4” to “0” the remote server is ready for queries, so that COV subscriptions can be re-registered. The registration of the COV subscriptions can be controlled via ClientControl bit 3.
      For further details see section “Process data”, subsection “BACnet client”.
    2. The network connection between client and server is interrupted.
      How can the status of remote servers be monitored? See item 1. In addition, the Device Status of the local BACnet adapter can be used to monitor the “linked” state of the network adapter (see section “Process data”, subsection “BACnet device”).
    3. The remote server does not support COV of Properties (COV-P).

      See also Section IX.

    4. The remote server is supporting COV-P, but the maximum number of subscriptions to the corresponding object exceeded on server side.

      In the logger window of the System Manager on the client side you will see:

      Example of COV-P error
      How to increase the maximum number of property subcriptions, which the server permits per object? On the server side the following parameter needs to be adjusted in order to increase the maximum number of subscriptions per object (see Advanced Settings under Memory-specific parameters):
      1. Select the BACnet adapter of the appropriate server
      2. Press button "Configure" under "Advanced Settings - Data Structures"
      3. Increase parameter "MAX_OBJ_SUBS_COV_ENTRIES" accordingly
      4. Press button "Save" to store changes / button "Cancel" to abort
      5. Apply changes with symbol "Activate configuration" respectively with symbol "Reload I/O devices (F4)" in mode "CONFIG" from the tool bar.
  2. During stopping/shutdown of the TwinCAT system the process data of some BACnet objects are reset

    During stopping/shutdown of the TwinCAT system the process data of some BACnet objects are reset. This leads to unintended effects, since some object states influence the persistent PLC data. How can the validity of the object states in the PLC be monitored?

    1. The validity of the object states can be monitored with the aid of the Device Status (bits 8...15) of the local BACnet adapter, by querying the state of the device state machine (mapped in the PLC). If the device state machine reports Complete (8), the local server and its objects and properties were initialised and the communication with remote servers can commence. During shutdown of TwinCAT system the device state machine is reset (< 8). If the resetting (< 8) is detected in the PLC, the object states (mapped properties) should no longer be evaluated.
    2. In general, the validity of client objects (of remote servers) cannot be verified, since communication timeouts etc. prevent timely monitoring. Failure of BACnet services is indicated by the client status (bit 0 and 1, see section “Process data”, subsection “BACnet client”). Failed queries result in the respective bits being set in the client status, which then have to be acknowledged. The local BACnet adapter can be monitored with the aid of the device status (see item 1.).
  3. Writing of data to a remote server in the event of change of value (Write On Change) should be temporarily disabled.

    Writing of data to a remote server in the event of change of value (Write On Change) should be temporarily disabled (e.g. for re-triggering of the PresentValue of a BinaryOutput object, without state INACTIVE being set). How can this be realised?

    1. In the process data ClientControl writing of Write On Change can be disabled with the aid of bit 2 (see section "Process data", subsection "BACnet client").
    2. Re-triggering of writing to a remote object can alternatively be accomplished with an ADS command (see section “ADS interface”). The PLC library “TcBACnet.lib” offers the convenient function block “FB_BACnetWriteProp” for this purpose.
  4. How can the sending of alarm events be prevented for BinaryOutput/Input or Value objects?
    1. Sending of events can be prevented by deselecting the bits in the Settings or Online tabs, or by writing the property EventEnable no. 35 (value = 0x0005). However, this only suppresses sending of event notifications. The status bit in_alarm of the property StatusFlags no. 111 continues to be set.
    2. To prevent generating any events for the respective binary object, support for intrinsic reporting (O4) can be disabled (see section “BACnet objects and properties”, subsection “Configuration”). This prevents setting of status bit in_alarm of property StatusFlags no. 111.
  5. How can NULL (NaN) be written to the priority array of the commandable property PresentValue of an AnalogOutput by the PLC via the process data?
    1. The PresentValue must be activated as a process data with the required priority.
    2. The process data must be linked with the PLC (data type REAL)
    3. In PLC program the library function “F_BACnet_NAN()” can be used to write the state NULL (NaN) from the library “TcBACnet.lib” to the process data → This cancels the respective priority of the priority array.
  6. Why is the process data PresentValue of a binary* object of type WORD?

    Within BACnet the PresentValue of binary* object is stored as enumeration of type BACnetBinaryPV (active, inactive). Enumerations are generally mapped with type WORD. The manufacturer-specific property PresentValueBool was introduced to simplify handling of binary* objects. It can be mapped with data type BOOL via the PLC mapped (see section “Process data”).

  7. The K-bus of BACnet controller fails sporadically, without apparent reason. What could be the causes ?
    1. The K-bus power supply was exceeded. The K-bus is switched off, if e.g. many relay output terminals are activated simultaneously during operation, resulting in the maximum permitted K-Bus current to be exceeded. Power requirements of the terminals should be checked (see power consumption in the data sheet for the terminal) and an appropriate K-Bus refresh (see description of the KL9400) must be provided.
    2. If the K-bus task is triggered by the BACnet task (mapping only between BACnet and K-bus, no PLC etc.→ asynchronous mapping), under heavy load of the BACnet task the K-bus task may not be triggered often enough. The reason is task time exceedance of the BACnet task (frequently exceeds → see Exceed counter for the respective task) in the event of high BACnet communication traffic.
      How can the K-bus task be triggered independent of the BACnet task?
      1. Create a new task in the TwinCAT System Manager

      2. Configure the task; activate Auto start and set the required cycle time (Cycle ticks)

      3. Add a variable for the mapping (e.g. CycleTime of type UINT)

      4. Link the K-bus variable “CycleTime” and task variable “K_Bus_CycleTime”

      5. Activate the modified configuration with the icon “Activate configuration” in the toolbar
  8. Why does the property StatusFlags of an object have the value 0x0004 or the property EventEnable the value 0x0005, despite the fact that no status bits of the property are set?

    Properties with bit flags (subtype BitFieldBits) are internally transferred as so-called bit string. A bit string always consists off a high byte and a low byte. The low byte indicates how many bits of high byte are not used (from the left). i.e. StatusFlags = 0x0004 means the 4 higher bits of the high byte are not used (i.e. only bits 8, 9, 10 and 11 of the WORD data type are used). For further details see section “Process data / bit string”.

  9. A BACnet client whose process data are linked with the PLC is always shown as “Offline” in the System Manager. However, the client is shown in a scan. What could be the problem?

    If process data are used that were linked by PLC automapping, the properties are usually obtained via COV subscription. This can lead to problems, if the client does not support COV (logger messages such as: “Error TCOM Server (10) [...] BACnet Client [...] - COV subscription failed! Reject Reason: unrecognized service”). Since the COV subscription fails, new requests keep being sent to the remote server. This leads to timeouts and eventually to the client be shown as “Offline” in the System Manager.

    Solution: The input process data of the client properties should be switched to “Polling” mode in the System Manager.

    How can the input process data (Read) of a client be changed from COV to Polling?
    1. Select the respective client
    2. Open the “Objects” tab
    3. Open the Property wizard (see also BACnet wizards)

    4. Select the client under “Select Objects” and...
      1. Activate option “Optimize Process Data Access (Tick Modulo)”
      2. Activate option “Change Process Data In Configuration (Read)”
      3. Set mode “Process Data Read Mode” to “Polling”
      4. Set parameter "Cycle Time (ms)” to 10000 = 10 seconds read cycle, for example (Please note: This parameter must be optimised based on the application requirements and may have to be determined individually for the respective property)
    5. Select all entries under “Select Properties” (right-click, “Select All”)
    6. Click Apply to confirm the changes.
  10. The PLC auto-mapping is much slower than usual. What could be the problem?

    Cause: The PLC auto-mapping should not be performed when the system manager logged on the target system. When the System Manager is connected to the target system, there will be delays when linking process data. The PLC auto-mapping creates potentially many links of process data and this leads to a much longer PLC auto-mapping cycle.

    Solution: Before the PLC auto-mapping is performed the System Manager should be connected to local runtime system. After the PLC auto-mapping was performed the System Manager can be reconnected to the target system.


Example: Create BACnet adapters and servers

As already described in section BACnet device, server, client, the BACnet adapter is added into a project as an Ethernet device. Step-by-step instructions for creating a server under the BACnet adapter are provided below.

  1. Creating a BACnet server under the used BACnet adapter

    a) Right-click on the adapter and select "Append Object..."

    b) In the subsequent dialog select the module "BACnet server" and confirm with "OK"

    Notice     		Supplement Key
    Each configured BACnet adapter requires a licence key, the so-called "Supplement Key". See section "Set up BACnet Supplement Key" for further information.
  2. The option Persist Server Online Data should be activated if the server has to store the configuration data of all subordinate objects persistently. The screenshot below shows the Settings tab under which the option can be activated (see also section "Persistent data"):


Example: Manual linking of hardware (terminal), BACnet <a class=BACnet>BinaryInput</a> and PLC runtime

TS8020 | TwinCAT BACnet Supplement

Example: Manual linking of hardware (terminal), BACnet BinaryInput and PLC program

The following example describes the linking of two digital inputs with the corresponding objects and the PLC.

  1. Create a BACnet adapter and server (see "Example: Create BACnet adapters and servers")
  2. Link the status of the Bus Coupler under which the hardware terminal was added with the BACnet server

    a) Right-click on couplerState

    b) In the subsequent dialog select BusState of the Bus Coupler selected (Please note: Deselect "Exclude other Devices" and "Exclude same Image" and select "All Types") and confirm with "OK"

    c) Confirm the subsequent dialog with "OK"

  3. The first BinaryInput object under the previously created BACnet server is now added

    a) Right-click on the BACnet server and select "Append Object..."

    b) In the subsequent dialog select the module "BACnet Binary Input Object" and confirm with "OK"

  4. For setting the property "Reliability" of the BinaryInput object the bus number of the bus status linked under (2) above has to be set in the BACnet object (bus index "0"):

  5. For subsequent mapping onto the PLC the corresponding properties should be added to the cyclic I/O mapping. To this end the following properties should be selected as a minimum:

  6. Subsequently the link between the hardware terminal and the BACnet object is created. To this end RawIoBinaryBoolValue has to be linked with the corresponding bit of the hardware terminal:

    a) Right-click on RawIoBinaryBoolValue under the BACnet object "BI_0" and select "Change Link..."

    b) In the subsequent dialog select the symbol "Input" of the corresponding hardware terminal (Please note: Deselect "Exclude other Devices" and "Exclude same Image" and select "Matching Size") and confirm with "OK"

  7. The library "TcBACnet.lib" can be used for accessing BACnet objects from a PLC runtime. It makes all objects available as function blocks with the corresponding I/O points for the mapping in the System Manager. In the following example a PLC project with an instance of the function "FB_BACnet_BinaryInput" with name "BI_0" is created. The function is added to the PLC program "DEMO" as follows (Please note: The program "DEMO" is called from the program "MAIN". The program "MAIN" is added as a task in the task configuration). The block instance "Device" enables access to the device object and the server status and has to be transferred to the block instance "BI_0":

  8. Once the PLC project is compiled it has to be made available in the System Manager. Right-click on the symbol "PLC - Configuration". Then add the TPY file of the previously compiled PLC project via "Append PLC Project...":

  9. Once the PLC project has been added, all I/O variables of the PLC program are available in the System Manager. The global instance "fbBACnet_adapter" of type FB_BACnet_adapter is available in each PLC project linked via the library "TcBACnet.lib". It is used for accessing the BACnet network adapter, its AMS NetID and the link status. The I/O variables under the instance now have to be linked with the I/O points of the BACnet adapter:

    a) Right-click on the symbol ".fbBACnet_adapter._AmsNetID" and select "Change Link..."

    b) In the subsequent dialog select the AmsNetID of the BACnet device (Please note: Deselect "Exclude other Devices" and select "Matching Size") and confirm with "OK"

  10. Repeat step 9 with "DeviceStatus" of the BACnet adapter
  11. The process data inputs: "_SystemStatus", "_ObjIdentifier" and outputs:"_ServerControl" of the device object have to be linked in the same way. This maps the status of the BACnet server and the local device object to the PLC.

    a) Create process data for the device object:

    b) Create link between PLC and I/O process data.

  12. All I/O signals of the PLC/BACnet block "BI_0" now have to be linked with the actual BACnet object. The links are established in the same way as specified under item 9 ("_PresentValue" and "_StatusFlags"):

  13. To check the function without active PLC runtime, the configuration of the BACnet device and the hardware terminals can be tested in Free Run mode:

    a) Select "Reload I/O Devices (F4)" from the toolbar or press F4

    b) Select "Toggle Free Run State (Ctrl-F5)" from the toolbar or press CTRL+F5

    c) The I/O bus of the target system should then switch to RUN. The state of the hardware input can now be monitored in the Online tab of the BACnet object "BI_0". The property Present_Value no. 85 represents the logical state of the hardware input. Using the context menu of Online tab, the Auto Update mode should be activated in advance (see section "BACnet objects and properties").

  14. After a successful test in "Free Run" mode the configuration has to be activated permanently. To this end activate the configuration as usual via the symbol "Activate Configuration" from the toolbar or by pressing CTRL+SHIFT+F4 (this loads the configuration into the target system):

  15. This is followed by loading of the PLC runtime:

  16. and starting in RUN mode:

  17. The states of the BACnet object can be monitored via the Online view of the "DEMO" program. The state of signal Present_Value represents the logical state of the hardware input:


Example: Linking of BinaryInput and BinaryOutput objects during PLC runtime

TS8020 | TwinCAT BACnet Supplement

Example: Linking of BinaryInput and BinaryOutput objects in the PLC program

The following example illustrates how the link of a binary input with a binary output can be realised with the aid of BACnet objects and a PLC program. The procedure is based on PLC automapping.

Brief summary:

  • A binary input, represented by the BACnet object "BI_0", is to write its Present Value to the binary output, represented by the BACnet object "BO_0", with priority "12", if the object "BI_0" is not in state OutOfService
  • If the object "BI_0" is in state OutOfService, PresentValue access with priority "12" to object "BO_0" should be deleted.

The example can be downloaded from here: .

The strategy is explained step-by-step with the aid of screenshots (For creating servers and objects see also examples "Create BACnet adapters and servers" and "Manual linking of hardware (terminal), BACnet BinaryInput and PLC program"):

  1. Create BACnet adapters and servers (see Example "Create BACnet adapters and servers")
  2. Creating an I/O bus (K-bus, E-bus, BK90xx)
  3. Execute I/O automapping of the bus on BACnet (see "example: I/O automapping")
  4. Creating a PLC project and inserting object instances (The link to the input/output objects is realised using the object names "BI_0" and "BO_0" in the comment, see also "PLC automapping"):

  5. Adding the PLC project (.tpy) to the System Manager configuration:

  6. Important: To ensure correct linking, the object names should correspond to the PLC comment (assignment using the object ID would also be possible):

    a) Binary output "BinaryOutput: 0" is to be linked with the PLC instance "BO_0":

    b) Binary input "BinaryInput: 0" is to be linked with the PLC instance "BI_0":

  7. Execute PLC automapping via the Settings tab of the BACnet server:

  8. The process data of the BACnet objects and the corresponding data of the PLC program are then linked:

  9. The configuration has to be activated (Ctrl+Shift-F4), and the PLC program has to be loaded (PLC Control via menu "Online --> Login" or F11). The PLC is then switched to Run state with F5 or "Online --> Start".
  10. The different PLC states and the corresponding BACnet properties are described below:

    a) Case 1: "BI_0" is not OutOfService and ACTIVE or INACTIVE → Priority "12" of "BO_0" is set to ACTIVE or INACTIVE and acts on the hardware terminal:

    b) Case 2: "BI_0" is OutOfService → Priority "12" of "BO_0" is deleted (Zero) and the value from property RelinquishDefault of "BO_0" acts on the hardware terminal:


Example: I/O automapping

In a BACnet environment data are always represented via objects and their properties. This applies to memory states (variables) as well as hardware inputs and outputs. Essentially it means that all hardware terminals of the I/O system have to be mapped via BACnet objects. The automapping option minimises the complexity of linking between BACnet objects and hardware terminals. The procedure is described below by means of screenshots. Further technical information can be found in section "I/O automapping". An example for manual linking between hardware terminals and BACnet objects can be found in section "Manual hardware linking (terminal), BACnet BinaryInput and PLC runtime".

  1. Create BACnet adapters and servers (see Example "Create BACnet adapters and servers")
  2. Create an I/O bus via the Scan function in Config mode or manually (see also section "I/O automapping")
  3. Activate EtherCAT or K-bus automapping

    a) Select the required bus system via the dropdown box

    b) Press the "Map" button

  4. The mapping parameters can be set in the Automapping dialog and confirmed with the "Map" button

  5. A separate dialog indicates the mapping progress

  6. The BACnet objects representing the the terminals of the I/O bus are located under a Structured View

  7. The objects are available "Online" once the configuration has been loaded with "Reload I/O Devices" and the Free RUN mode has been activated


Example: PLC automapping

In a BACnet environment, data are represented via objects and their properties. This applies to memory states (variables) and PLC signals that are meant to be visible in BACnet. Essentially this means that all states of the PLC runtime which are meant to be visible in BACnet have to be mapped via BACnet objects. The automapping option minimises the complexity of linking between BACnet objects and SPS signals. The procedure is described below by means of screenshots. For further information please refer to section "PLC automapping".

The example can be downloaded from here: .

  1. Creating BACnet adapters and servers (see: "Example: Create BACnet adapters and servers")
  2. Create a PLC project with the following block instances

    The aim is to create the PLC instances of the BACnet blocks as BACnet objects in the System Manager configuration, pre-configure the process data and properties and link the process data between the PLC and the objects. The required process data definitions (AT%I* / AT%Q*) are already included in the library blocks of the PLC library. Initialisation of the object properties is described below.

  3. Add automapping comments to the PLC instances and call up the block instances in the PLC program

    Notice     		Note:
    • The PLC program "DEMO" is called from program "MAIN". The program "MAIN" is entered as a task in the task configuration
    • The test program contains the library "TcBACnet.lib" as reference

  4. Compile the PLC project (CTRL+F8)
  5. Add the PLC project to the hardware configuration

  6. In the Settings tab of the BACnet server select the PLC configuration and execute automapping by pressing the "Map" button

  7. Wait until the mapping is complete (dialog with progress bar appears)

  8. The links have now been created. Finally, activate the configuration by pressing the button "Activate Configuration" button in the toolbar

  9. Log into the PLC (F11) and load the program (then start the PLC project with F5, if required)


Example: Create BACnet adapters and servers

TS8020 | TwinCAT BACnet Supplement

Example: BACnet day/night control

The example below illustrates how to configure simple day/night control with the aid of a BACnet schedule and output object. This can be used for lighting control, for example, which is active during the night. The time for activating the binary output is set to 22:00. The output is reset at 04:00.

The example can be downloaded from here: .

  1. Creating BACnet adapters and servers (see: "Example: Create BACnet adapters and servers")
  2. Adding an I/O bus via I/O automapping (see: "Example: I/O automapping")
  3. Creating a schedule object under the server

    a) Right-click on the server and select "Append Object..." to create a new BACnet object

    b) Select module "BACnet Schedule Object" and add with "OK"

  4. The object of type BACnetBinaryOuput, which represents the binary output for the lighting control, is entered as object reference for writing the schedule value (ACTIVE/INACTIVE):

    a) Double-click on the property ListOfObjectReferences:

    b) Then select the PresentValue of the required BinaryOutput object:

    Note: The selection of the object reference is important for the subsequent steps. It determines the data type of the TimeValue entries in the property ExceptionSchedule for the following wizard. If the PresentValue of a binary* object is selected, the data type BACnetBinaryPV is otherwise added to Bool.

  5. Double-click on the property ExceptionSchedule:

  6. The wizards facilitates configuration of the switch-on and switch-off times:

  7. The configuration now has to be loaded into the target system by clicking on "Active configuration" on the toolbar:


Example: Linking of BinaryInput and BinaryOutput objects during PLC runtime

TS8020 | TwinCAT BACnet Supplement

Example: Operating BACnet and BK90XX via an Ethernet interface

This section explains how a BACnet device can be operated in parallel with one or several BK90XX ( real-time Ethernet ) via an Ethernet interface.

First, a real-time Ethernet adapter (multi-protocol handler) is created and linked with the required Ethernet interface:

Then a BACnet device is created and used as Ethernet adapter Port 1 for the multi-protocol handler:

The procedure for the real-time Ethernet protocol is similar:

BACnet and real-time Ethernet can now be operated in parallel via the same Ethernet interface. ( e.g. scanning in of devices etc. )

If the real-time Ethernet protocol device is not controlled via BACnet but through synchronous mapping from a PLC, for example, the network queues have to be activated in the BACnet device. The reason is that internal BACnet functions can only be called up via the BACnet task. Synchronous mapping of the real-time Ethernet protocol device results in BACnet being called up in the context of the linked task. In this case the network queues decouple internal BACnet functions from this task.

The network queues can be activated in the "Settings" dialog of the BACnet device:

The procedure described here can also be used for configuring several BACnet servers (devices) on a network interface. For each BACnet server a BACnet device has to be created and linked with the port of the multi-protocol handler. In this way several BACnet servers can be operated in parallel - the IP address then has to be adapted for each associated BACnet device, since the BACnet servers are distinguished through the IP address.


Example: PLC automapping

TS8020 | TwinCAT BACnet Supplement

Example: NotificationClass and NotificationSink

An example for using the NotificationClass in conjunction with a NotificationSink is provided below. It "collects" the events of 3 objects (BV, AV, MV) and sends them to the local process 10 (NotificationSink) of the local BACnet device (event notification via intrinsic reporting).

In addition the PresentValue of the AnalogValue object should be sent to the NotificationSink if the value changes by 0.1 (COV notification).

The example can be downloaded from here: . The included TSM file can be used for testing purposes without loading the PLC.

Fig. 1: Schematic diagram of an NotificationClass example configuration, its event-generating objects (AV, MV, BV) and the NotificationSink.

The objects are configured via the declaration in the PLC program:

        VAR
 viewDummy : BOOL; (* ~( BACnet_StructuredViewPath : \/DemoNClass : ) *)

 fbDevice : FB_BACnet_Device;

 fbBV_0 : FB_BACnet_BinaryValue;
  (* ~(BACnet_ObjectIdentifier : 0 : nolink )
  (BACnet_EventEnable : {to_offnormal;to_fault;to_normal} : nolink )
  (BACnet_ActiveText : EIN : nolink )
  (BACnet_InactiveText : AUS : nolink )
  (BACnet_NotificationClass : 10 : nolink ) *)

 fbAV_0 : FB_BACnet_AnalogValue;
  (* ~(BACnet_ObjectIdentifier : 0 : nolink )
  (BACnet_EventEnable : {to_offnormal;to_fault;to_normal} : nolink )
  (BACnet_NotificationClass : 10 : nolink ) *)

 fbMV_0 : FB_BACnet_MultiStateValue;
  (* ~(BACnet_ObjectIdentifier : 0 : nolink )
  (BACnet_EventEnable : {to_offnormal;to_fault;to_normal} : nolink )
  (BACnet_NotificationClass : 10 : nolink )
  (BACnet_NumberOfStates : 5 : nolink )
  (BACnet_StateText : ErrLow;WarnLow;Normal;WarnHigh;ErrHigh : nolink )
  (BACnet_FaultValues : 1;5 : nolink )
  (BACnet_AlarmValues : 2;4 : nolink )
  (BACnet_Description : MV DEMO Objekt. : nolink ) *)

 fbNC_10 : FB_BACnet_NotificationClass;
  (* ~(BACnet_ObjectIdentifier : 10 : nolink )
  (BACnet_Priority : 70;80;90 : nolink )
  (BACnet_AckRequired : {to_offnormal;to_fault;to_normal} : nolink )
  (BACnet_RecipientList :
      <ArrayOfBACnetDestination>
        <BACnetDestination>
          <recipient>
            <choice>device</choice>
            <BACnetObjectIdentifier>
              <objId>33661729</objId>
            </BACnetObjectIdentifier>
          </recipient>
          <validDays>65025</validDays>
          <fromTime>
            <hour>0</hour>
            <minute>0</minute>
            <second>0</second>
            <hundredths>0</hundredths>
          </fromTime>
          <toTime>
            <hour>23</hour>
            <minute>59</minute>
            <second>59</second>
            <hundredths>99</hundredths>
          </toTime>
          <processIdentifier>10</processIdentifier>
          <transitions>57349</transitions>
          <issueConfirmedNotifications>false</issueConfirmedNotifications>
        </BACnetDestination>
      </ArrayOfBACnetDestination>
  : nolink ) *)END_VAR

The NotificationSink added for receiving the events is configured in the System Manager:

Fig. 2: NotificationSink in the System Manager tree view

Fig. 3: NotificationSink configuration in the System Manager

Process ID: The process ID is set to 10 and reported to the NotificationClass as a receive process (via PLC automapping comment).

COV Subscriptions: As an example the PresentValue of the AnalogValue object (AV:0) is subscribed to. The parameter covIncrement specifies the change of value threshold at which a COV notification is sent.

The following entries are displayed in the Online tab of the NotificationSink , once the configuration has been loaded and the PresentValue's of the respective objects have been modified:

Fig. 4: NotificationSink online data after COV and event notifications have been received. Note: The text under messageText is formed from the property Description of the event-generating object.


Introduction

TS8020 | TwinCAT BACnet Supplement

PLC library: TcBACnet-Lib

The functionality of the PLC library "TcBACnet.lib" is described below. The library offers convenient access to objects of a BACnet configuration from a PLC program.

The application of the library is not compulsory.

The data (properties) of the BACnet objects can be accessed in two ways:

  1. The function blocks or self-declared variables are linked with the aid of "synchronous" process data mapping (linking of the PLC with the hardware configuration in the System Manager). For this purpose the function blocks of the PLC include the allocation as input or output data ("bValue AT%I* : BOOL" or "bValue AT%Q* : BOOL"). The advantage is that the data are updated cyclically. All values are written or read synchronous with the PLC cycle.
  2. Object data are read or written asynchronously with the aid of ADS. Data to be written/read are sent to the corresponding address with the aid of ADS blocks (NetID, port, index group and offset --> object type, instances and property ID) (FB_BACnet_WriteProp) or read by it (FB_BACnet_ReadProp). This method has the advantage that it is possible to write data only if an actual change has occurred. However, in cases with frequent changes unforeseeable delays may occur. The maximum delay is 5 seconds ("tBACnet_ADSTimeOut : TIME :=t#5s"). After this time the block returns an error code.

The library can be downloaded from here: . The contents of the ZIP archive must be copied into the TwinCAT folder (default: "C:\TwinCAT") under "\PLC\Lib".

Overview

The PLC library TcBACnet-Lib is a collection of function blocks for programming a BACnet controller. For each BACnet object function blocks are available that are read and written via the selected properties. In general a distinction is made between function blocks for server and client objects. Function blocks for client objects have the prefix "Remote", since they enable access to remote BACnet objects on other devices. The BACnet object function blocks ascertain whether process data are valid and the BACnet controller is ready for operation (bReady).

The function block FB_BACnet_Adapter represents a BACnet device and therefore the access point to the BACnet network via a network card. This block enables the existence of a link to be verified, for example. In order to make the PLC program more transparent, the BACnet adapter is created as a global variable within the TcBACnet-Lib, since in the majority of the projects a single BACnet adapter is used.

Depending on the client and server functionality, the function blocks FB_BACnet_Device or FB_BACnet_RemoteDevice can be used to link state and control information for the BACnet client and server. The operational readiness of the BACnet objects is determined via the client and server status and the property System_Status for the respective device or remote device object. Each BACnet object function block must therefore transfer a reference to the instance of the corresponding FB_BACnet_Device or FB_BACnet-RemoteDevice, in order to enable the status evaluation (bReady).

The following figure shows an overview of the function blocks of TcBACnet-Lib and the corresponding links with the BACnet modules. The linking between a PLC program based on TcBACnet-Lib and the BACnet modules of a configuration can be automated via the function "PLC automapping".

Notice 		Block names

The block names refer to the block versions with maximum process data (extension "_EX"). The standard blocks contain a minimum set of process data, in order to avoid performance impairment in large configurations.

In addition there are function blocks for objects with commandable properties Present_Value which realise write access via ADS (extension "_ADS"). This has the advantage that the process data are not copied cyclically, but are only written to the object in the event of changes. This also enables repeated write access to local objects (writing with identical priority).

Function block variants with extension "_RAW" provide access to the raw value of the corresponding object. Using this module variant the property Present_Value is not mapped to the terminal hardware but in the PLC program. This allows for example to connect BACnet values with values of sub bus systems. An example is shown in the block description.


FB_BACnet_Device

TS8020 | TwinCAT BACnet Supplement

FB_BACnet_Adapter

The following function block is used for linking the PLC program with a local BACnet adapter (network card). The linking of the function block takes place with the aid of process data.

The process data can be linked manually or automatically via PLC automapping. The comments required for PLC automapping ( (* ~ (BACnet... | ??? | ??? ) *) ) are already included in the declaration of the function block.

Fig. 1: Process data of the BACnet adapter in the System Manager.

Fig. 2: Function block of the BACnet adapter in the PLC program.

Use

The function block "FB_BACnet_Adapter" is used to read the state of the local BACnet adapter (process data "Device Status") and output it in the PLC program. In addition, the process data "AmsNetID" is used to read the AMS NetID of the BACnet adapter (ARRAY OF BYTE --> string) and to output it as a string.

An instance of the block FB_BACnet_Adapter is provided through the PLC library as a global instance and does therefore not have to be created explicitly. The global instance is detected during PLC automapping and automatically linked with the BACnet adapter in the System Manager. The block instance is required by the blocks "FB_BACnet_Device" and "FB_BACnet_RemoteDevice". The hierarchy between "FB_BACnet_Adapter", "FB_BACnet_Device" and "FB_BACnet_RemoteDevice" and an object of type AnalogValue is shown below:

Fig. 3: Example for linking the FB instances in the PLC.

For notes on using the blocks "FB_BACnet_Device" and "-_RemoteDevice" see FB_BACnet_Device and FB_BACnet_RemoteDevice. Calling of the instance of the block FB_BACnet_Adapter is not compulsory. If required, the adapter block is called automatically by the instances of the blocks "FB_BACnet_Device" or "FB_BACnet_RemoteDevice".

VAR_OUTPUT

      Name             : Type

eAdapterStatus   : E_BACnetAdapterStatus;
bEthLinkOk       : BOOL;
bGatewayOk       : BOOL;
sAmsNetId        : T_AmsNetId;
bFirstCycle      : BOOL;
bError           : BOOL;
nErrorId         : UINT;

eAdapterStatus: Current status of the BACnet adapter. The following values are possible:
0: BACnetAdapterStatus_Init (initialisation has commenced)
1: BACnetAdapterStatus_CheckIpAddr (checking the IP address)
2: BACnetAdapterStatus_CheckParam (checking the parameter)
3: BACnetAdapterStatus_GetGatewayMAC (determining the MAC of the gateway)
4: BACnetAdapterStatus_WaitGatewayMAC (waiting for MAC address of the gateway)
5: BACnetAdapterStatus_Complete (initialised and ready)

bEthLinkOk: The local Ethernet connection is active (cable connected, adapter linked) if the output is set to TRUE.

bGatewayOk: The configured gateway can be reached if the output is set to TRUE.

sAmsNetId: Output of the AMS NetID of the local BACnet adapter (can be used for asynchronous access to BACnet objects via ADS).

bFirstCycle: Is set for one cycle when the block instance is first called after a PLC reset or restart.

bError: An error is pending.

nErrorId: Error number (0 = no error; 1 = no valid AMS NetID). The error numbers can be queried as block constants via the FB instance (FB_BACnet_Adapter.nERR_xxx).

Notes

If no network connection is available (bEthLinkOk = FALSE) or a gateway cannot be reached (bGatewayOk = FALSE) all linked remote objects (clients) are blocked. Local objects are not affected.


FB_BACnet_Device

The following function block is used for linking the PLC program to a local BACnet device object (server). The linking of the function block takes place with the aid of process data.

The process data can be linked manually or automatically via PLC automapping. The comments required for PLC automapping ( (* ~ (BACnet... | ??? | ??? ) *) ) are already included in the declaration of the function block. The process data for the BACnet device object also include the required process data for linking the BACnet server.

Fig. 1: Process data of the BACnet device object and server in the System Manager.

Fig. 2: Function block of the BACnet device object and server in the PLC program.

Use

The function block "FB_BACnet_Device" is used to read the state of the local BACnet device object (System_Status) and output it in the PLC program. In addition, the process data "Server Control" is used to control the local BACnet server (activation and handling of the PLC backup).

The block "FB_BACnet_Device" also requires a global instance of the block FB_BACnet_Adapter for each PLC project. The block FB_BACnet_Adapter establishes the connection between PLC and BACnet adapter in the System Manager. This global instance is already provided by the PLC library. The hierarchy between FB_BACnet_Adapter, FB_BACnet_Device and FB_BACnet_RemoteDevice and an object of type AnalogValue (AV) is shown below:

Fig. 3: Example for linking the FB instances in the PLC.

For notes on using the blocks FB_BACnet_Adapter and -_RemoteDevice see FB_BACnet_Adapter and FB_BACnet_RemoteDevice.

VAR_INPUT

      Name             : Type

bReset           : BOOL;
bSupportBackup   : BOOL;
nAdsPort         : UINT := 1000; (* Optional setting: Ads port of local BACnet-Server, default = 1000 *)

bReset: Resets the error state in the event of a signal change FALSE --> TRUE.

bSupportBackup: If the input is set to TRUE, saving of the persistent PLC runtime data via BACnet is supported. If this mode is activated, the persistent PLC data (by default under: "C:\TwinCAT\Boot\") have to be created as BACnet file objects and associated with the value "TwinCAT Configuration File" of the property File_Type (in this way the BACnet stack ensures that the files are saved).
If BACnet-based backup of the persistent PLC data is used, no further instance of the block FB_WritePersistentData should be used in the PLC runtime (FB_WritePersistentData is executed by FB_BACnet_Device)

nAdsPort: ADS port of the local BACnet server. The default number is 1000 (provided the BACnet server is the first element under the BACnet adapter in the System Manager). The port number can be read in the System Manager (see Fig. 4):

Fig. 4: ADS port in the System Manager

VAR_OUTPUT

Name             : Type
eSystemStatus    : E_BACnetDeviceStatus;
sAmsNetId        : T_AmsNetId;
bBackupActive    : BOOL;
bOperational     : BOOL;
bFirstCycle      : BOOL;
bError           : BOOL;
nErrorId         : UINT;

eSystemStatus: Current status of the BACnet server object (see BACnet specification DIN EN ISO 16484-5 for BACnet device object and property System_Status).
0: BACnetDeviceStatus_Operational
1: BACnetDeviceStatus_OperationalReadOnly (only read access to properties)
2: BACnetDeviceStatus_DownloadRequired (loading of the configuration required)
3: BACnetDeviceStatus_DownloadInProgress (configuration download in progress)
4: BACnetDeviceStatus_NonOperational
5: BACnetDeviceStatus_BackupInProgress

sAmsNetId: Output of the AMS NetID of the local BACnet adapter (can be used for asynchronous access to BACnet objects via ADS).

bBackupActive: Feedback to indicate that a backup via BACnet is executed if the output is set to TRUE.

bOperational: BACnet device object (of the local server) reports "operational" and the device adapter reports the status "GetGatewayMAC" (0x03xx) or "WaitGatewayMAC" (0x04xx) or "Complete" (0x08xx). If the output becomes FALSE, all linked objects are blocked (block instances).

bFirstCycle: Is set for one cycle when the block instance is first called after a PLC reset or restart.

bError: An error is pending.

nErrorId: Error number
0 = no error
1 = no valid AMS NetID
20 = error during writing of the persistent data
The error numbers can be queried as block constants via the FB instance (FB_BACnet_Device.nERR_xxx). All errors with error number equal or greater than 20 have to be acknowledged with bReset.

Notes

An instance of block "FB_BACnet_Device" is required whenever access to objects of a local BACnet server from the PLC is required. In principle, several instances of the block "FB_BACnet_Device" can be created, although this would result in an error message in the System Manager when PLC automapping is used. This is due to the BACnet architecture. Under a BACnet adapter (network device) only one BACnet server can be created at a time. If PLC automapping is not used, any number of BACnet adapters and servers can be used in a PLC project. In this case the instances are linked manually.

The block "FB_BACnet_Device" accesses the global variable "pBACnet_Adapter" internally. It contains a reference to the global instance of the block FB_BACnet_Adapter. If several instances of the block "FB_BACnet_Device" are to be created and manually linked in the System Manager with the corresponding BACnet servers, several instances of the block FB_BACnet_Adapter have to be created. Before the instance of the BACnet server block is called, it is essential to call the corresponding instance of the BACnet adapter block. A CFC example is provided below (Please note the order in which the blocks are called!):

Fig. 5: Example for using several adapter and server instances in a PLC project. | Fig. 6: Example for calling blocks of type FB_BACnet_AnalogValue with different local BACnet servers in a PLC project.

The use of several local BACnet servers (adapters) in a PLC project is a special case and is not recommended. It could make sense (e.g. in cases where several network cards and therefore separate BACnet networks are used) to use several PLC projects and therefore several PLC runtimes. Data exchange between the individual runtimes can be realised via process data mapping or ADS communication. In this case PLC automapping could be used for BACnet objects.


FB_BACnet_Accumulator

The following function block is used for linking a BACnet object of the local BACnet server. The function block for the corresponding BACnet object is linked with the aid of process data.

The process data can be created manually in the BACnet object, linked manually, or they can be generated automatically via PLC automapping. The comments required for PLC automapping ( (* ~ (BACnet... | ??? | ??? ) *) ) are already included in the declaration of the function block.

Use

The function block "FB_BACnet_Accumulator" can be used for read and write access to a BACnet object of type Accumulator (ACC). To this end the BACnet object was created under a local BACnet server.

Fig. 1: Example of a BACnet object under a local BACnet server.

VAR_INPUT

Name             : Type
nPV              : UDINT;

nPV: Value to be written to the property Present_Value. Process data are always written cyclically.

VAR_OUTPUT

Note: Variables shown in grey italics are only available in the extended version of the block. The extended versions of the blocks end with "_EX". They offer substantially more process data, although in projects with a large number of objects this may have performance implications.

Name             : Type
bReady           : BOOL;
nPresentValue    : UDINT;
nMaxPV           : UDINT;
bOverridden      : BOOL;
bOutOfService    : BOOL;
bFault           : BOOL;
bInAlarm         : BOOL;
bOverRange       : BOOL;
bUnderRange      : BOOL;
bNoSensor        : BOOL;
bOpenLoop        : BOOL;
bShortedLoop     : BOOL;
bOtherFault      : BOOL;
eEventState      : E_BACnetEventState;
bError           : BOOL;
nErrorId         : UINT;

bReady: Notification of general readiness. If this output is set, the other status outputs are valid (PresentValue, Overridden ...). If the output is FALSE, the corresponding function block "FB_BACnet_Device" does not report "Operational", or the block instance was not linked correctly in the System Manager.

nPresentValue: Current value of the BACnet object (see also BACnet specification DIN EN ISO 16484-5 for BACnet object Accumulator and property Present_value).

nMaxPV: Current value of the property Max_Pres_Value of the BACnet object (see also BACnet specification DIN EN ISO 16484-5 for BACnet object Accumulator and property Max_Pres_Value).

bOverride, bOutOfService, bFault, bInAlarm: See BACnet specification DIN EN ISO 16484-5 for BACnet object Accumulator and property Status_Flags.

bOverRange, bUnderRange, bNoSensor, bOpenLoop, bShortedLoop, bOtherFault: See BACnet specification DIN EN ISO 16484-5 for BACnet object Accumulator and property Reliability.

eEventState: See BACnet specification DIN EN ISO 16484-5 for BACnet object Accumulator and property Event_State.

bError: An error is pending.

nErrorId: Error number
0 = no error
2 = incorrect process data mapping detected (check mapping in the System Manager; if necessary compile complete PLC project and reload)
3 = the corresponding BACnet server is not ready (bOperational = FALSE at instance of the FB_BACnet_Device)
The error numbers can be queried as block constants via the FB instance (FB_BACnet_???.nERR_xxx).

VAR_IN_OUT

Name             : Type
Device           : FB_BACnet_Device;

Device: Specification of the instance of the local corresponding BACnet server block. For each BACnet adapter one BACnet server is possible. See FB_BACnet_Adapter and FB_BACnet_Device for further information.


FB_BACnet_AnalogInput

The following function block is used for linking a BACnet object of the local BACnet server. The function block for the corresponding BACnet object is linked with the aid of process data.

The process data can be created manually in the BACnet object, linked manually, or they can be generated automatically via PLC automapping. The comments required for PLC automapping ( (* ~ (BACnet... | ??? | ??? ) *) ) are already included in the declaration of the function block.

Use

The function block "FB_BACnet_AnalogInput" can be used for read access to a BACnet object of type AnalogInput (AI). To this end the BACnet object was created under a local BACnet server.

Fig. 1: Example of a BACnet object under a local BACnet server.

VAR_OUTPUT

Note: Variables shown in grey italics are only available in the extended version of the block. The extended versions of the blocks end with "_EX". They offer substantially more process data, although in projects with a large number of objects this may have performance implications.

Name             : Type
bReady                  : BOOL;
fPresentValue           : REAL;
bOverridden             : BOOL;
bOutOfService           : BOOL;
bFault                  : BOOL;
bInAlarm                : BOOL;
bOverRange              : BOOL;
bUnderRange             : BOOL;
bNoSensor               : BOOL;
bOpenLoop               : BOOL;
bShortedLoop            : BOOL;
bOtherFault             : BOOL;
eEventState             : E_BACnetEventState;
bAckedTrans_ToOffNormal : BOOL;
bAckedTrans_ToFault     : BOOL;
bAckedTrans_ToNormal    : BOOL;bError                  : BOOL;
nErrorId                : UINT;

bReady: Notification of general readiness. If this output is set, the other status outputs are valid (PresentValue, Overridden ...). If the output is FALSE, the corresponding function block "FB_BACnet_Device" does not report "Operational", or the block instance was not linked correctly in the System Manager.

fPresentValue: Current value of the BACnet object (see also BACnet specification DIN EN ISO 16484-5 for BACnet object AnalogInput and property Present_Value).

bOverride, bOutOfService, bFault, bInAlarm: See BACnet specification DIN EN ISO 16484-5 for BACnet object AnalogInput and property Status_Flags.

bOverRange, bUnderRange, bNoSensor, bOpenLoop, bShortedLoop, bOtherFault: See BACnet specification DIN EN ISO 16484-5 for BACnet object AnalogInput and property Reliability.

eEventState: See BACnet specification DIN EN ISO 16484-5 for BACnet object AnalogInput and property Event_State.

bAckedTrans_ToOffNormal, bAckedTrans_ToFault, bAckedTrans_ToNormal: Flags of property Acked_Transitions (see also BACnet specification DIN EN ISO 16484-5 for BACnet object AnalogInput and property Acked_Transitions).

bError: An error is pending.

nErrorId: Error number
0 = no error
2 = incorrect process data mapping detected (check mapping in the System Manager; if necessary compile complete PLC project and reload)
3 = the corresponding BACnet server is not ready (bOperational = FALSE at instance of the FB_BACnet_Device)
The error numbers can be queried as block constants via the FB instance (FB_BACnet_???.nERR_xxx).

VAR_IN_OUT

Name             : Type
Device           : FB_BACnet_Device;

Device: Specification of the instance of the local corresponding BACnet server block. For each BACnet adapter one BACnet server is possible. See FB_BACnet_Adapter and and FB_BACnet_Device for further information.


FB_BACnet_AnalogInput_RAW

The following function block is used for linking a BACnet object of the local BACnet server. The function block for the corresponding BACnet object is linked with the aid of process data.

The process data can be created manually in the BACnet object, linked manually, or they can be generated automatically via PLC automapping. The comments required for PLC automapping ( (* ~ (BACnet... | ??? | ??? ) *) ) are already included in the declaration of the function block.

Contrary to the standard variant of the function block, the raw value is provided by a function block input and not by the terminal hardware. This allows e.g. Analog input information that are generated in the PLC code displayed as an analog input object to BACnet (signal mapping for sub bus systems or virtual data points, etc.).

Use

The function block "FB_BACnet_AnalogInput_RAW" can be used for read access to a BACnet object of type AnalogInput (AI). To this end the BACnet object was created under a local BACnet server.

Fig. 1: Example of a BACnet object under a local BACnet server.

VAR_INPUT

Name             : Type
nRawIn           : INT; (* ~(BACnet_RawIoAnalogSignedValue : : ) *)

nRawIn: Raw value input of the object in the range -32768 ... 32767. The input is linked to the process data "RawIoAnalogSignedValue" of the BACnet object. The value of "nRawIn" results to property Present_Value according to property Resolution (assuming the object state is not out_of_service).

VAR_OUTPUT

Name             : Type
bReady                  : BOOL;
fPresentValue           : REAL;
bOverridden             : BOOL;
bOutOfService           : BOOL;
bFault                  : BOOL;
bInAlarm                : BOOL;
bAckedTrans_ToOffNormal : BOOL;
bAckedTrans_ToFault     : BOOL;
bAckedTrans_ToNormal    : BOOL;bError                  : BOOL;
nErrorId                : UINT;

bReady: Notification of general readiness. If this output is set, the other status outputs are valid (PresentValue, Overridden ...). If the output is FALSE, the corresponding function block "FB_BACnet_Device" does not report "Operational", or the block instance was not linked correctly in the System Manager.

fPresentValue: Current value of the BACnet object (see also BACnet specification DIN EN ISO 16484-5 for BACnet object AnalogInput and property Present_Value).

bOverride, bOutOfService, bFault, bInAlarm: See BACnet specification DIN EN ISO 16484-5 for BACnet object AnalogInput and property Status_Flags.

bAckedTrans_ToOffNormal, bAckedTrans_ToFault, bAckedTrans_ToNormal: Flags of property Acked_Transitions (see also BACnet specification DIN EN ISO 16484-5 for BACnet object AnalogInput and property Acked_Transitions).

bError: An error is pending.

nErrorId: Error number
0 = no error
2 = incorrect process data mapping detected (check mapping in the System Manager; if necessary compile complete PLC project and reload)
3 = the corresponding BACnet server is not ready (bOperational = FALSE at instance of the FB_BACnet_Device)
The error numbers can be queried as block constants via the FB instance (FB_BACnet_???.nERR_xxx).

VAR_IN_OUT

Name             : Type
Device           : FB_BACnet_Device;

Device: Specification of the instance of the local corresponding BACnet server block. For each BACnet adapter one BACnet server is possible. See FB_BACnet_Adapter and FB_BACnet_Device for further information.

Example

The following example shows the mapping of an EIB integer value into the Property Present_Value of an analog input object:

Fig. 2: Example for the mapping from EIB to the Property Present_Value in PLC code. This example requires the library "TcKL6301.lib". Refer to the manual of terminal KL6301 for more information about EIB.


FB_BACnet_AnalogOutput

The following function block is used for linking a BACnet object of the local BACnet server. The function block for the corresponding BACnet object is linked with the aid of process data.

The process data can be created manually in the BACnet object, linked manually, or they can be generated automatically via PLC automapping. The comments required for PLC automapping ( (* ~ (BACnet... | ??? | ??? ) *) ) are already included in the declaration of the function block.

Use

The function block "FB_BACnet_AnalogOutput" can be used for read and write access to a BACnet object of type AnalogOutput (AO) To this end the BACnet object was created under a local BACnet server.

Fig. 1: Example of a BACnet object under a local BACnet server.

VAR_INPUT

Name             : Type
bEnablePV        : BOOL;
fPV              : REAL;

bEnablePV: Enables the value of input "fPV". When the input is set to TRUE, an entry is made in the Priority_Array of the corresponding BACnet object with the value of input "fPV". This corresponds to a write access to the commandable property Present_Value with the set priority (default: 12 when PLC automapping is used or 16 for manual linking in the System Manager).

fPV: Value to be written to the Priority_Array of the commandable property Present_Value. The priority is based on the process data configuration and mapping of the BACnet object in the System Manager (see also Figs. 2 and 3). Writing is enabled by setting the input "bEnablePV" to TRUE. Process data are always written cyclically once enabled.

Fig. 2: Example of a BACnet object with process data for writing the commandable property Present_Value. | Fig. 3: Example for a process data configuration of an BACnet object in the System Manager. Priority 12 and 16 are created as mappable process data (see result in Fig. 2).

VAR_OUTPUT

Note: Variables shown in grey italics are only available in the extended version of the block. The extended versions of the blocks end with "_EX". They offer substantially more process data, although in projects with a large number of objects this may have performance implications.

Name             : Type
bReady                  : BOOL;
fPresentValue           : REAL;
bOverridden             : BOOL;
bOutOfService           : BOOL;
bFault                  : BOOL;
bInAlarm                : BOOL;
bNoOutput               : BOOL;
bOpenLoop               : BOOL;
bShortedLoop            : BOOL;
bOtherFault             : BOOL;
eEventState             : E_BACnetEventState;
bAckedTrans_ToOffNormal : BOOL;
bAckedTrans_ToFault     : BOOL;
bAckedTrans_ToNormal    : BOOL;
nActivePrio             : UINT;
bError                  : BOOL;
nErrorId                : UINT;

bReady: Notification of general readiness. If this output is set, the other status outputs are valid (PresentValue, Overridden ...). If the output is FALSE, the corresponding function block "FB_BACnet_Device" does not report "Operational", or the block instance was not linked correctly in the System Manager.

fPresentValue: Current value of the BACnet object (see also BACnet specification DIN EN ISO 16484-5 for BACnet object AnalogOutput and property Present_Value).

bOverridden, bOutOfService, bFault, bInAlarm: See BACnet specification DIN EN ISO 16484-5 for BACnet object AnalogOutput and property Status_Flags.

bNoOutput, bOpenLoop, bShortedLoop, bOtherFault: See BACnet specification DIN EN ISO 16484-5 for BACnet object AnalogOutput and property Reliability.

eEventState: See BACnet specification DIN EN ISO 16484-5 for BACnet object AnalogOutput and property Event_State.

bAckedTrans_ToOffNormal, bAckedTrans_ToFault, bAckedTrans_ToNormal: Flags of property Acked_Transitions (see also BACnet specification DIN EN ISO 16484-5 for BACnet object AnalogOutput and property Acked_Transitions).

nActivePrio: Indicates the currently active priority of the priority array, which acts on the Present_Value (see also BACnet specification DIN EN ISO 16484-5 for BACnet object AnalogOutput and property Present_Value).

bError: An error is pending.

nErrorId: Error number
0 = no error
2 = incorrect process data mapping detected (check mapping in the System Manager; if necessary compile complete PLC project and reload)
3 = the corresponding BACnet server is not ready (bOperational = FALSE at instance of the FB_BACnet_Device)
The error numbers can be queried as block constants via the FB instance (FB_BACnet_???.nERR_xxx).

VAR_IN_OUT

Name             : Type
Device           : FB_BACnet_Device;

Device: Specification of the instance of the local corresponding BACnet server block. For each BACnet adapter one BACnet server is possible. See FB_BACnet_Adapter and FB_BACnet_Device for further information.


FB_BACnet_AnalogOutput_ADS

The following function block is used for linking a BACnet object of the local BACnet server. The function block for the corresponding BACnet object is linked with the aid of process data.

The process data can be created manually in the BACnet object, linked manually, or they can be generated automatically via PLC automapping. The comments required for PLC automapping ( (* ~ (BACnet... | ??? | ??? ) *) ) are already included in the declaration of the function block.

Use

The function block "FB_BACnet_AnalogOutput_ADS" can be used for read and asynchronous write access to a BACnet object of type AnalogOutput (AO). To this end the BACnet object was created under a local BACnet server.

Fig. 1: Example of a BACnet object under a local BACnet server.

VAR_INPUT

Name             : Type
bEnablePV        : BOOL;
fPV              : REAL; (* decimal number for priority x, when input bEnablePV is TRUE *)
bManual                 : BOOL; (* FALSE --> TRUE: write present_value immediately,
FALSE: only write present_value on-change,
TRUE: write present_value on-change and when device turns operational *)
ePriority               : E_BACNETPRIORITY := BACNETPRIORITY_12;

bEnablePV: Enables the value of input "fPV". When the input is set to TRUE, an entry is made in the Priority_Array of the corresponding BACnet object with the value of input "fPV". This corresponds to a write access to the commandable property Present_Value with the priority given by the input "ePriority" (default: 12 when the input "ePriroty" is not connected).

fPV: Value to be written to the Priority_Array of the commandable property Present_Value. The priority is given by the input "ePriority". Writing is enabled by setting the input "bEnablePV" to TRUE. The value is written on change (WOC) or by the logic behind the input "bManual" (refer to the input description).

Hint: Since writing the property Present_Value happens acyclically and only on value change, it is potentially possible that the property Present_Value is overwritten with the same priority by other BACnet devices. In case of equal priorities, the last write access "wins".

bManual: The following logic will be distinguished for the input:
- FALSE: Write on change (WOC) for the input "fPV"
- edge transition FALSE --> TRUE: Triggers the writing of the input "fPV" immediately
- TRUE: Writing when value changed or when the associated BACnet server changes in the "operational" state (see FB_BACnet_Device).

ePriority: Priority for write accesses to the property Present_Value (Default: 12, see E_BACNETPRIORITY).

VAR_OUTPUT

Name             : Type
bReady           : BOOL;
bPvDone          : BOOL; (* present_value written over ADS *)
fPresentValue    : REAL;
bOverridden      : BOOL;
bOutOfService    : BOOL;
bFault           : BOOL;
bInAlarm         : BOOL;
bError           : BOOL;
nErrorId         : UINT;
nAdsErrorId      : UDINT;

bReady: Notification of general readiness. If this output is set, the other status outputs are valid (PresentValue, Overridden ...). If the output is FALSE, the corresponding function block "FB_BACnet_Device" does not report "Operational", or the block instance was not linked correctly in the System Manager.

bPvDone: Positive edge when write access to property Present_Value was successfull.

fPresentValue: Current value of the BACnet object (see also BACnet specification DIN EN ISO 16484-5 for BACnet object AnalogOutput and property Present_Value).

bOverridden, bOutOfService, bFault, bInAlarm: See BACnet specification DIN EN ISO 16484-5 for BACnet object AnalogOutput and property Status_Flags.

bError: An error is pending.

nErrorId: Error number
0 = no error
2 = incorrect process data mapping detected (check mapping in the System Manager; if necessary compile complete PLC project and reload)
3 = the corresponding BACnet server is not ready (bOperational = FALSE at instance of the "FB_BACnet_Device")
4 = the object type of the BACnet object dosn't match the function block type (the object type will determined over the process data. --> check the process data mapping in the System Manager!)
The error numbers can be queried as block constants via the FB instance (FB_BACnet_???.nERR_xxx).

nAdsErrorId: ADS error code.

VAR_IN_OUT

Name             : Type
Device           : FB_BACnet_Device;

Device: Specification of the instance of the local corresponding BACnet server block. For each BACnet adapter one BACnet server is possible. See FB_BACnet_Adapter and FB_BACnet_Device for further information.


FB_BACnet_AnalogOutput_RAW

The following function block is used for linking a BACnet object of the local BACnet server. The function block for the corresponding BACnet object is linked with the aid of process data.

The process data can be created manually in the BACnet object, linked manually, or they can be generated automatically via PLC automapping. The comments required for PLC automapping ( (* ~ (BACnet... | ??? | ??? ) *) ) are already included in the declaration of the function block.

Contrary to the standard variant of the function block, the raw value is provided by a function block output and not by the terminal hardware. This allows e.g. Analog output information that is used in the PLC code displayed as an analog output object to BACnet (signal mapping for sub bus systems or virtual data points, etc.).

Use

The function block "FB_BACnet_AnalogOutput_RAW" can be used for read and write access to a BACnet object of type AnalogOutput (AO). To this end the BACnet object was created under a local BACnet server.

Fig. 1: Example of a BACnet object under a local BACnet server.

VAR_INPUT

Name             : Type
bEnablePV        : BOOL;
fPV              : REAL;

bEnablePV: Enables the value of input "fPV". When the input is set to TRUE, an entry is made in the Priority_Array of the corresponding BACnet object with the value of input "fPV". This corresponds to a write access to the commandable property Present_Value with the set priority (default: 12 when PLC automapping is used or 16 for manual linking in the System Manager).

fPV: Value to be written to the Priority_Array of the commandable property Present_Value. The priority is based on the process data configuration and mapping of the BACnet object in the System Manager (see also Figs. 2 and 3). Writing is enabled by setting the input "bEnablePV" to TRUE. Process data are always written cyclically once enabled.

Fig. 2: Example of a BACnet object with process data for writing the commandable property Present_Value. | Fig. 3: Example for a process data configuration of an BACnet object in the System Manager. Priority 12 and 16 are created as mappable process data (see result in Fig. 2).

VAR_OUTPUT

Name             : Type
bReady                  : BOOL;
fPresentValue           : REAL;
bOverridden             : BOOL;
bOutOfService           : BOOL;
bFault                  : BOOL;
bInAlarm                : BOOL;
bAckedTrans_ToOffNormal : BOOL;
bAckedTrans_ToFault     : BOOL;
bAckedTrans_ToNormal    : BOOL;bError                  : BOOL;
nErrorId                : UINT;
nRawOut                : INT; (* ~(BACnet_RawIoAnalogSignedValue : : ) *)

bReady: Notification of general readiness. If this output is set, the other status outputs are valid (PresentValue, Overridden ...). If the output is FALSE, the corresponding function block "FB_BACnet_Device" does not report "Operational", or the block instance was not linked correctly in the System Manager.

fPresentValue: Current value of the BACnet object (see also BACnet specification DIN EN ISO 16484-5 for BACnet object AnalogOutput and property Present_Value).

bOverridden, bOutOfService, bFault, bInAlarm: See BACnet specification DIN EN ISO 16484-5 for BACnet object AnalogOutput and property Status_Flags.

bAckedTrans_ToOffNormal, bAckedTrans_ToFault, bAckedTrans_ToNormal: Flags of property Acked_Transitions (see also BACnet specification DIN EN ISO 16484-5 for BACnet object AnalogOutput and property Acked_Transitions).

bError: An error is pending.

nErrorId: Error number
0 = no error
2 = incorrect process data mapping detected (check mapping in the System Manager; if necessary compile complete PLC project and reload)
3 = the corresponding BACnet server is not ready (bOperational = FALSE at instance of the FB_BACnet_Device)
The error numbers can be queried as block constants via the FB instance (FB_BACnet_???.nERR_xxx).

nRawOut: Raw value output of the object in the range -32768 ... 32767. The output is linked to the process data "RawIoAnalogSignedValue" of the BACnet object. The value of "nRawOut" is the calculation result of property Present_Value and property Resolution (assuming the object state is not out_of_service).

VAR_IN_OUT

Name             : Type
Device           : FB_BACnet_Device;

Device: Specification of the instance of the local corresponding BACnet server block. For each BACnet adapter one BACnet server is possible. See FB_BACnet_Adapter and FB_BACnet_Device for further information.

Example

The following example shows the mapping of the Property Present_Value of an analog output object to an EIB integer value:

Fig. 4: Example for the mapping of the property Present_Value to EIB in PLC code. This example requires the library "TcKL6301.lib". Refer to the manual of terminal KL6301 for more information about EIB.


FB_BACnet_AnalogValue

The following function block is used for linking a BACnet object of the local BACnet server. The function block for the corresponding BACnet object is linked with the aid of process data.

The process data can be created manually in the BACnet object, linked manually, or they can be generated automatically via PLC automapping. The comments required for PLC automapping ( (* ~ (BACnet... | ??? | ??? ) *) ) are already included in the declaration of the function block.

Use

The function block "FB_BACnet_AnalogValue" can be used for read and write access to a BACnet object of type AnalogValue (AV). To this end the BACnet object was created under a local BACnet server.

Fig. 1: Example of a BACnet object under a local BACnet server.

VAR_INPUT

Name             : Type
bEnablePV        : BOOL;
fPV              : REAL;

bEnablePV: Enables the value of input "fPV". When the input is set to TRUE, an entry is made in the Priority_Array of the corresponding BACnet object with the value of input "fPV". This corresponds to a write access to the commandable property Present_Value with the set priority (default: 12 when PLC automapping is used or 16 for manual linking in the System Manager).
If bEnablePV is set to FALSE, the corresponding entry from the Priority_Array is removed again (write ZERO).

fPV: Value to be written to the Priority_Array of the commandable property Present_Value. The priority is based on the process data configuration and mapping of the BACnet object in the System Manager (see also Figs. 2 and 3). Writing is enabled by setting the input bEnablePV to TRUE. Process data are always written cyclically once enabled.

Fig. 2: Example of a BACnet object with process data for writing the commandable property Present_Value. | Fig. 3: Example for a process data configuration of an BACnet object in the System Manager. Priority 12 and 16 are created as mappable process data (see result in Fig. 2).

VAR_OUTPUT

Note: Variables shown in grey italics are only available in the extended version of the block. The extended versions of the blocks end with "_EX". They offer substantially more process data, although in projects with a large number of objects this may have performance implications.

Name             : Type
bReady                  : BOOL;
fPresentValue           : REAL;
bOverridden             : BOOL;
bOutOfService           : BOOL;
bFault                  : BOOL;
bInAlarm                : BOOL;
bOverRange              : BOOL;
bUnderRange             : BOOL;
bOtherFault             : BOOL;
eEventState             : E_BACnetEventState;
bAckedTrans_ToOffNormal : BOOL;
bAckedTrans_ToFault     : BOOL;
bAckedTrans_ToNormal    : BOOL;
nActivePrio             : UINT;
bError                  : BOOL;
nErrorId                : UINT;

bReady: Notification of general readiness. If this output is set, the other status outputs are valid (PresentValue, Overridden ...). If the output is FALSE, the corresponding function block "FB_BACnet_Device" does not report "Operational", or the block instance was not linked correctly in the System Manager.

fPresentValue: Current value of the BACnet object (see also BACnet specification DIN EN ISO 16484-5 for BACnet object AnalogValue and property Present_Value).

bOverride, bOutOfService, bFault, bInAlarm: See BACnet specification DIN EN ISO 16484-5 for BACnet object AnalogValue and property Status_Flags.

bOverRange, bUnderRange, bOtherFault: See BACnet specification DIN EN ISO 16484-5 for BACnet object AnalogValue and property Reliability.

eEventState: See BACnet specification DIN EN ISO 16484-5 for BACnet object AnalogValue and property Event_State.

bAckedTrans_ToOffNormal, bAckedTrans_ToFault, bAckedTrans_ToNormal: Flags of property Acked_Transitions (see also BACnet specification DIN EN ISO 16484-5 for BACnet object AnalogValue and property Acked_Transitions).

nActivePrio: Indicates the currently active priority of the priority array, which acts on the Present_Value (see also BACnet specification DIN EN ISO 16484-5 for BACnet object AnalogValue and property Present_Value).

bError: An error is pending.

nErrorId: Error number
0 = no error
2 = incorrect process data mapping detected (check mapping in the System Manager; if necessary compile complete PLC project and reload)
3 = the corresponding BACnet server is not ready (bOperational = FALSE at instance of the FB_BACnet_Device)
The error numbers can be queried as block constants via the FB instance (FB_BACnet_???.nERR_xxx).

VAR_IN_OUT

Name             : Type
Device           : FB_BACnet_Device;

Device: Specification of the instance of the local corresponding BACnet server block. For each BACnet adapter one BACnet server is possible. See FB_BACnet_Adapter and FB_BACnet_Device for further information.


FB_BACnet_BinaryValue_ADS

The following function block is used for linking a BACnet object of the local BACnet server. The function block for the corresponding BACnet object is linked with the aid of process data.

The process data can be created manually in the BACnet object, linked manually, or they can be generated automatically via PLC automapping. The comments required for PLC automapping ( (* ~ (BACnet... | ??? | ??? ) *) ) are already included in the declaration of the function block.

Use

The function block "FB_BACnet_BinaryValue_ADS" can be used for read and write access to a BACnet object of type BinaryValue (BV). To this end the BACnet object was created under a local BACnet server.

Fig. 1: Example of a BACnet object under a local BACnet server.

VAR_INPUT

Name             : Type
bEnablePV        : BOOL;
bPV              : BOOL; (* present value bool type *)
bManual                 : BOOL; (* FALSE --> TRUE: write present_value immediately,
FALSE: only write present_value on-change,
TRUE: write present_value on-change and when device turns operational *)
ePriority               : E_BACNETPRIORITY := BACNETPRIORITY_12;

bEnablePV: Enables the value of input "bPV". When the input is set to TRUE, an entry is made in the Priority_Array of the corresponding BACnet object with the value of input "bPV". This corresponds to a write access to the commandable property Present_Value with the priority given by the input "ePriority" (default: 12 when the input "ePriroty" is not connected).

bPV: Value to be written to the Priority_Array of the commandable property Present_Value. The priority is given by the input "ePriority". Writing is enabled by setting the input "bEnablePV" to TRUE. The value is written on change (WOC) or by the logic behind the input "bManual" (refer to the input description).

Hint: Since writing the property Present_Value happens acyclically and only on value change, it is potentially possible that the property Present_Value is overwritten with the same priority by other BACnet devices. In case of equal priorities, the last write access "wins".

bManual: The following logic will be distinguished for the input:
- FALSE: Write on change (WOC) for the input "bPV"
- edge transition FALSE --> TRUE: Triggers the writing of the input "bPV" immediately
- TRUE: Writing when value changed or when the associated BACnet server changes in the "operational" state (see FB_BACnet_Device).

ePriority: Priority for write accesses to the property Present_Value (Default: 12, see E_BACNETPRIORITY).

VAR_OUTPUT

Name             : Type
bReady           : BOOL;
bPvDone          : BOOL; (* present_value written over ADS *)
bPresentValue    : BOOL;
bOverridden      : BOOL;
bOutOfService    : BOOL;
bFault           : BOOL;
bInAlarm         : BOOL;
bError           : BOOL;
nErrorId         : UINT;
nAdsErrorId      : UDINT;

bReady: Notification of general readiness. If this output is set, the other status outputs are valid (PresentValue, Overridden ...). If the output is FALSE, the corresponding function block "FB_BACnet_Device" does not report "Operational", or the block instance was not linked correctly in the System Manager.

bPvDone: Positive edge when write access to property Present_Value was successfull.

bPresentValue: Current value of the BACnet object (see also BACnet specification DIN EN ISO 16484-5 for BACnet object BinaryValue and property Present_Value).

bOverridden, bOutOfService, bFault, bInAlarm: See BACnet specification DIN EN ISO 16484-5 for BACnet object BinaryValue and property Status_Flags.

bError: An error is pending.

nErrorId: Error number
0 = no error
2 = incorrect process data mapping detected (check mapping in the System Manager; if necessary compile complete PLC project and reload)
3 = the corresponding BACnet server is not ready (bOperational = FALSE at instance of the FB_BACnet_Device)
4 = the object type of the BACnet object dosn't match the function block type (the object type will determined over the process data. --> check the process data mapping in the System Manager!)
The error numbers can be queried as block constants via the FB instance (FB_BACnet_???.nERR_xxx).

nAdsErrorId: ADS error code.

VAR_IN_OUT

Name             : Type
Device           : FB_BACnet_Device;

Device: Specification of the instance of the local corresponding BACnet server block. For each BACnet adapter one BACnet server is possible. See FB_BACnet_Adapter and FB_BACnet_Device for further information.


FB_BACnet_BinaryInput

The following function block is used for linking a BACnet object of the local BACnet server. The function block for the corresponding BACnet object is linked with the aid of process data.

The process data can be created manually in the BACnet object, linked manually, or they can be generated automatically via PLC automapping. The comments required for PLC automapping ( (* ~ (BACnet... | ??? | ??? ) *) ) are already included in the declaration of the function block.

Use

The function block FB_BACnet_BinaryInput can be used for read access to a BACnet object of type BinaryInput (BI). To this end the BACnet object was created under a local BACnet server.

Fig. 1: Example of a BACnet object under a local BACnet server.

VAR_OUTPUT

Note: Variables shown in grey italics are only available in the extended version of the block. The extended versions of the blocks end with "_EX". They offer substantially more process data, although in projects with a large number of objects this may have performance implications.

Name             : Type
bReady                  : BOOL;
bPresentValue           : BOOL;
bOverridden             : BOOL;
bOutOfService           : BOOL;
bFault                  : BOOL;
bInAlarm                : BOOL;
bNoSensor               : BOOL;
bOpenLoop               : BOOL;
bShortedLoop            : BOOL;
bOtherFault             : BOOL;
eEventState             : E_BACnetEventState;
bAckedTrans_ToOffNormal : BOOL;
bAckedTrans_ToFault     : BOOL;
bAckedTrans_ToNormal    : BOOL;
bError                  : BOOL;
nErrorId                : UINT;

bReady: Notification of general readiness. If this output is set, the other status outputs are valid (PresentValue, Overridden ...). If the output is FALSE, the corresponding function block "FB_BACnet_Device" does not report "Operational", or the block instance was not linked correctly in the System Manager.

bPresentValue: Current value of the BACnet object (see also BACnet specification DIN EN ISO 16484-5 for BACnet object BinaryInput and property Present_Value).

bOverridden, bOutOfService, bFault, bInAlarm: See BACnet specification DIN EN ISO 16484-5 for BACnet object BinaryInput and property Status_Flags.

bNoSensor, bOpenLoop, bShortedLoop, bOtherFault: See BACnet specification DIN EN ISO 16484-5 for BACnet object BinaryInput and property Reliability.

eEventState: See BACnet specification DIN EN ISO 16484-5 for BACnet object BinaryInput and property Event_State.

bAckedTrans_ToOffNormal, bAckedTrans_ToFault, bAckedTrans_ToNormal: Flags of property Acked_Transitions (see also BACnet specification DIN EN ISO 16484-5 for BACnet object BinaryInput and property Acked_Transitions).

bError: An error is pending.

nErrorId: Error number
0 = no error
2 = incorrect process data mapping detected (check mapping in the System Manager; if necessary compile complete PLC project and reload)
3 = the corresponding BACnet server is not ready (bOperational = FALSE at instance of the FB_BACnet_Device)
The error numbers can be queried as block constants via the FB instance (FB_BACnet_???.nERR_xxx).

VAR_IN_OUT

Name             : Type
Device           : FB_BACnet_Device;

Device: Specification of the instance of the local corresponding BACnet server block. For each BACnet adapter one BACnet server is possible. See FB_BACnet_Adapter and FB_BACnet_Device for further information.


FB_BACnet_BinaryInput_RAW

The following function block is used for linking a BACnet object of the local BACnet server. The function block for the corresponding BACnet object is linked with the aid of process data.

The process data can be created manually in the BACnet object, linked manually, or they can be generated automatically via PLC automapping. The comments required for PLC automapping ( (* ~ (BACnet... | ??? | ??? ) *) ) are already included in the declaration of the function block.

Contrary to the standard variant of the function block, the raw value is provided by a function block input and not by the terminal hardware. This allows e.g. Digital input information that are generated in the PLC code displayed as an binary input object to BACnet (signal mapping for sub bus systems or virtual data points, etc.).

Use

The function block "FB_BACnet_BinaryInput_RAW" can be used for read access to a BACnet object of type BinaryInput (BI). To this end the BACnet object was created under a local BACnet server.

Fig. 1: Example of a BACnet object under a local BACnet server.

VAR_INPUT

Name             : Type
bRawIn           : BOOL; (* ~(BACnet_RawIoBinaryBoolValue : : ) *)

bRawIn: Raw value input of the object. The input is linked to the process data "RawIoBinaryBoolValue" of the BACnet object. The value of "bRawIn" is mapped to the property Present_Value (assuming the object state is not out_of_service).

VAR_OUTPUT

Name             : Type
bReady                  : BOOL;
bPresentValue           : BOOL;
bOverridden             : BOOL;
bOutOfService           : BOOL;
bFault                  : BOOL;
bInAlarm                : BOOL;
bAckedTrans_ToOffNormal : BOOL;
bAckedTrans_ToFault     : BOOL;
bAckedTrans_ToNormal    : BOOL;
bError                  : BOOL;
nErrorId                : UINT;

bReady: Notification of general readiness. If this output is set, the other status outputs are valid (PresentValue, Overridden ...). If the output is FALSE, the corresponding function block "FB_BACnet_Device" does not report "Operational", or the block instance was not linked correctly in the System Manager.

bPresentValue: Current value of the BACnet object (see also BACnet specification DIN EN ISO 16484-5 for BACnet object BinaryInput and property Present_Value).

bOverridden, bOutOfService, bFault, bInAlarm: See BACnet specification DIN EN ISO 16484-5 for BACnet object BinaryInput and property Status_Flags.

bAckedTrans_ToOffNormal, bAckedTrans_ToFault, bAckedTrans_ToNormal: Flags of property Acked_Transitions (see also BACnet specification DIN EN ISO 16484-5 for BACnet object BinaryInput and property Acked_Transitions).

bError: An error is pending.

nErrorId: Error number
0 = no error
2 = incorrect process data mapping detected (check mapping in the System Manager; if necessary compile complete PLC project and reload)
3 = the corresponding BACnet server is not ready (bOperational = FALSE at instance of the FB_BACnet_Device)
The error numbers can be queried as block constants via the FB instance (FB_BACnet_???.nERR_xxx).

VAR_IN_OUT

Name             : Type
Device           : FB_BACnet_Device;

Device: Specification of the instance of the local corresponding BACnet server block. For each BACnet adapter one BACnet server is possible. See FB_BACnet_Adapter and FB_BACnet_Device for further information.

Example

The following example shows the mapping of an EIB bit value to the property Present_Value of an binary input object:

Fig. 2: Example for the mapping of an EIB binary value to the Property Present_Value in PLC code. This example requires the library "TcKL6301.lib". Refer to the manual of terminal KL6301 for more information about EIB.


FB_BACnet_BinaryOutput

The following function block is used for linking a BACnet object of the local BACnet server. The function block for the corresponding BACnet object is linked with the aid of process data.

The process data can be created manually in the BACnet object, linked manually, or they can be generated automatically via PLC automapping. The comments required for PLC automapping ( (* ~ (BACnet... | ??? | ??? ) *) ) are already included in the declaration of the function block.

Use

The function block "FB_BACnet_BinaryOutput" can be used for read and write access to a BACnet object of type BinaryOutput (BO). To this end the BACnet object was created under a local BACnet server.

Fig. 1: Example of a BACnet object under a local BACnet server.

VAR_INPUT

Name             : Type
bEnablePV        : BOOL;
bPV              : BOOL;

bEnablePV: Enables the value of input "bPV". When the input is set to TRUE, an entry is made in the Priority_Array of the corresponding BACnet object with the value of input "bPV". This corresponds to a write access to the commandable property Present_Value with the set priority (default: 12 when PLC automapping is used or 16 for manual linking in the System Manager).
If bEnablePV is set to FALSE, the corresponding entry from the Priority_Array is removed again (write ZERO).

bPV: Value to be written to the Priority_Array of the commandable property Present_Value. The priority is based on the process data configuration and mapping of the BACnet object in the System Manager (see also Figs. 2 and 3). Writing is enabled by setting the input "bEnablePV" to TRUE. Process data are always written cyclically once enabled.

Fig. 2: Example of a BACnet object with process data for writing the commandable property Present_Value. | Fig. 3: Example for a process data configuration of an BACnet object in the System Manager. Priority 12 and 16 are created as mappable process data (see result in Fig. 2).

VAR_OUTPUT

Note: Variables shown in grey italics are only available in the extended version of the block. The extended versions of the blocks end with "_EX". They offer substantially more process data, although in projects with a large number of objects this may have performance implications.

Name             : Type
bReady                  : BOOL;
bPresentValue           : BOOL;
bOverridden             : BOOL;
bOutOfService           : BOOL;
bFault                  : BOOL;
bInAlarm                : BOOL;
bNoOutput               : BOOL;
bOpenLoop               : BOOL;
bShortedLoop            : BOOL;
bOtherFault             : BOOL;
eEventState             : E_BACnetEventState;
bAckedTrans_ToOffNormal : BOOL;
bAckedTrans_ToFault     : BOOL;
bAckedTrans_ToNormal    : BOOL;
nActivePrio             : UINT;
bError                  : BOOL;
nErrorId                : UINT;

bReady: Notification of general readiness. If this output is set, the other status outputs are valid (PresentValue, Overridden ...). If the output is FALSE, the corresponding function block "FB_BACnet_Device" does not report "Operational", or the block instance was not linked correctly in the System Manager.

bPresentValue: Current value of the BACnet object (see also BACnet specification DIN EN ISO 16484-5 for BACnet object BinaryOutput and property Present_Value).

bOverridden, bOutOfService, bFault, bInAlarm: See BACnet specification DIN EN ISO 16484-5 for BACnet object BinaryOutput and property Status_Flags.

bOtherFault: See BACnet specification DIN EN ISO 16484-5 for BACnet object BinaryOutput and property Reliability.

eEventState: See BACnet specification DIN EN ISO 16484-5 for BACnet object BinaryOutput and property Event_State.

bAckedTrans_ToOffNormal, bAckedTrans_ToFault, bAckedTrans_ToNormal: Flags of property Acked_Transitions (see also BACnet specification DIN EN ISO 16484-5 for BACnet object BinaryOutput and property Acked_Transitions).

nActivePrio: Indicates the currently active priority of the priority array, which acts on the Present_Value (see also BACnet specification DIN EN ISO 16484-5 for BACnet object BinaryOutput and property Present_Value).

bError: An error is pending.

nErrorId: Error number
0 = no error
2 = incorrect process data mapping detected (check mapping in the System Manager; if necessary compile complete PLC project and reload)
3 = the corresponding BACnet server is not ready (bOperational = FALSE at instance of the FB_BACnet_Device)
The error numbers can be queried as block constants via the FB instance (FB_BACnet_???.nERR_xxx).

VAR_IN_OUT

Name             : Type
Device           : FB_BACnet_Device;

Device: Specification of the instance of the local corresponding BACnet server block. For each BACnet adapter one BACnet server is possible. See FB_BACnet_Adapter and FB_BACnet_Device for further information.


FB_BACnet_BinaryOutput_ADS

The following function block is used for linking a BACnet object of the local BACnet server. The function block for the corresponding BACnet object is linked with the aid of process data.

The process data can be created manually in the BACnet object, linked manually, or they can be generated automatically via PLC automapping. The comments required for PLC automapping ( (* ~ (BACnet... | ??? | ??? ) *) ) are already included in the declaration of the function block.

Use

The function block "FB_BACnet_BinaryOutput_ADS" can be used for read and write access to a BACnet object of type BinaryOutput (BO). To this end the BACnet object was created under a local BACnet server.

Fig. 1: Example of a BACnet object under a local BACnet server.

VAR_INPUT

Name             : Type
bEnablePV        : BOOL;
bPV              : BOOL; (* present value bool type *)
bManual                 : BOOL; (* FALSE --> TRUE: write present_value immediately,
FALSE: only write present_value on-change,
TRUE: write present_value on-change and when device turns operational *)
ePriority               : E_BACNETPRIORITY := BACNETPRIORITY_12;

bEnablePV: Enables the value of input "bPV". When the input is set to TRUE, an entry is made in the Priority_Array of the corresponding BACnet object with the value of input "bPV". This corresponds to a write access to the commandable property Present_Value with the priority given by the input "ePriority" (default: 12 when the input "ePriroty" is not connected).

bPV: Value to be written to the Priority_Array of the commandable property Present_Value. The priority is given by the input "ePriority". Writing is enabled by setting the input "bEnablePV" to TRUE. The value is written on change (WOC) or by the logic behind the input "bManual" (refer to the input description).

Hint: Since writing the property Present_Value happens acyclically and only on value change, it is potentially possible that the property Present_Value is overwritten with the same priority by other BACnet devices. In case of equal priorities, the last write access "wins".

bManual: The following logic will be distinguished for the input:
- FALSE: Write on change (WOC) for the input "bPV"
- edge transition FALSE --> TRUE: Triggers the writing of the input "bPV" immediately
- TRUE: Writing when value changed or when the associated BACnet server changes in the "operational" state (see FB_BACnet_Device).

ePriority: Priority for write accesses to the property Present_Value (Default: 12, see E_BACNETPRIORITY).

VAR_OUTPUT

Name             : Type
bReady           : BOOL;
bPvDone          : BOOL; (* present_value written over ADS *)
bPresentValue    : BOOL;
bOverridden      : BOOL;
bOutOfService    : BOOL;
bFault           : BOOL;
bInAlarm         : BOOL;
bError           : BOOL;
nErrorId         : UINT;
nAdsErrorId      : UDINT;

bReady: Notification of general readiness. If this output is set, the other status outputs are valid (PresentValue, Overridden ...). If the output is FALSE, the corresponding function block "FB_BACnet_Device" does not report "Operational", or the block instance was not linked correctly in the System Manager.

bPvDone: Positive edge when write access to property Present_Value was successfull.

bPresentValue: Current value of the BACnet object (see also BACnet specification DIN EN ISO 16484-5 for BACnet object BinaryOutput and property Present_Value).

bOverridden, bOutOfService, bFault, bInAlarm: See BACnet specification DIN EN ISO 16484-5 for BACnet object BinaryOutput and property Status_Flags.

bError: An error is pending.

nErrorId: Error number
0 = no error
2 = incorrect process data mapping detected (check mapping in the System Manager; if necessary compile complete PLC project and reload)
3 = the corresponding BACnet server is not ready (bOperational = FALSE at instance of the FB_BACnet_Device)
4 = the object type of the BACnet object dosn't match the function block type (the object type will determined over the process data. --> check the process data mapping in the System Manager!)
The error numbers can be queried as block constants via the FB instance (FB_BACnet_???.nERR_xxx).

nAdsErrorId: ADS error code.

VAR_IN_OUT

Name             : Type
Device           : FB_BACnet_Device;

Device: Specification of the instance of the local corresponding BACnet server block. For each BACnet adapter one BACnet server is possible. See FB_BACnet_Adapter and FB_BACnet_Device for further information.


FB_BACnet_BinaryOutput_RAW

The following function block is used for linking a BACnet object of the local BACnet server. The function block for the corresponding BACnet object is linked with the aid of process data.

The process data can be created manually in the BACnet object, linked manually, or they can be generated automatically via PLC automapping. The comments required for PLC automapping ( (* ~ (BACnet... | ??? | ??? ) *) ) are already included in the declaration of the function block.

Contrary to the standard variant of the function block, the raw value is provided by a function block output and not by the terminal hardware. This allows e.g. Binary output information that is used in the PLC code displayed as an analog output object to BACnet (signal mapping for sub bus systems or virtual data points, etc.).

Use

The function block "FB_BACnet_BinaryOutput_RAW" can be used for read and write access to a BACnet object of type BinaryOutput (BO). To this end the BACnet object was created under a local BACnet server.

Fig. 1: Example of a BACnet object under a local BACnet server.

VAR_INPUT

Name             : Type
bEnablePV        : BOOL;
bPV              : BOOL;

bEnablePV: Enables the value of input "bPV". When the input is set to TRUE, an entry is made in the Priority_Array of the corresponding BACnet object with the value of input "bPV". This corresponds to a write access to the commandable property Present_Value with the set priority (default: 12 when PLC automapping is used or 16 for manual linking in the System Manager).
If bEnablePV is set to FALSE, the corresponding entry from the Priority_Array is removed again (write ZERO).

bPV: Value to be written to the Priority_Array of the commandable property Present_Value. The priority is based on the process data configuration and mapping of the BACnet object in the System Manager (see also Figs. 2 and 3). Writing is enabled by setting the input "bEnablePV" to TRUE. Process data are always written cyclically once enabled.

Fig. 2: Example of a BACnet object with process data for writing the commandable property Present_Value. | Fig. 3: Example for a process data configuration of an BACnet object in the System Manager. Priority 12 and 16 are created as mappable process data (see result in Fig. 2).

VAR_OUTPUT

Name             : Type
bReady                  : BOOL;
bPresentValue           : BOOL;
bOverridden             : BOOL;
bOutOfService           : BOOL;
bFault                  : BOOL;
bInAlarm                : BOOL;
bAckedTrans_ToOffNormal : BOOL;
bAckedTrans_ToFault     : BOOL;
bAckedTrans_ToNormal    : BOOL;
bError                  : BOOL;
nErrorId                : UINT;
bRawOut                 : BOOL; (* ~(BACnet_RawIoBinaryBoolValue : : ) *)

bReady: Notification of general readiness. If this output is set, the other status outputs are valid (PresentValue, Overridden ...). If the output is FALSE, the corresponding function block "FB_BACnet_Device" does not report "Operational", or the block instance was not linked correctly in the System Manager.

bPresentValue: Current value of the BACnet object (see also BACnet specification DIN EN ISO 16484-5 for BACnet object BinaryOutput and property Present_Value).

bOverridden, bOutOfService, bFault, bInAlarm: See BACnet specification DIN EN ISO 16484-5 for BACnet object BinaryOutput and property Status_Flags.

bAckedTrans_ToOffNormal, bAckedTrans_ToFault, bAckedTrans_ToNormal: Flags of property Acked_Transitions (see also BACnet specification DIN EN ISO 16484-5 for BACnet object BinaryOutput and property Acked_Transitions).

bError: An error is pending.

nErrorId: Error number
0 = no error
2 = incorrect process data mapping detected (check mapping in the System Manager; if necessary compile complete PLC project and reload)
3 = the corresponding BACnet server is not ready (bOperational = FALSE at instance of the FB_BACnet_Device)
The error numbers can be queried as block constants via the FB instance (FB_BACnet_???.nERR_xxx).

bRawOut: Raw value output of the object. The output is linked to the process data "RawIoAnalogSignedValue" of the BACnet object. The value of "bRawOut" is the value of property Present_Value (assuming the object state is not out_of_service).

VAR_IN_OUT

Name             : Type
Device           : FB_BACnet_Device;

Device: Specification of the instance of the local corresponding BACnet server block. For each BACnet adapter one BACnet server is possible. See FB_BACnet_Adapter and FB_BACnet_Device for further information.

Example

The following example shows the mapping of the Property Present_Value of an binary output object to an EIB bit value:

Fig. 4: Example for the mapping of the property Present_Value to EIB in PLC code. This example requires the library "TcKL6301.lib". Refer to the manual of terminal KL6301 for more information about EIB.


FB_BACnet_BinaryValue

The following function block is used for linking a BACnet object of the local BACnet server. The function block for the corresponding BACnet object is linked with the aid of process data.

The process data can be created manually in the BACnet object, linked manually, or they can be generated automatically via PLC automapping. The comments required for PLC automapping ( (* ~ (BACnet... | ??? | ??? ) *) ) are already included in the declaration of the function block.

Use

The function block "FB_BACnet_BinaryValue" can be used for read and write access to a BACnet object of type BinaryValue (BV). To this end the BACnet object was created under a local BACnet server.

Fig. 1: Example of a BACnet object under a local BACnet server.

VAR_INPUT

Name             : Type
bEnablePV        : BOOL;
bPV              : BOOL;

bEnablePV: Enables the value of input "bPV". When the input is set to TRUE, an entry is made in the Priority_Array of the corresponding BACnet object with the value of input "bPV". This corresponds to a write access to the commandable property Present_Value with the set priority (default: 12 when PLC automapping is used or 16 for manual linking in the System Manager).
If bEnablePV is set to FALSE, the corresponding entry from the Priority_Array is removed again (write ZERO).

bPV: Value to be written to the Priority_Array of the commandable property Present_Value. The priority is based on the process data configuration and mapping of the BACnet object in the System Manager (see also Figs. 2 and 3). Writing is enabled by setting the input "bEnablePV" to TRUE. Process data are always written cyclically once enabled.

Fig. 2: Example of a BACnet object with process data for writing the commandable property Present_Value. | Fig. 3: Example for a process data configuration of an BACnet object in the System Manager. Priority 12 and 16 are created as mappable process data (see result in Fig. 2).

VAR_OUTPUT

Note: Variables shown in grey italics are only available in the extended version of the block. The extended versions of the blocks end with "_EX". They offer substantially more process data, although in projects with a large number of objects this may have performance implications.

Name             : Type
bReady                  : BOOL;
bPresentValue           : BOOL;
bOverridden             : BOOL;
bOutOfService           : BOOL;
bFault                  : BOOL;
bInAlarm                : BOOL;
bOtherFault             : BOOL;
eEventState             : E_BACnetEventState;
bAckedTrans_ToOffNormal : BOOL;
bAckedTrans_ToFault     : BOOL;
bAckedTrans_ToNormal    : BOOL;
nActivePrio             : UINT;
bError                  : BOOL;
nErrorId                : UINT;

bReady: Notification of general readiness. If this output is set, the other status outputs are valid (PresentValue, Overridden ...). If the output is FALSE, the corresponding function block "FB_BACnet_Device" does not report "Operational", or the block instance was not linked correctly in the System Manager.

bPresentValue: Current value of the BACnet object (see also BACnet specification DIN EN ISO 16484-5 for BACnet object BinaryValue and property Present_Value).

bOverridden, bOutOfService, bFault, bInAlarm: See BACnet specification DIN EN ISO 16484-5 for BACnet object BinaryValue and property Status_Flags.

bOtherFault: See BACnet specification DIN EN ISO 16484-5 for BACnet object BinaryValue and property Reliability.

eEventState: See BACnet specification DIN EN ISO 16484-5 for BACnet object BinaryValue and property Event_State.

bAckedTrans_ToOffNormal, bAckedTrans_ToFault, bAckedTrans_ToNormal: Flags of property Acked_Transitions (see also BACnet specification DIN EN ISO 16484-5 for BACnet object BinaryValue and property Acked_Transitions).

nActivePrio: Indicates the currently active priority of the priority array, which acts on the Present_Value (see also BACnet specification DIN EN ISO 16484-5 for BACnet object BinaryValue and property Present_Value).

bError: An error is pending.

nErrorId: Error number
0 = no error
2 = incorrect process data mapping detected (check mapping in the System Manager; if necessary compile complete PLC project and reload)
3 = the corresponding BACnet server is not ready (bOperational = FALSE at instance of the FB_BACnet_Device)
The error numbers can be queried as block constants via the FB instance (FB_BACnet_???.nERR_xxx).

VAR_IN_OUT

Name             : Type
Device           : FB_BACnet_Device;

Device: Specification of the instance of the local corresponding BACnet server block. For each BACnet adapter one BACnet server is possible. See FB_BACnet_Adapter and FB_BACnet_Device for further information.


FB_BACnet_Calendar

The following function block is used for linking a BACnet object of the local BACnet server. The function block for the corresponding BACnet object is linked with the aid of process data.

The process data can be created manually in the BACnet object, linked manually, or they can be generated automatically via PLC automapping. The comments required for PLC automapping ( (* ~ (BACnet... | ??? | ??? ) *) ) are already included in the declaration of the function block.

Use

The function block "FB_BACnet_Calendar" can be used for read access to a BACnet object of type Calendar (CAL). To this end the BACnet object was created under a local BACnet server.

Fig. 1: Example of a BACnet object under a local BACnet server.

VAR_OUTPUT

Name             : Type
bReady           : BOOL;
bPresentValue    : BOOL;
bError           : BOOL;
nErrorId         : UINT;

bReady: Notification of general readiness. If this output is set, the other status outputs are valid (PresentValue). If the output is FALSE, the associated function block "FB_BACnet_Device" reports "not operational".

bPresentValue: Current value of the BACnet object (see also BACnet specification DIN EN ISO 16484-5 for BACnet object Calendar and property Present_Value).

bError: An error is pending.

nErrorId: Error number
0 = no error
3 = the corresponding BACnet server is not ready (bOperational = FALSE at instance of the FB_BACnet_Device)
The error numbers can be queried as block constants via the FB instance (FB_BACnet_???.nERR_xxx).

VAR_IN_OUT

Name             : Type
Device           : FB_BACnet_Device;

Device: Specification of the instance of the local corresponding BACnet server block. For each BACnet adapter one BACnet server is possible. See FB_BACnet_Adapter and FB_BACnet_Device for further information.


FB_BACnet_Command

The following function block is used for linking a BACnet object of the local BACnet server. The function block for the corresponding BACnet object is linked with the aid of process data.

The process data can be created manually in the BACnet object, linked manually, or they can be generated automatically via PLC automapping. The comments required for PLC automapping ( (* ~ (BACnet... | ??? | ??? ) *) ) are already included in the declaration of the function block.

Use

The function block "FB_BACnet_Command" can be used for read and write access to a BACnet object of type Command (CMD). To this end the BACnet object was created under a local BACnet server.

Fig. 1: Example of a BACnet object under a local BACnet server.

VAR_INPUT

Name             : Type
bEnablePV        : BOOL;
nPV              : UDINT;
bRetrigger       : BOOL;

bEnablePV: Enables the value of input nPV. When the input is set to TRUE, writing takes place into the property Present_Value of the corresponding BACnet object with the value of input nPV.
If bEnablePV is set to FALSE, the process data of the mapped property Present_Value are written to 16#FFFFFFFF and thus deactivated.

nPV: Value of the property Present_Value to be written. If the value is outside the value range (see BACnet specification DIN EN ISO 16484-5 for BACnet object Command and property Present_Value), the corresponding process data is disabled, i.e. writing to the property is disabled and other BACnet services have write access to the property Present_Value.
Writing of a valid value triggers execution of the corresponding command list of the BACnet object. The value of the property Present_Value is written whenever the process data changes (i.e. change in the value of nPV with bEnablePV set or signal change from FALSE to TRUE at input bRetrigger with bEnablePV set).

bRetrigger: A rising edge at this input triggers a repeat of the write process and therefore execution of the corresponding commands of the BACnet object Command. The signal change from FALSE to TRUE corresponds to a change of the process data of the property Present_Value from x to 0 to x.

VAR_OUTPUT

Name             : Type
bReady           : BOOL;
nPresentValue    : UDINT;
bAllWritesOk     : BOOL;
bInProcess       : BOOL;
bError           : BOOL;
nErrorId         : UINT;

bReady: Notification of general readiness. If this output is set, the other status outputs are valid (PresentValue, AllWritesOk, InProcess). If the output is FALSE, the associated function block "FB_BACnet_Device" reports "not operational".

nPresentValue: Current value of the BACnet object (see also BACnet specification DIN EN ISO 16484-5 for BACnet object Command and property Present_Value).

bAllWritesOk: The last requested command list was successfully processed (see also BACnet specification DIN EN ISO 16484-5 for BACnet object Command and property All_Writes_Successful).

bInProcess: The selected command list is processed (see also BACnet specification DIN EN ISO 16484-5 for BACnet object Command and property In_Process).

bError: An error is pending.

nErrorId: Error number
0 = no error
3 = the corresponding BACnet server is not ready (bOperational = FALSE at instance of the FB_BACnet_Device)
The error numbers can be queried as block constants via the FB instance (FB_BACnet_???.nERR_xxx).

VAR_IN_OUT

Name             : Type
Device           : FB_BACnet_Device;

Device: Specification of the instance of the local corresponding BACnet server block. For each BACnet adapter one BACnet server is possible. See FB_BACnet_Adapter and FB_BACnet_Device for further information.


FB_BACnet_File

The following function block is used for linking a BACnet object of the local BACnet server. The function block for the corresponding BACnet object is linked with the aid of process data.

The process data can be created manually in the BACnet object, linked manually, or they can be generated automatically via PLC automapping. The comments required for PLC automapping ( (* ~ (BACnet... | ??? | ??? ) *) ) are already included in the declaration of the function block.

Use

The function block "FB_BACnet_File" can be used for read access to a BACnet object of type File (FILE). To this end the BACnet object was created under a local BACnet server.

Fig. 1: Example of a BACnet object under a local BACnet server.

VAR_OUTPUT

Name             : Type
bReady           : BOOL;
bPresentValue    : BOOL;
bError           : BOOL;
nErrorId         : UINT;

bReady: Notification of general readiness. If this output is set, the other status outputs are valid (PresentValue). If the output is FALSE, the associated function block "FB_BACnet_Device" reports "not operational".

bPresentValue: Current value of the BACnet object (see also BACnet specification DIN EN ISO 16484-5 for BACnet object File and property Present_Value).

bError: An error is pending.

nErrorId: Error number
0 = no error
3 = the corresponding BACnet server is not ready (bOperational = FALSE at instance of the FB_BACnet_Device)
The error numbers can be queried as block constants via the FB instance (FB_BACnet_???.nERR_xxx).

VAR_IN_OUT

Name             : Type
Device           : FB_BACnet_Device;

Device: Specification of the instance of the local corresponding BACnet server block. For each BACnet adapter one BACnet server is possible. See FB_BACnet_Adapter and FB_BACnet_Device for further information.


FB_BACnet_Group

The following function block is used for linking a BACnet object of the local BACnet server. The function block for the corresponding BACnet object is linked with the aid of process data.

The process data can be created manually in the BACnet object, linked manually, or they can be generated automatically via PLC automapping. The comments required for PLC automapping ( (* ~ (BACnet... | ??? | ??? ) *) ) are already included in the declaration of the function block.

Use

The function block "FB_BACnet_Group" serves as placeholder for future functions.

VAR_OUTPUT

      Name             : Type

bReady           : BOOL;
bError           : BOOL;
nErrorId         : UINT;

bReady: Notification of general readiness. If the output is FALSE, the associated function block FB_BACnet_Device reports "not operational".

bError: An error is pending.

nErrorId: Error number
0 = no error
3 = the corresponding BACnet server is not ready (bOperational = FALSE at instance of the FB_BACnet_Device)
The error numbers can be queried as block constants via the FB instance (FB_BACnet_???.nERR_xxx).

VAR_IN_OUT

      Name             : Type

Device           : FB_BACnet_Device;

Device: Specification of the instance of the local corresponding BACnet server block. For each BACnet adapter one BACnet server is possible. See FB_BACnet_Adapter and FB_BACnet_Device for further information.


FB_BACnet_Loop

The following function block is used for linking a BACnet object of the local BACnet server. The function block for the corresponding BACnet object is linked with the aid of process data.

The process data can be created manually in the BACnet object, linked manually, or they can be generated automatically via PLC automapping. The comments required for PLC automapping ( (* ~ (BACnet... | ??? | ??? ) *) ) are already included in the declaration of the function block.

Use

The function block "FB_BACnet_Loop" provides the object functionality for the BACnet stack. To this end the BACnet object was created under a local BACnet server. The BACnet object on the BACnet stack side (System Manager) serves as interface to the BACnet world. The control and therefore functionality of the BACnet object is provided by the PLC instance of the block "FB_BACnet_Loop".

This approach has the advantage that existing, customer-specific controllers from a PLC project can easily be linked with the BACnet world. Only the process data of the BACnet-Loop object have to be provided and processed.

The function block "FB_BACnet_Loop" of the TcBACnet-Lib contains a standard PID controller (FB_BACnet_PidControl) and therefore covers a wide range of control tasks.

Fig. 1: Example of a BACnet-LOOP object under a local BACnet server.

VAR_INPUT

Name             : Type
bEnable          : BOOL;

bEnable: Enables the control. FALSE at the input sets the state of BACnet object to Out_Of_Service (see BACnet specification DIN EN ISO 16484-5 for BACnet object Loop and property Out_Of_Service).

VAR_OUTPUT

Name             : Type
bReady           : BOOL;
fSetPoint        : REAL;
fControlledValue : REAL;
fPresentValue    : REAL;
fPropBand        : REAL;
bOverridden      : BOOL;
bOutOfService    : BOOL;
bFault           : BOOL;
bInAlarm         : BOOL;
bOpenLoop        : BOOL;
bOtherFault      : BOOL;
bError           : BOOL;
nErrorId         : UINT;

bReady: Notification of general readiness. If this output is set, the other status outputs are valid (PresentValue, Overridden ...). If the output is FALSE, the corresponding function block "FB_BACnet_Device" does not report "Operational", or the block instance was not linked correctly in the System Manager.

fSetPoint: Feedback of the controller specification (W, set value).

fControlledValue: Feedback of the current process parameter (X, actual value).

fPresentValue: Feedback of the current control output (Y, control value). Attention: Present_Value and Controller_Variable_Value can easily lead to confusion (see also BACnet specification DIN EN ISO 16484-5 for BACnet object Loop and properties Present_Value, Controlled_Variable_Value and Controlled_Variable_Reference).

fPropBand: Feedback of the current control output in percent (-100%...+100%) in relation to the minimum and maximum control output (properties Minimum_Output and Maximum_Output).

bOverridden, bOutOfService, bFault, bInAlarm: See BACnet specification DIN EN ISO 16484-5 for BACnet object Loop and property Status_Flags.

bOpenLoop, bOtherFault: See BACnet specification DIN EN ISO 16484-5 for BACnet object Loop and property Reliability.

bError: An error is pending.

nErrorId: Error number
0 = no error
2 = incorrect process data mapping detected (check mapping in the System Manager; if necessary compile complete PLC project and reload)
3 = the corresponding BACnet server is not ready (bOperational = FALSE at instance of the FB_BACnet_Device)
The error numbers can be queried as block constants via the FB instance (FB_BACnet_???.nERR_xxx).

VAR_IN_OUT

Name             : Type
Device           : FB_BACnet_Device;

Device: Specification of the instance of the local corresponding BACnet server block. For each BACnet adapter one BACnet server is possible. See FB_BACnet_Adapter and FB_BACnet_Device for further information.

Controller configuration

The controller is configured using the following BACnet properties: Action, Proportional_Constant (P-factor), Integral_Constant (I-factor), Derivative_Constant (D-factor), Bias (output offset), Maximum_Output (maximum control output) and Minimum_Output (minimum control output). See BACnet specification DIN EN ISO 16484-5 for BACnet object Loop.


FB_BACnet_MultiStateInput

The following function block is used for linking a BACnet object of the local BACnet server. The function block for the corresponding BACnet object is linked with the aid of process data.

The process data can be created manually in the BACnet object, linked manually, or they can be generated automatically via PLC automapping. The comments required for PLC automapping ( (* ~ (BACnet... | ??? | ??? ) *) ) are already included in the declaration of the function block.

Use

The function block "FB_BACnet_MultiStateInput" can be used for read access to a BACnet object of type MultiStateInput (MI). To this end the BACnet object was created under a local BACnet server.

Fig. 1: Example of a BACnet object under a local BACnet server.

VAR_OUTPUT

Note: Variables shown in grey italics are only available in the extended version of the block. The extended versions of the blocks end with "_EX". They offer substantially more process data, although in projects with a large number of objects this may have performance implications.

Name             : Type
bReady                  : BOOL;
nPresentValue           : UDINT;
bOverridden             : BOOL;
bOutOfService           : BOOL;
bFault                  : BOOL;
bInAlarm                : BOOL;
bOverRange              : BOOL;
bUnderRange             : BOOL;
bNoSensor               : BOOL;
bOpenLoop               : BOOL;
bShortedLoop            : BOOL;
bMultiStateFault        : BOOL;
bOtherFault             : BOOL;
eEventState             : E_BACnetEventState;
bAckedTrans_ToOffNormal : BOOL;
bAckedTrans_ToFault     : BOOL;
bAckedTrans_ToNormal    : BOOL;nNbrOfStates            : UDINT;
bError                  : BOOL;
nErrorId                : UINT;

bReady: Notification of general readiness. If this output is set, the other status outputs are valid (PresentValue, Overridden ...). If the output is FALSE, the corresponding function block "FB_BACnet_Device" does not report "Operational", or the block instance was not linked correctly in the System Manager.

nPresentValue: Current value of the BACnet object (see also BACnet specification DIN EN ISO 16484-5 for BACnet object MultiStateInput and property Present_value).

bOverridden, bOutOfService, bFault, bInAlarm: See BACnet specification DIN EN ISO 16484-5 for BACnet object MultiStateInput and property Status_Flags.

bOverRange, bUnderRange, bNoSensor, bOpenLoop, bShortedLoop, bMultiStateFault, bOtherFault: See BACnet specification DIN EN ISO 16484-5 for BACnet object MultiStateInput and property Reliability.

eEventState: See BACnet specification DIN EN ISO 16484-5 for BACnet object MultiStateInput and property Event_State.

bAckedTrans_ToOffNormal, bAckedTrans_ToFault, bAckedTrans_ToNormal: Flags of property Acked_Transitions (see also BACnet specification DIN EN ISO 16484-5 for BACnet object MultiStateInput and property Acked_Transitions).

nNbrOfStates: Reports the available number of values, which the Present_Value of the MultiStateInput object can assume (1...nNbrOfStates). If "nNbrOfStates" is 0, then there is no valid "state" which the object can assume (Present_Value is 0).

bError: An error is pending.

nErrorId: Error number
0 = no error
2 = incorrect process data mapping detected (check mapping in the System Manager; if necessary compile complete PLC project and reload)
3 = the corresponding BACnet server is not ready (bOperational = FALSE at instance of the FB_BACnet_Device)
The error numbers can be queried as block constants via the FB instance (FB_BACnet_???.nERR_xxx).

VAR_IN_OUT

Name             : Type
Device           : FB_BACnet_Device;

Device: Specification of the instance of the local corresponding BACnet server block. For each BACnet adapter one BACnet server is possible. See FB_BACnet_Adapter and FB_BACnet_Device for further information.


FB_BACnet_MultiStateOutput

The following function block is used for linking a BACnet object of the local BACnet server. The function block for the corresponding BACnet object is linked with the aid of process data.

The process data can be created manually in the BACnet object, linked manually, or they can be generated automatically via PLC automapping. The comments required for PLC automapping ( (* ~ (BACnet... | ??? | ??? ) *) ) are already included in the declaration of the function block.

Use

The function block "FB_BACnet_MultiStateOutput" can be used for read and write access to a BACnet object of type MultiStateOutput (MO). To this end the BACnet object was created under a local BACnet server.

Fig. 1: Example of a BACnet object under a local BACnet server.

VAR_INPUT

Name             : Type
bEnablePV        : BOOL;
nPV              : UDINT;

bEnablePV: Enables the value of input nPV. When the input is set to TRUE, an entry is made in the Priority_Array of the corresponding BACnet object with the value of the input nPV. This corresponds to a write access to the commandable property Present_Value with the set priority (default: 12 when PLC automapping is used or 16 for manual linking in the System Manager).
If bEnablePV is set to FALSE, the corresponding entry from the Priority_Array is removed again (write ZERO).

nPV: Value to be written to the Priority_Array of the commandable property Present_Value. The priority is based on the process data configuration and mapping of the BACnet object in the System Manager (see also Figs. 2 and -3). Writing is enabled by setting the input bEnablePV to TRUE. Process data are always written cyclically once enabled.

Fig. 2: Example of a BACnet object with process data for writing the commandable property Present_Value. | Fig. 3: Example for a process data configuration of an BACnet object in the System Manager. Priority 12 and 16 are created as mappable process data (see result in Fig. 2).

VAR_OUTPUT

Note: Variables shown in grey italics are only available in the extended version of the block. The extended versions of the blocks end with "_EX". They offer substantially more process data, although in projects with a large number of objects this may have performance implications.

Name             : Type
bReady                  : BOOL;
nPresentValue           : UDINT;
bOverridden             : BOOL;
bOutOfService           : BOOL;
bFault                  : BOOL;
bInAlarm                : BOOL;
bNoOutput               : BOOL;
bOpenLoop               : BOOL;
bShortedLoop            : BOOL;
bOtherFault             : BOOL;
eEventState             : E_BACnetEventState;
bAckedTrans_ToOffNormal : BOOL;
bAckedTrans_ToFault     : BOOL;
bAckedTrans_ToNormal    : BOOL;
nActivePrio             : UINT;
nNbrOfStates            : UDINT;
bError                  : BOOL;
nErrorId                : UINT;

bReady: Notification of general readiness. If this output is set, the other status outputs are valid (PresentValue, Overridden ...). If the output is FALSE, the corresponding function block "FB_BACnet_Device" does not report "Operational", or the block instance was not linked correctly in the System Manager.

nPresentValue: Current value of the BACnet object (see also BACnet specification DIN EN ISO 16484-5 for BACnet object MultiStateOutput and property Present_value).

bOverridden, bOutOfService, bFault, bInAlarm: See BACnet specification DIN EN ISO 16484-5 for BACnet object MultiStateOutput and property Status_Flags.

bNoOutput, bOpenLoop, bShortedLoop, bOtherFault: See BACnet specification DIN EN ISO 16484-5 for BACnet object MultiStateOutput and property Reliability.

eEventState: See BACnet specification DIN EN ISO 16484-5 for BACnet object MultiStateOutput and property Event_State.

bAckedTrans_ToOffNormal, bAckedTrans_ToFault, bAckedTrans_ToNormal: Flags of property Acked_Transitions (see also BACnet specification DIN EN ISO 16484-5 for BACnet object MultiStateOutput and property Acked_Transitions).

nActivePrio: Indicates the currently active priority of the priority array, which acts on the Present_Value (see also BACnet specification DIN EN ISO 16484-5 for BACnet object MultiStateOutput and property Present_Value).

nNbrOfStates: Reports the available number of values, which the Present_Value of the MultiStateOutput object can assume (1...nNbrOfStates). If nNbrOfStates is 0, then there is no valid "state" which the object can assume (Present_Value is 0).

bError: An error is pending.

nErrorId: Error number
0 = no error
2 = incorrect process data mapping detected (check mapping in the System Manager; if necessary compile complete PLC project and reload)
3 = the corresponding BACnet server is not ready (bOperational = FALSE at instance of the FB_BACnet_Device)
The error numbers can be queried as block constants via the FB instance (FB_BACnet_???.nERR_xxx).

VAR_IN_OUT

Name             : Type
Device           : FB_BACnet_Device;

Device: Specification of the instance of the local corresponding BACnet server block. For each BACnet adapter one BACnet server is possible. See FB_BACnet_Adapter and FB_BACnet_Device for further information.


FB_BACnet_MultiStateOutput_ADS

The following function block is used for linking a BACnet object of the local BACnet server. The function block for the corresponding BACnet object is linked with the aid of process data.

The process data can be created manually in the BACnet object, linked manually, or they can be generated automatically via PLC automapping. The comments required for PLC automapping ( (* ~ (BACnet... | ??? | ??? ) *) ) are already included in the declaration of the function block.

Use

The function block "FB_BACnet_MultiStateOutput_ADS" can be used for read and asynchronous write access to a BACnet object of type MultiStateOutput (MO). To this end the BACnet object was created under a local BACnet server.

Fig. 1: Example of a BACnet object under a local BACnet server.

VAR_INPUT

Name             : Type
bEnablePV        : BOOL;
nPV              : UDINT; (* number for priority x, when input bEnablePV is TRUE *)
bManual                 : BOOL; (* FALSE --> TRUE: write present_value immediately,
FALSE: only write present_value on-change,
TRUE: write present_value on-change and when device turns operational *)
ePriority               : E_BACNETPRIORITY := BACNETPRIORITY_12;

bEnablePV: Enables the value of input "nPV". When the input is set to TRUE, an entry is made in the Priority_Array of the corresponding BACnet object with the value of input "nPV". This corresponds to a write access to the commandable property Present_Value with the priority given by the input "ePriority" (default: 12 when the input "ePriroty" is not connected).

nPV: Value to be written to the Priority_Array of the commandable property Present_Value. The priority is given by the input "ePriority". Writing is enabled by setting the input "bEnablePV" to TRUE. The value is written on change (WOC) or by the logic behind the input "bManual" (refer to the input description).

Hint: Since writing the property Present_Value happens acyclically and only on value change, it is potentially possible that the property Present_Value is overwritten with the same priority by other BACnet devices. In case of equal priorities, the last write access "wins".

bManual: The following logic will be distinguished for the input:
- FALSE: Write on change (WOC) for the input "nPV"
- edge transition FALSE --> TRUE: Triggers the writing of the input "nPV" immediately
- TRUE: Writing when value changed or when the associated BACnet server changes in the "operational" state (see FB_BACnet_Device).

ePriority: Priority for write accesses to the property Present_Value (Default: 12, see E_BACNETPRIORITY).

VAR_OUTPUT

Name             : Type
bReady           : BOOL;
bPvDone          : BOOL; (* present_value written over ADS *)
nPresentValue    : UDINT;
bOverridden      : BOOL;
bOutOfService    : BOOL;
bFault           : BOOL;
bInAlarm         : BOOL;
nNbrOfStates     : UDINT;
bError           : BOOL;
nErrorId         : UINT;
nAdsErrorId      : UDINT;

bReady: Notification of general readiness. If this output is set, the other status outputs are valid (PresentValue, Overridden ...). If the output is FALSE, the corresponding function block "FB_BACnet_Device" does not report "Operational", or the block instance was not linked correctly in the System Manager.

bPvDone: Positive edge when write access to property Present_Value was successfull.

nPresentValue: Current value of the BACnet object (see also BACnet specification DIN EN ISO 16484-5 for BACnet object MultiStateOutput and property Present_value).

bOverridden, bOutOfService, bFault, bInAlarm: See BACnet specification DIN EN ISO 16484-5 for BACnet object MultiStateOutput and property Status_Flags.

nNbrOfStates: Reports the available number of values, which the Present_Value of the MultiStateOutput object can assume (1...nNbrOfStates). If nNbrOfStates is 0, then there is no valid "state" which the object can assume (Present_Value is 0).

bError: An error is pending.

nErrorId: Error number
0 = no error
2 = incorrect process data mapping detected (check mapping in the System Manager; if necessary compile complete PLC project and reload)
3 = the corresponding BACnet server is not ready (bOperational = FALSE at instance of the FB_BACnet_Device)
4 = the object type of the BACnet object dosn't match the function block type (the object type will determined over the process data. --> check the process data mapping in the System Manager!)
The error numbers can be queried as block constants via the FB instance (FB_BACnet_???.nERR_xxx).

nAdsErrorId: ADS error code.

VAR_IN_OUT

Name             : Type
Device           : FB_BACnet_Device;

Device: Specification of the instance of the local corresponding BACnet server block. For each BACnet adapter one BACnet server is possible. See FB_BACnet_Adapter and FB_BACnet_Device for further information.


FB_BACnet_MultiStateValue

The following function block is used for linking a BACnet object of the local BACnet server. The function block for the corresponding BACnet object is linked with the aid of process data.

The process data can be created manually in the BACnet object, linked manually, or they can be generated automatically via PLC automapping. The comments required for PLC automapping ( (* ~ (BACnet... | ??? | ??? ) *) ) are already included in the declaration of the function block.

Use

The function block "FB_BACnet_MultiStateValue" can be used for read and write access to a BACnet object of type MultiStateValue (MV). To this end the BACnet object was created under a local BACnet server.

Fig. 1: Example of a BACnet object under a local BACnet server.

VAR_INPUT

Name             : Type
bEnablePV        : BOOL;
nPV              : UDINT;

bEnablePV: Enables the value of input nPV. When the input is set to TRUE, an entry is made in the Priority_Array of the corresponding BACnet object with the value of the input nPV. This corresponds to a write access to the commandable property Present_Value with the set priority (default: 12 when PLC automapping is used or 16 for manual linking in the System Manager).
If bEnablePV is set to FALSE, the corresponding entry from the Priority_Array is removed again (write ZERO).

nPV: Value to be written to the Priority_Array of the commandable property Present_Value. The priority is based on the process data configuration and mapping of the BACnet object in the System Manager (see also Figs. 2 and -3). Writing is enabled by setting the input bEnablePV to TRUE. Process data are always written cyclically once enabled.

Fig. 2: Example of a BACnet object with process data for writing the commandable property Present_Value. | Fig. 3: Example for a process data configuration of an BACnet object in the System Manager. Priority 12 and 16 are created as mappable process data (see result in Fig. 2).

VAR_OUTPUT

Note: Variables shown in grey italics are only available in the extended version of the block. The extended versions of the blocks end with "_EX". They offer substantially more process data, although in projects with a large number of objects this may have performance implications.

Name             : Type
bReady                  : BOOL;
nPresentValue           : UDINT;
bOverridden             : BOOL;
bOutOfService           : BOOL;
bFault                  : BOOL;
bInAlarm                : BOOL;
bMultiStateFault        : BOOL;
bOtherFault             : BOOL;
eEventState             : E_BACnetEventState;
bAckedTrans_ToOffNormal : BOOL;
bAckedTrans_ToFault     : BOOL;
bAckedTrans_ToNormal    : BOOL;nNbrOfStates            : UDINT;
bError                  : BOOL;
nErrorId                : UINT;

bReady: Notification of general readiness. If this output is set, the other status outputs are valid (PresentValue, Overridden ...). If the output is FALSE, the corresponding function block "FB_BACnet_Device" does not report "Operational", or the block instance was not linked correctly in the System Manager.

nPresentValue: Current value of the BACnet object (see also BACnet specification DIN EN ISO 16484-5 for BACnet object MultiStateValue and property Present_value).

bOverridden, bOutOfService, bFault, bInAlarm: See BACnet specification DIN EN ISO 16484-5 for BACnet object MultiStateValue and property Status_Flags.

bMultiStateFault, bOtherFault: See BACnet specification DIN EN ISO 16484-5 for BACnet object MultiStateValue and property Reliability.

eEventState: See BACnet specification DIN EN ISO 16484-5 for BACnet object MultiStateValue and property Event_State.

bAckedTrans_ToOffNormal, bAckedTrans_ToFault, bAckedTrans_ToNormal: Flags of property Acked_Transitions (see also BACnet specification DIN EN ISO 16484-5 for BACnet object MultiStateValue and property Acked_Transitions).

nNbrOfStates: Reports the available number of values, which the Present_Value of the MultiStateValue object can assume (1...nNbrOfStates). If "nNbrOfStates" is 0, then there is no valid "state" which the object can assume (Present_Value is 0).

bError: An error is pending.

nErrorId: Error number
0 = no error
2 = incorrect process data mapping detected (check mapping in the System Manager; if necessary compile complete PLC project and reload)
3 = the corresponding BACnet server is not ready (bOperational = FALSE at instance of the FB_BACnet_Device)
The error numbers can be queried as block constants via the FB instance (FB_BACnet_???.nERR_xxx).

VAR_IN_OUT

Name             : Type
Device           : FB_BACnet_Device;

Device: Specification of the instance of the local corresponding BACnet server block. For each BACnet adapter one BACnet server is possible. See FB_BACnet_Adapter and FB_BACnet_Device for further information.


FB_BACnet_MultiStateValue_ADS

The following function block is used for linking a BACnet object of the local BACnet server. The function block for the corresponding BACnet object is linked with the aid of process data.

The process data can be created manually in the BACnet object, linked manually, or they can be generated automatically via PLC automapping. The comments required for PLC automapping ( (* ~ (BACnet... | ??? | ??? ) *) ) are already included in the declaration of the function block.

Use

The function block "FB_BACnet_MultiStateValue_ADS" can be used for read and asynchronous write access to a BACnet object of type MultiStateValue (MV). To this end the BACnet object was created under a local BACnet server.

Fig. 1: Example of a BACnet object under a local BACnet server.

VAR_INPUT

Name             : Type
bEnablePV        : BOOL;
nPV              : UDINT; (* number for priority x, when input bEnablePV is TRUE *)
bManual                 : BOOL; (* FALSE --> TRUE: write present_value immediately,
FALSE: only write present_value on-change,
TRUE: write present_value on-change and when device turns operational *)
ePriority               : E_BACNETPRIORITY := BACNETPRIORITY_12;

bEnablePV: Enables the value of input "nPV". When the input is set to TRUE, an entry is made in the Priority_Array of the corresponding BACnet object with the value of input "nPV". This corresponds to a write access to the commandable property Present_Value with the priority given by the input "ePriority" (default: 12 when the input "ePriroty" is not connected).

nPV: Value to be written to the Priority_Array of the commandable property Present_Value. The priority is given by the input "ePriority". Writing is enabled by setting the input "bEnablePV" to TRUE. The value is written on change (WOC) or by the logic behind the input "bManual" (refer to the input description).

Hint: Since writing the property Present_Value happens acyclically and only on value change, it is potentially possible that the property Present_Value is overwritten with the same priority by other BACnet devices. In case of equal priorities, the last write access "wins".

bManual: The following logic will be distinguished for the input:
- FALSE: Write on change (WOC) for the input "nPV"
- edge transition FALSE --> TRUE: Triggers the writing of the input "nPV" immediately
- TRUE: Writing when value changed or when the associated BACnet server changes in the "operational" state (see FB_BACnet_Device).

ePriority: Priority for write accesses to the property Present_Value (Default: 12, see E_BACNETPRIORITY).

VAR_OUTPUT

Note: Variables shown in grey italics are only available in the extended version of the block. The extended versions of the blocks end with "_EX". They offer substantially more process data, although in projects with a large number of objects this may have performance implications.

Name             : Type
bReady           : BOOL;
bPvDone          : BOOL; (* present_value written over ADS *)
nPresentValue    : UDINT;
bOverridden      : BOOL;
bOutOfService    : BOOL;
bFault           : BOOL;
bInAlarm         : BOOL;
nNbrOfStates     : UDINT;
bError           : BOOL;
nErrorId         : UINT;
nAdsErrorId      : UDINT;

bReady: Notification of general readiness. If this output is set, the other status outputs are valid (PresentValue, Overridden ...). If the output is FALSE, the corresponding function block "FB_BACnet_Device" does not report "Operational", or the block instance was not linked correctly in the System Manager.

bPvDone: Positive edge when write access to property Present_Value was successfull.

nPresentValue: Current value of the BACnet object (see also BACnet specification DIN EN ISO 16484-5 for BACnet object MultiStateValue and property Present_value).

bOverridden, bOutOfService, bFault, bInAlarm: See BACnet specification DIN EN ISO 16484-5 for BACnet object MultiStateValue and property Status_Flags.

nNbrOfStates: Reports the available number of values, which the Present_Value of the MultiStateValue object can assume (1...nNbrOfStates). If "nNbrOfStates" is 0, then there is no valid "state" which the object can assume (Present_Value is 0).

bError: An error is pending.

nErrorId: Error number
0 = no error
2 = incorrect process data mapping detected (check mapping in the System Manager; if necessary compile complete PLC project and reload)
3 = the corresponding BACnet server is not ready (bOperational = FALSE at instance of the FB_BACnet_Device)
4 = the object type of the BACnet object dosn't match the function block type (the object type will determined over the process data. --> check the process data mapping in the System Manager!)
The error numbers can be queried as block constants via the FB instance (FB_BACnet_???.nERR_xxx).

nAdsErrorId: ADS error code.

VAR_IN_OUT

Name             : Type
Device           : FB_BACnet_Device;

Device: Specification of the instance of the local corresponding BACnet server block. For each BACnet adapter one BACnet server is possible. See FB_BACnet_Adapter and FB_BACnet_Device for further information.


FB_BACnet_NotificationClass

The following function block is used for linking a BACnet object of the local BACnet server. The function block for the corresponding BACnet object is linked with the aid of process data.

The process data can be created manually in the BACnet object, linked manually, or they can be generated automatically via PLC automapping. The comments required for PLC automapping ( (* ~ (BACnet... | ??? | ??? ) *) ) are already included in the declaration of the function block.

Use

The function block "FB_BACnet_NotificationClass" serves as placeholder for future functions.

VAR_OUTPUT

      Name             : Type

bReady           : BOOL;
bError           : BOOL;
nErrorId         : UINT;

bReady: Notification of general readiness. If the output is FALSE, the associated function block "FB_BACnet_Device" reports "not operational".

bError: An error is pending.

nErrorId: Error number
0 = no error
3 = the corresponding BACnet server is not ready (bOperational = FALSE at instance of the FB_BACnet_Device)
The error numbers can be queried as block constants via the FB instance (FB_BACnet_???.nERR_xxx).

VAR_IN_OUT

      Name             : Type

Device           : FB_BACnet_Device;

Device: Specification of the instance of the local corresponding BACnet server block. For each BACnet adapter one BACnet server is possible. See FB_BACnet_Adapter and FB_BACnet_Device for further information.


FB_BACnet_Program

The following function block is used for linking a BACnet object of the local BACnet server. The function block for the corresponding BACnet object is linked with the aid of process data.

The process data can be created manually in the BACnet object, linked manually, or they can be generated automatically via PLC automapping. The comments required for PLC automapping ( (* ~ (BACnet... | ??? | ??? ) *) ) are already included in the declaration of the function block.

Use

The function block "FB_BACnet_Program" provides the object functionality for the BACnet stack. To this end the BACnet object was created under a local BACnet server. The BACnet object on the BACnet stack side serves as interface to the BACnet world. The processing of the BACnet object is provided by the PLC instance of the block FB_BACnet_Program.

This approach has the advantage that existing, customer-specific PLC functions can easily be linked with the BACnet world. In this way, procedures that are implemented in PLC code can be triggered with the aid of the handshake interface (stDoneFlags, stFailedFlags and stRequestFlags) of the FB "FB_BACnet_Program".

The function block "FB_BACnet_Program" contains the state transitions described in the BACnet specification and maps them to the FB interface using the structures: stDoneFlags, stFailedFlags and stRequestFlags (see below Transition diagram Fig. 2).

Fig. 1: Example of a BACnet program object under a local BACnet server.

VAR_INPUT

Name               : Type
bRelease           : BOOL;
bCommonError       : BOOL;
bWaitForSomething  : BOOL;
stDoneFlags        : ST_BACnet_ProgramHandshakeRequests;
stFailedFlags      : ST_BACnet_ProgramHandshakeRequests;
bModeUnloadComplex : BOOL := TRUE;

bRelease: Enables processing of requests. If bRelease = FALSE is set, the program waits in state HALTED.

bCommonError: Error during execution of aProgram_Change requests from the structure stRequestFlags. Setting the input while a Program_Change requests is running leads to an abort condition (see Transition diagram Fig. 2).

bWaitForSomething: If the BACnet object is in state RUNNING, setting the input to TRUE switches to state WAITING, so that the BACnet object is blocked for further requests except Unload and Halt (see Transition diagram Fig. 2).
To return to state RUNNING set the input back to FALSE.

stDoneFlags: The flags within the input structure are used to acknowledge pending Program_Change requests from the output structure stRequestFlags. A signal change of one of the flags from FALSE to TRUE acknowledges execution of the corresponding Program_Change request.

stFailedFlags: The flags within the input structure are used to report cancellation of the pending Program_Change request from the output structure stRequestFlags. A signal change of one of the flags from FALSE to TRUE cancels execution of the corresponding Program_Change request.

bModeUnloadComplex: If the mode "Unload Complex" was activated via the input, the BACnet object status changes from UNLOADING to IDLE once the request Unload has been executed (see Transition diagram Fig. 2). If the input is set to FALSE, the BACnet object remains in state UNLOADING after the request Unload has been executed.

VAR_OUTPUT

Name               : Type
bReady             : BOOL;
bOverridden        : BOOL;
bOutOfService      : BOOL;
bFault             : BOOL;
bInAlarm           : BOOL;
bProcessError      : BOOL;
bOtherFault        : BOOL;
stRequestFlags     : ST_BACnet_ProgramHandshakeRequests;
stActiveStateFlags : ST_BACnet_ProgramHandshakeStates;
bError             : BOOL;
nErrorId           : UINT;

bReady: Notification of general readiness. If this output is set, the other status outputs are valid (ActiveStateFlags, Overridden ...). If the output is FALSE, the corresponding function block "FB_BACnet_Device" does not report "Operational", or the block instance was not linked correctly in the System Manager.

bOverridden, bOutOfService, bFault, bInAlarm: See BACnet specification DIN EN ISO 16484-5 for BACnet object Program and property Status_Flags.

bProcessError, bOtherFault: See BACnet specification DIN EN ISO 16484-5 for BACnet object Program and property Reliability.

stRequestFlags: Contains the flags for the corresponding Program_Change requests. If a flag is set to TRUE, a change in status of the program object is requested by the PLC program. If the change was successful, this is acknowledged with a signal change from FALSE to TRUE of the corresponding flags in the input structure stDoneFlags. If the corresponding PLC program is unable to execute the request or if the process is aborted, this must be reported via the corresponding flag in the input structure stFailedFlags. The termination is then shown in the status of the BACnet object.

stActiveStateFlags: Contains flags that reflect the current state of the BACnet program object (see Transition diagram Fig. 2).

bError: An error is pending.

nErrorId: Error number
0 = no error
2 = incorrect process data mapping detected (check mapping in the System Manager; if necessary compile complete PLC project and reload)
3 = the corresponding BACnet server is not ready (bOperational = FALSE at instance of the FB_BACnet_Device)
The error numbers can be queried as block constants via the FB instance (FB_BACnet_???.nERR_xxx).

VAR_IN_OUT

Name             : Type
Device           : FB_BACnet_Device;

Device: Specification of the instance of the local corresponding BACnet server block. For each BACnet adapter one BACnet server is possible. See FB_BACnet_Adapter and FB_BACnet_Device for further information.

Transition diagram

Fig. 2: from BACnet specification DIN EN ISO 16484-5 for BACnet object Program, Fig. 12-3 "State Transitions for the program object"


FB_BACnet_Schedule

The following function block is used for linking a BACnet object of the local BACnet server. The function block for the corresponding BACnet object is linked with the aid of process data.

The process data can be created manually in the BACnet object, linked manually, or they can be generated automatically via PLC automapping. The comments required for PLC automapping ( (* ~ (BACnet... | ??? | ??? ) *) ) are already included in the declaration of the function block.

Use

The function block "FB_BACnet_Schedule" can be used for read access to a BACnet object of type Schedule (SCHED). To this end the BACnet object was created under a local BACnet server.

Fig. 1: Example of a BACnet object under a local BACnet server.

VAR_OUTPUT

Note: Variables shown in grey italics are only available in the extended version of the block. The extended versions of the blocks end with "_EX". They offer substantially more process data, although in projects with a large number of objects this may have performance implications.

Name             : Type
bReady           : BOOL;
bPresentValue    : BOOL;
bOverridden      : BOOL;
bOutOfService    : BOOL;
bFault           : BOOL;
bInAlarm         : BOOL;
bConfigError     : BOOL;
bOtherFault      : BOOL;
bError           : BOOL;
nErrorId         : UINT;

bReady: Notification of general readiness. If this output is set, the other status outputs are valid (PresentValue, Overridden ...). If the output is FALSE, the corresponding function block "FB_BACnet_Device" does not report "Operational", or the block instance was not linked correctly in the System Manager.

bPresentValue: Current value of the BACnet object (see also BACnet specification DIN EN ISO 16484-5 for BACnet object Schedule and property Present_Value). The state is specified in 3 stages (enumeration) (0 = INACTIVE, 1 = ACTIVE and 2 = ZERO).

bOverridden, bOutOfService, bFault, bInAlarm: See BACnet specification DIN EN ISO 16484-5 for BACnet object Schedule and property Status_Flags.

bConfigError, bOtherFault: See BACnet specification DIN EN ISO 16484-5 for BACnet object Schedule and property Reliability.

bError: An error is pending.

nErrorId: Error number
0 = no error
2 = incorrect process data mapping detected (check mapping in the System Manager; if necessary compile complete PLC project and reload)
3 = the corresponding BACnet server is not ready (bOperational = FALSE at instance of the FB_BACnet_Device)
The error numbers can be queried as block constants via the FB instance (FB_BACnet_???.nERR_xxx).

VAR_IN_OUT

Name           : Type
Device         : FB_BACnet_Device;

Device: Specification of the instance of the local corresponding BACnet server block. For each BACnet adapter one BACnet server is possible. See FB_BACnet_Adapter and FB_BACnet_Device for further information.


FB_BACnet_TrendLog

The following function block is used for linking a BACnet object of the local BACnet server. The function block for the corresponding BACnet object is linked with the aid of process data.

The process data can be created manually in the BACnet object, linked manually, or they can be generated automatically via PLC automapping. The comments required for PLC automapping ( (* ~ (BACnet... | ??? | ??? ) *) ) are already included in the declaration of the function block.

Use

The function block "FB_BACnet_TrendLog" can be used for read access to a BACnet object of type TrendLog (TREND). To this end the BACnet object was created under a local BACnet server.

Fig. 1: Example of a BACnet object under a local BACnet server.

VAR_OUTPUT

Note: Variables shown in grey italics are only available in the extended version of the block. The extended versions of the blocks end with "_EX". They offer substantially more process data, although in projects with a large number of objects this may have performance implications.

Name             : Type
bReady                  : BOOL;
bLogEnable              : BOOL;
nRecordCount            : UDINT;
nTotalCount             : UDINT;
eEventState             : E_BACnetEventState;
bAckedTrans_ToOffNormal : BOOL;
bAckedTrans_ToFault     : BOOL;
bAckedTrans_ToNormal    : BOOL;
bError                  : BOOL;
nErrorId                : UINT;

bReady: Notification of general readiness. If this output is set, the other status outputs are valid (LogEnable, RecordCount...). If the output is FALSE, the corresponding function block "FB_BACnet_Device " does not report "Operational", or the block instance was not linked correctly in the System Manager.

bLogEnable: See BACnet specification DIN EN ISO 16484-5 for BACnet object TrendLog and property Log_Enable.

nRecordCount: See BACnet specification DIN EN ISO 16484-5 for BACnet object TrendLog and property Record_Count.

nTotalCount: See BACnet specification DIN EN ISO 16484-5 for BACnet object TrendLog and property Total_Record_Count.

eEventState: See BACnet specification DIN EN ISO 16484-5 for BACnet object TrendLog and property Event_State.

bAckedTrans_ToOffNormal, bAckedTrans_ToFault, bAckedTrans_ToNormal: Flags of property Acked_Transitions (see also BACnet specification DIN EN ISO 16484-5 for BACnet object TrendLog and property Acked_Transitions).

bError: An error is pending.

nErrorId: Error number
0 = no error
2 = incorrect process data mapping detected (check mapping in the System Manager; if necessary compile complete PLC project and reload)
3 = the corresponding BACnet server is not ready (bOperational = FALSE at instance of the FB_BACnet_Device)
The error numbers can be queried as block constants via the FB instance (FB_BACnet_???.nERR_xxx).

VAR_IN_OUT

Name             : Type
Device           : FB_BACnet_Device;

Device: Specification of the instance of the local corresponding BACnet server block. For each BACnet adapter one BACnet server is possible. See FB_BACnet_Adapter and FB_BACnet_Device for further information.


FB_BACnet_Device

TS8020 | TwinCAT BACnet Supplement

FB_BACnet_RemoteDevice

The following function block is used for linking the PLC program to a remote BACnet device object (local client). The linking of the function block takes place with the aid of process data.

The process data can be linked manually or automatically via PLC automapping. The comments required for PLC automapping ( (* ~ (BACnet... | ??? | ??? ) *) ) are already included in the declaration of the function block. The process data for the BACnet device object also include the required process data for linking the BACnet client.

Fig. 1: Process data of the remote BACnet device object and client in the System Manager.

Fig. 2: Function block of the remote BACnet device object and client in the PLC program.

Use

The function block "FB_BACnet_RemoteDevice" is used to read the state of the remote BACnet device object (System_Status) and output it in the PLC program. The process data "Client Control" and "Client Status" are also used to control the local BACnet client (disable/enable WriteOnChange, resubscription to properties, automatic subscription of properties after connection faults and error acknowledgement).

The block FB_BACnet_RemoteDevice also requires a global instance of the block FB_BACnet_Adapter for each PLC project. The block FB_BACnet_Adapter establishes the connection between PLC and BACnet adapter in the System Manager. This global instance is already provided by the PLC library. The hierarchy between FB_BACnet_Adapter, FB_BACnet_Device and FB_BACnet_RemoteDevice and an object of type AnalogValue is shown below:

Fig. 3: Example for linking the FB instances in the PLC.

Application notes: see also blocks FB_BACnet_Adapter and FB_BACnet_Device.

VAR_INPUT

      Name             : Type

bReset           : BOOL;
bAutoReset       : BOOL;
bDisableWOC      : BOOL;
bReSubscribeCOV  : BOOL;
bAutoReSubscribe : BOOL;

bReset: Resets the error state in the event of a signal change FALSE --> TRUE.

bAutoReset: When input is TRUE, errors with ID 20 and 21 are automatically acknowledged . Related remote FBs will not be blocked (bReady of the FB remains TRUE). Instead of the error ID, an error counter is incremented (see nTimeoutCnt and nServiceFailCnt).

bDisableWOC: If the input is set to TRUE, WriteOnChange (WOC) is suppressed for all objects of this client. This means that changes in the process data do not automatically trigger writing of the properties to the remote objects (only applies to properties that are configured for WriteOnChange under the client).

bReSubscribeCOV: A signal change at the input from FALSE to TRUE triggers resubscription of all properties that are configured for COV. This function may affect many objects and should therefore only be executed when necessary. Normally all subscribed properties are automatically re-subscribed once a timeout time has elapsed (resubscription interval).

bAutoReSubscribe: If the input is set to TRUE, automatic resubscription of all properties that are configured for COV is triggered as required. Not to be confused with the resubscription interval! Automatic resubscription is triggered if a remote server was no longer accessible and the connection has been restored, for example. If the input is set to FALSE, resubscription is only triggered once the resubscription interval has elapsed.

VAR_OUTPUT

      Name             : Type

eSystemStatus    : E_BACnetDeviceStatus;
bEthLinkOk       : BOOL;
bGatewayOk       : BOOL;
sAmsNetId        : T_AmsNetId;
bEnabledWOC      : BOOL;
bOperational     : BOOL;
bConnecting      : BOOL;
bFirstCycle      : BOOL;
bError           : BOOL;
nErrorId         : UINT;
bClientTimeout   : BOOL;
bServiceFailed   : BOOL;
nTimeoutCnt      : UDINT;
nServiceFailCnt  : UDINT;

eSystemStatus: Current status of the remote BACnet server object (see BACnet specification DIN EN ISO 16484-5 for BACnet device object and property System_Status).
0: BACnetDeviceStatus_Operational
1: BACnetDeviceStatus_OperationalReadOnly (only read access to properties)
2: BACnetDeviceStatus_DownloadRequired (loading of the configuration required)
3: BACnetDeviceStatus_DownloadInProgress (configuration download in progress)
4: BACnetDeviceStatus_NonOperational
5: BACnetDeviceStatus_BackupInProgress

bEthLinkOk: The local Ethernet connection is active (cable connected, adapter linked) if the output is set to TRUE.

bGatewayOk: The configured gateway can be reached if the output is set to TRUE.

sAmsNetId: Output of the AMS NetID of the local BACnet adapter (can be used for asynchronous access to BACnet objects via ADS).

bEnabledWOC: WriteOnChange (WOC) is activated for properties that are configured for COV.

bOperational: BACnet device object of the remote server reports "operational" (System_Status = 0), the device adapter reports status bEthLinkOk, status bConnecting is FALSE and bit 0 of the process data "Client Status" is not set (nERR_CLIENT_TIMEOUT). If the output becomes FALSE, all linked objects are blocked (block instances).

bConnecting: The connection to the remote server is established (process data "Client Status" is less than 0x04xx).

bFirstCycle: Is set for one cycle when the block instance is first called after a PLC reset or restart.

bError: An error is pending.

nErrorId: Error number
0 = no error
1 = function block of the corresponding client (RemoteDevice) is not called or not called regularly enough from the PLC program.
1 = no valid AMS NetID
3 = no network connection (bEthLinkOk = FALSE)
4 = gateway cannot be reached (bGatewayOk = FALSE)
20 = timeout during communication with remote server
21 = error during execution of a service between the remote server (Subscribe-COV, Property-Write etc.)
The error numbers can be queried as block constants via the FB instance (FB_BACnet_RemoteDevice.nERR_xxx). All errors with error number equal or greater than 20 have to be acknowledged with bReset.

bClientTimeout: When output is set to TRUE, a timeout error (ID 20) has occurred. The output will reset to FALSE if no error occurred for 10 seconds.

bServiceFailed: When output is set to TRUE, a service error (ID 21) has occurred. The output will reset to FALSE if no error occurred for 10 seconds.

nTimeoutCnt: Number of timeout errors that occurred (ID 20). The positive edge of the corresponding status flag of client will count.

nServiceFailCnt: Number of errors that occurred Service (ID 21). The positive edge of the corresponding status flag of client will count.

Notes

An instance of the block "FB_BACnet_RemoteDevice" is required whenever objects of a remote BACnet server are to be accessed from the PLC with the aid of a local BACnet client. Several instances of the block "FB_BACnet_RemoteDevice" can be created and linked with the corresponding clients in the System Manager via PLC automapping. All instances of the block "FB_BACnet_RemoteDevice" use the same global instance of block FB_BACnet_Adapter.

If several instances of the block FB_BACnet_Adapter are to be used, the corresponding instance of the BACnet adapter block must be called before the instance of the BACnet client block is called. A CFC example is provided below (Please note the order in which the blocks are called!):

Fig. 4: Example for using several adapter and client instances in a PLC project. | Fig. 5: Example for calling blocks of type FB_BACnet_RemoteAnalogValue with different remote BACnet servers in a PLC project.

The use of several BACnet adapters in a PLC project is a special case and is not recommended. It could make sense (e.g. in cases where several network cards and therefore separate BACnet networks are used) to use several PLC projects and therefore several PLC runtimes. Data exchange between the individual runtimes can be realised via process data mapping or ADS communication. In this case PLC automapping could be used for BACnet objects.


FB_BACnet_RemoteAccumulator

The following function block is used for linking a remote BACnet object of the local BACnet client. The function block for the corresponding BACnet object is linked with the aid of process data. The data exchange with the remote BACnet server takes place via BACnet with the aid of WOC (Write-On-Change) and COV (Changes-On-Value) or via polling (not recommended).

The process data can be created manually in the BACnet object, linked manually, or they can be generated automatically via PLC automapping. The comments required for PLC automapping ( (* ~ (BACnet... | ??? | ??? ) *) ) are already included in the declaration of the function block.

Use

The function block "FB_BACnet_RemoteAccumulator" can be used for read access to a remote BACnet object of type Accumulator (AC). To this end the remote BACnet object was added to a local BACnet client.

Fig. 1: Example for a remote BACnet object under a local BACnet client.

VAR_OUTPUT

Name             : Type
bReady           : BOOL;
nPresentValue    : UDINT;
bOverridden      : BOOL;
bOutOfService    : BOOL;
bFault           : BOOL;
bInAlarm         : BOOL;
bError           : BOOL;
nErrorId         : UINT;

bReady: Notification of general readiness. If this output is set, the other status outputs are valid (PresentValue, Overridden ...). If the output is FALSE, the corresponding function block "FB_BACnet_RemoteDevice" reports "not operational", the block instances was not linked correctly in the System Manager or the remote server cannot be reached (gateway cannot be reached, no Ethernet link).

nPresentValue: Current value of the BACnet object (see also BACnet specification DIN EN ISO 16484-5 for BACnet object Accumulator and property Present_value).

bOverride, bOutOfService, bFault, bInAlarm: See BACnet specification DIN EN ISO 16484-5 for BACnet object Accumulator and property Status_Flags.

bError: An error is pending.

nErrorId: Error number
0 = no error
1 = function block of the corresponding client (RemoteDevice) is not called or not called regularly enough from the PLC program.
2 = incorrect process data mapping detected (check mapping in the System Manager; if necessary compile complete PLC project and reload)
3 = the corresponding BACnet client is not ready (bOperational = FALSE at instance of the FB_BACnet_RemoteDevice)
The error numbers can be queried as block constants via the FB instance (FB_BACnet_Remote???.nERR_xxx).

VAR_IN_OUT

Name             : Type
RemoteDevice     : FB_BACnet_RemoteDevice;

RemoteDevice: Block instance of the corresponding remote BACnet device object. The remote BACnet device object of a remote BACnet server has been added under a local BACnet client. Local client and remote server are linked via BACnet. Any number of clients can be linked via BACnet adapter. See FB_BACnet_Adapter and FB_BACnet_RemoteDevice for further information.


FB_BACnet_RemoteAnalogInput

The following function block is used for linking a remote BACnet object of the local BACnet client. The function block for the corresponding BACnet object is linked with the aid of process data. The data exchange with the remote BACnet server takes place via BACnet with the aid of WOC (Write-On-Change) and COV (Changes-On-Value) or via polling (not recommended).

The process data can be created manually in the BACnet object, linked manually, or they can be generated automatically via PLC automapping. The comments required for PLC automapping ( (* ~ (BACnet... | ??? | ??? ) *) ) are already included in the declaration of the function block.

Use

The function block "FB_BACnet_RemoteAnalogInput" can be used for read access to a remote BACnet object of type AnalogInput (AI). To this end the remote BACnet object was added to a local BACnet client.

Fig. 1: Example for a remote BACnet object under a local BACnet client.

VAR_OUTPUT

Note: Variables shown in grey italics are only available in the extended version of the block. The extended versions of the blocks end with "_EX". They offer substantially more process data, although in projects with a large number of objects this may have performance implications.

Name             : Type
bReady           : BOOL;
fPresentValue    : REAL;
bOverridden      : BOOL;
bOutOfService    : BOOL;
bFault           : BOOL;
bInAlarm         : BOOL;
bOverRange       : BOOL;
bUnderRange      : BOOL;
bNoSensor        : BOOL;
bOpenLoop        : BOOL;
bShortedLoop     : BOOL;
bOtherFault      : BOOL;
eEventState      : E_BACnetEventState;bError           : BOOL;
nErrorId         : UINT;

bReady: Notification of general readiness. If this output is set, the other status outputs are valid (PresentValue, Overridden ...). If the output is FALSE, the corresponding function block "FB_BACnet_RemoteDevice" reports "not operational", the block instances was not linked correctly in the System Manager or the remote server cannot be reached (gateway cannot be reached, no Ethernet link).

fPresentValue: Current value of the BACnet object (see also BACnet specification DIN EN ISO 16484-5 for BACnet object AnalogInput and property Present_Value).

bOverride, bOutOfService, bFault, bInAlarm: See BACnet specification DIN EN ISO 16484-5 for BACnet object AnalogInput and property Status_Flags.

bOverRange, bUnderRange, bNoSensor, bOpenLoop, bShortedLoop, bOtherFault: See BACnet specification DIN EN ISO 16484-5 for BACnet object AnalogInput and property Reliability.

eEventState: See BACnet specification DIN EN ISO 16484-5 for BACnet object AnalogInput and property Event_State.

bError: An error is pending.

nErrorId: Error number
0 = no error
1 = function block of the corresponding client (RemoteDevice) is not called or not called regularly enough from the PLC program.
2 = incorrect process data mapping detected (check mapping in the System Manager; if necessary compile complete PLC project and reload)
3 = the corresponding BACnet client is not ready (bOperational = FALSE at instance of the FB_BACnet_RemoteDevice)
The error numbers can be queried as block constants via the FB instance (FB_BACnet_???.nERR_xxx).

VAR_IN_OUT

Name             : Type
RemoteDevice     : FB_BACnet_RemoteDevice;

RemoteDevice: Block instance of the corresponding remote BACnet device object. The remote BACnet device object of a remote BACnet server has been added under a local BACnet client. Local client and remote server are linked via BACnet. Any number of clients can be linked via BACnet adapter. See FB_BACnet_Adapter and FB_BACnet_RemoteDevice for further information.


FB_BACnet_RemoteAnalogOutput

The following function block is used for linking a remote BACnet object of the local BACnet client. The function block for the corresponding BACnet object is linked with the aid of process data. The data exchange with the remote BACnet server takes place via BACnet with the aid of WOC (Write-On-Change) and COV (Changes-On-Value) or via polling (not recommended).

The process data can be created manually in the BACnet object, linked manually, or they can be generated automatically via PLC automapping. The comments required for PLC automapping ( (* ~ (BACnet... | ??? | ??? ) *) ) are already included in the declaration of the function block.

Use

The function block "FB_BACnet_RemoteAnalogOutput" can be used for read and write access to a BACnet object of type AnalogOutput (AO) To this end the remote BACnet object was added to a local BACnet client.

Fig. 1: Example for a remote BACnet object under a local BACnet client.

VAR_INPUT

Name             : Type
bEnablePV        : BOOL;
fPV              : REAL;

bEnablePV: Enables the value of input "fPV". When the input is set to TRUE, an entry is made in the Priority_Array of the corresponding BACnet object with the value of input "fPV". This corresponds to a write access to the commandable property Present_Value with the set priority (default: 12 when PLC automapping is used or 16 for manual linking in the System Manager).

fPV: Value to be written to the Priority_Array of the commandable property Present_Value. The priority is based on the process data configuration and mapping of the BACnet object in the System Manager (see also Figs. 2 and 3). Writing is enabled by setting the input "bEnablePV" to TRUE. Writing of the process data to the local client always takes place cyclically. After enabling via bEnablePV the data are sent via BACnet to the remote server either cyclically (Periodic Write) or when changes occur (Write On Change - recommended).

Fig. 2: Example of a BACnet object with process data for writing the commandable property Present_Value. | Fig. 3: Example for a process data configuration of an BACnet object in the System Manager. Priority 12 is created as a mappable process data (see result in Fig. 2).

VAR_OUTPUT

Note: Variables shown in grey italics are only available in the extended version of the block. The extended versions of the blocks end with "_EX". They offer substantially more process data, although in projects with a large number of objects this may have performance implications.

Name             : Type
bReady           : BOOL;
fPresentValue    : REAL;
bOverridden      : BOOL;
bOutOfService    : BOOL;
bFault           : BOOL;
bInAlarm         : BOOL;
bNoOutput        : BOOL;
bOpenLoop        : BOOL;
bShortedLoop     : BOOL;
bOtherFault      : BOOL;
eEventState      : E_BACnetEventState;
nActivePrio      : UINT;
bError           : BOOL;
nErrorId         : UINT;

bReady: Notification of general readiness. If this output is set, the other status outputs are valid (PresentValue, Overridden ...). If the output is FALSE, the corresponding function block FB_BACnet_RemoteDevice reports "not operational", the block instances was not linked correctly in the System Manager or the remote server cannot be reached (gateway cannot be reached, no Ethernet link).

fPresentValue: Current value of the BACnet object (see also BACnet specification DIN EN ISO 16484-5 for BACnet object AnalogOutput and property Present_Value).

bOverridden, bOutOfService, bFault, bInAlarm: See BACnet specification DIN EN ISO 16484-5 for BACnet object AnalogOutput and property Status_Flags.

bNoOutput, bOpenLoop, bShortedLoop, bOtherFault: See BACnet specification DIN EN ISO 16484-5 for BACnet object AnalogOutput and property Reliability.

eEventState: See BACnet specification DIN EN ISO 16484-5 for BACnet object AnalogOutput and property Event_State.

nActivePrio: Indicates the currently active priority of the priority array, which acts on the Present_Value (see also BACnet specification DIN EN ISO 16484-5 for BACnet object AnalogOutput and property Present_Value).

bError: An error is pending.

nErrorId: Error number
0 = no error
1 = function block of the corresponding client (RemoteDevice) is not called or not called regularly enough from the PLC program.
2 = incorrect process data mapping detected (check mapping in the System Manager; if necessary compile complete PLC project and reload)
3 = the corresponding BACnet client is not ready (bOperational = FALSE at instance of the FB_BACnet_RemoteDevice)
The error numbers can be queried as block constants via the FB instance (FB_BACnet_Remote???.nERR_xxx).

VAR_IN_OUT

Name             : Type
RemoteDevice     : FB_BACnet_RemoteDevice;

RemoteDevice: Block instance of the corresponding remote BACnet device object. The remote BACnet device object of a remote BACnet server has been added under a local BACnet client. Local client and remote server are linked via BACnet. Any number of clients can be linked via BACnet adapter. See FB_BACnet_Adapter and FB_BACnet_RemoteDevice for further information.


FB_BACnet_RemoteAnalogValue

The following function block is used for linking a remote BACnet object of the local BACnet client. The function block for the corresponding BACnet object is linked with the aid of process data. The data exchange with the remote BACnet server takes place via BACnet with the aid of WOC (Write-On-Change) and COV (Changes-On-Value) or via polling (not recommended).

The process data can be created manually in the BACnet object, linked manually, or they can be generated automatically via PLC automapping. The comments required for PLC automapping ( (* ~ (BACnet... | ??? | ??? ) *) ) are already included in the declaration of the function block.

Use

The function block "FB_BACnet_RemoteAnalogValue" can be used for read and write access to a remote BACnet object of type AnalogValue (AV). To this end the remote BACnet object was added to a local BACnet client.

Fig. 1: Example for a remote BACnet object under a local BACnet client.

VAR_INPUT

Name             : Type
bEnablePV        : BOOL;
fPV              : REAL;

bEnablePV: Enables the value of input fPV. When the input is set to TRUE, an entry is made in the Priority_Array of the corresponding BACnet object with the value of input fPV. This corresponds to a write access to the commandable property Present_Value with the set priority (default: 12 when PLC automapping is used or 16 for manual linking in the System Manager).
If bEnablePV is set to FALSE, the corresponding entry from the Priority_Array is removed again (write ZERO).

fPV: Value to be written to the Priority_Array of the commandable property Present_Value. The priority is based on the process data configuration and mapping of the BACnet object in the System Manager (see also Figs. 2 and 3). Writing is enabled by setting the input bEnablePV to TRUE. Writing of the process data to the local client always takes place cyclically. After enabling via bEnablePV the data are sent via BACnet to the remote server either cyclically (Periodic Write) or when changes occur (Write On Change - recommended).

Fig. 2: Example of a BACnet object with process data for writing the commandable property Present_Value. | Fig. 3: Example for a process data configuration of an BACnet object in the System Manager. Priority 12 is created as a mappable process data (see result in Fig. 2).

VAR_OUTPUT

Note: Variables shown in grey italics are only available in the extended version of the block. The extended versions of the blocks end with "_EX". They offer substantially more process data, although in projects with a large number of objects this may have performance implications.

Name             : Type
bReady           : BOOL;
fPresentValue    : REAL;
bOverridden      : BOOL;
bOutOfService    : BOOL;
bFault           : BOOL;
bInAlarm         : BOOL;
bOverRange       : BOOL;
bUnderRange      : BOOL;
bOtherFault      : BOOL;
eEventState      : E_BACnetEventState;
nActivePrio      : UINT;
bError           : BOOL;
nErrorId         : UINT;

bReady: Notification of general readiness. If this output is set, the other status outputs are valid (PresentValue, Overridden ...). If the output is FALSE, the corresponding function block "FB_BACnet_RemoteDevice" reports "not operational", the block instances was not linked correctly in the System Manager or the remote server cannot be reached (gateway cannot be reached, no Ethernet link).

fPresentValue: Current value of the BACnet object (see also BACnet specification DIN EN ISO 16484-5 for BACnet object AnalogValue and property Present_Value).

bOverride, bOutOfService, bFault, bInAlarm: See BACnet specification DIN EN ISO 16484-5 for BACnet object AnalogValue and property Status_Flags.

bOverRange, bUnderRange, bOtherFault: See BACnet specification DIN EN ISO 16484-5 for BACnet object AnalogValue and property Reliability.

eEventState: See BACnet specification DIN EN ISO 16484-5 for BACnet object AnalogValue and property Event_State.

nActivePrio: Indicates the currently active priority of the priority array, which acts on the Present_Value (see also BACnet specification DIN EN ISO 16484-5 for BACnet object AnalogValue and property Present_Value).

bError: An error is pending.

nErrorId: Error number
0 = no error
1 = function block of the corresponding client (RemoteDevice) is not called or not called regularly enough from the PLC program.
2 = incorrect process data mapping detected (check mapping in the System Manager; if necessary compile complete PLC project and reload)
3 = the corresponding BACnet client is not ready (bOperational = FALSE at instance of the FB_BACnet_RemoteDevice)
The error numbers can be queried as block constants via the FB instance (FB_BACnet_Remote???.nERR_xxx).

VAR_IN_OUT

Name             : Type
RemoteDevice     : FB_BACnet_RemoteDevice;

RemoteDevice: Block instance of the corresponding remote BACnet device object. The remote BACnet device object of a remote BACnet server has been added under a local BACnet client. Local client and remote server are linked via BACnet. Any number of clients can be linked via BACnet adapter. See FB_BACnet_Adapter and FB_BACnet_RemoteDevice for further information.


FB_BACnet_RemoteAveraging

The following function block is used for linking a remote BACnet object of the local BACnet client. The function block for the corresponding BACnet object is linked with the aid of process data. The data exchange with the remote BACnet server takes place via BACnet with the aid of WOC (Write-On-Change) and COV (Changes-On-Value) or via polling (not recommended).

The process data can be created manually in the BACnet object, linked manually, or they can be generated automatically via PLC automapping. The comments required for PLC automapping ( (* ~ (BACnet... | ??? | ??? ) *) ) are already included in the declaration of the function block.

Use

The function block "FB_BACnet_RemoteAveraging" can be used for read access to a remote BACnet object of type Averaging (AVG). To this end the remote BACnet object was added to a local BACnet client.

Fig. 1: Example for a remote BACnet object under a local BACnet client.

VAR_OUTPUT

Name             : Type
bReady           : BOOL;
nAverageValue    : UDINT;
bOverridden      : BOOL;
bOutOfService    : BOOL;
bFault           : BOOL;
bInAlarm         : BOOL;
bError           : BOOL;
nErrorId         : UINT;

bReady: Notification of general readiness. If this output is set, the other status outputs are valid (PresentValue, Overridden ...). If the output is FALSE, the corresponding function block "FB_BACnet_RemoteDevice" reports "not operational", the block instances was not linked correctly in the System Manager or the remote server cannot be reached (gateway cannot be reached, no Ethernet link).

nAverageValue: Current value of the BACnet object (see also BACnet specification DIN EN ISO 16484-5 for BACnet object Averaging.

bOverride, bOutOfService, bFault, bInAlarm: See BACnet specification DIN EN ISO 16484-5 for BACnet object Averaging and property Status_Flags.

bError: An error is pending.

nErrorId: Error number
0 = no error
1 = function block of the corresponding client (RemoteDevice) is not called or not called regularly enough from the PLC program.
2 = incorrect process data mapping detected (check mapping in the System Manager; if necessary compile complete PLC project and reload)
3 = the corresponding BACnet client is not ready (bOperational = FALSE at instance of the FB_BACnet_RemoteDevice)
The error numbers can be queried as block constants via the FB instance (FB_BACnet_Remote???.nERR_xxx).

VAR_IN_OUT

Name             : Type
RemoteDevice     : FB_BACnet_RemoteDevice;

RemoteDevice: Block instance of the corresponding remote BACnet device object. The remote BACnet device object of a remote BACnet server has been added under a local BACnet client. Local client and remote server are linked via BACnet. Any number of clients can be linked via BACnet adapter. See FB_BACnet_Adapter and FB_BACnet_RemoteDevice for further information.


FB_BACnet_RemoteBinaryInput

The following function block is used for linking a remote BACnet object of the local BACnet client. The function block for the corresponding BACnet object is linked with the aid of process data. The data exchange with the remote BACnet server takes place via BACnet with the aid of WOC (Write-On-Change) and COV (Changes-On-Value) or via polling (not recommended).

The process data can be created manually in the BACnet object, linked manually, or they can be generated automatically via PLC automapping. The comments required for PLC automapping ( (* ~ (BACnet... | ??? | ??? ) *) ) are already included in the declaration of the function block.

Use

The function block "FB_BACnet_RemoteBinaryInput" can be used for read access to a remote BACnet object of type BinaryInput (BI). To this end the remote BACnet object was added to a local BACnet client.

Fig. 1: Example for a remote BACnet object under a local BACnet client.

VAR_OUTPUT

Note: Variables shown in grey italics are only available in the extended version of the block. The extended versions of the blocks end with "_EX". They offer substantially more process data, although in projects with a large number of objects this may have performance implications.

Name             : Type
bReady           : BOOL;
bPresentValue    : BOOL;
bOverridden      : BOOL;
bOutOfService    : BOOL;
bFault           : BOOL;
bInAlarm         : BOOL;
bNoSensor        : BOOL;
bOpenLoop        : BOOL;
bShortedLoop     : BOOL;
bOtherFault      : BOOL;
eEventState      : E_BACnetEventState;
bError           : BOOL;
nErrorId         : UINT;

bReady: Notification of general readiness. If this output is set, the other status outputs are valid (PresentValue, Overridden ...). If the output is FALSE, the corresponding function block "FB_BACnet_RemoteDevice" reports "not operational", the block instances was not linked correctly in the System Manager or the remote server cannot be reached (gateway cannot be reached, no Ethernet link).

bPresentValue: Current value of the BACnet object (see also BACnet specification DIN EN ISO 16484-5 for BACnet object BinaryOutput and property Present_Value).

bOverridden, bOutOfService, bFault, bInAlarm: See BACnet specification DIN EN ISO 16484-5 for BACnet object BinaryInput and property Status_Flags.

bNoSensor, bOpenLoop, bShortedLoop, bOtherFault: See BACnet specification DIN EN ISO 16484-5 for BACnet object BinaryInput and property Reliability.

eEventState: See BACnet specification DIN EN ISO 16484-5 for BACnet object BinaryInput and property Event_State.

bError: An error is pending.

nErrorId: Error number
0 = no error
1 = function block of the corresponding client (RemoteDevice) is not called or not called regularly enough from the PLC program.
2 = incorrect process data mapping detected (check mapping in the System Manager; if necessary compile complete PLC project and reload)
3 = the corresponding BACnet client is not ready (bOperational = FALSE at instance of the FB_BACnet_RemoteDevice)
The error numbers can be queried as block constants via the FB instance (FB_BACnet_Remote???.nERR_xxx).

VAR_IN_OUT

Name             : Type
RemoteDevice     : FB_BACnet_RemoteDevice;

RemoteDevice: Block instance of the corresponding remote BACnet device object. The remote BACnet device object of a remote BACnet server has been added under a local BACnet client. Local client and remote server are linked via BACnet. Any number of clients can be linked via BACnet adapter. See FB_BACnet_Adapter and FB_BACnet_RemoteDevice for further information.


FB_BACnet_RemoteBinaryOutput

The following function block is used for linking a remote BACnet object of the local BACnet client. The function block for the corresponding BACnet object is linked with the aid of process data. The data exchange with the remote BACnet server takes place via BACnet with the aid of WOC (Write-On-Change) and COV (Changes-On-Value) or via polling (not recommended).

The process data can be created manually in the BACnet object, linked manually, or they can be generated automatically via PLC automapping. The comments required for PLC automapping ( (* ~ (BACnet... | ??? | ??? ) *) ) are already included in the declaration of the function block.

Use

The function block "FB_BACnet_RemoteBinaryOutput" can be used for read and write access to a remote BACnet object of type BinaryOutput (BO). To this end the remote BACnet object was added to a local BACnet client.

Fig. 1: Example for a remote BACnet object under a local BACnet client.

VAR_INPUT

Name             : Type
bEnablePV        : BOOL;
bPV              : E_BACnetBinaryPV;

bEnablePV: Enables the value of input "bPV". When the input is set to TRUE, an entry is made in the Priority_Array of the corresponding BACnet object with the value of input "bPV". This corresponds to a write access to the commandable property Present_Value with the set priority (default: 12 when PLC automapping is used or 16 for manual linking in the System Manager).
If bEnablePV is set to FALSE, the corresponding entry from the Priority_Array is removed again (write ZERO).

bPV: Value to be written to the Priority_Array of the commandable property Present_Value. The priority is based on the process data configuration and mapping of the BACnet object in the System Manager (see also Figs. 2 and 3). Writing is enabled by setting the input "bEnablePV" to TRUE. Writing of the process data to the local client always takes place cyclically. After enabling via bEnablePV the data are sent via BACnet to the remote server either cyclically (Periodic Write) or when changes occur (Write On Change - recommended).

Fig. 2: Example of a BACnet object with process data for writing the commandable property Present_Value. | Fig. 3: Example for a process data configuration of an BACnet object in the System Manager. Priority 12 is created as a mappable process data (see result in Fig. 2).

VAR_OUTPUT

Note: Variables shown in grey italics are only available in the extended version of the block. The extended versions of the blocks end with "_EX". They offer substantially more process data, although in projects with a large number of objects this may have performance implications.

Name             : Type
bReady           : BOOL;
bPresentValue    : BOOL;
bOverridden      : BOOL;
bOutOfService    : BOOL;
bFault           : BOOL;
bInAlarm         : BOOL;
bNoOutput        : BOOL;
bOpenLoop        : BOOL;
bShortedLoop     : BOOL;
bOtherFault      : BOOL;
eEventState      : E_BACnetEventState;
nActivePrio      : UINT;
bError           : BOOL;
nErrorId         : UINT;

bReady: Notification of general readiness. If this output is set, the other status outputs are valid (PresentValue, Overridden ...). If the output is FALSE, the corresponding function block "FB_BACnet_RemoteDevice" reports "not operational", the block instances was not linked correctly in the System Manager or the remote server cannot be reached (gateway cannot be reached, no Ethernet link).

bPresentValue: Current value of the BACnet object (see also BACnet specification DIN EN ISO 16484-5 for BACnet object BinaryOutput and property Present_Value).

bOverridden, bOutOfService, bFault, bInAlarm: See BACnet specification DIN EN ISO 16484-5 for BACnet object BinaryOutput and property Status_Flags.

bOtherFault: See BACnet specification DIN EN ISO 16484-5 for BACnet object BinaryOutput and property Reliability.

eEventState: See BACnet specification DIN EN ISO 16484-5 for BACnet object BinaryOutput and property Event_State.

nActivePrio: Indicates the currently active priority of the priority array, which acts on the Present_Value (see also BACnet specification DIN EN ISO 16484-5 for BACnet object BinaryOutput and property Present_Value).

bError: An error is pending.

nErrorId: Error number
0 = no error
1 = function block of the corresponding client (RemoteDevice) is not called or not called regularly enough from the PLC program.
2 = incorrect process data mapping detected (check mapping in the System Manager; if necessary compile complete PLC project and reload)
3 = the corresponding BACnet client is not ready (bOperational = FALSE at instance of the FB_BACnet_RemoteDevice)
The error numbers can be queried as block constants via the FB instance (FB_BACnet_Remote???.nERR_xxx).

VAR_IN_OUT

Name             : Type
RemoteDevice     : FB_BACnet_RemoteDevice;

RemoteDevice: Block instance of the corresponding remote BACnet device object. The remote BACnet device object of a remote BACnet server has been added under a local BACnet client. Local client and remote server are linked via BACnet. Any number of clients can be linked via BACnet adapter. See FB_BACnet_Adapter and FB_BACnet_RemoteDevice for further information.


FB_BACnet_RemoteBinaryValue

The following function block is used for linking a remote BACnet object of the local BACnet client. The function block for the corresponding BACnet object is linked with the aid of process data. The data exchange with the remote BACnet server takes place via BACnet with the aid of WOC (Write-On-Change) and COV (Changes-On-Value) or via polling (not recommended).

The process data can be created manually in the BACnet object, linked manually, or they can be generated automatically via PLC automapping. The comments required for PLC automapping ( (* ~ (BACnet... | ??? | ??? ) *) ) are already included in the declaration of the function block.

Use

The function block "FB_BACnet_RemoteBinaryValue" can be used for read and write access to a remote BACnet object of type BinaryValue (BV). To this end the remote BACnet object was added to a local BACnet client.

Fig. 1: Example for a remote BACnet object under a local BACnet client.

VAR_INPUT

Name             : Type
bEnablePV        : BOOL;
bPV              : E_BACnetBinaryPV;

bEnablePV: Enables the value of input "bPV". When the input is set to TRUE, an entry is made in the Priority_Array of the corresponding BACnet object with the value of input "bPV". This corresponds to a write access to the commandable property Present_Value with the set priority (default: 12 when PLC automapping is used or 16 for manual linking in the System Manager).
If bEnablePV is set to FALSE, the corresponding entry from the Priority_Array is removed again (write ZERO).

bPV: Value to be written to the Priority_Array of the commandable property Present_Value. The priority is based on the process data configuration and mapping of the BACnet object in the System Manager (see also Figs. 2 and 3). Writing is enabled by setting the input "bEnablePV" to TRUE. Writing of the process data to the local client always takes place cyclically. After enabling via bEnablePV the data are sent via BACnet to the remote server either cyclically (Periodic Write) or when changes occur (Write On Change - recommended).

Fig. 2: Example of a BACnet object with process data for writing the commandable property Present_Value. | Fig. 3: Example for a process data configuration of an BACnet object in the System Manager. Priority 12 is created as a mappable process data (see result in Fig. 2).

VAR_OUTPUT

Note: Variables shown in grey italics are only available in the extended version of the block. The extended versions of the blocks end with "_EX". They offer substantially more process data, although in projects with a large number of objects this may have performance implications.

Name             : Type
bReady           : BOOL;
bPresentValue    : BOOL;
bOverridden      : BOOL;
bOutOfService    : BOOL;
bFault           : BOOL;
bInAlarm         : BOOL;
bOtherFault      : BOOL;
eEventState      : E_BACnetEventState;
nActivePrio      : UINT;
bError           : BOOL;
nErrorId         : UINT;

bReady: Notification of general readiness. If this output is set, the other status outputs are valid (PresentValue, Overridden ...). If the output is FALSE, the corresponding function block "FB_BACnet_RemoteDevice" reports "not operational", the block instances was not linked correctly in the System Manager or the remote server cannot be reached (gateway cannot be reached, no Ethernet link).

bPresentValue: Current value of the BACnet object (see also BACnet specification DIN EN ISO 16484-5 for BACnet object BinaryOutput and property Present_Value).

bOverridden, bOutOfService, bFault, bInAlarm: See BACnet specification DIN EN ISO 16484-5 for BACnet object BinaryValue and property Status_Flags.

bOtherFault: See BACnet specification DIN EN ISO 16484-5 for BACnet object BinaryValue and property Reliability.

eEventState: See BACnet specification DIN EN ISO 16484-5 for BACnet object BinaryValue and property Event_State.

nActivePrio: Indicates the currently active priority of the priority array, which acts on the Present_Value (see also BACnet specification DIN EN ISO 16484-5 for BACnet object BinaryValue and property Present_Value).

bError: An error is pending.

nErrorId: Error number
0 = no error
1 = function block of the corresponding client (RemoteDevice) is not called or not called regularly enough from the PLC program.
2 = incorrect process data mapping detected (check mapping in the System Manager; if necessary compile complete PLC project and reload)
3 = the corresponding BACnet client is not ready (bOperational = FALSE at instance of the FB_BACnet_RemoteDevice)
The error numbers can be queried as block constants via the FB instance (FB_BACnet_Remote???.nERR_xxx).

VAR_IN_OUT

Name             : Type
RemoteDevice     : FB_BACnet_RemoteDevice;

RemoteDevice: Block instance of the corresponding remote BACnet device object. The remote BACnet device object of a remote BACnet server has been added under a local BACnet client. Local client and remote server are linked via BACnet. Any number of clients can be linked via BACnet adapter. See FB_BACnet_Adapter and FB_BACnet_RemoteDevice for further information.


FB_BACnet_RemoteCalendar

The following function block is used for linking a remote BACnet object of the local BACnet client. The function block for the corresponding BACnet object is linked with the aid of process data. The data exchange with the remote BACnet server takes place via BACnet with the aid of WOC (Write-On-Change) and COV (Changes-On-Value) or via polling (not recommended).

The process data can be created manually in the BACnet object, linked manually, or they can be generated automatically via PLC automapping. The comments required for PLC automapping ( (* ~ (BACnet... | ??? | ??? ) *) ) are already included in the declaration of the function block.

Use

The function block "FB_BACnet_RemoteCalendar" can be used for read access to a remote BACnet object of type Calendar (CAL). To this end the remote BACnet object was added to a local BACnet client.

Fig. 1: Example for a remote BACnet object under a local BACnet client.

VAR_OUTPUT

Name             : Type
bReady           : BOOL;
bPresentValue    : BOOL;
bError           : BOOL;
nErrorId         : UINT;

bReady: Notification of general readiness. If this output is set, the other status outputs are valid (PresentValue). If the output is FALSE, the associated function block "FB_BACnet_RemoteDevice" reports "not operational".

bPresentValue: Current value of the BACnet object (see also BACnet specification DIN EN ISO 16484-5 for BACnet object Calendar and property Present_Value).

bError: An error is pending.

nErrorId: Error number
0 = no error
1 = function block of the corresponding client (RemoteDevice) is not called or not called regularly enough from the PLC program.
3 = the corresponding BACnet client is not ready (bOperational = FALSE at instance of the FB_BACnet_RemoteDevice)
The error numbers can be queried as block constants via the FB instance (FB_BACnet_Remote???.nERR_xxx).

VAR_IN_OUT

Name             : Type
RemoteDevice     : FB_BACnet_RemoteDevice;

RemoteDevice: Block instance of the corresponding remote BACnet device object. The remote BACnet device object of a remote BACnet server has been added under a local BACnet client. Local client and remote server are linked via BACnet. Any number of clients can be linked via BACnet adapter. See FB_BACnet_Adapter and FB_BACnet_RemoteDevice for further information.


FB_BACnet_RemoteCommand

The following function block is used for linking a remote BACnet object of the local BACnet client. The function block for the corresponding BACnet object is linked with the aid of process data. The data exchange with the remote BACnet server takes place via BACnet with the aid of WOC (Write-On-Change) and COV (Changes-On-Value) or via polling (not recommended).

The process data can be created manually in the BACnet object, linked manually, or they can be generated automatically via PLC automapping. The comments required for PLC automapping ( (* ~ (BACnet... | ??? | ??? ) *) ) are already included in the declaration of the function block.

Use

The function block "FB_BACnet_RemoteCommand" can be used for read and write access to a remote BACnet object of type Command (CMD). To this end the remote BACnet object was added to a local BACnet client.

Fig. 1: Example for a remote BACnet object under a local BACnet client.

VAR_INPUT

Name             : Type
bEnablePV        : BOOL;
nPV              : UDINT;
bRetrigger       : BOOL;

bEnablePV: Enables the value of input nPV. When the input is set to TRUE, writing takes place into the property Present_Value of the corresponding BACnet object with the value of input nPV.
If bEnablePV is set to FALSE, the process data of the mapped property Present_Value are written to 16#FFFFFFFF and thus deactivated.

nPV: Value of the property Present_Value to be written. If the value is outside the value range (see BACnet specification DIN EN ISO 16484-5 for BACnet object Command and property Present_Value), the corresponding process data is disabled, i.e. writing to the property is disabled and other BACnet services have write access to the property Present_Value.
Writing of a valid value triggers execution of the corresponding command list of the BACnet object. The value of the property Present_Value is written whenever the process data changes (i.e. change in the value of nPV with bEnablePV set or signal change from FALSE to TRUE at input bRetrigger with bEnablePV set).

bRetrigger: A rising edge at this input triggers a repeat of the write process and therefore execution of the corresponding commands of the BACnet object Command. The signal change from FALSE to TRUE corresponds to a change of the process data of the property Present_Value from x to 0 to x.

VAR_OUTPUT

Name             : Type
bReady           : BOOL;
nPresentValue    : UDINT;
bAllWritesOk     : BOOL;
bInProcess       : BOOL;
bError           : BOOL;
nErrorId         : UINT;

bReady: Notification of general readiness. If this output is set, the other status outputs are valid (PresentValue, AllWritesOk, InProcess). If the output is FALSE, the associated function block "FB_BACnet_RemoteDevice" reports "not operational".

nPresentValue: Current value of the BACnet object (see also BACnet specification DIN EN ISO 16484-5 for BACnet object Command and property Present_Value).

bAllWritesOk: The last requested command list was successfully processed (see also BACnet specification DIN EN ISO 16484-5 for BACnet object Command and property All_Writes_Successful).

bInProcess: The selected command list is processed (see also BACnet specification DIN EN ISO 16484-5 for BACnet object Command and property In_Process).

bError: An error is pending.

nErrorId: Error number
0 = no error
1 = function block of the corresponding client (RemoteDevice) is not called or not called regularly enough from the PLC program.
3 = the corresponding BACnet client is not ready (bOperational = FALSE at instance of the FB_BACnet_RemoteDevice)
The error numbers can be queried as block constants via the FB instance (FB_BACnet_Remote???.nERR_xxx).

VAR_IN_OUT

Name             : Type
RemoteDevice     : FB_BACnet_RemoteDevice;

RemoteDevice: Block instance of the corresponding remote BACnet device object. The remote BACnet device object of a remote BACnet server has been added under a local BACnet client. Local client and remote server are linked via BACnet. Any number of clients can be linked via BACnet adapter. See FB_BACnet_Adapter and FB_BACnet_RemoteDevice for further information.


FB_BACnet_RemoteEventEnrollment

The following function block is used for linking a remote BACnet object of the local BACnet client. The function block for the corresponding BACnet object is linked with the aid of process data. The data exchange with the remote BACnet server takes place via BACnet with the aid of WOC (Write-On-Change) and COV (Changes-On-Value) or via polling (not recommended).

The process data can be created manually in the BACnet object, linked manually, or they can be generated automatically via PLC automapping. The comments required for PLC automapping ( (* ~ (BACnet... | ??? | ??? ) *) ) are already included in the declaration of the function block.

Use

The function block "FB_BACnet_RemoteEventEnrollment" serves as placeholder for future functions.

VAR_OUTPUT

      Name             : Type

bReady           : BOOL;
bError           : BOOL;
nErrorId         : UINT;

bReady: Notification of general readiness. If the output is FALSE, the associated function block FB_BACnet_RemoteDevice reports "not operational".

bError: An error is pending.

nErrorId: Error number
0 = no error
1 = function block of the corresponding client (RemoteDevice) is not called or not called regularly enough from the PLC program.
3 = the corresponding BACnet client is not ready (bOperational = FALSE at instance of the FB_BACnet_RemoteDevice)
The error numbers can be queried as block constants via the FB instance (FB_BACnet_Remote???.nERR_xxx).

VAR_IN_OUT

      Name             : Type

RemoteDevice     : FB_BACnet_RemoteDevice;

RemoteDevice: Block instance of the corresponding remote BACnet device object. The remote BACnet device object of a remote BACnet server has been added under a local BACnet client. Local client and remote server are linked via BACnet. Any number of clients can be linked via BACnet adapter. See FB_BACnet_Adapter and FB_BACnet_RemoteDevice for further information.


FB_BACnet_RemoteFile

The following function block is used for linking a remote BACnet object of the local BACnet client. The function block for the corresponding BACnet object is linked with the aid of process data. The data exchange with the remote BACnet server takes place via BACnet with the aid of WOC (Write-On-Change) and COV (Changes-On-Value) or via polling (not recommended).

The process data can be created manually in the BACnet object, linked manually, or they can be generated automatically via PLC automapping. The comments required for PLC automapping ( (* ~ (BACnet... | ??? | ??? ) *) ) are already included in the declaration of the function block.

Use

The function block "FB_BACnet_RemoteFile" can be used for read access to a remote BACnet object of type File (FILE). To this end the remote BACnet object was added to a local BACnet client.

Fig. 1: Example for a remote BACnet object under a local BACnet client.

VAR_OUTPUT

Name             : Type
bReady           : BOOL;
bPresentValue    : BOOL;
bError           : BOOL;
nErrorId         : UINT;

bReady: Notification of general readiness. If this output is set, the other status outputs are valid (PresentValue). If the output is FALSE, the associated function block "FB_BACnet_RemoteDevice" reports "not operational".

bPresentValue: Current value of the BACnet object (see also BACnet specification DIN EN ISO 16484-5 for BACnet object File and property Present_Value).

bError: An error is pending.

nErrorId: Error number
0 = no error
1 = function block of the corresponding client (RemoteDevice) is not called or not called regularly enough from the PLC program.
3 = the corresponding BACnet client is not ready (bOperational = FALSE at instance of the FB_BACnet_RemoteDevice)
The error numbers can be queried as block constants via the FB instance (FB_BACnet_Remote???.nERR_xxx).

VAR_IN_OUT

Name             : Type
RemoteDevice     : FB_BACnet_RemoteDevice;

RemoteDevice: Block instance of the corresponding remote BACnet device object. The remote BACnet device object of a remote BACnet server has been added under a local BACnet client. Local client and remote server are linked via BACnet. Any number of clients can be linked via BACnet adapter. See FB_BACnet_Adapter and FB_BACnet_RemoteDevice for further information.


FB_BACnet_RemoteGroup

The following function block is used for linking a remote BACnet object of the local BACnet client. The function block for the corresponding BACnet object is linked with the aid of process data. The data exchange with the remote BACnet server takes place via BACnet with the aid of WOC (Write-On-Change) and COV (Changes-On-Value) or via polling (not recommended).

The process data can be created manually in the BACnet object, linked manually, or they can be generated automatically via PLC automapping. The comments required for PLC automapping ( (* ~ (BACnet... | ??? | ??? ) *) ) are already included in the declaration of the function block.

Use

The function block "FB_BACnet_RemoteGroup" serves as placeholder for future functions.

VAR_OUTPUT

      Name             : Type

bReady           : BOOL;
bError           : BOOL;
nErrorId         : UINT;

bReady: Notification of general readiness. If the output is FALSE, the associated function block FB_BACnet_RemoteDevice reports "not operational".

bError: An error is pending.

nErrorId: Error number
0 = no error
1 = function block of the corresponding client (RemoteDevice) is not called or not called regularly enough from the PLC program.
3 = the corresponding BACnet client is not ready (bOperational = FALSE at instance of the FB_BACnet_RemoteDevice)
The error numbers can be queried as block constants via the FB instance (FB_BACnet_Remote???.nERR_xxx).

VAR_IN_OUT

      Name             : Type

RemoteDevice     : FB_BACnet_RemoteDevice;

RemoteDevice: Block instance of the corresponding remote BACnet device object. The remote BACnet device object of a remote BACnet server has been added under a local BACnet client. Local client and remote server are linked via BACnet. Any number of clients can be linked via BACnet adapter. See FB_BACnet_Adapter and FB_BACnet_RemoteDevice for further information.


FB_BACnet_RemoteLoop

The following function block is used for linking a remote BACnet object of the local BACnet client. The function block for the corresponding BACnet object is linked with the aid of process data. The data exchange with the remote BACnet server takes place via BACnet with the aid of WOC (Write-On-Change) and COV (Changes-On-Value) or via polling (not recommended).

The process data can be created manually in the BACnet object, linked manually, or they can be generated automatically via PLC automapping. The comments required for PLC automapping ( (* ~ (BACnet... | ??? | ??? ) *) ) are already included in the declaration of the function block.

Use

The function block "FB_BACnet_RemoteLoop" can be used for read access to a remote BACnet object of type Loop (LOOP). To this end the remote BACnet object was added to a local BACnet client.

Fig. 1: Example for a remote BACnet object under a local BACnet client.

VAR_OUTPUT

Note: Variables shown in grey italics are only available in the extended version of the block. The extended versions of the blocks end with "_EX". They offer substantially more process data, although in projects with a large number of objects this may have performance implications.

Name             : Type
bReady           : BOOL;
fControlledValue : REAL;
fPresentValue    : REAL;
bOverridden      : BOOL;
bOutOfService    : BOOL;
bFault           : BOOL;
bInAlarm         : BOOL;
bOpenLoop        : BOOL;
bOtherFault      : BOOL;
eEventState      : E_BACnetEventState;
bError           : BOOL;
nErrorId         : UINT;

bReady: Notification of general readiness. If this output is set, the other status outputs are valid (PresentValue, Overridden ...). If the output is FALSE, the corresponding function block "FB_BACnet_RemoteDevice" reports "not operational", the block instances was not linked correctly in the System Manager or the remote server cannot be reached (gateway cannot be reached, no Ethernet link).

fControlledValue: Feedback of the current process parameter (X, actual value).

fPresentValue: Feedback of the current control output (Y, control value). Attention: Present_Value and Controller_Variable_Value can easily lead to confusion (see also BACnet specification DIN EN ISO 16484-5 for BACnet object Loop and properties Present_Value, Controlled_Variable_Value and Controlled_Variable_Reference).

fPropBand: Feedback of the current control output in percent (-100%...+100%) in relation to the minimum and maximum control output (properties Minimum_Output and Maximum_Output).

eEventState: See BACnet specification DIN EN ISO 16484-5 for BACnet object Loop and property Event_State.

bOverridden, bOutOfService, bFault, bInAlarm: See BACnet specification DIN EN ISO 16484-5 for BACnet object Loop and property Status_Flags.

bOpenLoop, bOtherFault: See BACnet specification DIN EN ISO 16484-5 for BACnet object Loop and property Reliability.

bError: An error is pending.

nErrorId: Error number
0 = no error
1 = function block of the corresponding client (RemoteDevice) is not called or not called regularly enough from the PLC program.
2 = incorrect process data mapping detected (check mapping in the System Manager; if necessary compile complete PLC project and reload)
3 = the corresponding BACnet client is not ready (bOperational = FALSE at instance of the FB_BACnet_RemoteDevice)
The error numbers can be queried as block constants via the FB instance (FB_BACnet_Remote???.nERR_xxx).

VAR_IN_OUT

Name             : Type
RemoteDevice     : FB_BACnet_RemoteDevice;

RemoteDevice: Block instance of the corresponding remote BACnet device object. The remote BACnet device object of a remote BACnet server has been added under a local BACnet client. Local client and remote server are linked via BACnet. Any number of clients can be linked via BACnet adapter. See FB_BACnet_Adapter and FB_BACnet_RemoteDevice for further information.

Controller configuration

The controller is configured using the following BACnet properties: Action, Proportional_Constant (P-factor), Integral_Constant (I-factor), Derivative_Constant (D-factor), Bias (output offset), Maximum_Output (maximum control output) and Minimum_Output (minimum control output). See BACnet specification DIN EN ISO 16484-5 for BACnet object Loop.


FB_BACnet_RemoteMultiStateInput

The following function block is used for linking a remote BACnet object of the local BACnet client. The function block for the corresponding BACnet object is linked with the aid of process data. The data exchange with the remote BACnet server takes place via BACnet with the aid of WOC (Write-On-Change) and COV (Changes-On-Value) or via polling (not recommended).

The process data can be created manually in the BACnet object, linked manually, or they can be generated automatically via PLC automapping. The comments required for PLC automapping ( (* ~ (BACnet... | ??? | ??? ) *) ) are already included in the declaration of the function block.

Use

The function block "FB_BACnet_RemoteMultiStateInput" can be used for read access to a remote BACnet object of type MultiStateInput (MI). To this end the remote BACnet object was added to a local BACnet client.

Fig. 1: Example for a remote BACnet object under a local BACnet client.

VAR_OUTPUT

Note: Variables shown in grey italics are only available in the extended version of the block. The extended versions of the blocks end with "_EX". They offer substantially more process data, although in projects with a large number of objects this may have performance implications.

Name             : Type
bReady           : BOOL;
nPresentValue    : UDINT;
bOverridden      : BOOL;
bOutOfService    : BOOL;
bFault           : BOOL;
bInAlarm         : BOOL;
bOverRange       : BOOL;
bUnderRange      : BOOL;
bNoSensor        : BOOL;
bOpenLoop        : BOOL;
bShortedLoop     : BOOL;
bMultiStateFault : BOOL;
bOtherFault      : BOOL;
eEventState      : E_BACnetEventState;
nNbrOfStates     : UDINT;
bError           : BOOL;
nErrorId         : UINT;

bReady: Notification of general readiness. If this output is set, the other status outputs are valid (PresentValue, Overridden ...). If the output is FALSE, the corresponding function block "FB_BACnet_RemoteDevice" reports "not operational", the block instances was not linked correctly in the System Manager or the remote server cannot be reached (gateway cannot be reached, no Ethernet link).

nPresentValue: Current value of the BACnet object (see also BACnet specification DIN EN ISO 16484-5 for BACnet object MultiStateInput and property Present_value).

bOverridden, bOutOfService, bFault, bInAlarm: See BACnet specification DIN EN ISO 16484-5 for BACnet object MultiStateInput and property Status_Flags.

bOverRange, bUnderRange, bNoSensor, bOpenLoop, bShortedLoop, bMultiStateFault, bOtherFault: See BACnet specification DIN EN ISO 16484-5 for BACnet object MultiStateInput and property Reliability.

eEventState: See BACnet specification DIN EN ISO 16484-5 for BACnet object MultiStateInput and property Event_State.

nNbrOfStates: Reports the available number of values, which the Present_Value of the MultiStateInput object can assume (1...nNbrOfStates). If "nNbrOfStates" is 0, then there is no valid "state" which the object can assume (Present_Value is 0).

bError: An error is pending.

nErrorId: Error number
0 = no error
1 = function block of the corresponding client (RemoteDevice) is not called or not called regularly enough from the PLC program.
2 = incorrect process data mapping detected (check mapping in the System Manager; if necessary compile complete PLC project and reload)
3 = the corresponding BACnet client is not ready (bOperational = FALSE at instance of the FB_BACnet_RemoteDevice)
The error numbers can be queried as block constants via the FB instance (FB_BACnet_Remote???.nERR_xxx).

VAR_IN_OUT

Name             : Type
RemoteDevice     : FB_BACnet_RemoteDevice;

RemoteDevice: Block instance of the corresponding remote BACnet device object. The remote BACnet device object of a remote BACnet server has been added under a local BACnet client. Local client and remote server are linked via BACnet. Any number of clients can be linked via BACnet adapter. See FB_BACnet_Adapter and FB_BACnet_RemoteDevice for further information.


FB_BACnet_RemoteMultiStateOutput

The following function block is used for linking a remote BACnet object of the local BACnet client. The function block for the corresponding BACnet object is linked with the aid of process data. The data exchange with the remote BACnet server takes place via BACnet with the aid of WOC (Write-On-Change) and COV (Changes-On-Value) or via polling (not recommended).

The process data can be created manually in the BACnet object, linked manually, or they can be generated automatically via PLC automapping. The comments required for PLC automapping ( (* ~ (BACnet... | ??? | ??? ) *) ) are already included in the declaration of the function block.

Use

The function block "FB_BACnet_RemoteMultiStateOutput" can be used for read and write access to a remote BACnet object of type MultiStateOutput (MO). To this end the remote BACnet object was added to a local BACnet client.

Fig. 1: Example for a remote BACnet object under a local BACnet client.

VAR_INPUT

Name             : Type
bEnablePV        : BOOL;
nPV              : UDINT;

bEnablePV: Enables the value of input nPV. When the input is set to TRUE, an entry is made in the Priority_Array of the corresponding BACnet object with the value of the input nPV. This corresponds to a write access to the commandable property Present_Value with the set priority (default: 12 when PLC automapping is used or 16 for manual linking in the System Manager).
If bEnablePV is set to FALSE, the corresponding entry from the Priority_Array is removed again (write ZERO).

nPV: Value to be written to the Priority_Array of the commandable property Present_Value. The priority is based on the process data configuration and mapping of the BACnet object in the System Manager (see also Figs. 2 and -3). Writing is enabled by setting the input bEnablePV to TRUE. Writing of the process data to the local client always takes place cyclically. After enabling via bEnablePV the data are sent via BACnet to the remote server either cyclically (Periodic Write) or when changes occur (Write On Change - recommended).

Fig. 2: Example of a BACnet object with process data for writing the commandable property Present_Value. | Fig. 3: Example for a process data configuration of an BACnet object in the System Manager. Priority 12 is created as a mappable process data (see result in Fig. 2).

VAR_OUTPUT

Note: Variables shown in grey italics are only available in the extended version of the block. The extended versions of the blocks end with "_EX". They offer substantially more process data, although in projects with a large number of objects this may have performance implications.

Name             : Type
bReady           : BOOL;
nPresentValue    : UDINT;
bOverridden      : BOOL;
bOutOfService    : BOOL;
bFault           : BOOL;
bInAlarm         : BOOL;
bNoOutput        : BOOL;
bOpenLoop        : BOOL;
bShortedLoop     : BOOL;
bOtherFault      : BOOL;
eEventState      : E_BACnetEventState;
nActivePrio      : UINT;
nNbrOfStates     : UDINT;
bError           : BOOL;
nErrorId         : UINT;

bReady: Notification of general readiness. If this output is set, the other status outputs are valid (PresentValue, Overridden ...). If the output is FALSE, the corresponding function block FB_BACnet_RemoteDevice reports "not operational", the block instances was not linked correctly in the System Manager or the remote server cannot be reached (gateway cannot be reached, no Ethernet link).

nPresentValue: Current value of the BACnet object (see also BACnet specification DIN EN ISO 16484-5 for BACnet object MultiStateOutput and property Present_value).

bOverridden, bOutOfService, bFault, bInAlarm: See BACnet specification DIN EN ISO 16484-5 for BACnet object MultiStateOutput and property Status_Flags.

bNoOutput, bOpenLoop, bShortedLoop, bOtherFault: See BACnet specification DIN EN ISO 16484-5 for BACnet object MultiStateOutput and property Reliability.

eEventState: See BACnet specification DIN EN ISO 16484-5 for BACnet object MultiStateOutput and property Event_State.

nActivePrio: Indicates the currently active priority of the priority array, which acts on the Present_Value (see also BACnet specification DIN EN ISO 16484-5 for BACnet object BinaryOutput and property Present_Value).

nNbrOfStates: Reports the available number of values, which the Present_Value of the MultiStateInput object can assume (1...nNbrOfStates). If nNbrOfStates is 0, then there is no valid "state" which the object can assume (Present_Value is 0).

bError: An error is pending.

nErrorId: Error number
0 = no error
1 = function block of the corresponding client (RemoteDevice) is not called or not called regularly enough from the PLC program.
2 = incorrect process data mapping detected (check mapping in the System Manager; if necessary compile complete PLC project and reload)
3 = the corresponding BACnet client is not ready (bOperational = FALSE at instance of the FB_BACnet_RemoteDevice)
The error numbers can be queried as block constants via the FB instance (FB_BACnet_Remote???.nERR_xxx).

VAR_IN_OUT

Name             : Type
RemoteDevice     : FB_BACnet_RemoteDevice;

RemoteDevice: Block instance of the corresponding remote BACnet device object. The remote BACnet device object of a remote BACnet server has been added under a local BACnet client. Local client and remote server are linked via BACnet. Any number of clients can be linked via BACnet adapter. See FB_BACnet_Adapter and FB_BACnet_RemoteDevice for further information.


FB_BACnet_RemoteMultiStateValue

The following function block is used for linking a remote BACnet object of the local BACnet client. The function block for the corresponding BACnet object is linked with the aid of process data. The data exchange with the remote BACnet server takes place via BACnet with the aid of WOC (Write-On-Change) and COV (Changes-On-Value) or via polling (not recommended).

The process data can be created manually in the BACnet object, linked manually, or they can be generated automatically via PLC automapping. The comments required for PLC automapping ( (* ~ (BACnet... | ??? | ??? ) *) ) are already included in the declaration of the function block.

Use

The function block "FB_BACnet_RemoteMultiStateValue" can be used for read and write access to a remote BACnet object of type MultiStateValue (MV). To this end the remote BACnet object was added to a local BACnet client.

Fig. 1: Example for a remote BACnet object under a local BACnet client.

VAR_INPUT

Name             : Type
bEnablePV        : BOOL;
nPV              : UDINT;

bEnablePV: Enables the value of input nPV. When the input is set to TRUE, an entry is made in the Priority_Array of the corresponding BACnet object with the value of the input nPV. This corresponds to a write access to the commandable property Present_Value with the set priority (default: 12 when PLC automapping is used or 16 for manual linking in the System Manager).
If bEnablePV is set to FALSE, the corresponding entry from the Priority_Array is removed again (write ZERO).

nPV: Value to be written to the Priority_Array of the commandable property Present_Value. The priority is based on the process data configuration and mapping of the BACnet object in the System Manager (see also Figs. 2 and -3). Writing is enabled by setting the input bEnablePV to TRUE. Writing of the process data to the local client always takes place cyclically. After enabling via bEnablePV the data are sent via BACnet to the remote server either cyclically (Periodic Write) or when changes occur (Write On Change - recommended).

Fig. 2: Example of a BACnet object with process data for writing the commandable property Present_Value. | Fig. 3: Example for a process data configuration of an BACnet object in the System Manager. Priority 12 is created as a mappable process data (see result in Fig. 2).

VAR_OUTPUT

Note: Variables shown in grey italics are only available in the extended version of the block. The extended versions of the blocks end with "_EX". They offer substantially more process data, although in projects with a large number of objects this may have performance implications.

Name             : Type
bReady           : BOOL;
nPresentValue    : UDINT;
bOverridden      : BOOL;
bOutOfService    : BOOL;
bFault           : BOOL;
bInAlarm         : BOOL;
bMultiStateFault : BOOL;
bOtherFault      : BOOL;
eEventState      : E_BACnetEventState;
nNbrOfStates     : UDINT;
bError           : BOOL;
nErrorId         : UINT;

bReady: Notification of general readiness. If this output is set, the other status outputs are valid (PresentValue, Overridden ...). If the output is FALSE, the corresponding function block "FB_BACnet_RemoteDevice" reports "not operational", the block instances was not linked correctly in the System Manager or the remote server cannot be reached (gateway cannot be reached, no Ethernet link).

nPresentValue: Current value of the BACnet object (see also BACnet specification DIN EN ISO 16484-5 for BACnet object MultiStateValue and property Present_value).

bOverridden, bOutOfService, bFault, bInAlarm: See BACnet specification DIN EN ISO 16484-5 for BACnet object MultiStateValue and property Status_Flags.

bMultiStateFault, bOtherFault: See BACnet specification DIN EN ISO 16484-5 for BACnet object MultiStateValue and property Reliability.

eEventState: See BACnet specification DIN EN ISO 16484-5 for BACnet object MultiStateValue and property Event_State.

nNbrOfStates: Reports the available number of values, which the Present_Value of the MultiStateValue object can assume (1...nNbrOfStates). If "nNbrOfStates" is 0, then there is no valid "state" which the object can assume (Present_Value is 0).

bError: An error is pending.

nErrorId: Error number
0 = no error
1 = function block of the corresponding client (RemoteDevice) is not called or not called regularly enough from the PLC program.
2 = incorrect process data mapping detected (check mapping in the System Manager; if necessary compile complete PLC project and reload)
3 = the corresponding BACnet client is not ready (bOperational = FALSE at instance of the FB_BACnet_RemoteDevice)
The error numbers can be queried as block constants via the FB instance (FB_BACnet_Remote???.nERR_xxx).

VAR_IN_OUT

Name             : Type
RemoteDevice     : FB_BACnet_RemoteDevice;

RemoteDevice: Block instance of the corresponding remote BACnet device object. The remote BACnet device object of a remote BACnet server has been added under a local BACnet client. Local client and remote server are linked via BACnet. Any number of clients can be linked via BACnet adapter. See FB_BACnet_Adapter and FB_BACnet_RemoteDevice for further information.


FB_BACnet_RemoteNotificationClass

The following function block is used for linking a remote BACnet object of the local BACnet client. The function block for the corresponding BACnet object is linked with the aid of process data. The data exchange with the remote BACnet server takes place via BACnet with the aid of WOC (Write-On-Change) and COV (Changes-On-Value) or via polling (not recommended).

The process data can be created manually in the BACnet object, linked manually, or they can be generated automatically via PLC automapping. The comments required for PLC automapping ( (* ~ (BACnet... | ??? | ??? ) *) ) are already included in the declaration of the function block.

Use

The function block "FB_BACnet_RemoteNotificationClass" serves as placeholder for future functions.

VAR_OUTPUT

      Name             : Type

bReady           : BOOL;
bError           : BOOL;
nErrorId         : UINT;

bReady: Notification of general readiness. If the output is FALSE, the associated function block FB_BACnet_RemoteDevice reports "not operational".

bError: An error is pending.

nErrorId: Error number
0 = no error
1 = function block of the corresponding client (RemoteDevice) is not called or not called regularly enough from the PLC program.
3 = the corresponding BACnet client is not ready (bOperational = FALSE at instance of the FB_BACnet_RemoteDevice)
The error numbers can be queried as block constants via the FB instance (FB_BACnet_Remote???.nERR_xxx).

VAR_IN_OUT

      Name             : Type

RemoteDevice     : FB_BACnet_RemoteDevice;

RemoteDevice: Block instance of the corresponding remote BACnet device object. The remote BACnet device object of a remote BACnet server has been added under a local BACnet client. Local client and remote server are linked via BACnet. Any number of clients can be linked via BACnet adapter. See FB_BACnet_Adapter and FB_BACnet_RemoteDevice for further information.


FB_BACnet_RemoteProgram

The following function block is used for linking a remote BACnet object of the local BACnet client. The function block for the corresponding BACnet object is linked with the aid of process data. The data exchange with the remote BACnet server takes place via BACnet with the aid of WOC (Write-On-Change) and COV (Changes-On-Value) or via polling (not recommended).

The process data can be created manually in the BACnet object, linked manually, or they can be generated automatically via PLC automapping. The comments required for PLC automapping ( (* ~ (BACnet... | ??? | ??? ) *) ) are already included in the declaration of the function block.

Use

The function block "FB_BACnet_RemoteProgram" can be used for read and write access to a remote BACnet object of type Program (PROG). To this end the remote BACnet object was added to a local BACnet client.

Fig. 1: Example for a remote BACnet object under a local BACnet client.

VAR_INPUT

Name             : Type
bEnablePV        : BOOL;
ePV              : E_BACnetProgramRequest;
bRetrigger       : BOOL; (* execute selected request on raising edge again *)

bEnablePV: Enables the value of input ePV. If the input is set to TRUE, the value of ePV is written to the property Program_Change of the object. If the input is set to FALSE, 0xFFFF is written to the process data of the property Program_Change of the object. The value 0xFFFF prevents writing to the remote server and therefore writing to the remote object.

ePV: Request to the remote program object. If bEnablePV was set to TRUE, the value of the input is written to the property Program_Change (see also Transition diagram).

bRetrigger: A change from FALSE to TRUE triggers writing of the input ePV to the property Program_Change, if input bEnablePV is set to TRUE.

VAR_OUTPUT

Note: Variables shown in grey italics are only available in the extended version of the block. The extended versions of the blocks end with "_EX". They offer substantially more process data, although in projects with a large number of objects this may have performance implications.

Name             : Type
bReady           : BOOL;
ePrgState        : E_BACnetProgramState;
ePrgChangeReq    : E_BACnetProgramRequest;
ePrgReasonHalt   : E_BACnetProgramError;
bOverridden      : BOOL;
bOutOfService    : BOOL;
bFault           : BOOL;
bInAlarm         : BOOL;
bProcessError    : BOOL;bOtherFault      : BOOL;
bError           : BOOL;
nErrorId         : UINT;

bReady: Notification of general readiness. If this output is set, the other status outputs are valid (ProgramState, Overridden ...). If the output is FALSE, the corresponding function block FB_BACnet_RemoteDevice reports "not operational", the block instances was not linked correctly in the System Manager or the remote server cannot be reached (gateway cannot be reached, no Ethernet link).

ePrgState: Feedback of the current program state (see also Transition diagram).

ePrgChangeReq: Feedback on the state of the current program request (see also Transition diagram).

ePrgReasonHalt: Error feedback on program cancellation.

bOverridden, bOutOfService, bFault, bInAlarm: See BACnet specification DIN EN ISO 16484-5 for BACnet object Program and property Status_Flags.

bProcessError, bOtherFault: See BACnet specification DIN EN ISO 16484-5 for BACnet object Program and property Reliability.

bError: An error is pending.

nErrorId: Error number
0 = no error
1 = function block of the corresponding client (RemoteDevice) is not called or not called regularly enough from the PLC program.
2 = incorrect process data mapping detected (check mapping in the System Manager; if necessary compile complete PLC project and reload)
3 = the corresponding BACnet client is not ready (bOperational = FALSE at instance of the FB_BACnet_RemoteDevice)
The error numbers can be queried as block constants via the FB instance (FB_BACnet_Remote???.nERR_xxx).

VAR_IN_OUT

Name             : Type
RemoteDevice     : FB_BACnet_RemoteDevice;

RemoteDevice: Block instance of the corresponding remote BACnet device object. The remote BACnet device object of a remote BACnet server has been added under a local BACnet client. Local client and remote server are linked via BACnet. Any number of clients can be linked via BACnet adapter. See FB_BACnet_Adapter and FB_BACnet_RemoteDevice for further information.

Transition diagram

Fig. 2: from BACnet specification DIN EN ISO 16484-5 for BACnet object Program, Fig. 12-3 "State Transitions for the program object"


FB_BACnet_RemotePulseConverter

The following function block is used for linking a remote BACnet object of the local BACnet client. The function block for the corresponding BACnet object is linked with the aid of process data. The data exchange with the remote BACnet server takes place via BACnet with the aid of WOC (Write-On-Change) and COV (Changes-On-Value) or via polling (not recommended).

The process data can be created manually in the BACnet object, linked manually, or they can be generated automatically via PLC automapping. The comments required for PLC automapping ( (* ~ (BACnet... | ??? | ??? ) *) ) are already included in the declaration of the function block.

Use

The function block "FB_BACnet_RemotePulseConverter" can be used for read access to a remote BACnet object of type PulseConverter (PC). To this end the remote BACnet object was added to a local BACnet client.

Fig. 1: Example for a remote BACnet object under a local BACnet client.

VAR_OUTPUT

Name             : Type
bReady           : BOOL;
bOverridden      : BOOL;
bOutOfService    : BOOL;
bFault           : BOOL;
bInAlarm         : BOOL;
bError           : BOOL;
nErrorId         : UINT;

bReady: Notification of general readiness. If this output is set, the other status outputs are valid (PresentValue, Overridden ...). If the output is FALSE, the corresponding function block FB_BACnet_RemoteDevice reports "not operational", the block instances was not linked correctly in the System Manager or the remote server cannot be reached (gateway cannot be reached, no Ethernet link).

bOverride, bOutOfService, bFault, bInAlarm: See BACnet specification DIN EN ISO 16484-5 for BACnet object PulseConverter and property Status_Flags.

bError: An error is pending.

nErrorId: Error number
0 = no error
1 = function block of the corresponding client (RemoteDevice) is not called or not called regularly enough from the PLC program.
2 = incorrect process data mapping detected (check mapping in the System Manager; if necessary compile complete PLC project and reload)
3 = the corresponding BACnet client is not ready (bOperational = FALSE at instance of the FB_BACnet_RemoteDevice)
The error numbers can be queried as block constants via the FB instance (FB_BACnet_Remote???.nERR_xxx).

VAR_IN_OUT

Name             : Type
RemoteDevice     : FB_BACnet_RemoteDevice;

RemoteDevice: Block instance of the corresponding remote BACnet device object. The remote BACnet device object of a remote BACnet server has been added under a local BACnet client. Local client and remote server are linked via BACnet. Any number of clients can be linked via BACnet adapter. See FB_BACnet_Adapter and FB_BACnet_RemoteDevice for further information.


FB_BACnet_RemoteSchedule

The following function block is used for linking a remote BACnet object of the local BACnet client. The function block for the corresponding BACnet object is linked with the aid of process data. The data exchange with the remote BACnet server takes place via BACnet with the aid of WOC (Write-On-Change) and COV (Changes-On-Value) or via polling (not recommended).

The process data can be created manually in the BACnet object, linked manually, or they can be generated automatically via PLC automapping. The comments required for PLC automapping ( (* ~ (BACnet... | ??? | ??? ) *) ) are already included in the declaration of the function block.

Use

The function block "FB_BACnet_RemoteSchedule" can be used for read access to a remote BACnet object of type Schedule (SCHED). To this end the remote BACnet object was added to a local BACnet client.

Fig. 1: Example for a remote BACnet object under a local BACnet client.

VAR_OUTPUT

Note: Variables shown in grey italics are only available in the extended version of the block. The extended versions of the blocks end with "_EX". They offer substantially more process data, although in projects with a large number of objects this may have performance implications.

Name             : Type
bReady           : BOOL;
bPresentValue    : BOOL;
bOverridden      : BOOL;
bOutOfService    : BOOL;
bFault           : BOOL;
bInAlarm         : BOOL;
bConfigError     : BOOL;
bOtherFault      : BOOL;
bError           : BOOL;
nErrorId         : UINT;

bReady: Notification of general readiness. If this output is set, the other status outputs are valid (PresentValue, Overridden ...). If the output is FALSE, the corresponding function block "FB_BACnet_RemoteDevice" reports "not operational", the block instances was not linked correctly in the System Manager or the remote server cannot be reached (gateway cannot be reached, no Ethernet link).

bPresentValue: Current value of the BACnet object (see also BACnet specification DIN EN ISO 16484-5 for BACnet object Schedule and property Present_Value). The state is specified in 3 stages (enumeration) (0 = INACTIVE, 1 = ACTIVE and 2 = ZERO).

bOverridden, bOutOfService, bFault, bInAlarm: See BACnet specification DIN EN ISO 16484-5 for BACnet object Schedule and property Status_Flags.

bConfigError, bOtherFault: See BACnet specification DIN EN ISO 16484-5 for BACnet object Schedule and property Reliability.

bError: An error is pending.

nErrorId: Error number
0 = no error
1 = function block of the corresponding client (RemoteDevice) is not called or not called regularly enough from the PLC program.
2 = incorrect process data mapping detected (check mapping in the System Manager; if necessary compile complete PLC project and reload)
3 = the corresponding BACnet client is not ready (bOperational = FALSE at instance of the FB_BACnet_RemoteDevice)
The error numbers can be queried as block constants via the FB instance (FB_BACnet_Remote???.nERR_xxx).

VAR_IN_OUT

Name             : Type
RemoteDevice     : FB_BACnet_RemoteDevice;

RemoteDevice: Block instance of the corresponding remote BACnet device object. The remote BACnet device object of a remote BACnet server has been added under a local BACnet client. Local client and remote server are linked via BACnet. Any number of clients can be linked via BACnet adapter. See FB_BACnet_Adapter and FB_BACnet_RemoteDevice for further information.


FB_BACnet_RemoteTrendLog

The following function block is used for linking a remote BACnet object of the local BACnet client. The function block for the corresponding BACnet object is linked with the aid of process data. The data exchange with the remote BACnet server takes place via BACnet with the aid of WOC (Write-On-Change) and COV (Changes-On-Value) or via polling (not recommended).

The process data can be created manually in the BACnet object, linked manually, or they can be generated automatically via PLC automapping. The comments required for PLC automapping ( (* ~ (BACnet... | ??? | ??? ) *) ) are already included in the declaration of the function block.

Use

The function block "FB_BACnet_RemoteTrendLog" can be used for read access to a remote BACnet object of type TrendLog (TREND). To this end the remote BACnet object was added to a local BACnet client.

Fig. 1: Example for a remote BACnet object under a local BACnet client.

VAR_OUTPUT

Note: Variables shown in grey italics are only available in the extended version of the block. The extended versions of the blocks end with "_EX". They offer substantially more process data, although in projects with a large number of objects this may have performance implications.

Name             : Type
bReady           : BOOL;
bLogEnable       : BOOL;
nRecordCount     : UDINT;
nTotalCount      : UDINT;
eEventState      : E_BACnetEventState;
bError           : BOOL;
nErrorId         : UINT;

bReady: Notification of general readiness. If this output is set, the other status outputs are valid (LogEnable, RecordCount...). If the output is FALSE, the corresponding function block FB_BACnet_RemoteDevice reports "not operational", the block instances was not linked correctly in the System Manager or the remote server cannot be reached (gateway cannot be reached, no Ethernet link).

bLogEnable: See BACnet specification DIN EN ISO 16484-5 for BACnet object TrendLog and property Log_Enable.

nRecordCount: See BACnet specification DIN EN ISO 16484-5 for BACnet object TrendLog and property Record_Count.

nTotalCount: See BACnet specification DIN EN ISO 16484-5 for BACnet object TrendLog and property Total_Record_Count.

eEventState: See BACnet specification DIN EN ISO 16484-5 for BACnet object TrendLog and property Event_State.

bError: An error is pending.

nErrorId: Error number
0 = no error
1 = function block of the corresponding client (RemoteDevice) is not called or not called regularly enough from the PLC program.
2 = incorrect process data mapping detected (check mapping in the System Manager; if necessary compile complete PLC project and reload)
3 = the corresponding BACnet client is not ready (bOperational = FALSE at instance of the FB_BACnet_RemoteDevice)
The error numbers can be queried as block constants via the FB instance (FB_BACnet_Remote???.nERR_xxx).

VAR_IN_OUT

Name             : Type
RemoteDevice     : FB_BACnet_RemoteDevice;

RemoteDevice: Block instance of the corresponding remote BACnet device object. The remote BACnet device object of a remote BACnet server has been added under a local BACnet client. Local client and remote server are linked via BACnet. Any number of clients can be linked via BACnet adapter. See FB_BACnet_Adapter and FB_BACnet_RemoteDevice for further information.


F_BACnet_GetObjId

Function for coding the object type and the object instance in the BACnet Object_Identifier.

VAR_INPUT

      Name             : Type

ObjectType       : E_BACnetObjectType;
ObjectInstance   : UDINT;

ObjectType: BACnet object type.

ObjectInstance: BACnet object number (instance, 0...4'194'303).

Return value is the resulting BACnet Object_Identifier.


F_BACnet_GetObjInstance

Function for decoding the BACnet Object_Identifier in the object instance (object number).

VAR_INPUT

      Name             : Type

nObjectId        : DWORD;

nObjectId: BACnet Object_Identifier.

Return value is the BACnet object number (instance, 0...4'194'303).


F_BACnet_GetObjType

Function for decoding the BACnet Object_Identifier in the object type.

VAR_INPUT

      Name             : Type

nObjectId        : DWORD;

nObjectId: BACnet Object_Identifier.

Return value is the resulting BACnet object type (see E_BACnetObjectType).


F_BACnet_IsFinite

Function for checking a floating-point number for finite value range.

VAR_INPUT

      Name             : Type

fValue           : REAL;

fValue: Floating-point number to be checked.

Return value: TRUE = value is within the finite value range, FALSE = number infinitely positive or infinitely negative.


F_BACnet_NAN

Function returns the floating-point value "Not ANumber". This can be used for deleting priority entries in the Priority_Array of an Analog_Value or Analog_Output object.

Return value: "Not a number" or #QNAN (0x7FFF0000).


F_BACnet_RealEQ

Function for comparing two floating-point values taking into account the value range. This function should be used instead of the standard operators ("=" or "EQ") for values from BACnet, since otherwise a PLC stop is triggered if the values to be compared are not in the finite range.

VAR_INPUT

      Name             : Type

fIn1             : REAL;
fIn2             : REAL;

Return value: TRUE = value 1 and value 2 are identical or both are not in the finite value range. FALSE = value 1 and value 2 differ.


F_BACnet_RealGE

Function for comparing two floating-point values taking into account the value range. This function should be used instead of the standard operators (">" or "GE") for values from BACnet, since otherwise a PLC stop is triggered if the values to be compared are not in the finite range.

VAR_INPUT

      Name             : Type

fIn1             : REAL;
fIn2             : REAL;

Return value: TRUE = value 1 is equal or greater than value 2. FALSE = value 2 is smaller than value 1, or one of the two values is not in the finite value range.


F_BACnet_RealGT

Function for comparing two floating-point values taking into account the value range. This function should be used instead of the standard operators (">" or "GT") for values from BACnet, since otherwise a PLC stop is triggered if the values to be compared are not in the finite range.

VAR_INPUT

      Name             : Type

fIn1             : REAL;
fIn2             : REAL;

Return value: TRUE = value 1 is greater than value 2. FALSE = value 2 is smaller or equal value 1, or one of the two values is not in the finite value range.


F_BACnet_RealLE

Function for comparing two floating-point values taking into account the value range. This function should be used instead of the standard operators ("<" or "LE") for values from BACnet, since otherwise a PLC stop is triggered if the values to be compared are not in the finite range.

VAR_INPUT

      Name             : Type

fIn1             : REAL;
fIn2             : REAL;

Return value: TRUE = value 1 is smaller or equal value 2. FALSE = value 2 is greater than value 1, or one of the two values is not in the finite value range.


F_BACnet_RealLT

Function for comparing two floating-point values taking into account the value range. This function should be used instead of the standard operators ("<" or "LT") for values from BACnet, since otherwise a PLC stop is triggered if the values to be compared are not in the finite range.

VAR_INPUT

      Name             : Type

fIn1             : REAL;
fIn2             : REAL;

Return value: TRUE = value 1 is smaller than value 2. FALSE = value 2 is greater or equal value 1, or one of the two values is not in the finite value range.


F_BACnet_RealToStr

Function for converting a floating-point number to a string, taking into account the value range.

VAR_INPUT

      Name             : Type

pValue           : POINTER TO REAL;

pValue: Pointer to the floating-point number to be converted ("ADR()").

Return value: For a finite value range the string from the floating-point number is output in the same format as after conversion with "REAL_TO_STRING()". If the value is in the infinite range, "#QNAN" (positive infinite) or "-#QNAN" (negative infinite) is output, depending on the sign.

Example

Fig. 1: Example for pointer determination with "ADR()". "fValue" represents a variable of type REAL.


FB_BACnet_GetDiagInfo

Function block for access to BACnet diagnosis via ADS.

Use

The block instance is created by the PLC program and called cyclically.

The required NetID (AMS NetID) of the BACnet device can be read in the System Manager (see Fig. 1, Note: The NetID does not match the local NetID and always has to be specified - empty strings cannot be used!). Another possibility is to query the NetID from the device block or adapter block in the PLC (see Fig. 2).

Fig. 1: AMS NetID of the BACnet device

For information on the operating principle of the adapter block see FB_BACnet_Adapter.

Fig. 2: AMS NetID of the BACnet device

VAR_INPUT

Name             : Type
sNetId           : T_AmsNetId;
bExecute         : BOOL;
tTimeout         : TIME := tBACnet_ADSTimeOut;

sNetId: AMS NetID of the BACnet device (adapter) under which the server or client was configured.

bExecute: Rising edge at the input starts the read process.

tTimeout: Optional input, monitoring time for ADS access (default: tBACnet_ADSTimeOut).

VAR_OUTPUT

Name             : Type
bBusy            : BOOL;
bError           : BOOL;
nErrID           : UDINT;
stInfo           : ST_BACnet_Diagnosis;

bBusy: The block is busy.

bError: Error during processing.

nErrID: ADS error code.

stInfo: Structure with diagnostic information on BACnet.

Example

Fig. 3: Example for cyclic reading of the diagnostic information


FB_BACnet_NotificationSinkDelEntry

Function block for deleting entries from the "notification sink" via ADS.

Use

The block instance is created by the PLC program and called cyclically. The input nPort is assigned with the ADS port from the System Manager configuration (see Fig. 1). Ports may vary, depending on the configuration.

The block can be used to delete entries from anywhere in the "notification sink". If all entries were removed or the specified index is greater than the number of list entries, then block returns bEmpty.

Fig. 1: ADS port in the System Manager

The required NetID (AMS NetID) of the BACnet device can be read in the System Manager (see Fig. 2, Note: The NetID does not match the local NetID and always has to be specified - empty strings cannot be used!). Another possibility is to query the NetID from the device block or adapter block in the PLC (see Fig. 3).

Fig. 2: AMS NetID of the BACnet device

For information on the operating principle of the adapter block see FB_BACnet_Adapter.

Fig. 3: AMS NetID of the BACnet device

VAR_INPUT

Name             : Type
bExecute         : BOOL;
nIndex           : UDINT;
sNetId           : T_AmsNetId;
nPort            : T_AmsPort;
tTimeout         : TIME := tBACnet_ADSTimeOut;

bExecute: Rising edge at the input starts the read process.

nIndex: Index of the entry to be deleted (0 ... n-1).

sNetId: AMS NetID of the BACnet device (adapter) under which the server or client was configured.

nPort: ADS port under which the "notification sink" was created (see also under Use).

tTimeout: Optional input, monitoring time for ADS access (default: tBACnet_ADSTimeOut).

VAR_OUTPUT

Name             : Type
bBusy            : BOOL;
bEmpty           : BOOL;
bError           : BOOL;
nErrorId         : UDINT;

bBusy: The block is busy.

bEmpty: Is set, if an attempt is made to delete a non-existing entry. Note: Once the last entry (index 0) has been deleted, the bEmpty message is only sent if another attempt is made to delete an entry (index 0) from the empty list.

bError: Error during processing.

nErrorId: ADS error code.

Example

Fig. 4: Example for deleting the whole "notification sink" under port 1004. If the bit "bClearList" is set, deleting of entry "0" is repeated until the block reports bEmpty. The bit "bClearList" is then reset automatically.


FB_BACnet_PidControl

PID controller block in parallel configuration (Kp has no effect on I and D component). The controller block serve as a basis for the object "LOOP" (FB_BACnet_Loop).

Block diagram

Use

The controller block must be called cyclically in the PLC program. Please ensure that the cycle time of the call at input fCtrlCycleTime is transferred as precisely as possible. The cycle time can be determined from the global structure "SystemTaskInfoArr", for example. A possible controller configuration is presented under Example.

VAR_INPUT

      Name             : Type

fSetpoint        : REAL; (* setpoint value *)
fPresentValue    : REAL; (* actual value *)
bReset           : BOOL; (* reset flag *)
fCtrlCycleTime   : REAL; (* controller cycle time in seconds [s] *)
fBias            : REAL; (* bias also active when reset is set to 1 *)
fKp              : REAL; (* proportional gain Kp (P) *)
fKi              : REAL; (* integral gain Ki (I) *)
fKd              : REAL; (* derivative gain Kd (D) *)
fMaxOutput       : REAL;
fMinOutput       : REAL;

fSetpoint: Set value input (e.g. temperature specification for a room in [°C])

fPresentValue: Actual value (e.g. actual room temperature in [°C])

bReset: Resets the controller, the output is set to fBias set for the duration and limited through fMaxOutput and fMinOutput. Note: If fMinOutput is set to 5% and fBias to 0%, for example, the output fY is set to 5% for the duration of the reset.

fCtrlCycleTime: Cycle time with which the controller is called in seconds [s].

fBias: Output offset. This value is offset with the output. The unit must match the unit of the control value (e.g. heating capacity in [%]).

fKp: Gain factor P. The control deviation is multiplied with P and added to the output (output behaves proportional to the input deviation).

fKi: Integral gain I. The control deviation is multiplied with I (taking into account the cycle time), added to the previous result and added to the output (High control deviation = fast increasing output).

fKd: Differential gain D. The control deviation is offset with the previous controller difference, the result multiplied with D (taking into account the cycle time) and added to the output (strong controller variation = strong response).

fMaxOutput : Upper limitation of the output value fY. The unit must match the unit of the control value (e.g. heating capacity maximum 90%).

fMinOutput : Lower limitation of the output value fY. The unit must match the unit of the control value (e.g. heating capacity minimum 5%).

VAR_OUTPUT

      Name             : Type

fY               : REAL; (* controller output command *)
nErrorStatus     : UINT; (* controller error output (0: no error; >0:error) *)

fY: Control value (e.g. heating capacity in [%]).

nErrorStatus: Error status (0 = no error, 1 = invalid parameters:, 2 = invalid cycle time). Error messages do not have to be acknowledged.

Example

Fig. 4: Application example
Note re. P = 10 --> a temperature difference of 1 K results in 10% heating capacity, for example
Note re. I = 0.01 --> a temperature difference of 1 K results in 0.01% heating output increase per second, for example
Note re. D = 0 --> no D component.


FB_BACnet_ReadProp

Function block for access to BACnet properties via ADS. All BACnet properties of server and client objects can be read or written via ADS. If a client is accessed via ADS, the ADS accesses are converted to "Read_Property" or "Read_Range" BACnet requests and sent to the remote server.

Use

The block instance is created by the PLC program and called cyclically. The input BACnetDevicePort is assigned with the ADS port from the System Manager configuration (see Fig. 1). Ports for servers and clients may vary, depending on the configuration.

Fig. 1: ADS port in the System Manager

The NetID (AMS NetID) of the BACnet device can also be read in the System Manager (see Fig. 2, Note: The NetID does not match the local NetID and always has to be specified - empty strings cannot be used!). Another possibility is to query the NetID from the device block or adapter block in the PLC (see Fig. 3).

Fig. 2: AMS NetID of the BACnet device

For information on the operating principle of the adapter block see FB_BACnet_Adapter.

Fig. 3: AMS NetID of the BACnet device

VAR_INPUT

Name             : Type
BACnetDevicePort : UINT := 16#FFFF;
bExecute         : BOOL;
sNetId           : T_AmsNetId;
ObjectType       : E_BACnetObjectType;
PropertyID       : E_BACnetPropertyIdentifier;
DataType         : E_BACnetDataTypes;
ObjectInstance   : DINT;
ptrValue         : POINTER TO BYTE;
nLenValue        : UDINT; (* byte size of value (SIZEOF) *)

BACnetDevicePort: ADS port under which the required object was created (see also under use).

bExecute: Rising edge at the input starts the read process. Falling edge deletes the output bDone.

sNetId: AMS NetID of the BACnet device (adapter) under which the server or client was configured.

ObjectType: Enumeration of the object type (AnalogValue, BinaryInput...).

PropertyID: Enumeration of the property ID (Present_Value, Status_Flags...).

ObjectInstance: Object number of the BACnet object (the lower 22 bits of the Object_Identifier).

ptrValue: Pointer to the variable in which the read data are to be stored (can be determined with ADR()).

nLenValue: Byte length of the variable in which the read data are to be stored (can be determined with SIZEOF()).

VAR_OUTPUT

Name             : Type
bDone            : BOOL;
bBusy            : BOOL;
bError           : BOOL;
nErrID           : UDINT;
nProcessedLen    : UDINT; (* the received data length (can be different to given length) *)

bDone: Read of the data completed successfully. bDone remains set until bExecute is reset. If bExecute is reset before bDone is active, bDone is set for one cycle.

bBusy: The block is busy.

bError: Error during processing.

nErrID: ADS error code.

nProcessedLen: Byte length of the read data. The length may differ from the target length nLenValue (smaller/equal).

Example

Fig. 4: Application example


FB_BACnet_WriteProp

Function block for access to BACnet properties via ADS. All BACnet properties of server and client objects can be read or written via ADS. If a client is accessed via ADS, the ADS accesses are converted to "Write_Property" BACnet requests and sent to the remote server.

Use

The block instance is created by the PLC program and called cyclically. The input BACnetDevicePort is assigned with the ADS port from the System Manager configuration (see Fig. 1). Ports for servers and clients may vary, depending on the configuration.

By using the WriteProp block for accessing the Present_Value, for example, WOC (Write On Change) to local BACnet server objects can be realised. In contrast to process data mapping the priority of the write access can be adjusted online. In addition, process data mapping to local server objects results in cyclic writing of the data, so that remote clients do not have access with the same priority as the local PLC.

Fig. 1: ADS port in the System Manager

The NetID (AMS NetID) of the BACnet device can also be read in the System Manager (see Fig. 2, Note: The NetID does not match the local NetID and always has to be specified - empty strings cannot be used!). Another possibility is to query the NetID from the device block or adapter block in the PLC (see Fig. 3).

Fig. 2: AMS NetID of the BACnet device

For information on the operating principle of the adapter block see FB_BACnet_Adapter.

Fig. 3: AMS NetID of the BACnet device

VAR_INPUT

Name             : Type
BACnetDevicePort : UINT := 16#FFFF;
bExecute         : BOOL;
sNetId           : T_AmsNetId;
ObjectType       : E_BACnetObjectType;
PropertyID       : E_BACnetPropertyIdentifier;
Priority         : E_BACnetPriority;
DataType         : E_BACnetDataTypes;
ObjectInstance   : UDINT;
ptrValue         : POINTER TO BYTE;
nLenValue        : UDINT; (* byte size of value (SIZEOF) *)

BACnetDevicePort: ADS port under which the required object was created (see also under use).

bExecute: Rising edge at the input starts the read process. Falling edge deletes the output bDone.

sNetId: AMS NetID of the BACnet device (adapter) under which the server or client was configured.

ObjectType: Enumeration of the object type (AnalogValue, BinaryInput...).

PropertyID: Enumeration of the property ID (Present_Value, Status_Flags...).

Priority: Enumeration of the write access priority. The priority is required for write accesses to prioritisable properties (e.g. Present_Value). Access with priority x then generates an entry at location x in the corresponding Priority_Array.

ObjectInstance: Object number of the BACnet object (the lower 22 bits of the Object_Identifier).

ptrValue: Pointer to the variable from which the data to be written are taken (can be determined with ADR()).

nLenValue: Byte length of the variable from which the data to be written are taken (can be determined with SIZEOF()).

VAR_OUTPUT

Name             : Type
bDone            : BOOL;
bBusy            : BOOL;
bError           : BOOL;
nErrID           : UDINT;

bDone: Writing of the data completed successfully. bDone remains set until bExecute is reset. If bExecute is reset before bDone is active, bDone is set for one cycle.

bBusy: The block is busy.

bError: Error during processing.

nErrID: ADS error code.

Example

Fig. 4: Application example

Fig. 5: Example for Write on Change (WOC)


FB_BACnet_Program

TS8020 | TwinCAT BACnet Supplement

ST_BACnet_Date

Structure with date information.

nYear        : BYTE; (* year minus 1900 X'FF' = unspecified *)
nMonth       : BYTE; (* (1.. 12) 1 = January X'FF' = unspecified *)
nDay         : BYTE; (* day OF month (1..31), X'FF' = unspecified *)
nDayOfWeek   : BYTE; (* day OF week (1..7) 1 = Monday -- 7 = Sunday -- X'FF' = unspecified *)

nYear: year number minus 1900 (0 ... 254 = 1900 ... 2154, 0xFF = not specified).

nMonth: month number (1...12, 1 = January, 0xFF = not specified).

nDay: day of the month (1...31, 0xFF = not specified).

nDayOfWeek: day of the week (1...7, 1 = Monday, 7 = Sunday, 0xFF = not specified).


FB_BACnet_Program

TS8020 | TwinCAT BACnet Supplement

ST_BACnet_DateTime

Structure with date/time information.

stDate : ST_BACnet_Date;
stTime : ST_BACnet_Time;


FB_BACnet_Program

TS8020 | TwinCAT BACnet Supplement

ST_BACnet_Diagnosis

Structure with information from the BACnet device adapter. Includes dynamic response, statistics for server and client and diagnostic information on network traffic.

ethDevice        : ST_BACnet_DiagEthStatistics;
execTiming       : ST_BACnet_DiagnosisTiming;
frameStatistics  : ST_BACnet_FrameStatistics;
nRes1            : DWORD;
info             : ST_BACnet_Info;
nRes2            : DWORD;
serverInfo       : ST_BACnet_ServerStatistics;
lastUpdate       : ST_BACnet_DateTime;
nRes3            : DWORD;

lastUpdate: Timestamp of the diagnostic data (time at which the data were read).


FB_BACnet_Program

TS8020 | TwinCAT BACnet Supplement

ST_BACnet_ConfirmedServiceDiag

Structure with information on confirmed BACnet services (confirmed).

nReqSend        : DWORD; (* ULONG *)
nReqSendFail    : DWORD; (* ULONG *)
nReqRecv        : DWORD; (* ULONG *)
nReqRecvFail    : DWORD; (* ULONG *)
nAckSend        : DWORD; (* ULONG *)
nAckSendFail    : DWORD; (* ULONG *)
nAckRecv        : DWORD; (* ULONG *)
nAckRecvFail    : DWORD; (* ULONG *)

nReqSend: Number of confirmed requests, including retries.

nReqSendFail: Number of failed requests (no acknowledgement received).

nReqRecv: Number of confirmed requests.

nReqRecvFail: Number of confirmed requests that could not be processed (no free memory, wrong coding etc.).

nAckSend: Number of sent acknowledgements).

nAckSendFail: Number of failed acknowledgements.

nAckRecv: Number of received acknowledgements.

nAckRecvFail: Number of faulty received acknowledgements (no free memory, wrong coding etc.).


FB_BACnet_Program

TS8020 | TwinCAT BACnet Supplement

ST_BACnet_DiagEthStatistics

Structure with information on the Ethernet adapter.

ethStat    : ST_BACnet_TcIoEthStatistic;
txRxErrCnt : ST_BACnet_TcIoEthTxRxErrorCount;


FB_BACnet_Program

TS8020 | TwinCAT BACnet Supplement

ST_BACnet_DiagnosisTiming

Structure with information on faulty network frames from the network driver.

msIoInCurExecutionTime    : DWORD; (* ULONG *)
msIoInMinExecutionTime    : DWORD; (* ULONG *)
msIoInMaxExecutionTime    : DWORD; (* ULONG *)
msIoOutCurExecutionTime   : DWORD; (* ULONG *)
msIoOutMinExecutionTime   : DWORD; (* ULONG *)
msIoOutMaxExecutionTime   : DWORD; (* ULONG *)
msCycleCurExecutionTime   : DWORD; (* ULONG *)
msCycleMinExecutionTime   : DWORD; (* ULONG *)
msCycleMaxExecutionTime   : DWORD; (* ULONG *)
msInputCurDistanceTime    : DWORD; (* ULONG *)
msInputMinDistanceTime    : DWORD; (* ULONG *)
msInputMaxDistanceTime    : DWORD; (* ULONG *)

msIoInCurExecutionTime: Current processing time of the input data in the BACnet task (ms).

msIoInMinExecutionTime: Minimum processing time of the input data in the BACnet task (ms).

msIoInMaxExecutionTime: Maximum processing time of the input data in the BACnet task (ms).

msIoOutCurExecutionTime: Current processing time of the output data in the BACnet task (ms).

msIoOutMinExecutionTime: Minimum processing time of the output data in the BACnet task (ms).

msIoOutMaxExecutionTime: Maximum processing time of the output data in the BACnet task (ms).

msCycleCurExecutionTime: Current processing time of the BACnet task (ms).

msCycleMinExecutionTime: Minimum processing time of the BACnet task (ms).

msCycleMaxExecutionTime: Maximum processing time of the BACnet task (ms).

msInputCurDistanceTime: Current time duration between the start of the input data processing (ms).

msInputMinDistanceTime: Minimum time duration between the start of the input data processing (ms).

msInputMaxDistanceTime: Maximum time duration between the start of the input data processing (ms).


FB_BACnet_Program

TS8020 | TwinCAT BACnet Supplement

ST_BACnet_DiagnosisTiming

Structure with information on BACnet frames.

confirmed            : ARRAY[0..29] OF ST_BACnet_ConfirmedServiceDiag; (* [SERVICE_CONFIRMED_MAX + 1]; 29 + 1 *)
unConfirmed          : ARRAY[0..9] OF ST_BACnet_UnConfirmedServiceDiag; (* [SERVICE_UNCONFIRMED_MAX + 1]; 9 *)
nSegmSendTimeouts    : DWORD; (* ULONG *)
nFrameAllocFailCnt   : DWORD; (* ULONG *)
nFrameSendCnt        : DWORD; (* ULONG *)
nFrameSendFailCnt    : DWORD; (* ULONG *)
nFrameRecvCnt        : DWORD; (* ULONG *)
nFrameRecvFailCnt    : DWORD; (* ULONG *)
nLinkStatusChangedCnt: DWORD; (* ULONG *)

nSegmSendTimeouts: Timeout during receipt of acknowledgement of segmented packages (remote station does not acknowledge a segmented response, segmented ACK)

nFrameAllocFailCnt: Number of lost frames due to problems with memory allocation (no free memory).

nFrameSendCnt: Number of sent frames.

nFrameSendFailCnt: Number of failed frames.

nFrameRecvCnt: Number of received frames.

nFrameRecvFailCnt: Number of faulty received frames.

nLinkStatusChangedCnt: Frequency of network status changes (cable pulled/link lost, cable plugged/link OK).


FB_BACnet_Program

TS8020 | TwinCAT BACnet Supplement

ST_BACnet_Info

Structure with general information on the BACnet task.

nAmsAllocCnt: DINT; (* LONG *)
nAmsAllocCntMax: DWORD; (* ULONG *)
nAmsAllocFailCnt: DWORD; (* ULONG *)
nAvailPhysMemBytes: DWORD; (* ULONG *)
nAvailFlashMemBytes: ARRAY[0..1] OF DWORD; (* ULONGLONG *)
nRecvFrameFifoSize: DWORD; (* ULONG *)
nEmptyFrameFifoSize: DWORD; (* ULONG *)
nRecvSegmUDPFramesListSize: DWORD; (* ULONG *)
nRecvSegmFramesListSize: DWORD; (* ULONG *)
nSendSegmFramesListSize: DWORD; (* ULONG *)
nClientScanListSize: DWORD; (* ULONG *)
nAdsRequestListSize: DWORD; (* ULONG *)

nAmsAllocCnt: Number of reserved router memory blocks (1 block= 1024 bytes). The number should not increase continuously (a maximum of 2000 blocks=2 MB are available by default). Otherwise increase the router memory in the System Manager (see Fig. 1).

nAmsAllocCntMax: Peak value of the simultaneously allocated router memory blocks.

nAmsAllocFailCnt: Number of failed router memory reservations (allocation fails if no more blocks are available).

nAvailPhysMemBytes: Free physical memory of the operating system in bytes.

nAvailFlashMemBytes: Free hard disk space of the operating system in bytes.

nRecvFrameFifoSize: Number of frames currently in the receive frame queue (for receive queue see "Network adapter settings")

nEmptyFrameFifoSize: Available memory for buffering received frames (frame is copied and then copied to RecvFrameFifo)

nRecvSegmUDPFramesListSize: Number of currently received buffered IP segments (name is wrong, not UDP but IP)

nRecvSegmFramesListSize: Number of currently received buffered BACnet frame segments

nSendSegmFramesListSize: Number of current BACnet frame segments that were buffered before sending

nClientScanListSize: Number of currently known BACnet devices in the network (DeviceAddressBinding in the device object is formed from this)

nAdsRequestListSize: Number of currently open internal ADS requests for reading/writing of files (stack accesses local files via ADS)

Fig. 1: AMS router memory setting


FB_BACnet_Program

TS8020 | TwinCAT BACnet Supplement

ST_BACnet_ServerStatistics

Structure with information on the BACnet server.

nOpenRequests       : DWORD; (* ULONG *)
nRequestRetries     : DWORD; (* ULONG *)
nRequestTimeOuts    : DWORD; (* ULONG *)
nPropChanges        : DWORD; (* ULONG *)
nPersistWrites      : DWORD; (* ULONG *)
persistChangeSetId  : DWORD; (* ULONG *)
secpersistNextWrite : DWORD; (* ULONG *)
persistLastWrite    : ST_BACnet_DateTime;

nOpenRequests: Number of open requests.

nRequestRetries: Number of repeated requests.

nRequestTimeOuts: Number of failed requests.

nPropChanges: Number of property value changes (Present_Value, Status_Flags... etc.).

nPersistWrites: Number of write cycles for persistent data (frequency since system start).

persistChangeSetId: Absolute number of write cycles since the system was loaded (safe restart).

secpersistNextWrite: Seconds until the persistent data are saved next.

persistLastWrite: Time when the persistent data were saved last.


FB_BACnet_Program

TS8020 | TwinCAT BACnet Supplement

ST_BACnet_TcIoEthStatistic

Structure with information for sending and receiving of network frames from the network driver.

dcTimeStamp    : ARRAY[0..1] OF DWORD; (* ULONGLONG *)
sendFrames     : DWORD; (* ULONG *)
recvFrames     : DWORD; (* ULONG *)
sendTimeRTime  : DWORD; (* ULONG *)
recvTimeRTime  : DWORD; (* ULONG *)
sendTimeNdis   : DWORD; (* ULONG *)
recvTimeNdis   : DWORD; (* ULONG *)

dcTimeStamp: Real-time timestamp (DC time).

sendFrames: Sent Ethernet frames of the BACnet adapter.

recvFrames: Processed Ethernet frames of the BACnet adapter.

sendTimeRTime: Non-BACnet specific information from the network driver (internal diagnosis).

recvTimeRTime: Non-BACnet specific information from the network driver (internal diagnosis).

sendTimeNdis: Non-BACnet specific information from the network driver (internal diagnosis).

recvTimeNdis: Non-BACnet specific information from the network driver (internal diagnosis).


FB_BACnet_Program

TS8020 | TwinCAT BACnet Supplement

ST_BACnet_TcIoEthTxRxErrorCount

Structure with information on faulty network frames from the network driver.

txCnt    : DWORD; (* ULONG *)
rxCnt    : DWORD; (* ULONG *)

txCnt: Number of faulty sent frames (lost sent packets).

rxCnt: Number of faulty received frames (discarded received packets).


FB_BACnet_Program

TS8020 | TwinCAT BACnet Supplement

ST_BACnet_UnConfirmedServiceDiag

Structure with information on unconfirmed BACnet services (unconfirmed).

nReqSend        : DWORD; (* ULONG *)
nReqSendFail    : DWORD; (* ULONG *)
nReqRecv        : DWORD; (* ULONG *)
nReqRecvFail    : DWORD; (* ULONG *)

nReqSend: Number of sent requests (unconfirmed requests).

nReqSendFail: Number of failed requests.

nReqRecv: Number of received requests (unconfirmed requests).

nReqRecvFail: Number of requests that could not be processed (no free memory, wrong coding etc.).


FB_BACnet_Program

TS8020 | TwinCAT BACnet Supplement

ST_BACnet_ProgramHandshakeRequests

Structure with program request flags:

bLoad   : BOOL;
bSetup  : BOOL;
bRun    : BOOL;
bHalt   : BOOL;
bUnload : BOOL;

bLoad: Request loading of a program.

bSetup: Request setting up of a program.

bRun: Request starting of a program.

bHalt: Request stopping of a program.

bUnload: Request stopping and unloading of the program.


FB_BACnet_Program

TS8020 | TwinCAT BACnet Supplement

ST_BACnet_ProgramHandshakeStates

Structure with program handshake-flags:

bIdle      : BOOL;
bLoading   : BOOL;
bRunning   : BOOL;
bWaiting   : BOOL;
bHalted    : BOOL;
bUnloading : BOOL;

bIdle: Program is unloaded.

bLoading: Program is being loaded.

bRunning: Program was started.

bWaiting: Program is waiting for an external condition.

bHalted: Program stopped.

bUnloading: Program is being unloaded.


FB_BACnet_Program

TS8020 | TwinCAT BACnet Supplement

ST_BACnet_Time

Structure with time information.

nHour       : BYTE; (* hour (0..23), (X'FF') = unspecified *)
nMinute     : BYTE; (* minute (0..59), (X'FF') = unspecified *)
nSecond     : BYTE; (* (0..59), (X'FF') = unspecified *)
nHundredths : BYTE; (* hundredths (0..99), (X'FF') = unspecified *)

nHour: hour (0..23, 0xFF = not specified).

nMinute: minute (0..59, 0xFF = not specified).

nSecond: second (0..59, 0xFF = not specified).

nHundredths: hundredth of seconds (0..99, 0xFF = not specified).


FB_BACnet_Program

TS8020 | TwinCAT BACnet Supplement

E_BACnetAdapterStatus

BACnetAdapterStatus_Init := 16#0,
BACnetAdapterStatus_CheckIpAddr := 16#1,
BACnetAdapterStatus_CheckParam := 16#2,
BACnetAdapterStatus_GetGatewayMAC := 16#3,
BACnetAdapterStatus_WaitGatewayMAC := 16#4,
BACnetAdapterStatus_Complete := 16#8


FB_BACnet_Program

TS8020 | TwinCAT BACnet Supplement

E_BACnetBinaryPV

BACnetBinaryPV_inactive :=0,
BACnetBinaryPV_active :=1,
BACnetBinaryPV_NULL := 2


FB_BACnet_Program

TS8020 | TwinCAT BACnet Supplement

E_BACnetDataTypes

BACnetDataType_Null :=0,
BACnetDataType_Bool :=1,
BACnetDataType_UnsignedInteger :=2,
BACnetDataType_SignedInteger :=3,
BACnetDataType_Real :=4,
BACnetDataType_Double :=5,
BACnetDataType_OctetString :=6,
BACnetDataType_CharacterStringExt :=7,
BACnetDataType_BitString :=8,
BACnetDataType_Enumerated :=9,
BACnetDataType_Date :=10,
BACnetDataType_Time :=11,
BACnetDataType_ObjectIdentifier :=12,
BACnetDataType_DateTime :=14,
BACnetDataType_ArrayIndex :=15,
BACnetDataType_CalendarEntry :=16,
BACnetDataType_ObjectType :=17,
BACnetDataType_EventTransitionBits :=18,
BACnetDataType_ActionList :=19,
BACnetDataType_StatusFlags :=20,
BACnetDataType_EventState :=21,
BACnetDataType_Reliability :=22,
BACnetDataType_Polarity :=23,
BACnetDataType_EngineeringUnits :=25,
BACnetDataType_PriorityValue :=26,
BACnetDataType_LimitEnable :=27,
BACnetDataType_NotifyType :=29,
BACnetDataType_TimeStamp :=30,
BACnetDataType_DeviceObjectPropertyReference :=31,
BACnetDataType_DeviceStatus :=32,
BACnetDataType_ServicesSupported :=33,
BACnetDataType_ObjectTypesSupported :=34,
BACnetDataType_Segmentation :=35,
BACnetDataType_VTClass :=36,
BACnetDataType_VTSession :=37,
BACnetDataType_SessionKey :=38,
BACnetDataType_Recipient :=39,
BACnetDataType_AddressBinding :=40,
BACnetDataType_COVSubscription :=41,
BACnetDataType_EventType :=42,
BACnetDataType_EventParameter :=43,
BACnetDataType_FileAccessMethod :=44,
BACnetDataType_ReadAccessSpecification :=45,
BACnetDataType_ReadAccessResult :=46,
BACnetDataType_ObjectPropertyReference :=47,
BACnetDataType_SetpointReference :=48,
BACnetDataType_Destination :=49,
BACnetDataType_ProgramState :=50,
BACnetDataType_ProgramRequest :=51,
BACnetDataType_ProgramError :=52,
BACnetDataType_DateRange :=53,
BACnetDataType_DailySchedule :=54,
BACnetDataType_SpecialEvent :=55,
BACnetDataType_ClientCOV :=56,
BACnetDataType_LogRecord :=57,
BACnetDataType_LifeSafetyState :=58,
BACnetDataType_LifeSafetyMode :=59,
BACnetDataType_SilencedState :=60,
BACnetDataType_LifeSafetyOperation :=61,
BACnetDataType_BinaryPV :=62,
BACnetDataType_DaysOfWeek :=63,
BACnetDataType_WeekNDay :=64,
BACnetDataType_TimeValue :=65,
BACnetDataType_Value :=66,
BACnetDataType_Address :=67,
BACnetDataType_PropertyIdentifier :=68,
BACnetDataType_EnumerationValueType :=69,
BACnetDataType_BitFieldBit :=70,
BACnetDataType_LogDatum :=71,
BACnetDataType_AnyType :=72,
BACnetDataType_PresentValue :=73,
BACnetDataType_ContextTag :=74,
BACnetDataType_ValueChoice :=75,
BACnetDataType_LogStatus :=76,
BACnetDataType_RecipientProcess :=77,
BACnetDataType_SubscribeCOVPropertyRequest :=78,
BACnetDataType_PropertyReference :=79,
BACnetDataType_PropertyResult :=80,
BACnetDataType_DeviceObjectPropertyValue :=81,
BACnetDataType_COVNotificationRequest :=82,
BACnetDataType_EventNotificationRequest :=83,
BACnetDataType_NotificationParameters :=84,
BACnetDataType_Change_of_Bitstring :=85,
BACnetDataType_Change_of_State :=86,
BACnetDataType_Change_of_Value :=87,
BACnetDataType_Command_failure :=88,
BACnetDataType_Floating_limit :=89,
BACnetDataType_Out_of_Range :=90,
BACnetDataType_PropertyValue :=91,
BACnetDataType_Complex_Tag :=92,
BACnetDataType_Change_of_life_safety :=93,
BACnetDataType_Extended :=94,
BACnetDataType_Buffer_ready :=95,
BACnetDataType_Unsigned_range :=96,
BACnetDataType_PropertyResultValue :=97,
BACnetDataType_ServiceCOVPropSubscription :=98,
BACnetDataType_ServiceCOVSubscription :=99,
BACnetDataType_COVNotification :=100,
BACnetDataType_AcknowledgeAlarmRequest :=101,
BACnetDataType_VTOpenRequest :=102,
BACnetDataType_Prescale :=103,
BACnetDataType_Scale :=104,
BACnetDataType_Action :=105,
BACnetDataType_Error :=106,
BACnetDataType_ErrorType :=107,
BACnetDataType_ErrorClass :=108,
BACnetDataType_ErrorCode :=109,
BACnetDataType_RejectReason :=110,
BACnetDataType_AbortReason :=111,
BACnetDataType_BDTEntry :=112,
BACnetDataType_IpEntry :=113,
BACnetDataType_MaskEntry :=114,
BACnetDataType_UnsignedIntegerArr :=258,
BACnetDataType_CharacterStringExtArr :=263,
BACnetDataType_ObjectIdentifierArr :=268,
BACnetDataType_CalendarEntryArr :=272,
BACnetDataType_ActionListArr :=275,
BACnetDataType_PriorityValueArr :=282,
BACnetDataType_TimeStampArr :=286,
BACnetDataType_DeviceObjectPropertyReferenceArr :=287,
BACnetDataType_VTClassArr :=292,
BACnetDataType_VTSessionArr :=293,
BACnetDataType_SessionKeyArr :=294,
BACnetDataType_RecipientArr :=295,
BACnetDataType_AddressBindingArr :=296,
BACnetDataType_COVSubscriptionArr :=297,
BACnetDataType_ReadAccessSpecificationArr :=301,
BACnetDataType_ReadAccessResultArr :=302,
BACnetDataType_DestinationArr :=305,
BACnetDataType_SpecialEventArr :=311,
BACnetDataType_LogRecordArr :=313,
BACnetDataType_LifeSafetyStateArr :=314,
BACnetDataType_TimeValueArr :=321,
BACnetDataType_UnsignedIntegerList :=514,
BACnetDataType_CharacterStringExtList :=519,
BACnetDataType_ReadAccessSpecificationList :=557,
BACnetDataType_ReadAccessResultList :=558,
BACnetDataType_SpecialEventList :=567,
BACnetDataType_LogRecordList :=569,
BACnetDataType_TimeValueList :=577,
BACnetDataType_ValueList :=578,
BACnetDataType_LogDatumList :=583,
BACnetDataType_PropertyReferenceList :=591,
BACnetDataType_PropertyResultList :=592,
BACnetDataType_COVNotificationRequestList :=594,
BACnetDataType_EventNotificationRequestList :=595,
BACnetDataType_PropertyValueList :=603,
BACnetDataType_DailyScheduleList :=1089


FB_BACnet_Program

TS8020 | TwinCAT BACnet Supplement

E_BACnetDeviceStatus

BACnetDeviceStatus_Operational :=0,
BACnetDeviceStatus_OperationalReadOnly :=1,
BACnetDeviceStatus_DownloadRequired :=2,
BACnetDeviceStatus_DownloadInProgress :=3,
BACnetDeviceStatus_NonOperational :=4,
BACnetDeviceStatus_BackupInProgress :=5


FB_BACnet_Program

TS8020 | TwinCAT BACnet Supplement

E_BACnetEventState

BACnetEventState_state_normal :=0,
BACnetEventState_fault :=1,
BACnetEventState_offnormal :=2,
BACnetEventState_high_limit :=3,
BACnetEventState_low_limit :=4,
BACnetEventState_life_safety_alarm :=5


FB_BACnet_Program

TS8020 | TwinCAT BACnet Supplement

E_BACnetObjectType

BACnetObjectType_AnalogInput :=0,
BACnetObjectType_AnalogOutput :=1,
BACnetObjectType_AnalogValue :=2,
BACnetObjectType_BinaryInput :=3,
BACnetObjectType_BinaryOutput :=4,
BACnetObjectType_BinaryValue :=5,
BACnetObjectType_Calendar :=6,
BACnetObjectType_Command :=7,
BACnetObjectType_Device :=8,
BACnetObjectType_EventEnrollment :=9,
BACnetObjectType_File :=10,
BACnetObjectType_Group :=11,
BACnetObjectType_Loop :=12,
BACnetObjectType_MultiStateInput :=13,
BACnetObjectType_MultiStateOutput :=14,
BACnetObjectType_NotificationClass :=15,
BACnetObjectType_Program :=16,
BACnetObjectType_Schedule :=17,
BACnetObjectType_Averaging :=18,
BACnetObjectType_MultiStateValue :=19,
BACnetObjectType_TrendLog :=20,
BACnetObjectType_LifeSafetyPoint :=21,
BACnetObjectType_LifeSafetyZone :=22,
BACnetObjectType_Accumulator :=23,
BACnetObjectType_PulseConverter :=24


FB_BACnet_Program

TS8020 | TwinCAT BACnet Supplement

E_BACnetPriority

BACnetPriority_None :=0,
BACnetPriority_1 :=1,
BACnetPriority_2 :=2,
BACnetPriority_3 :=3,
BACnetPriority_4 :=4,
BACnetPriority_5 :=5,
BACnetPriority_6 :=6,
BACnetPriority_7 :=7,
BACnetPriority_8 :=8,
BACnetPriority_9 :=9,
BACnetPriority_10 :=10,
BACnetPriority_11 :=11,
BACnetPriority_12 :=12,
BACnetPriority_13 :=13,
BACnetPriority_14 :=14,
BACnetPriority_15 :=15,
BACnetPriority_16 :=16


FB_BACnet_Program

TS8020 | TwinCAT BACnet Supplement

E_BACnetProgramError

Enumeration with error feedback for the program object (program error):

BACnetProgramError_program_normal :=0,
BACnetProgramError_load_failed :=1,
BACnetProgramError_progerror_internal :=2,
BACnetProgramError_program :=3,
BACnetProgramError_other :=4

BACnetProgramError_program_normal: No error.

BACnetProgramError_load_failed: Loading of the program has failed.

BACnetProgramError_progerror_internal: Internal program error.

BACnetProgramError_program: Error during program execution.

BACnetProgramError_other: Unknown error.


FB_BACnet_Program

TS8020 | TwinCAT BACnet Supplement

E_BACnetProgramRequest

Enumeration with request to the program object (program request):

BACnetProgramRequest_ready :=0,
BACnetProgramRequest_load :=1,
BACnetProgramRequest_run :=2,
BACnetProgramRequest_halt :=3,
BACnetProgramRequest_restart :=4,
BACnetProgramRequest_unload :=5

BACnetProgramRequest_ready: The program is ready for a request or has executed/aborted the last request.

BACnetProgramRequest_load: Request loading of the program.

BACnetProgramRequest_run: Request initiating of the program.

BACnetProgramRequest_halt: Request stopping of a program.

BACnetProgramRequest_restart: Request restarting of the program.

BACnetProgramRequest_unload: Request stopping and unloading of the program.


FB_BACnet_Program

TS8020 | TwinCAT BACnet Supplement

E_BACnetProgramState

Enumeration with the state of the program object (program state):

BACnetProgramState_idle :=0,
BACnetProgramState_loading :=1,
BACnetProgramState_running :=2,
BACnetProgramState_waiting :=3,
BACnetProgramState_halted :=4,
BACnetProgramState_unloading :=5

BACnetProgramState_idle: Program is unloaded.

BACnetProgramState_loading: Program is being loaded.

BACnetProgramState_running: Program was started.

BACnetProgramState_waiting: Program is waiting for an external condition.

BACnetProgramState_halted: Program stopped.

BACnetProgramState_unloading: Program is being unloaded.


FB_BACnet_Program

TS8020 | TwinCAT BACnet Supplement

E_BACnetPropertyIdentifier

BACnetPropertyIdentifier_AckedTransitions :=0,
BACnetPropertyIdentifier_AckRequired :=1,
BACnetPropertyIdentifier_Action :=2,
BACnetPropertyIdentifier_ActionText :=3,
BACnetPropertyIdentifier_ActiveText :=4,
BACnetPropertyIdentifier_ActiveVtSessions :=5,
BACnetPropertyIdentifier_AlarmValue :=6,
BACnetPropertyIdentifier_AlarmValues :=7,
BACnetPropertyIdentifier_All :=8,
BACnetPropertyIdentifier_AllWritesSuccessful :=9,
BACnetPropertyIdentifier_ApduSegmentTimeout :=10,
BACnetPropertyIdentifier_ApduTimeout :=11,
BACnetPropertyIdentifier_ApplicationSoftwareVersion :=12,
BACnetPropertyIdentifier_Archive :=13,
BACnetPropertyIdentifier_Bias :=14,
BACnetPropertyIdentifier_ChangeOfStateCount :=15,
BACnetPropertyIdentifier_ChangeOfStateTime :=16,
BACnetPropertyIdentifier_NotificationClass :=17,
BACnetPropertyIdentifier_ControlledVariableReference :=19,
BACnetPropertyIdentifier_ControlledVariableUnits :=20,
BACnetPropertyIdentifier_ControlledVariableValue :=21,
BACnetPropertyIdentifier_CovIncrement :=22,
BACnetPropertyIdentifier_Datelist :=23,
BACnetPropertyIdentifier_DaylightSavingsStatus :=24,
BACnetPropertyIdentifier_Deadband :=25,
BACnetPropertyIdentifier_DerivativeConstant :=26,
BACnetPropertyIdentifier_DerivativeConstantUnits :=27,
BACnetPropertyIdentifier_Description :=28,
BACnetPropertyIdentifier_DescriptionOfHalt :=29,
BACnetPropertyIdentifier_DeviceAddressBinding :=30,
BACnetPropertyIdentifier_DeviceType :=31,
BACnetPropertyIdentifier_EffectivePeriod :=32,
BACnetPropertyIdentifier_ElapsedActiveTime :=33,
BACnetPropertyIdentifier_ErrorLimit :=34,
BACnetPropertyIdentifier_EventEnable :=35,
BACnetPropertyIdentifier_EventState :=36,
BACnetPropertyIdentifier_EventType :=37,
BACnetPropertyIdentifier_ExceptionSchedule :=38,
BACnetPropertyIdentifier_FaultValues :=39,
BACnetPropertyIdentifier_FeedbackValue :=40,
BACnetPropertyIdentifier_FileAccessMethod :=41,
BACnetPropertyIdentifier_FileSize :=42,
BACnetPropertyIdentifier_FileType :=43,
BACnetPropertyIdentifier_FirmwareRevision :=44,
BACnetPropertyIdentifier_HighLimit :=45,
BACnetPropertyIdentifier_InactiveText :=46,
BACnetPropertyIdentifier_InProcess :=47,
BACnetPropertyIdentifier_InstanceOf :=48,
BACnetPropertyIdentifier_IntegralConstant :=49,
BACnetPropertyIdentifier_IntegralConstantUnits :=50,
BACnetPropertyIdentifier_IssueConfirmedNotifications :=51,
BACnetPropertyIdentifier_LimitEnable :=52,
BACnetPropertyIdentifier_ListOfGroupMembers :=53,
BACnetPropertyIdentifier_ListOfObjectPropertyReferences :=54,
BACnetPropertyIdentifier_ListOfSessionKeys :=55,
BACnetPropertyIdentifier_LocalDate :=56,
BACnetPropertyIdentifier_LocalTime :=57,
BACnetPropertyIdentifier_Location :=58,
BACnetPropertyIdentifier_LowLimit :=59,
BACnetPropertyIdentifier_ManipulatedVariableReference :=60,
BACnetPropertyIdentifier_MaximumOutput :=61,
BACnetPropertyIdentifier_MaxApduLengthAccepted :=62,
BACnetPropertyIdentifier_MaxInfoFrames :=63,
BACnetPropertyIdentifier_MaxMaster :=64,
BACnetPropertyIdentifier_MaxPresValue :=65,
BACnetPropertyIdentifier_MinimumOfftime :=66,
BACnetPropertyIdentifier_MinimumOntime :=67,
BACnetPropertyIdentifier_MinimumOutput :=68,
BACnetPropertyIdentifier_MinPresValue :=69,
BACnetPropertyIdentifier_ModelName :=70,
BACnetPropertyIdentifier_ModificationDate :=71,
BACnetPropertyIdentifier_NotifyType :=72,
BACnetPropertyIdentifier_NumberOfAPDURetries :=73,
BACnetPropertyIdentifier_NumberOfStates :=74,
BACnetPropertyIdentifier_ObjectIdentifier :=75,
BACnetPropertyIdentifier_ObjectList :=76,
BACnetPropertyIdentifier_ObjectName :=77,
BACnetPropertyIdentifier_ObjectReference :=78,
BACnetPropertyIdentifier_ObjectType :=79,
BACnetPropertyIdentifier_Optional :=80,
BACnetPropertyIdentifier_OutOfService :=81,
BACnetPropertyIdentifier_OutputUnits :=82,
BACnetPropertyIdentifier_EventParameters :=83,
BACnetPropertyIdentifier_Polarity :=84,
BACnetPropertyIdentifier_PresentValue :=85,
BACnetPropertyIdentifier_Priority :=86,
BACnetPropertyIdentifier_PriorityArray :=87,
BACnetPropertyIdentifier_PriorityForWriting :=88,
BACnetPropertyIdentifier_ProcessIdentifier :=89,
BACnetPropertyIdentifier_ProgramChange :=90,
BACnetPropertyIdentifier_ProgramLocation :=91,
BACnetPropertyIdentifier_ProgramState :=92,
BACnetPropertyIdentifier_ProportionalConstant :=93,
BACnetPropertyIdentifier_ProportionalConstantUnits :=94,
BACnetPropertyIdentifier_ProtocolObjectTypesSupported :=96,
BACnetPropertyIdentifier_ProtocolServicesSupported :=97,
BACnetPropertyIdentifier_ProtocolVersion :=98,
BACnetPropertyIdentifier_ReadOnly :=99,
BACnetPropertyIdentifier_ReasonForHalt :=100,
BACnetPropertyIdentifier_Recipient :=101,
BACnetPropertyIdentifier_RecipientList :=102,
BACnetPropertyIdentifier_Reliability :=103,
BACnetPropertyIdentifier_RelinquishDefault :=104,
BACnetPropertyIdentifier_Required :=105,
BACnetPropertyIdentifier_Resolution :=106,
BACnetPropertyIdentifier_SegmentationSupported :=107,
BACnetPropertyIdentifier_Setpoint :=108,
BACnetPropertyIdentifier_SetpointReference :=109,
BACnetPropertyIdentifier_StateText :=110,
BACnetPropertyIdentifier_StatusFlags :=111,
BACnetPropertyIdentifier_SystemStatus :=112,
BACnetPropertyIdentifier_TimeDelay :=113,
BACnetPropertyIdentifier_TimeOfActiveTimeReset :=114,
BACnetPropertyIdentifier_TimeOfStateCountReset :=115,
BACnetPropertyIdentifier_TimeSynchronizationRecipients :=116,
BACnetPropertyIdentifier_Units :=117,
BACnetPropertyIdentifier_UpdateInterval :=118,
BACnetPropertyIdentifier_UtcOffset :=119,
BACnetPropertyIdentifier_VendorIdentifier :=120,
BACnetPropertyIdentifier_VendorName :=121,
BACnetPropertyIdentifier_VtClassesSupported :=122,
BACnetPropertyIdentifier_WeeklySchedule :=123,
BACnetPropertyIdentifier_AttemptedSamples :=124,
BACnetPropertyIdentifier_AverageValue :=125,
BACnetPropertyIdentifier_BufferSize :=126,
BACnetPropertyIdentifier_ClientCovIncrement :=127,
BACnetPropertyIdentifier_CovResubscriptionInterval :=128,
BACnetPropertyIdentifier_EventTimeStamps :=130,
BACnetPropertyIdentifier_LogBuffer :=131,
BACnetPropertyIdentifier_LogDeviceObjectProperty :=132,
BACnetPropertyIdentifier_LogEnable :=133,
BACnetPropertyIdentifier_LogInterval :=134,
BACnetPropertyIdentifier_MaximumValue :=135,
BACnetPropertyIdentifier_MinimumValue :=136,
BACnetPropertyIdentifier_NotificationThreshold :=137,
BACnetPropertyIdentifier_ProtocolRevision :=139,
BACnetPropertyIdentifier_RecordsSinceNotification :=140,
BACnetPropertyIdentifier_RecordCount :=141,
BACnetPropertyIdentifier_StartTime :=142,
BACnetPropertyIdentifier_StopTime :=143,
BACnetPropertyIdentifier_StopWhenFull :=144,
BACnetPropertyIdentifier_TotalRecordCount :=145,
BACnetPropertyIdentifier_ValidSamples :=146,
BACnetPropertyIdentifier_WindowInterval :=147,
BACnetPropertyIdentifier_WindowSamples :=148,
BACnetPropertyIdentifier_MaximumValueTimestamp :=149,
BACnetPropertyIdentifier_MinimumValueTimestamp :=150,
BACnetPropertyIdentifier_VarianceValue :=151,
BACnetPropertyIdentifier_ActiveCovSubscriptions :=152,
BACnetPropertyIdentifier_BackupFailureTimeout :=153,
BACnetPropertyIdentifier_ConfigurationFiles :=154,
BACnetPropertyIdentifier_DatabaseRevision :=155,
BACnetPropertyIdentifier_DirectReading :=156,
BACnetPropertyIdentifier_LastRestoreTime :=157,
BACnetPropertyIdentifier_MaintenanceRequired :=158,
BACnetPropertyIdentifier_MemberOf :=159,
BACnetPropertyIdentifier_Mode :=160,
BACnetPropertyIdentifier_OperationExpected :=161,
BACnetPropertyIdentifier_Setting :=162,
BACnetPropertyIdentifier_Silenced :=163,
BACnetPropertyIdentifier_TrackingValue :=164,
BACnetPropertyIdentifier_ZoneMembers :=165,
BACnetPropertyIdentifier_LifeSafetyAlarmValues :=166,
BACnetPropertyIdentifier_MaxSegmentsAccepted :=167,
BACnetPropertyIdentifier_ProfileName :=168,
BACnetPropertyIdentifier_InternalUse :=169,
BACnetPropertyIdentifier_LastNotifyRecord :=173,
BACnetPropertyIdentifier_ScheduleDefault :=174,
BACnetPropertyIdentifier_AcceptedModes :=175,
BACnetPropertyIdentifier_AdjustValue :=176,
BACnetPropertyIdentifier_Count :=177,
BACnetPropertyIdentifier_CountBeforeChange :=178,
BACnetPropertyIdentifier_CovPeriod :=180,
BACnetPropertyIdentifier_InputReference :=181,
BACnetPropertyIdentifier_LimitMonitoringInverval :=182,
BACnetPropertyIdentifier_LoggingObject :=183,
BACnetPropertyIdentifier_LoggingRecord :=184,
BACnetPropertyIdentifier_Prescale :=185,
BACnetPropertyIdentifier_PulseRate :=186,
BACnetPropertyIdentifier_Scale :=187,
BACnetPropertyIdentifier_ScaleFactor :=188,
BACnetPropertyIdentifier_UpdateTime :=189,
BACnetPropertyIdentifier_ValueBeforeChange :=190,
BACnetPropertyIdentifier_ValueSet :=191,
BACnetPropertyIdentifier_ValueChangeTime :=192


Support and Service

Beckhoff and their partners around the world offer comprehensive support and service, making available fast and competent assistance with all questions related to Beckhoff products and system solutions.

Beckhoff's branch offices and representatives

Please contact your Beckhoff branch office or representative for local support and service on Beckhoff products!

The addresses of Beckhoff's branch offices and representatives round the world can be found on her internet pages:
http://www.beckhoff.com

You will also find further documentation for Beckhoff components there.

Beckhoff Headquarters

Beckhoff Automation GmbH

Huelshorstweg 20
33415 Verl
Germany

Phone: | +49(0)5246/963-0
Fax: | +49(0)5246/963-198
e-mail: | info@beckhoff.com
Beckhoff Support

Support offers you comprehensive technical assistance, helping you not only with the application of individual Beckhoff products, but also with other, wide-ranging services:

  • support
  • design, programming and commissioning of complex automation systems
  • and extensive training program for Beckhoff system components
Hotline: | +49(0)5246/963-157
Fax: | +49(0)5246/963-9157
e-mail: | support@beckhoff.com
Beckhoff Service

The Beckhoff Service Center supports you in all matters of after-sales service:

  • on-site service
  • repair service
  • spare parts service
  • hotline service
Hotline: | +49(0)5246/963-460
Fax: | +49(0)5246/963-479
e-mail: | service@beckhoff.com


ADS Interface

All acyclic data are transferred with ADS Read, ADS Write, ADS ReadWrite or ADS Write Control to a BACnet device, a notification sink, a BACnet server or a BACnet client. Each BACnet device has a dedicate Net ID, which is displayed via the Settings tab and supports the following ports:

Port | Description
0xFFFF | Addresses the BACnet device itself, i.e. data that are not specific for a BACnet server, a notification sink or a BACnet client
1000 - 8192 | Addresses a BACnet server, a notification sink or a BACnet client. The first configured BACnet server/client can be reached via port 1000, the second via port 1001 etc. Deleting a BACnet server/client does not lead to shifting of the ports, i.e. the assignment of the ADS port can therefore not necessarily be deduced from the order in the System Manager. The respective port can be viewed via the Settings tab of a BACnet server/client.

ADS-Read

An overview of the IndexGroup/IndexOffset supported by a BACnet device for ADS Read is provided below.

IndexGroup with local addressing of the BACnet device (port 0xFFFF)

IndexGroup (Lo-Word) | IndexGroup (Hi-Word) | IndexOffset | Description
0x0006 | 0x8000 | always 0 | Starting a scan for other BACnet devices in the network.
0x0008 | 0x8000 | always 0 | Stopping a scan for other BACnet devices in the network. Preparation for reading the results list.
0x0007 0x8000 0 : Number of entries in the results list

(number of clients*2)

2*n: IP address of device n

2*n+1: Device ID of device n

0xffffffff

 A scan with the aid of a BACnet device follows the following pattern:
  1. Starting the scan
  2. Waiting for any timeout
  3. Stopping the scan
  4. Reading the scan results list

The scan results are read via this IndexGroup. The number of entries in the results list can be determined via IndexOffset 0. This corresponds to twice the number of BACnet devices found in the network. Even IndexOffsets > 0 address the IP address of a device; odd IndexOffsets address the device ID. Before reading the results list the scan process has to be stopped.

If, for example, 2 devices are found in a network, the query for index 0 comes up with 4. IndexOffset 1 relates to the device ID of device 1, IndexOffset 2 the IP address of device 1, IndexOffset 3 the device ID of device 2 and IndexOffset 4 the IP address of device 2.

Reading the objects present in the server. An array of type BACnetScanResult with the number of found clients is returned:

enum BACnetAddressChoice
{
 Ethernet,Arcnet,MsTp,LonTalk,LonTalkNeuronId,
 Address_3,Address_4,Address_5,Broadcast
}

struct BACnetAddress
{
 BACnetAddressChoice choice;
 BYTE layerAddress[7]; // MS/TP...LonTalk
                                BYTE reserved;
 USHORT network_number;
}
struct BACnetScanResult
{
 BACnetObjectIdentifier deviceObjIdentifier;
 BACnetAddress netAddress;
 ULONG IPadress;
 WORD UdpPort;
 WORD vendorId;
                 BYTE ethernetMacAddr[6];
}
0x000A | 0x8000 | always 0 | Starting a backup. (triggering the BACnet service Backup Start)
0x001A | 0x8000 | always 0 | Stopping a backup. (triggering the BACnet service Backup End) Between Backup Start and End the generated backup files can be saved with the aid of the Property Configuration Files of device object and the ADS file service.
0x002A | 0x8000 | always 0 | Starting a restore. (triggering the BACnet service Restore Start)
0x003A | 0x8000 | always 0 | Stopping a restore (triggering the BACnet service Restore End)
0x004A | 0x8000 | always 0 | Aborting a restore (triggering the BACnet service Restore Abort).
0x005A | 0x8000 | always 0 | Restarting the TwinCAT computer (triggering the BACnet service Cold Start)
0x006A | 0x8000 | always 0 | Restarting TwinCAT (triggering the BACnet service Warm Start).
0x000C 0x8000 always 0 Reading the supplement key status:
  • 0x0000000 - supplement key is not valid
  • 0x0000001 - supplement key is valid
0x000D 0x8000 always 0 Reading the current Foreign Device Table (FDT) as array of type FDTEntry:
struct FDTEntry
{
 ULONG ipAddr;
 USHORT udpPort;
 USHORT nTtlSecs;
 USHORT nPurgeSecs; // seconds until entry is deleted
                                USHORT reserved; // alignment
}
0x000E 0x8000 always 0 Reading the current Broadcast Distribution Table (BDT) as array of type BDTEntry:
struct BDTEntry
{
 ULONG ipAddr;
 ULONG mask;
 USHORT udpPort;
 USHORT reserved; // alignment
}
0x000F | 0x8000 | always 0 | Reading the BACnet diagnosis in the form of BACnetDiagnosis. (see BACnet device tab Diagnostics).
0x001F 0x8000 always 0 Reading the Advanced Parameters in the form of Advanced Parameters
struct AdvancedParameters
{
 ULONG ap_MAX_SUBSCRIBE_COV_ENTRIES;
 ULONG ap_MAX_PROPERTY_ELEMENTS;
 ULONG ap_LIST_ALLOC_MEM_BYTES;
 ULONG ap_MAX_DEVICE_BINDINGS;
 ULONG ap_HASHTABLE_MAX_OBJECTS;
 ULONG ap_HASHTABLE_MAX_CLIENTS;
 ULONG ap_MAX_TASK_LIST_ENTRIES;
 ULONG ap_MAX_TRENDLOG_ENTRYSIZE;
 ULONG ap_DYN_TRENDLOG_BUFFERSIZE;
 ULONG ap_MAX_MULTISTATE_DYNSTATES;
 ULONG ap_BACNET_MAX_RECV_BAC_SEGM_FRAMES;
 ULONG ap_BACNET_MAX_SEND_BAC_SEGM_FRAMES;
 ULONG ap_IO_STARTUP_TIMEOUT;
}

IndexGroup for addressing a BACnet server/client (port 1000-8191) - property access

Property specific ADS services can be used with an IndexGroup/IndexOffset with the following scheme:

  • Bit 0-21 contains the property ID of the required BACnet property
  • Bit 22-30 contains the group type describing the respective functionality
  • Bit 31 is always 1 and activates the group type mode for using the property-specific services
  • The IndexOffset contains the object ID of the required object
IndexGroup IndexOffset Description
0x80000000 + property ID

Group type (bits 22-30): 0

 Object ID
  • Bits 0 - 21: object instance
  • Bits 22 - 31: object type
 Reading the current data of a property.

Example: The property PresentValue of object BinaryInput: 42 can be read via IndexGroup: 0x80000055 and IndexOffset: 0x00C0002A.
0x80400000 + property ID

Group type (bits 22-30): 1

 Object ID
  • Bits 0 - 21: object instance
  • Bits 22 - 31: object type
 Reading the BACnet data type of a property. A list of data type coding can be found in the appendix.
0x80800000 + property ID

Group type (bits 22-30): 2

 Object ID
  • Bits 0 - 21: object instance
  • Bits 22 - 31: object type
 Reading the data length of the current property value.
0x80C00000 + property ID

Group type (bits 22-30): 3

 Object ID
  • Bits 0 - 21: object instance
  • Bits 22 - 31: object type
 Reading the write protection status of a property. The read data are interpreted as follows:
  • 0x00 property value can be written
  • 0x01 property value is read-only
0x81400000 + property ID

Group type (bits 22-30): 5

 Object ID
  • Bits 0 - 21: object instance
  • Bits 22 - 31: object type
 Reading the number of elements of list and array types.

IndexGroup for addressing a BACnet server (port 1000-8191)

IndexGroup | IndexOffset | Description
0x82400000 | 0 number of list entries > 0 and < 0xffffffff | Reading the objects present in the server. The objects created on a server can also be determined by reading the property ObjectList of the device object. Index 0: Number of entries Index n*2: object type for entry n Index n*2+1: object instance for entry n
0x83400000 | always 0 | Reading the list of dynamically created objects. For each object the list has a 4-byte entry containing the respective object ID.

IndexGroup for addressing a notification sink (port 1000-8191)

IndexGroup | IndexOffset | Description
0x00000001 | always 0 | Reading the current number of event notifications in the event notification buffer
0x00000002 | always 0 | Reading the current number of COV notifications in the COV notification buffer
0x00000003 | Number of the event notification (0 .. number-1) | Reading an event notification. The structure of event notifications can be determined in the online dialog of the notification sink.
0x00000004 | Number of the COV notification (0 .. number-1) | Reading a COV notification. The structure of COV notifications can be determined in the online dialog of the notification sink.
0x00000005 | Number of the event notification (0 .. number-1) | Deleting an event notification
0x00000006 | Number of the COV notification (0 .. number-1) | Deleting a COV notification
0x00000007 | Number of the event notification (0 .. number-1) | Reading the time of receipt of an event notification
0x00000008 | Number of the COV notification (0 .. number-1) | Reading the time of receipt of a COV notification

ADS Write

An overview of the IndexGroup/IndexOffset supported by TwinCAT BACnet/IP for ADS Write is provided below.

IndexGroup with local addressing of the BACnet device (port 0xFFFF)

IndexGroup IndexOffset Description
0x8000002D always 0 Triggering a global broadcast UTC synchronisation. A valid BACnetDateTime time stamp is required.
struct BACnetTime
{
   BYTE hour;
   BYTE minute;
   BYTE second;
   BYTE hundredths;
}

structBACnetDate
{
   BYTE year;
   BYTE month;
   BYTE day;
   BYTE dayOfWeek;
}

structBACnetDateTime
{
   BACnetDate date;
   BACnetTime time;
}
0x8000000F always 0 BACnet diagnosis control:

Transferred data size 4:

  • 0x00000000 : deactivate time measurement
  • 0x00000001 : activate time measurement

Data size not equal 4: resetting the BACnet diagnosis
0x8000000E always 0 Writing the Broadcast Distribution Table (BDT) as array in the form of BDTEntry:
struct BDTEntry
{
 ULONG ipAddr;
 ULONG mask;
 USHORT udpPort;
 USHORT reserved; // alignment
}

IndexGroup for addressing a BACnet server/client (port 1000-8191) - property access

Property specific ADS services can be used with an IndexGroup with the following scheme:

  • Bits 0-21 contains the property ID of the required BACnet property
  • Bit 22-30 contains the group type describing the respective functionality
  • Bit 31 is always 1 and activates the group type mode for using the property-specific services
  • The IndexOffset contains the object ID of the required object
IndexGroup IndexOffset Description
0x80000000 + property ID Object ID
  • Bits 0 - 21: object instance
  • Bits 22 - 31: object type
 Writing a property value. Prioritised write access is available via bits 22-30 of the IndexGroup. Priority 1 (top priority in BACnet) can be defined via the value 0x010 in bits 22-30. Priority 16 (the lowest priority in BACnet) can be defined with value 0x100.
0x84000000 + property-ID
 Object ID
  • Bits 0 - 21: object instance
  • Bits 22 - 31: object type
 Write access with priority 1.
...
0xC0000000 + property ID Object ID
  • Bits 0 - 21: object instance
  • Bits 22 - 31: object type
 Write access with priority 16.

IndexGroup for addressing a BACnet server/client (port 1000-8191)

IndexGroup | IndexOffset | Description
0x80800000 always 0 Creating an object dynamically. The following data must be transferred in the write request, in order to parameterise the object creation:
  • 4-byte object type
  • 4-byte object ID (the object type of the object ID must match the object type)
  • 4-byte flags (0x00000001 remote object (for client) , 0x00000000 local object (for server))
  • 8-byte 0x00 for an empty list of initial parameters, or a list of initials parameters with data type ReadPropertyMultipleResult
0x81000000 always 0 Deleting a dynamically created object. The following data must be transferred in a write request:
  • 4-byte object type
  • 4-byte object ID (the object type of the object ID must match the object type)
  • 4-byte flags (0x00000001 remote object (for client) , 0x00000000 local object (for server))
  • 8-byte 0x00
0x80C00000 | always 0 | Triggering saving of the persistent data. Only valid for BACnet servers if Persist Online Data is active.

ADS-ReadWrite

An overview of the IndexGroup/IndexOffset supported by TwinCAT BACnet/IP for ADS ReadWrite is provided below.

IndexGroup for addressing a BACnet server/client (port 1000-8191)

IndexGroup | IndexOffset | Description
0x82C00000 Object ID
  • Bits 0 - 21: object instance
  • Bits 22 - 31: object type
 Reading the property list of an object. This service consolidates all properties of an object, similar to the BACnet service ReadPropertyMultiple. When the ADS ReadWrite command is executed a list with the required properties must be transferred.

Currently only triggering of the complete list is supported. To this end 4 bytes with the value 0x00000008 must be transferred.
A list of type ReadPropertyMultipleResult is returned. The list contains list headers and property IDs, followed by the property data.
0x8B800000 | always 0 | Query of the object ID with the name of an object. The name of the requested object must be written as ASCII string. The corresponding object ID (4 bytes) is returned. If an object is not found the ADS error NOT_FOUND is returned.

ADS Error Codes

The 32-bit ADS error code always consists of a general ADS error code (low word, see ADS documentation). The appropriate text message will also be displayed in the TwinCAT System Manager Logger.


Data Types

In the automation interface and via ADS complex properties are coded as byte arrays. This section explains how the BACnet data concepts are mapped to C data structures within TwinCAT BACnet/IP, and how they can be used during configuration via the automation interface or ADS. Section 21 of the BACnet standard ("FORMAL DESCRIPTION OF APPLICATION PROTOCOL DATA UNITS") specifies the BACnet data structures.

Apart from a few exceptions, the mapping from BACnet to C is based on the BACnet specification. Exceptions are dynamic data, which are mapped to lists or AnyTypes. The type of a property can generally be determined with the aid of the TwinCAT System Manager. The data type of each property, including the structure (by expanding the property data), can be seen in the Type column in the Settings and Online tabs. Data type names in the Type column ending in "[]" are arrays, names ending in List are lists. Choice-based data types can be recognised by the selection combo box in the Type column, data types with optional fields by a checkbox in the ID field.

Primitive data types

0 = zero | Mapped through a data length of 0.
1 = Boolean | Mapped to ULONG (4 bytes) with the values 0x00000001 for TRUE and 0x00000000 for FALSE
2 = Unsigned Integer | Mapped to ULONG (4 bytes). An optimised variant can be used, whereby integer values up to 255 are shown as 1 byte and integer values up to 65535 as 2 bytes (USHORT).
3 = Signed Integer | Mapped to LONG (4 bytes)
4 = Real | Mapped to FLOAT (4 bytes)
5 = Double | Currently not used
6 = Octet String | Mapped to BYTE[]
7 = Character String | Mapped to CHAR[]. I.e. 0-terminated ISO 8859-1 strings. Currently TwinCAT BACnet/IP supports strings of length 256.
8 = Bit String | Mapped to BYTE[]. The highest-value (most significant) byte contains the number of bits that are not used in the following byte ( 0..7 ). The highest-value bit of the subsequent byte contains the first Boolean value. Apart from a few exceptions, bit strings have a length of 2 bytes.
9 = Enumerated | Mapped to C enumerations ( 4 bytes ), starting from 0.
10 = Date Mapped to:
struct
BACnetDate
{
    BYTE year;       // year minus 1900
X'FF' = unspecified
    BYTE month;      // (1.. 12) 1 = January
X'FF' = unspecified
    BYTE day;        // day of month (1..31),
X'FF' = unspecified
    BYTE dayOfWeek;  // day of week (1..7) 1
= Monday -- 7 = Sunday -- X'FF' = unspecified
}
11 = Time Mapped to:
struct
BACnetTime
{
    BYTE hour;       // hour (0..23),
(X'FF') = unspecified
    BYTE minute;     // minute (0..59),
(X'FF') = unspecified
    BYTE second;     // (0..59),
(X'FF') = unspecified
    BYTE hundredths; // hundredths (0..99),
(X'FF') = unspecified
}
12 = BACnetObjectIdentifier Mapped to a 4-byte ObjektIdentifier with 10 bits for the object type and a 22-bit object instance
struct
BACnetObjectIdentifier
{
    DWORD objInst : 22;
    DWORD objType : 10;
}

Structures

BACnet sequences without optional fields are mapped to structures. An example is shown below.

            BACnetPrescale ::=
SEQUENCE
{
    multiplier   [0] Unsigned,
    moduloDivide [1] Unsigned
}

            struct
BACnetPrescale
{
    ULONG multiplier;
    ULONG moduloDivide;
}

Optional fields

BACnet sequences with optional fields are mapped to structures with an additional field validFields. The additional field indicates which fields are active in the structure. Bit 0 of validFields indicates whether the next field (ObjectIdentifier in the example) is active. For non-optional fields the respective bit always has to be set.

            BACnetObjectPropertyReference ::= SEQUENCE
{
    objectIdentifier   [0] BACnetObjectIdentifier,
    propertyIdentifier [1] BACnetPropertyIdentifier,
    propertyArrayIndex [2] Unsigned OPTIONAL
}

            struct
BACnetObjectPropertyReference
{
    ULONG validFields;
    BACnetObjectIdentifier objectIdentifier; // [0]
    BACnetPropertyIdentifier propertyIdentifier; // [1]
    ULONG propertyArrayIndex; // [2] Unsigned
OPTIONAL
}

Choice

A BACnet choice is mapped to a structure with the field choiceField and a union. The choiceField determines which field of the union is active. The length of the data is determined by the largest field of the union. The choiceField is an enumeration (4 bytes).

            BACnetRecipient ::=
CHOICE
{
    device  [0] BACnetObjectIdentifier,
    address [1] BACnetAddress
}

            enum
BACnetRecipient_Choice
{
    device,
    address
};struct _BACnetRecipient
{
    BACnetRecipient_Choice choiceField;    union
    {
        BACnetObjectIdentifier device;
        BACnetAddress address;
    };
}

Arrays

BACnet arrays with fixed data sizes are mapped to C arrays. Some BACnet arrays may contain data of variable length (lists or AnyTypes). In this case BACnet arrays are mapped to lists, as described in the following section.

Lists

BACnet lists and some BACnet arrays are mapped to a special list structure. Each list element has a header (ListEntryHdr), followed immediately by the element data. The highest bit of nEntrySize (nEntrySize & 0x80000000) indicates whether a further element follows ( bit 31 = 1 ), or whether it is the last list element (bit 31 = 0). The size of the subsequent data is coded in the lower 31 bit of nEntrySize as the number of bytes. The header contains a further internally used reserved field, followed by the data. The following list element starts at a 4-byte-aligned boundary, which follows the data.

      struct
_ListEntryHdr
{
    DWORD nEntrySize;
    DWORD reserved;
}

For example, if a list contains a first element of length 1 with value 1, the list is coded as follows: 08 00 00 01 00 00 00 00 01, followed by 3 alignment bytes 00 00 00. If the next list element is the last element of the list with 1 byte of data with the value 3: 00 00 00 01 00 00 00 00 03. The data length of the example list would be 24 bytes, since the last element is followed by 3 alignment bytes.

An empty list is coded as (4 bytes): 00 00 00 00.

AnyTypes

BACnet data of type ABSTRACT-SYNTAX.&Type are mapped through the structure AnyType. The field nSize contains the size of the following data, including the field dataType (4 bytes). The actual data therefore have the size nSize-4. The field dataType indicates the data type of the data element. A list of data types is provided below.

      struct
AnyType
{
    ULONG nSize;
    BACnetDataTypes dataType;    //... Data
}

The data type codings used for AnyTypes are listed below:

#define ARRAYTYPE 0x100

#define LISTTYPE 0x200

enum BACnetDataTypes

{

// Primitive Data

DataTypeNull = 0,

DataTypeBool = 1,

DataTypeCharacterStringExt = 2,

DataTypeUnsignedInteger = 3,

DataTypeSignedInteger = 4,

DataTypeReal = 5,

DataTypeDouble = 6,

DataTypeOctetString = 7,

DataTypeEnumerated = 8,

DataTypeBACnetObjectIdentifier = 9,

DataTypeAddressBinding = 10,

DataTypeBitString = 11,

DataTypeDate = 12,

DataTypeTime = 13,

// Complex Data

DataTypeDateTime = 14,

DataTypeArrayIndex = 15,

DataTypeBACnetCalendarEntry = 16,

DataTypeBACnetObjectType = 17,

DataTypeBACnetEventTransitionBits = 18,

DataTypeBACnetStatusFlags = 20,

DataTypeBACnetEventState = 21,

DataTypeBACnetReliability = 22,

DataTypeBACnetPolarity = 23,

DataTypeBACnetDateTime = 24,

DataTypeBACnetEngineeringUnits = 25,

DataTypeBACnetPriorityValue = 26,

DataTypeBACnetLimitEnable = 27,

DataTypeBACnetNotifyType = 29,

DataTypeBACnetTimeStamp = 30,

DataTypeBACnetDeviceObjectPropertyReference = 31,

DataTypeBACnetDeviceStatus = 32,

DataTypeBACnetServicesSupported = 33,

DataTypeBACnetObjectTypesSupported = 34,

DataTypeBACnetSegmentation = 35,

DataTypeBACnetVTClass = 36,

DataTypeBACnetVTSession = 37,

DataTypeBACnetSessionKey = 38,

DataTypeBACnetRecipient = 39,

DataTypeBACnetAddressBinding = 40,

DataTypeBACnetCOVSubscription = 41,

DataTypeBACnetEventType = 42,

DataTypeBACnetEventParameter = 43,

DataTypeBACnetFileAccessMethod = 44,

DataTypeReadAccessSpecification = 45,

DataTypeReadAccessResult = 46,

DataTypeBACnetObjectPropertyReference = 47,

DataTypeBACnetSetpointReference = 48,

DataTypeBACnetDestination = 49,

DataTypeBACnetProgramState = 50,

DataTypeBACnetProgramRequest = 51,

DataTypeBACnetProgramError = 52,

DataTypeBACnetDateRange = 53,

DataTypeBACnetDailySchedule = 54,

DataTypeBACnetSpecialEvent = 55,

DataTypeBACnetClientCOV = 56,

DataTypeBACnetLogRecord = 57,

DataTypeBACnetLifeSafetyState = 58,

DataTypeBACnetLifeSafetyMode = 59,

DataTypeBACnetSilencedState = 60,

DataTypeBACnetLifeSafetyOperation = 61,

DataTypeBACnetBinaryPV = 62,

DataTypeBACnetDaysOfWeek = 63,

DataTypeBACnetWeekNDay = 64,

DataTypeBACnetTimeValue = 65,

DataTypeBACnetValue = 66,

DataTypeBACnetAddress = 67,

DataTypeBACnetPropertyIdentifier = 68,

DataTypeEnumerationValueType = 69,

DataTypeBitFieldBit = 70,

DataTypeBACnetLogDatum = 71,

DataTypeAnyType = 72,

DataTypePresentValue = 73,

DataTypeContextTag = 74,

DataTypeValueChoice = 75,

DataTypeBACnetLogStatus = 76,

DataTypeBACnetRecipientProcess = 77,

DataTypeSubscribeCOVPropertyRequest = 78,

DataTypeBACnetPropertyReference = 79,

DataTypeBACnetPropertyResult = 80,

DataTypeBACnetDeviceObjectPropertyValue = 81,

DataTypeCOVNotificationRequest = 82,

DataTypeEventNotificationRequest = 83,

DataTypeBACnetNotificationParameters = 84,

DataTypeChange_of_Bitstring = 85,

DataTypeChange_of_State=86,

DataTypeChange_of_Value=87,

DataTypeCommand_failure=88,

DataTypeFloating_limit=89,

DataTypeOut_of_Range =90,

DataTypeBACnetPropertyValue=91,

DataTypeComplex_Tag=92,

DataTypeChange_of_life_safety = 93,

DataTypeExtended=94,

DataTypeBuffer_ready =95,

DataTypeUnsigned_range = 96,

DataTypeBACnetPropertyResultValue = 97,

DataTypeServiceCOVPropSubscription = 98,

DataTypeServiceCOVSubscription = 99,

DataTypeCOVNotification = 100,

DataTypeAcknowledgeAlarmRequest = 101,

DataTypeBACnetVTOpenRequest = 102,

DataTypeBACnetPrescale = 103,

DataTypeBACnetScale = 104,

DataTypeBACnetAction = 105,

DataTypeBACnetError = 106,

DataTypeBacnetErrorType = 107,

DataTypeErrorClass = 108,

DataTypeErrorCode = 109,

DataTypeBACnetRejectReason = 110,

DataTypeBACnetAbortReason = 111,

DataTypeBDTEntry = 112,

DataTypeIpEntry = 113,

DataTypeMaskEntry = 114,

DataTypeBACnetEthernetAddress = 115,

DataTypeBACnetLonTalkAddress = 116,

DataTypeBACnetLonTalkNeuronId = 117,

DataTypeBACnetNodeType = 118,

DataTypeBACnetDeviceObjectReference = 119,

DataTypeBACnetActionCommand = 120,

DataTypeGetEventInformation = 121,

DataTypeGetEnrollmentSummaryCriteria = 122,

DataTypeGetEnrollmentSummaryCriteriaResponse = 123,

DataTypeDeviceCommunicationControl = 124,

DataTypeInt16 = 125,

DataTypeUInt16 = 126,

DataTypeUInt8 = 127,

DataTypeInt8 = 128,

DataTypeByte = 129,

DataTypeFDTEntry = 130,

DataTypeBACnetAddress_3 = 131,

DataTypeBACnetAddress_4 = 132,

DataTypeBACnetAddress_5 = 133,

DataTypePersistentDataState = 134,

DataTypeFallbackRealValue = 135,

DataTypeFallbackBinaryValue = 136,

DataTypeRealNull = 137, // PresentValue in AnalogObj

DataTypeEnumeratedNull = 138, // PresentValue in BinaryObj

DataTypeUnsignedIntegerNull = 139, // PresentValue in Multistate

DataTypeUnknown = 140,

DataTypeBACnetDiagnosisPerformance = 200,

DataTypeBACnetDiagnosisEthStatistics = 201,

DataTypeBACnetFrameStatistics = 202,

DataTypeBACnetInfo = 203,

DataTypeBACnetDiagnosis = 204,

DataTypeTcIoEthStatistic = 205,

DataTypeTcIoEthTxRxErrorCount = 206,

DataTypeTcIoEthPortStatistic = 207,

DataTypeBACnetServerStatistics = 208,

DataTypeBACnetFrameServicesDiag = 209,

// Array types

DataTypeBACnetCalendarEntryArr = ARRAYTYPE + DataTypeBACnetCalendarEntry,

DataTypeBACnetObjectIdentifierArr = ARRAYTYPE + DataTypeBACnetObjectIdentifier,

DataTypeCharacterStringExtArr = ARRAYTYPE + DataTypeCharacterStringExt,

DataTypeBACnetPriorityValueArr = ARRAYTYPE + DataTypeBACnetPriorityValue,

DataTypeBACnetTimeStampArr = ARRAYTYPE + DataTypeBACnetTimeStamp,

DataTypeBACnetVTClassArr = ARRAYTYPE + DataTypeBACnetVTClass,

DataTypeBACnetVTSessionArr = ARRAYTYPE + DataTypeBACnetVTSession,

DataTypeBACnetSessionKeyArr = ARRAYTYPE + DataTypeBACnetSessionKey,

DataTypeBACnetRecipientArr = ARRAYTYPE + DataTypeBACnetRecipient,

DataTypeBACnetAddressBindingArr = ARRAYTYPE + DataTypeBACnetAddressBinding,

DataTypeBACnetCOVSubscriptionArr = ARRAYTYPE + DataTypeBACnetCOVSubscription,

DataTypeUnsignedIntegerArr = ARRAYTYPE + DataTypeUnsignedInteger,

DataTypeBACnetDestinationArr = ARRAYTYPE + DataTypeBACnetDestination,

DataTypeBACnetDeviceObjectPropertyReferenceArr = ARRAYTYPE + DataTypeBACnetDeviceObjectPropertyReference,

DataTypeBACnetLifeSafetyStateArr = ARRAYTYPE + DataTypeBACnetLifeSafetyState,

DataTypeEnumeratedArr = ARRAYTYPE + DataTypeEnumerated,

DataTypeReadAccessSpecificationArr = ARRAYTYPE + DataTypeReadAccessSpecification,

DataTypeReadAccessResultArr = ARRAYTYPE + DataTypeReadAccessResult,

DataTypeBACnetSpecialEventArr = ARRAYTYPE + DataTypeBACnetSpecialEvent,

DataTypeBACnetLogRecordArr = ARRAYTYPE + DataTypeBACnetLogRecord,

DataTypeBACnetTimeValueArr = ARRAYTYPE + DataTypeBACnetTimeValue,

DataTypeBACnetDeviceObjectReferenceArr = ARRAYTYPE + DataTypeBACnetDeviceObjectReference,

// Listes

DataTypeBACnetTimeValueList = LISTTYPE + DataTypeBACnetTimeValue,

DataTypeBACnetSpecialEventList = LISTTYPE + DataTypeBACnetSpecialEvent,

DataTypeBACnetDailyScheduleList = LISTTYPE + DataTypeBACnetTimeValueList,

DataTypeCharacterStringExtList = LISTTYPE + DataTypeCharacterStringExt,

DataTypeBACnetLogRecordList = LISTTYPE + DataTypeBACnetLogRecord,

DataTypeUnsignedIntegerList = LISTTYPE + DataTypeUnsignedInteger,

DataTypeReadAccessResultList = LISTTYPE + DataTypeReadAccessResult,

DataTypeReadAccessSpecificationList = LISTTYPE + DataTypeReadAccessSpecification,

DataTypeBACnetValueList = LISTTYPE + DataTypeBACnetValue,

DataTypeBACnetLogDatumList = LISTTYPE + DataTypeBACnetLogDatum,

DataTypeBACnetPropertyResultList = LISTTYPE + DataTypeBACnetPropertyResult,

DataTypeBACnetPropertyReferenceList = LISTTYPE + DataTypeBACnetPropertyReference,

DataTypeCOVNotificationRequestList = LISTTYPE + DataTypeCOVNotificationRequest,

DataTypeEventNotificationRequestList = LISTTYPE + DataTypeEventNotificationRequest,

DataTypeBACnetPropertyValueList = LISTTYPE + DataTypeBACnetPropertyValue,

DataTypeBACnetActionList = LISTTYPE + DataTypeBACnetActionCommand,

DataTypeBACnetActionListList = LISTTYPE + DataTypeBACnetActionList,

};


Automation Interface

The TwinCAT System Manager offers an XML-based interface for programmatic configuration of TwinCAT BACnet/IP. All BACnet elements in a TwinCAT configuration can also be generated programmatically. For further information please refer to the general documentation for the TwinCAT Automation Interface. This section explains which parameters can be used for BACnet-specific components.

Generating BACnet client/server objects

The System Manager offers the CreateChild procedure for generating TwinCAT configuration elements. A TreeItem name, sub-type (for BACnet always 48), an insert position string or sub-type-specific information can be used as parameter.

serverItem.CreateChild("Bi_Demo", 48, "", 0x03060203);

The last parameter is also referred to as Class-ID. It identifies the element to be created. It is possible to create a BACnet device (CID_TcIoBACnetBACnetDevice), a BACnet server (CID_TcIoBACnetServer) or a BACnet client (CID_TcIoBACnetClient). BACnet server objects can be created with the Class-ID CID_TcIoBACnetObjBase together added with the object type. A BinaryInput object has the Class ID 0x03060203. BACnet client objects with base Class-ID CID_TcIoBACnetObjRemoteBase.

      ULONG CID_TcIoBACnetBACnetDevice   = 0x03060001;
ULONG CID_TcIoBACnetServer         = 0x03060110;
ULONG CID_TcIoBACnetClient         = 0x03060120;
ULONG CID_TcIoBACnetObjBase        = 0x03060200;
ULONG CID_TcIoBACnetObjRemoteBase  = 0x03060300;
ULONG CID_TcIoBACnetDynamicObject  = 0x030602FE;

Property configuration

The procedures ProduceXml and ConsumeXml are used to configure the individual TwinCAT components. Use the System Manager menu "Action" > "Export XML Description ..." to export and view the XML description for test purposes.

      <
      Parameter
      >
  <
      Name
      >TcIoBACnetPropCfg_PropTimeDelay</Name>
  <BaseType GUID="{18071995-0000-0000-0000-000000000007}">DWORD</BaseType>
  <PTCID>#x03060171</PTCID>
</Parameter>
...
<Value>
  <Name>TcIoBACnetPropCfg_PropTimeDelay</Name>
  <Value>0</Value>
</Value>

The figure shows a section of the XML description of a BACnet object generated with ProduceXml. The structure and the type of a parameter are described in the Parameter section. The actual value is specified in the Value section. The parameter ID of BACnet properties consists of 0x03060100 plus the respective property ID. The following C# source code extract shows how the value of the property TimeDelay, as shown in the "Settings" tab, can be read.

      XmlDocument doc = new System.Xml.XmlDocument();
s = objItem.ProduceXml(true);
doc.LoadXml(s);
XmlNodeList list = doc.SelectNodes("//Value[./Name='" + "TcIoBACnetPropCfg_PropTimeDelay"+ "']/Value");
UInt32 timeDelay = Convert.ToUInt32(list[0].InnerText);

When writing the property data it is advisable to first read the XML description via ProcuceXml, then to edit the parameter value and finally to read the parameter data via ConsumeXml.

      XmlDocument doc = new System.Xml.XmlDocument();
s = objItem.ProduceXml(true);
doc.LoadXml(s);
XmlNodeList list = doc.SelectNodes("//Value[./Name='" + "TcIoBACnetPropCfg_PropTimeDelay"+ "']/Value");
list[0].InnerText = 10;
objItem.ConsumeXml(doc.OuterXml);

Depending on the data type of the property, the parameter section may have to be adjusted, in addition to the parameter value. For string data types the string length must be entered under data type STRING(XX).

      <
      Parameter
      >
  <
      Name
      >TcIoBACnetPropCfg_PropObjectName</Name>
  <BaseType GUID="{18071995-0000-0000-0000-000000010006}">STRING(5)</BaseType>
  <PTCID>#x0306014d</PTCID>
</Parameter>
...
<Value>
  <Name>TcIoBACnetPropCfg_PropObjectName</Name>
  <String>CAL_0</String>
</Value>

For properties with complex data types the configuration data are stored as byte arrays. Data coding is described in more detail in section "Data types". To change complex parameter data, the BitSize and the Elements of the ArrayInfo which specifies the number of bytes has to be adjusted in the Parameter section. The actual data are coded in HEXBIN format in the Value section ( 2 hexadecimal values per byte ).

      <
      Parameter
      >
  <
      Name
       HideSubItems
      ="1">TcIoBACnetPropCfg_PropDatelist</Name>
  <BitSize>96</BitSize>
  <BaseType GUID="{18071995-0000-0000-0000-000000000001}">BYTE</BaseType>
  <ArrayInfo>
    <LBound>0</LBound>
    <Elements>12</Elements>
  </ArrayInfo>
  <PTCID>#x03060117</PTCID>
</Parameter>
...
<Value>
  <Name>TcIoBACnetPropCfg_PropDatelist</Name>
  <Data>00000000ffffffff00000000</Data>
</Value>

Process data configuration

The process data configuration within the XML description can also be modified via the Automation Interface. Each property that was activated as a process data variable has an entry in section DataArea. In TwinCAT BACnet/IP two DataAreas are available, one for input process data and one for output process data. The example shows the configuration of the DataArea with two input process data. A symbol exists for each activated property. The symbol contains the BitOffset, which determines the position of the property data in the process data image. It is important that the properties start at an aligned address (WORD symbol at addresses that can be divided by 2, DWORD symbols at addresses that can be divided by 4). The ByteSize of the DataArea indicates the size of the symbols.

      <
      DataAreas
      >
  <
      DataArea
      >
    <
      AreaNo
       AreaType
      ="InputSrc" ChildArea="1">0</AreaNo>
    <Name>Inputs</Name>
    <ContextId>1</ContextId>
    <ByteSize>4</ByteSize>
    <Symbol>
      <Name>PresentValue</Name>
      <BaseType GUID="{18071995-0000-0000-0000-000000000004}">WORD</BaseType>
      <BitSize>16</BitSize>
      <BitOffs>0</BitOffs>
    </Symbol>
    <Symbol>
      <Name>StatusFlags</Name>
      <BaseType GUID="{18071995-0000-0000-0000-000000000004}">WORD</BaseType>
      <BitSize>16</BitSize>
      <BitOffs>16</BitOffs>
    </Symbol>
  </DataArea>
  <DataArea>
    <AreaNo AreaType="OutputDst" ChildArea="1">1</AreaNo>
    <Name>Outputs</Name>
    <ContextId>1</ContextId>
    <ByteSize>0</ByteSize>
  </DataArea>
</DataAreas>

In addition to the configuration of the DataArea symbols, the parameters TcIoBACnetPdInCfg and TcIoBACnetPdOutCfg must contain information for the BACnet stack as to which property data should be treated as process data. If the parameters TcIoBACnetPdInCfg and TcIoBACnetPdOutCfg are changed, the data length has to be adjusted in the Parameter section. The structure of the two parameters is explained below.

      <
      Value
      >
  <
      Name
      >TcIoBACnetPdInCfg</Name>
  <Data>0000000055000000100000006f000000</Data>
</Value>

BACnet Server

For each activated process data property, the parameters TcIoBACnetPdInCfg and TcIoBACnetPdOutCfg must contain an element with structure ProcessDataServerCfg. The structure must specify to which bit offset the data should be copied, the property type (propId), and for output process data the priority with which the property data are to be copied to the PriorityArray.

      structProcessDataServerCfg
{
    ULONG bitOffs;
    USHORT propId;
    USHORT priority;
}

BACnet Client

Client objects also have further parameters in addition to the symbol configuration, which specify the configuration of the property process data. In client objects a distinction is made between input process data and output process data. The structure fields match the configuration dialogs in the System Manager.

      structProcessDataClientInCfg
{
    USHORT propId;
    USHORT useCov      : 1;
    USHORT usePolling  : 1;
    USHORT reserved    : 6;
    USHORT tickModulo  : 8;
    ULONG timeDataCOV;
    ULONG timeDataPoll;
    ULONG bitOffs;
    ULONG bitLen;
    floatcovIncrement;
}

      struct ProcessDataClientOutCfg
{
    USHORT propId;
    USHORT useWriteOnChange : 1;
    USHORT usePeriodicWrite : 1;
    USHORT usePriority      : 1;
    USHORT reserved         : 5;
    USHORT tickModulo       : 8;
    ULONG priority;
    ULONG cycleTime;
    ULONG bitOffs;
    ULONG bitLen;
}


Automation Interface .NET

TS8020 | TwinCAT BACnet Supplement

Automation Interface and the Microsoft .NET Framework

The functionality presented in this section is not covered by the general Beckhoff support. Use at your own risk. We are unable to guarantee the correctness of the presented functions. Please notify us of any errors you may find.

The library BACnetExtensionCtrl.dll (supplied with TwinCAT) is available for using the Automation Interface from the Microsoft .NET Framework. The library includes wrapper functions, which facilitate programmatic creation of a TwinCAT BACnet/IP configuration with C#, for example. This section uses selected examples to explain how to use the library. Not all options of the implemented functions are discussed in detail. A full overview of all functions can be obtained by using Visual Studio IntelliSense. All BACnet-specific functions are located in the TwinCAT.BACnet namespace.

To use the library, references to the following files have to be added to a .NET project:

  • C:\TwinCAT\Io\AddIns\BACnetExtensionCtrl.dll
  • C:\TwinCAT\Io\AddIns\TCatSysManagerLib.dll

The examples are based on the following namespace declaration:

      using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using TCatSysManagerLib;
using TwinCAT.BACnet.Extension;
using TwinCAT.BACnet.ExtensionHelper;
using TwinCAT.BACnet.BACnetDefinitions;
using System.Xml;

First obtain a reference to the TwinCAT System Manager.

ITcSysManager ipSysMan = (ITcSysManager)Activator.CreateInstance(Type.GetTypeFromProgID("TCatSysManager.TcSysManager"));

BACnet device configuration

In the TwinCAT.BACnet.Extension namespace a BACnetDevice can be created with the aid of the BACnetExtension class (CreateBACnetDevice). Elements are configured in the Automation Interface with the functions ProduceXml and ConsumeXml. ProduceXml is used for read parameters, ConsumtXml for writing. To obtain default parameters, a configuration should normally be read before parameters are modified. This can be done with the wrapper function BACnetExtension.GetXml. Further wrapper functions can then be used to manipulate data in the XML document. Modified parameters can be saved with the function XmlHelper.ConsumeAll. The function XmlHelper.ConsumeParameters can be used in cases where only parameters were modified, but not process data. This makes processing of ConsumeParameters more efficient. In general it is advisable to use the ConsumeXml functions of the BACnet library, because it includes optimisations that speed up project generation for larger projects.

Most functions of BACnetExtensionCtrl.dll support 2 options. One option uses an ITcSmTreeItem as parameter. In this case ProduceXml and ConsumeXml are called internally. In the second variant an XmlDocument is transferred, and the system expects reading and writing of the data to be realised externally. For complex operations on a TreeItem the functions with XmlDocument should be used, since ConsumeXml is a potentially calculation-intensive operation that should not be called repeatedly.

The following example describes the creation of a BACnet device. The mode for relative AmsNetIDs is activated. This is recommended for automatically generated projects, since in this case a valid AmsNetID is automatically calculated on the target system. The first four digits of the system Net ID are used for this purpose. The function SetNetworkAdapterVirtualName can be used to create the network adapter configuration via a virtual device name. This is sensible on Windows CE-based systems, since the generated configuration can be used on any CXxxx devices, without having to manually select a network adapter during commissioning. By default, the IP address is automatically obtained from the operating system: SetUseOsIpSettingsMode. In addition, automatic summer/winter time adjustment through the operating system is activated (ActivateOsTimeMode).

      ITcSmTreeItemipDevice = BACnetExtension.CreateBACnetDevice(ipSysMan);
XmlDocument doc = BACnetExtension.GetXml(ipDevice);
BACnetDeviceConfiguration.EnableRelativeAmsNetIdMode(doc);
BACnetDeviceConfiguration.SetNetworkAdapterVirtualName(doc, "TCIXPNPE1");
// use ip given by operating system
BACnetDeviceConfiguration.SetUseOsIpSettingsMode(doc, true);
// set daylightsavings status to automatic ( is also default )
BACnetDeviceConfiguration.ActivateOsTimeMode(doc);
// Commit all changes made to BACnet-Device configuration
XmlHelper.ConsumeAll(ipDevice, doc);

BACnet server configuration

The function BACnetDeviceConfiguration.CreateBACnetServer can be used to create a BACnet server. To this end an ITcSmTreeItem has to be transferred to a BACnet device, with a BACnet ID as parameter. The example explains how to configure a password and how to activate persistent data.

      ITcSmTreeItem ipServer = BACnetDeviceConfiguration.CreateBACnetServer(ipDevice, 123);
doc = BACnetExtension.GetXml(ipServer);
BACnetServerConfiguration.SetPassword(doc, newBACnetCharacterString("secure"));
// enable persistent data
BACnetServerConfiguration.SetPersistentDataMode(doc, true);
BACnetServerConfiguration.SetPersistentDataUsvMode(doc, false);
BACnetServerConfiguration.SetPersistentDataInterval(doc, 30 * 60); // set persistent data interval to 30 min.
// Commit all changes made to BACnet-Server configuration
XmlHelper.ConsumeAll(ipServer, doc);

BACnet object configuration

Object creation and property access

The function CreateObject can be used to create new BACnet objects. The system supports a mode with automatic ID generation and explicit configuration with an object ID. The function WriteProperty can be used to manipulate property values. The data type is specified in <> after the function. The generally Automation Interface section describes how the property data types are derived. The function ReadProperty can be used without <> in order to determine the data types of properties. In this way parameters can be read and the type of the returned .NET object generated as output.

In the example several properties are configured. For properties of data type String a suitable UTF8 coding is created automatically. In other words, the UCS2 strings used in .NET are converted to the BACnet-specific UTF8 format.

      // automatic mode -> obj-id and objname are assigned automatically

      ITcSmTreeItem biObj = BACnetServerConfiguration.CreateObject(ipServer, BACnetObjectType.BinaryInput);
// manual obj-id configuration
ITcSmTreeItem boObj = BACnetServerConfiguration.CreateObject(ipServer, BACnetObjectType.BinaryOutput, 17);
doc = BACnetExtension.GetXml(boObj);
BACnetObjectConfiguration.WriteProperty<string>(doc, BACnetPropertyIdentifier.Description, "компании Beckhoff"); // UTF-8 Support
BACnetObjectConfiguration.WriteProperty<string>(doc, BACnetPropertyIdentifier.ObjectName, "bo_12_x");
BACnetObjectConfiguration.WriteProperty<bool>(doc, BACnetPropertyIdentifier.OutOfService, true);
BACnetObjectConfiguration.WriteProperty<Byte[]>(doc, BACnetPropertyIdentifier.EventEnable, newByte[] { 0x05, 0xE0 });
XmlHelper.ConsumeAll(boObj, doc);

In the following example 10 MultistateValue objects are generated and configured with an increasing number of states (NumberOfStates).

      // create 10 multistate value objects with increasing number of states

      for (uint i = 0; i < 10; i++)
{
    ITcSmTreeItem mvObj = BACnetServerConfiguration.CreateObject(ipServer, BACnetObjectType.MultiStateValue);
    doc = BACnetExtension.GetXml(mvObj);
    CharacterStringExtList stateText = newCharacterStringExtList();
    for( int j=0; j<i+2; j++ )
        stateText.AddCharacterString("MV_State_" + j.ToString());
    BACnetObjectConfiguration.WriteProperty<CharacterStringExtList>(doc, BACnetPropertyIdentifier.StateText, stateText);
    BACnetObjectConfiguration.WriteProperty<string>(doc, BACnetPropertyIdentifier.Description, "Object with " + i.ToString() +" states");
    BACnetObjectConfiguration.WriteProperty<UInt32>(doc, BACnetPropertyIdentifier.NumberOfStates, i + 2);
    XmlHelper.ConsumeAll(mvObj, doc);
}

The library can also be used to configure complex BACnet properties. In the following example the Datelist property of a Calendar object is configured with DateRange, Date and WeekNDay entries. The WriteProperty library function converts the .NET classes/objects to serial data streams (byte arrays) and stores them in the XmlDocument in HexBin format.

      ITcSmTreeItem calObj = BACnetServerConfiguration.CreateObject(ipServer, BACnetObjectType.Calendar);
doc = BACnetExtension.GetXml(calObj);
BACnetCalendarEntry[] calEntries = newBACnetCalendarEntry[3];
calEntries[0] = newBACnetCalendarEntry(newBACnetDate(112, 1, 1, 255)); // Add date: 1.Jan.2012
calEntries[1] = newBACnetCalendarEntry(newBACnetDateRange(newBACnetDate(255, 1,1,255), newBACnetDate(255, 7,19,155))); // DateRange 1.7.-19.7
calEntries[2] = newBACnetCalendarEntry(newBACnetWeekNDay(255, 255, 7)); // every sunday
BACnetObjectConfiguration.WriteProperty<BACnetCalendarEntry[]>(doc, BACnetPropertyIdentifier.Datelist, calEntries);
XmlHelper.ConsumeAll(calObj, doc);

The following examples shows the configuration of a schedule object's exception schedule. The exception list will be active if the calendar object created before is active. The example demonstrates blinking with a frequency of 10 Hz of a BinaryOutput object having the object identifier instance 10.

      // remember calendar object for schedule configuration

      BACnetObjectIdentifier calObjId = BACnetObjectConfiguration.ReadProperty<BACnetObjectIdentifier>(doc, BACnetPropertyIdentifier.ObjectIdentifier);
ITcSmTreeItem schedObj = BACnetServerConfiguration.CreateObject(ipServer, BACnetObjectType.Schedule);
doc = BACnetExtension.GetXml(schedObj);

// blink with 10 Hz
BACnetSpecialEvent specialEvent = newBACnetSpecialEvent(calObjId, 1, newBACnetTimeValueList());
    specialEvent.AddBACnetTimeValue(
    newBACnetTimeValue(newBACnetTime(255, 255, 255, 0),
    newBACnetValue(BACnetBinaryPV.active)));
    specialEvent.AddBACnetTimeValue(
    newBACnetTimeValue(newBACnetTime(255, 255, 255, 50),
    newBACnetValue(BACnetBinaryPV.inactive)));

BACnetObjectConfiguration.WriteProperty<BACnetSpecialEventList>(
    doc,
    BACnetPropertyIdentifier.ExceptionSchedule,
    newBACnetSpecialEventList(newBACnetSpecialEvent[] { specialEvent }));
// set object/property reference to BO:0
BACnetObjectConfiguration.WriteProperty<BACnetDeviceObjectPropertyReference[]>(
    doc,
    BACnetPropertyIdentifier.ListOfObjectPropertyRefs,
    newBACnetDeviceObjectPropertyReference[]{newBACnetDeviceObjectPropertyReference(
    newBACnetObjectIdentifier(BACnetObjectType.BinaryOutput, 17), BACnetPropertyIdentifier.PresentValue)});
    XmlHelper.ConsumeAll(schedObj, doc);

Process data configuration

The library can also be used to activate process data of BACnet objects and link them via the LinkVariables functions of the Automation Interface. In the example a BinaryInput object and a BinaryOutput object is created, and the PresentValue properties are linked via Device2Device mapping. The function XmlHelper.GetBaseTypeBitSize can be used to determine the bit length of the property process data, which is required as parameter for the function LinkVariables.

      // create to objects to be linked together ( BO is on whenever BI is on )
ITcSmTreeItem pdBiObj = BACnetServerConfiguration.CreateObject(ipServer, BACnetObjectType.BinaryInput);
ITcSmTreeItem pdBoObj = BACnetServerConfiguration.CreateObject(ipServer, BACnetObjectType.BinaryOutput);
// add property PresentValue as input process data
doc = BACnetExtension.GetXml(pdBiObj);
string biVarName = BACnetObjectConfiguration.AddInputSymbolChecked(doc, BACnetPropertyIdentifier.PresentValue, BACnetObjectType.BinaryInput, false, null);
XmlHelper.ConsumeAll(pdBiObj, doc);
// add property PresentValue as output process data with priority 10
doc = BACnetExtension.GetXml(pdBoObj);
string boVarName = BACnetObjectConfiguration.AddOutputSymbolChecked(doc, BACnetPropertyIdentifier.PresentValue_Priority10, BACnetObjectType.BinaryOutput, false, null);
XmlHelper.ConsumeAll(pdBoObj, doc);
// get Property description to get process data size of present value properties
PropEntryDesc eDesc = PropertyDescriptions.GetPropDesc(BACnetPropertyIdentifier.PresentValue);
uint bitLen = XmlHelper.GetBaseTypeBitSize(eDesc.GetProcessDataTmcType(BACnetObjectType.BinaryInput));
// link the objects via process data
ipSysMan.LinkVariables(pdBiObj.PathName + "^Inputs^" + biVarName, pdBoObj.PathName + "^Outputs^" + boVarName, 0, 0, (int)bitLen);

Optional properties

Optional properties can be activated and deactivated with the library functions EnableProperty and DisableProperty. The example also demonstrates the process of iteration over all properties of an object type. DisableProperty supports disabling of related properties. If a property is disabled that requires the existence of a second property, this is also automatically disabled. For example, to deactivate all properties of Instrinsic Reporting, it is sufficient to deactivate the property NotifyType.

ITcSmTreeItem bvObj = BACnetServerConfiguration.CreateObject(ipServer, BACnetObjectType.BinaryValue);
doc = BACnetExtension.GetXml(bvObj);
// disable all optional properties
foreach (BACnetPropertyIdentifier prop inPropertyDescriptions.GetSupportedActiveOnlineProps(doc, BACnetObjectType.BinaryValue, true))
{
    eDesc = PropertyDescriptions.GetPropDesc(prop);
    if (PropertyDescriptions.IsOptProp(BACnetObjectType.BinaryValue, prop))
        PropertyDescriptions.DisableProperty(doc, BACnetObjectType.BinaryValue, prop);
}
XmlHelper.ConsumeAll(bvObj, doc);

Write protection configuration

The function EnablePropertyWriteProtection can be used to activate write protection for a property.

      ITcSmTreeItem bv2Obj = BACnetServerConfiguration.CreateObject(ipServer, BACnetObjectType.BinaryValue);
doc = BACnetExtension.GetXml(bv2Obj);
// enable write protection for all writable properties
foreach (BACnetPropertyIdentifier prop inPropertyDescriptions.GetSupportedActiveOnlineProps(doc, BACnetObjectType.BinaryValue, true))
{
    eDesc = PropertyDescriptions.GetPropDesc(prop);
    if (PropertyDescriptions.IsWritable(BACnetObjectType.BinaryValue, prop))
        PropertyDescriptions.EnablePropertyWriteProtection(doc, BACnetObjectType.BinaryValue, prop);
}
XmlHelper.ConsumeAll(bv2Obj, doc);

The function ObjectDescriptions.SupportedOfflineProps can be used to iterate over all properties that can be configured in the Settings dialog for the objects. In contrast, GetSupportedActiveOnlineProps iterates over all object properties that exist at runtime.

BACnet client configuration

Functions are also available for configuring remote BACnet devices. CreateBACnetClient creates a BACnet client with specified BACnet ID. The function CreateRemoteObject can be used to create BACnet objects. Process data of client objects can be activated and linked via the LinkVariables function of the Automation Interface. A RemotePdCfg has to be transferred to the functions AddInputSymbol and AddOutputSymbol, which configures the process data processing mode. RemotePdCfg consolidates parameters for read and write property access. This means that the remote configuration can initially be created and then be used for creating input and output symbols. The modes correspond to the options that can be configured in the System Manager ( Polling, COV, WriteOnChange etc.). The parameters RemotePdReadTickModulo and RemotePdWriteTickModulo can be used to specify in which cycle client interactions are to take place. In systems with many client objects it is advisable to distribute the interactions over several cycles.

Functions with the suffix Checked verify whether a process data variable has already been activated before attempting to activate it. If necessary, the variable is deactivated and then reactivated.

        ITcSmTreeItem ipClient = BACnetDeviceConfiguration.CreateBACnetClient(ipDevice, 42);
// create BACnet remote object
ITcSmTreeItem remAV = BACnetClientConfiguration.CreateRemoteObject(ipClient, BACnetObjectType.AnalogValue, 17);
doc = BACnetExtension.GetXml(remAV);
// add input symbol - read data from remote device
BACnetObjectConfiguration.AddInputSymbolChecked(
    doc,
    BACnetPropertyIdentifier.PresentValue,
    BACnetObjectType.AnalogValue,
    true,
    newBACnetObjectConfiguration.RemotePdCfg(BACnetObjectConfiguration.RemotePdCfg.RemotePdReadMode.COV_POLL, 1000, 1.0f, 240));
// add output symbol - with explicit remote configuration
// write property present value on change with priority 10
BACnetObjectConfiguration.RemotePdCfg remoteCfg = newBACnetObjectConfiguration.RemotePdCfg();
remoteCfg.WriteMode = BACnetObjectConfiguration.RemotePdCfg.RemotePdWriteMode.ONCHANGE;
remoteCfg.UsePriority = true;
remoteCfg.priority = 10;
remoteCfg.RemotePdWriteTickModulo = 2;
remoteCfg.resubsInterval = 240;
remoteCfg.cycleTimeWrite = 2000;
BACnetObjectConfiguration.AddOutputSymbolChecked(
    doc,
    BACnetPropertyIdentifier.PresentValue,
    BACnetObjectType.AnalogValue,    true,
    remoteCfg);
XmlHelper.ConsumeAll(remAV, doc);

Notification sink configuration

The BACnetExtensionCtrl library can also be used to create a notification sink. In the following example a notification sink with the process ID 100 is created. Subsequently a NotificationClass object is created and configured for sending local EventNotifications to the notification sink.

        ITcSmTreeItem ipSink = BACnetDeviceConfiguration.CreateNotificationSink(ipDevice);
doc = BACnetExtension.GetXml(ipSink);
BACnetNotificationSinkConfiguration.SetProcessId(doc, 100);
XmlHelper.ConsumeAll(ipSink, doc);
ITcSmTreeItem ipNotifyObj = BACnetServerConfiguration.CreateObject(ipServer, BACnetObjectType.NotificationClass);
doc = BACnetExtension.GetXml(ipNotifyObj);
BACnetDestination[] destArr = newBACnetDestination[1];
destArr[0] = newBACnetDestination();
destArr[0].processIdentifier = 100;
destArr[0].recipient = newBACnetRecipient(newBACnetObjectIdentifier(BACnetObjectType.Device, 123));
BACnetObjectConfiguration.WriteProperty<BACnetDestination[]>(doc, BACnetPropertyIdentifier.RecipientList, destArr);
XmlHelper.ConsumeAll(ipNotifyObj, doc);

The configuration can then be saved. The SaveConfiguration function of the Automation Interface is used to save the configuration.

ipSysMan.SaveConfiguration("C:\\BACnetExample.tsm");

All source code extracts presented in this section are available in the form of an executable Visual Studio project in the following .zip file. The project can also be used as a starting point for a separate project.


Persistent data

TS8020 | TwinCAT BACnet Supplement

Advanced Settings

Advanced settings can be made in the Settings tab of the BACnet device, as explained below.

Memory-specific parameters

Data structure-specific parameters can be adjusted via the Advanced settings. Essentially these parameters affect the available memory in the BACnet stack.

Parameter | Default value (min./max.) | Description
MAX_OBJ_SUBS_COV_ENTRIES | 10 ( 1 - 255 ) | The COV subscriptions are managed in TwinCAT BACnet/IP for each object. The default setting is 10 subscriptions per BACnet object. These parameters can be used to specify the maximum number of COV subscriptions per object. For performance reasons it may make sense to reduce the value of this parameter. in order to avoid excessive COV notifications if there are many changes in the system.
MAX_PROPERTY_ARRAYELEMENTS | 200 ( 10 - 10000 ) | For BACnet properties with array data types in TwinCAT BACnet/IP (data type ends with []), a memory for a pre-defined number of elements is created on startup, so that elements can be added dynamically during operation. By default up to 200 elements can be stored in an array property. If more than 200 elements are configured in an array property in the Settings dialog, additional memory capacity is automatically created during startup in order to accommodate all elements.
LIST_ALLOC_MEM_BYTES | 8192 ( 500 - 4294967295 ) | For properties with list data type in TwinCAT BACnet/IP (data type ends with list), the memory capacity required per element may vary. On startup a predefined memory is created, so that elements can also be added and modified dynamically for these properties. The default configuration is 8 kbytes. Via this parameter the memory capacity per list property can be defined. As for the array properties, if the property is configured with more memory in the Settings dialog, more memory is created.
MAX_DEVICE_BINDINGS | 1000 ( 10 - 10000 ) | Each device in the BACnet network (which sends an I-Am packet) is administered in the DeviceBindings table, where all the parameters required for the communication with a device are stored. The size of this table can be specified via this parameter. The table is cleared on each restart and when a scan process is triggered (e.g. in the System Manager).
MAX_OBJECTS | 1000 ( 10 - 4294967295 ) | BACnet objects for each BACnet client and BACnet server are administered in hash tables. This parameter defines the size of these tables. If a configuration is intended to contain BACnet servers and BACnet clients with more than 1000 objects, this parameter has to be increased. The number of objects refers to the total number of all objects configured under BACnet servers and BACnet clients and must be selected accordingly. When BACnet objects are added in the System Manager or through scanning of BACnet clients this parameter is automatically incremented in steps of 100. To support creation of a large number of dynamic objects at runtime this parameter should be increased manually.
MAX_CLIENTS | 255 ( 10 - 10000 ) | The clients created in the System Manager are administered in a list. If more than 255 (statically configured in the System Manager) clients are to be used, this parameter must be increased.
MAX_TRENDLOG_ENTRYSIZE | 56 ( 56 - 10000 ) | For TrendLog objects the memory for the LogBuffer is also created on startup. The parameter BufferSize can be used to specify the number of entries as a BACnet property. The memory size required for an entry depends on the logged property. The minimum size of 56 bytes is adequate for error log entries and for logging simple data types (REAL, Integer ...). If this entry: “Resources: No_space_to_write_property” appears in the LogBuffer, the available memory is inadequate, and the value of this parameter has to be increased.
DYN_TRENDLOG_BUFFERSIZE | 100 ( 10 - 10000 ) | Since the memory for the TrendLog buffer is created when the BACnet object is generated, for dynamically created TrendLog objects the value of the BACnet property BufferSize must be known. This is specified via this parameter.
MAX_MULTISTATE_DYNSTATES | 255 ( 2 - 10000 ) | For MultiState objects memory must be created for the BACnet property StateText during startup. The maximum possible number of states (NumberOfStates) must be known, since the BACnet property NumberOfStates can be modified during runtime. This parameter defines the maximum value of the property NumberOfStates and therefore the amount of memory to be created during startup.
MAX_RECV_BAC_SEGM_FRAMES | 1000 ( 100 - 10000 ) | The components of segmented frames have to be held in the buffer, so that they can be recombined to the original message once all components have been received. This parameter has to be set accordingly, depending on the envisaged parallel processing of segmented messages.
MAX_SEND_BAC_SEGM_FRAMES | 1000 ( 100 - 10000 ) | During sending messages may also have to be segmented . Frames prepared for sending are stored in the table. The size of this table can be set via this parameter.
IO_STARTUP_TIMEOUT | 2000 ( 0 - 10000 ) | The initialisation of a connected fieldbus (K-bus, EtherCAT) may take longer than starting of the BACnet server. This may result in the automatic fieldbus monitoring (Reliability, StatusFlags) setting all IO BACnet objects to an error state, which on the one hand generates trend log entries with set fault bits in the StatusFlags, but may also lead to notifications being sent. The state machine of the BACnet server can therefore be delayed by an IO start time, in order to await successful initialisation of the fieldbus during startup.

Network adapter queues

Small changes in BACnet may result in many messages being sent, for example if too many COV subscriptions exist on a particular property, or too many notification recipients were entered in a NotificationClass. In the TwinCAT default configuration, BACnet/IP Ethernet frames are sent directly to the network driver. If there are many Ethernet frames within a cycle, the memory resources may become overloaded. To avoid this, an additional queue can be configured in the BACnet stack, in which the frames can be held in the buffer, if Ethernet frames cannot be sent directly. By activating the option “Use separate Recv/Send queues” the user can configure the size of the corresponding send queue.

Due to the asynchronous activities in BACnet it is advisable to use a high task priority for BACnet (default=58), in order to avoid jeopardising the real-time (timeliness) of other TwinCAT activities. For BACnet itself no strict real-time limits are specified for each protocol. However, high task-priorities may result in BACnet being displaced by other tasks, so that BACnet is activated less often than the specified cycle time. This may lead to the receive buffers of the network driver filling up, since they are then not processed by the BACnet stack. In order to deal with this issue, TwinCAT BACnet/IP offers an option to use a receive queue and a further task, with the sole purpose of copying the Ethernet frames from the network driver and saving them in a queue for subsequent processing. The priority of this task can be set in the Network Adapter Queues dialog, and the task cycle time in the respective task dialog.

The figure shows the principle of operation of the network queues. The maximum number of frames that can be processed is limited by the NDIS driver, which can hold a maximum of 255 frames each on the send and receive side. By activating the network queues an additional task (Q) can copy the frames to internal BACnet structures, thereby decoupling the processing from the BACnet task (B).


FB_BACnet_Program

TwinCAT BACnet/IP - Programierung

BACnet_Globals

VAR_GLOBAL
(* global linkable BACnet adapter *)
    fbBACnet_Adapter : FB_BACnet_Adapter;
(* global visible BACnet adapter reference *)
    pBACnet_Adapter : POINTER TO FB_BACnet_Adapter;
END_VAR
VAR_GLOBAL CONSTANT
    tBACnet_ADSTimeOut : TIME := t#5s;
END_VAR