BACnet device

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 initialized 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 (summertime/wintertime) 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").

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 visualization of alarm messages (event notifications). COV notification subscriptions should only be used if state changes of complex BACnet properties must 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 of 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.