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 the entry: "Resources:No_space_to_write_property" appears in the LogBuffer, the available memory is not sufficient and the value of this parameter must 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 initialization 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 StateMachine of the BACnet server can therefore be delayed by an I/O start time, in order to await successful initialization of the fieldbus during startup. |
MAX_PARALLEL_COV_SUBS | 250 ( 1 - 255 ) | When using client process data in COV mode, slow remote stations may result in communication failures, or COV subscriptions may not be completed successfully. This parameter can be used to set the maximum number of concurrent COV subscription requests per BACnet client. |
AVERAGING_MAX_BUFFERSIZE | 1000 ( 1 - 10000 ) | Sets the size of the internal buffer for averaging. This buffer stores data for the calculation of statistical data (average value etc.). If the calculation is based on more than 1000 samples, this parameter must be increased. |
MAX_SENDFRAMES_PERCYCLE | 4294967295 ( 1 - 4294967295 ) | In order to limit temporary peak loads relating to sent BACnet telegrams, the number of frames to be sent per cycle can be limited. With a cycle time of 50 ms and a value of 1, the maximum number of frames that are sent per second is 20. This mechanism can be used to prevent flooding of the BACnet network in certain cases. However, in general it is better to find the cause for the large number of sent frames and rectify it, e.g. through the use of filters for AnalogInput objects. |
PROPOSED_WINDOW_SIZE | 16 ( 1 - 127 ) | Segmentation is used in BACnet when transferring large amounts of data. The maximum number of open unconfirmed sent messages is "negotiated" when the connection is established. This parameter determines what "window size" (i.e. the number of unconfirmed messages) is suggested by this device. For the CX8091, this value must be reduced to 4, because otherwise file access will not work due to limited network storage. |
FREERUN_CYCLETIME_MODULO | 10 ( 1 - 100 ) | In Freerun mode, the internal state machines of the BACnet objects are called with a cycle time of 2 ms. For large BACnet configurations this can lead to system overload. This parameter specifies after how many cycles BACnet objects are called. In the default case (10), the BACnet objects are therefore processed only every 20 ms. |
ARCHIVE_BUFFER_SIZE | 65535 ( 65535 - 16777216 ) | A buffer is used for persistent data that have to be stored. This buffer should be at least as large as the largest property in the system. Typically, it is the property LogBuffer of a TrendLog object. With a size of 40 bytes per entry (normal value, no error), the default value of 65535 for this parameter is exceeded from 1638 entries. In this case, this parameter should be increased. With a LogBuffer of 3000 entries, the value should therefore be set to 120,000 bytes (40*3000) |
Network adapter queues
Small changes can easily lead to the sending of many messages in BACnet. E.g. because many COV subscriptions to a certain property exist, or many notification recipients have been entered in a NotificationClass. Due to this asynchronous nature, BACnet runs in a low-priority task, in order to avoid delays in the PLC and the IO subsystem. For large configurations, the cycle time of the task should be configured in the range 40 ms to 100 ms. This processing "in the background" results in network adapter functions being executed less frequently. When receiving messages, this may result in buffer overflow in the driver and therefore loss of messages. Network hardware overload situations can also occur during sending of BACnet messages, if too many messages have to be sent within a cycle.
BACnet therefore offers different modes for processing network messages, in order to optimize the functionality of the network adapter. To cope with overloading during sending and receiving, BACnet uses a send buffer and a receive buffer with sizes that can be defined separately. The following diagram illustrates the operating principle of these "queues". On the left, BACnet messages are received via the NDIS driver, for example. A task (Q) copies these messages to the Recv queue. The messages are then processed in the context of the BACnet task (B), and potential messages are sent. If adequate resources are available in the network adapter, the message is sent directly (1); otherwise, messages are buffered in the Send queue and sent in the context of the task Q.
BACnet supports 3 network adapter modes, which essentially differ in terms of the context of which task (Q shown in the image) the functions for receiving and sending the network adapter are called:
- In Normal mode, network adapter-specific functions are executed in the context of the BACnet task itself. At the start of the cycle, all messages are copied into the receive buffer and processed further from there.
- In multi-protocol mode, network adapter-specific functions are executed in the context of another task. This mode must be used if further Ethernet-based drivers (such as real-time Ethernet) are operated in parallel with BACnet via the same network interface.
- In queue task mode, network adapter-specific functions are executed in the context of a special queue task. This mode is used when the BACnet task is operated with high cycle times, for example. The high-priority queue task with lower cycle time copies the messages from the network driver into the internal BACnet Recv queue and/or send messages from the Send queue. As a result, faster use is made of the hardware resources, while complex calculations continue to be executed with low priority.
The "Network Adapter Settings" dialog can be used for network adapter-specific settings. The size of send and receive queues can specified separately. In addition, the priority of the queue task can be specified, and the mode for the network adapter operation can be selected, of course.
The individual modes should be selected based on the following recommendations:
- Normal Mode
- Short BACnet cycle times (<20 ms)
- High-performance device (CX50XX)
- Multiprotocol Mode
- If real-time Ethernet is used!
- The trigger cycle should not be too long (<10 ms)
- Queue Task Mode
- Low-capacity devices (CX9010, CX8091, CX9020)
- Always for CCAT (CX8091)
- Long BACnet cycle time (>20 ms)
- Queue task with 1 ms at best (costs approx. 5-10% performance)
Typical setting for CX8091
BACnet task: 50 ms – 100 ms
SystemManager Settings
The dialog "BACnet System Manager Settings" can be used for BACnet-specific settings for the configuration software, i.e. the TwinCAT SystemManager.
The "Generate..." item can be used to specify whether StructuredView-specific property contents are created automatically when a BACnet configuration is activated. This enables the hierarchical representation of the SystemManager to be displayed in the BACnet network. This item is enabled by default, i.e. the StructuredView information is generated. In principle, StructuredView enables display of several views (e.g. at the device level, location-dependent or commercial). To implement specific requirements for StructuredView objects in a project, which go beyond the order of BACnet objects, this item can be disabled, so that StructuredView objects can be configured manually.
The "Optimize ..." item can be used to specify whether the interaction modulo factors for the interaction with remote BACnet devices should be optimized automatically. This feature is enabled by default.
The "Fixed ..." item can be used to specify that the object structure under a BACnet client should not be changed during scanning. If only a few objects are integrated in the cross communication, it may be useful to add only the actually used BACnet objects via PLC automapping. If this item is enabled, the object identifiers are verified during scanning, based on the BACnet object name. If changes are detected, new ObjectIdentifiers can be applied. This feature is also useful if only the object names are available during project planning, but not the ObjectIdentifier.
The "Plc ..." item can be used to specify the starting point of instance numbers for object identifiers that were generated automatically during PLC automapping. This functionality is required for the Remap function, in order to avoid collisions with outdated persistent data (.wbp).
UDP-Port Settings
The dialog "UDP settings" can be used to specify the UDP port used by BACnet.
The BACnet network number can also be set here. In pure BACnet/IP systems, configuration of the network number is usually not required. If the network number is set to a value other than 0 for purpose of additional splitting of a BACnet/IP network, then the following behavior is implemented in the BACnet stack:
- The network number is sent in the I-Am frame
- Only BACnet frames without network number or with the configured network number are accepted
- Optionally, the configured network number is transferred as the source address
The "Disable IP checksum check" item can be used to disable verification of the IP checksum. This function should only be activated if it is essential to communicate with devices that do not implement a correct checksum calculation.