Frequently asked questions

I.  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 must 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).
4. 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 properties subscriptions, which the server permits per object?
• On the server side the following parameter needs to be adjusted to increase the maximum number of subscriptions per object (see Advanced Settings under Memory-specific parameters):
• a.  Select the BACnet adapter of the appropriate server
  
• b.  Press button "Configure" under "Advanced Settings - Data Structures"
  
• c.  Increase parameter "MAX_OBJ_SUBS_COV_ENTRIES" accordingly
  
• d.  Press button "Save" to store changes / button "Cancel" to abort
• e.  Apply changes with symbol "Activate configuration" respectively with symbol "Reload I/O devices (F4)" in mode "CONFIG" from the tool bar.

II.  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 initialized 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 must be acknowledged. The local BACnet adapter can be monitored with the aid of the device status (see item 1.).

III.  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.

IV.  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.

V.  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.

VI.  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”).

VII.  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?
• a.  Create a new task in the TwinCAT System Manager
  
• b.  Configure the task; activate Auto start and set the required cycle time (Cycle ticks)
  
• c.  Add a variable for the mapping (e.g. CycleTime of type UINT)
  
• d.  Link the K-bus variable “CycleTime” and task variable “K_Bus_CycleTime”
  
• e.  Activate the modified configuration with the icon “Activate configuration” in the toolbar

VIII.  Why does the property StatusFlags of an object have the value 0x0004 or the property EventEnable the value 0x0005, even though 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”.

IX.  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...
• a.  Activate option “Optimize Process Data Access (Tick Modulo)”
• b.  Activate option “Change Process Data In Configuration (Read)”
• c.  Set mode “Process Data Read Mode” to “Polling”
• d.  Set parameter "Cycle Time (ms)” to 10000 = 10 seconds read cycle, for example
      Notice This parameter must be optimized 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.

X.  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.