BACnet communication protocol

Supported device types and versions
Communication line configuration
Communication station configuration
I/O tag configuration
Scheduler in Siemens Desigo devices
Scheduler in Delta Controls devices
Information about events
Information about alarms
Comment on the address cache
Comment on Delta Controls devices
Comment on E-DDC3.1 devices
Comment on Siemens Desigo devices
Comment on Klimasoft MBG-MSTP devices
Comment on iLON 10 Ethernet adapter
Comment on BACnet MS/TP implementation
Tell commands
Literature
Changes and modifications
Document revisions

...

• Siemens
  • Desigo PXM20 (Control unit, LON interface, BACnet over LON)
  • Desigo PXC22 (Control station, LON interface, BACnet over LON)
  • Desigo PXC22-E.D (Control station, Ethernet interface, BACnet/IP)
  • Desigo PXG80-N (BACnet router, Ethernet interface, LON interface, BACnet/IP, BACnet over LON)
• Delta Controls
  • DSC-1212E (System controller, Ethernet interface, BACnet/IP)
  • DAC-633 (Application controller, MS/TP interface connected to DSC-1212E, which works as BACnet router)
  • DAC-633 (Application controller, MS/TP interface connected to Moxa 5250 serial/ethernet converter and communicated directly as BACnet MS/TP device in UDP mode)
  • DAC-1146 - (Application controller, MS/TP interface connected to DSC-1212E which works as BACnet router)
• Sauter
  • EYK220F001 (Automation station, Ethernet interface, BACnet/IP)
  • EYR203F001 (Universal controller connected to EYK220F001)
  • EYR207F001 (Universal controller connected to EYK220F001)
• York
  • BACnet MS/TP MicroGateway (Communication card for York coolers, RS485 interface, BACnet MS/TP)
• SE-Elektronic GmbH:
  • E-DDC3.1 (DDC automation station, Ethernet interface, BACnet/IP)
• Klimasoft
  • BACnet/Mbus converter MBG-MSTP: Converter from BACnet to Mbus protocol (RS485 interface, BACnet MS/TP)

...

BACnet protocol consider all the participants of the communication as the network devices. Each network device contains at least one (mostly just one) object Device (its Object Identifier must be unique in the whole network). This object contains other object of defined types (Analog Input, Analog Output, Analog Value, Binary Input, Binary Output, Binary Value, Calendar, Command, Event, Group, File etc.). The object detection - see a description of Request type Who-Is and Who-Has.
Each object has the properties, which can be required and optional. Moreover, each producer of BACnet devices can implement other properties when necessary.
The messages in BACnet protocol relates to the manipulation with objects and their properties. They are defined by the help of ASN.1 (Abstract Syntax Notation version 1) and encoded by simple version of BER (Basic Encoding Rules - encoding of ASN.1 messages).
The messages contain, besides fixed defined items, also the items 'Abstract Syntax & Notation'. It means that any sequence (or "tree"), which meaning is defined by an implementator, can be on the given place in the message. When using BER, it enables parsing of the message with the unknown items. BER defines two basic item types (tags): application and context.
The application tags are predefined:

...

The properties of objects are mapped on I/O tags in D2000 configuration. Due to the existence of contextual tags, you may specify an Application tag in the I/O tag. It determines the interpretation of the contextual tag. The parameter Complex address defines "a path" in the parse "tree" to get the values from the sequence that is defined by implementator.

...

...

• Station type: BACnet/IP station must be configured on TCP/IP-UDP line. LonWorks station must be configured on LonWorks line. MS/TP station must be configured on SerialOverUDP Device Redundant or Serial line.

• Kotva
  adresa adresa

  Address:
• BACnet/IP station: IP address of station (in the form A.B.C.D, e.g. 172.16.0.99)
• LonWorks station: address of LON subnet and LON node (in the form subnet.node, a subnet is 8-bit number and a node is 7-bit number)
• MS/TP station: number of node on the line (0-254, address 255 is a broadcast)
• Port: (only for BACnet/IP): UDP port number on station (according to standard 0xBAC0, i.e. 47808)
• Domain: (only for LonWorks): 0 or 1, it relates with the line configuration. On LonWorks line you can configure a membership to one or two domains. On BACnet station, if you choose some domain, it means that the device belongs to this domain (it influences 'domain' bit in LON address).
• Source network: source network number (i.e. a network with KOM process). This parameter may not be set for LonWorks line. For TCP/IP-UDP line, it is 16-bit number (or it is not set, see Note 2).

• Kotva
  destionation_network destionation_network

  Destination network: 16-bit number of a destination network (i.e. a network including the device which communicates with KOM process).
  Set this for LonWorks line if KOM process communicates with the device that is placed after BACnet router. In that case, Address of station is the address of BACnet router and Destination address is the address of destination device.
  For TCP/IP-UDP line, use Destination network if there is a communication between different BACnet networks.
  
  Note 1: This configuration was tested as follows:
  • Line: TCP/IP-UDP
  • Station type: BACnet/IP
  • Address: 172.16.99.1 (address of BACnet router PXG80-N)
  • Destination network: 1
  • Destination address: 1.1 (address PXC22 on LON network after BACnet router)
  KOM process communicated with the device PXC22 which was connected to LON network by BACnet router PXG80-N. KOM process communicates with BACnet router over Ethernet, so the line is TCP/IP-UDP. The communication between BACnet router and station PXC22 was done over LON network.
  
  

  Kotva
  pozn2 pozn2

  Note 2: We tested the similar configuration. We used Delta Controls DSM-RTR (connected over Ethernet network) and Klimasoft MBG device (gateway on M-Bus) after it connected over MS/TP interface. The communication started if only Destination network (value 50020) and Destination address (value 96) were configured and not Source network. However, in other configuration, the communication proceeded also with the parameter Source network. We recommend you to try various settings of network parameters for the devices.

...

• Kotva
  destionation_address destionation_address

  Destination address: It is the address of destination device if KOM communicates with it over BACnet router. When setting this parameter, you can (but you may not, see note about E-DDC3.1) set also the parameter Destination network. Parameter Destination address should be in the form subnet.node (if destination device is in LON network) or in the form A.B.C.D (if destination device is in BACnet/IP network).
  
  Note 1: On BACnet/IP station you can configure Destination address in the form subnet.node (e.g. 1.31). This configuration corresponds to BACnet router, which communicates with KOM process over BACnet/IP and is connected to destination device over LONTalk network.
  
  Note 2: On BACnet/IP station you can configure Destination address as a number from the interval 1-255. This configuration corresponds to BACnet router, which communicates with KOM process over BACnet/IP and is connected to destination device by MS/TP bus (DAC-633).
  
  Note 3: On BACnet/IP station you can configure Destination address as bigger number (e.g. 2001), which works for E-DDC3.1.

• Kotva
  resubscribe resubscribe

  Resubscribe interval: Time in seconds. After it elapses, a station again gets a request to send changes of I/O tags. This parameter relates to the I/O tags with Request type that is equal to SubscribeCOV or SubscribeCOVProperty.
• Max APDU: Maximum size of message (APDU = Application Protocol Data Unit) that is sent by KOM process. A default value is:
  • 1467 octets for TCP/IP-UDP line
  • 487 octets for SerialOverUDP Device Redundant or Serial lines (BACnet MS/TP)
  • 55 octets for LonWorks line (the limitation depends on size of packets which may be transmitted over Ethernet and LonWorks. For LonWorks the maximum value is 206. The value 55 is due to the limitation of iLON 10 Ethernet adapter)
  
  The changing of default value is important for testing and adjusting to the stations which are able to process only smaller messages. For example, the reducing of Max APDU influences only the size and amount of messages ReadPropertyMultiple-Request. These messages are intended for a periodic reading of I/O tag value (see I/O tag configuration).
  
  Note: The setting of Max APDU does not affect the size of max-APDU-length-accepted in APDU BACnet-Confirmed-Request-PDU, with the help of which KOM process informs a partner what big message is capable to process. This parameter is configured by the station protocol parameter Segment-Response.
  
  
• Priority: A priority of message in BACnet protocol. There are 4 priorities: Normal (default), Urgent, CriticalEquipment and LifeSafety.
• Rpt_timer & reply: (only for LonWorks) The parameters Repeat timer (default value = 1) and Retry (default value =1 ) of LonTalk protocol.
• Tx_timer: (only for LonWorks) Parameter Tx_timer in LonTalk protocol. Default value = 3.
• Timeout and retry: A timeout in milliseconds to confirm the message. Default value according to BACnet protocol is 3000 ms. After the timeout elapses, the message is sent retry-times. If any confirmation is not received, an error count will increase on station.
  
  Note: When testing Siemens PXC64-U device (the communication over LonTalk), we had to set Retry=8, Timeout=300 (more retries with shorter timeout). Due to that, we had to increase the values COM_ERR=10, HARD_ERR=20 so that the station did not switch to error state at retrying to send message.
• COM_ERR: The value of error counter on station when the station switches to COM_ERR status. The situation when station does not reply on call for reading or writing of value could be consider as error. A negative confirmation of a command (refusal of recording) is not the error. Default value = 5. See the parameters Timeout and retry.
• HARD_ERR: The value of error counter on station when the station switches to HARD_ERR status. Default value = 10. See the parameters Timeout and retry.
• Register-Foreign-Device, R-F-D Time to live: In this example the station is placed on LONTalk network after BACnet router which communicates with KOM process over Ethernet (e.g. Desigo PXG80-N). BACnet router sends the broadcasts from LONTalk to Ethernet as UDP broadcasts. If distributing of UDP broadcasts is disabled or KOM process is placed in other segment of network than BACnet router (it does not receive any UDP broadcasts), you should mark off the option Register-Foreign-Device on the station. This will cause, KOM process will send the message Register-Foreign-Device to BVLC router (BACnet Virtual Link Control) after start. The message calls for the registration to FDT table (Foreign Device Table) in router. The router sends the broadcasts in the form of UDP unicast (whose distribution is not limited to one segment) to the devices that are registered in FDT table. TTL - time in seconds (1-65535) is the parameter of message Register-Foreign-Device. It defines the expiration of registration that stops sending of UDP unicasts. That is why KOM process must ask BACNet router to register it before TTL expires. If there are more stations after BACnet router, just mark off Register-Foreign-Device on one of them.
  
  Note 1: If router does not support BBMD functionality (BACnet/IP Broadcast Management Device), it replies to the message Register-Foreign-Device with the error code and does not send LonTalk broadcasts to KOM process in the form of UDP unicasts. In that case you must use other solution (the communication over iLon Ethernet Adapter, the placing of KOM process on the same segment in network on which is BACnet router, etc.).
  Note 2: Router Desigo PXG80-N supports this functionality (tested). The control station Desigo PXC22-E.D does not support it probably (not tested yet).
  Note 3:In case of Desigo devices, if the D2000 KOM process is on a different network segment than the Desigo device, this parameter must be checked at the station. Otherwie Who-Is and Who-Has queries won't work (and thus addressing by object's name), as responses to these queries are sent as UDP broadcasts which will not go through a router.
  
  
• Master: (only for MS/TP): The station is Master type. KOM process transmits a token to Master station which has the next larger address than is the address of KOM process (the parameter of line MS/TP address). If the addresses of all Master station are lower than addresses of KOM process, token is given to Master station with the lowest address. If any Master station has not been configured, KOM process supposes to be the only master and does not give any token. You should get the information about the type of station from a producer or device documentation.
  
  Note: The current version of protocol does not contain the automatic search of Master station. You can find more information in the section Comment on BACnet MS/TP implementation.

Example of station configuration on TCP/IP-UDP line:

...

• Kotva
  requesttype requesttype

  Request type: Reading and writing of the object properties may be done in several ways:

  • Kotva
    readproperty readproperty

    ReadProperty - a periodical reading of object property as request-response. A period of polling is set on the tab Time parameters of station. The message ReadProperty-Request represents the request and the message ReadProperty-Ack represents the response from the device. The periodic reading loads the network and is ineffective. That is why, if the device supports the sending of change data, we recommend you to use SubscribeCOV or SubscribeCOVProperty.
    The message ReadProperty-Request is sent if checkbox Subscribe/read is ticked off.
  • ReadPropertyMultiple - the functionality is similar to the previous parameter. Unlike ReadProperty, more object properties are sent in one request-response, so the communication is much more effective. The message ReadPropertyMultiple-Request represents the request and the message ReadPropertyMultiple-Ack represents the response from the device.
    The message ReadPropertyMultiple-Request is sent if checkbox Subscribe/read is ticked off.
  • WriteProperty - the message WriteProperty-Request writes the values. The parameter Application tag must be specified as well. If Subscribe/read is marked off, the recorded value is reread by the message ReadProperty-Request after writing.

  • Kotva
    subscribecov subscribecov

    SubscribeCOV - reading of object value by change method. If the checkbox Subscribe/read is ticked off, after starting, KOM process send the message SubscribeCOV-Request which asks the device to send information about the change of object value. You can specify whether the device will send the confirmed notifications (message ConfirmedCOVNotification-Request) or the unconfirmed ones (UnconfirmedCOVNotification-Request). The confirmed notification requires the explicit confirmation from KOM (the message BACnet-SimpleACK-PDU), so it loads the network. However, the probability that the notification will lost is lower than if you would specify the unconfirmed notification (if the device does not receive the confirmation, it repeats the message).
    
    Note 1: Besides the dynamic registration by the message SubscribeCOV-Request, some devices can support also static one (it is saved in the configuration). So the registration is not required and the checkbox Subscribe/read may not be ticked off.
    Note 2: The registration can be sent in regular intervals (because of the potential failure of device supply). You can set this interval on the station - the parameter Resubscribe interval.

  • Kotva
    subscribecovproperty subscribecovproperty

    SubscribeCOVProperty - the functionality is similar to SubscribeCOV. Moreover, you can specify Property identifier (so you can monitor also the changes of other object properties as values) and Increment - a size of increment which causes the change will be sent (i.e. dead zone).
    This message - SubscribeCOVProperty-Request is sent.
    
    Note: The device Siemens PXC64-U did not support the parameter Increment.

  • Kotva
    whois whois

    WhoIs - the identification message Who-Is-Request to detect the type of Device Object in a device. The message I-Am-Request is the response (it contains the fields iAmDeviceIdentifier, maxAPDULengthAccepted, segmentationSupported, vendorID). If the I/O tag is TxtI, this information is extracted to the value of I/O tag in a text form. After you identify the Device Object, you can configure I/O tag for reading the property object-list of this Device Object. If the device implements this property, it returns the list of identifiers of all objects which it contains. Then you can detect the properties of these objects (object-name, location, description, present-value ..)
    
    Note: For Siemens PXC64-U you must set the Array index and then read the property object-list. Array index=0 defines number of array elements, Array index=1 up to N enables the access to the individual elements.

  • Kotva
    whohas whohas

    WhoHas - the identification message Who-Has-Request to detect the object name from the object identifier or vice versa. The response is the message I-Have-Request (it contains the fields: deviceIdentifier, objectIdentifier and objectName). The message Who-Has-Request is sent only once when initialization of I/O tag (or after the TELL command SETPTADDR). It is intended for the transfer between names and identifiers of objects.
    The message Who-Has-Request will contain either name or identifier of object depending on whether the Address type has been configured as Name or Object type+Instance in I/O tag.
    If Subscribe/read is ticked off, you can use the information from 17280087 BACnet cache , which is much more faster than detection from the communication.

  • Kotva
    readwritescheduler readwritescheduler

    ReadWriteScheduler - the message ReadProperty-Requestna is used for the request, the message WriteProperty-Request is used for write (it writes N pairs time-value). Th configuration is used for the reading and writing of objects of schedule type, see the article Scheduler in Siemens Desigo devices.

  • Kotva
    geteventinformation geteventinformation

    GetEventInformation: a detection of objects that are in alarm or error state or they need to be acknowledged, see the section Information about events.

  • Kotva
    acknowledgealarm acknowledgealarm

    AcknowledgeAlarm: the acknowledgement of alarms that have been loaded by the request GetEventInformation. See the section Information about alarms. I/O tag must be the text output (TxtO).

• Kotva
  addresstype addresstype

  Address type: Each object in BACnet protocol is addressed by Object identifier. When designing the application in Desigo system, the objects are represented by name, but the object address is not accessible and can vary following the changes of application. As regards Delta Controls devices, they contain the objects whose addresses are defined by the author of the application. For this reason, there are two ways how to define the address of I/O tag which corresponds to two Address type:
  • Name: enter the object name. A type of object and number of instance are found out dynamically from the communication. To avoid the overloading of communication lines when starting the KOM process, data are stored in a 17280087 BACnet cache.
  • Object type + Instance: enter the type of object and number of instance. This is recommended for BACnet objects with the constant addresses.
• Object type: type of objects, whose properties will be read/written. You can use the predefined types or write the number of new type of object which has been defined by a producer. The type of object is 10-bit number.
• Instance: a sequence number of object within the object type. Each object has a unique Object Identifier in the device, which is a pair [Object type, Instance].

• Kotva
  objectname objectname

  Object Name: name of object, Address type= Name, i.e. it means the I/O tag address is detected dynamically from the communication. Object Name must be set without spaces in the beginning and end, and the uppercase and lower case letters must correspond to object name that is stored in the device with which it communicates.
• Property type: type of property - set only PropertyIdentifier for Simple, and both PropertyIdentifier and Complex address for Complex. The complex type of property is necessary when parsing by implementer of extension of the messages (Abstract Syntax & Notation). When sending the messages ReadProperty-Request, ReadPropertyMultiple-Request, SubscribeCOV-Request, SubscribeCOVProperty-Request, the Complex address is ignored.
• Property identifier: identifier of object property. You can use the predefined properties or number of new property which has defined the producer. The type of property identifier is Enumerated Value, the properties 0-511 are reserved for BACnet, the numbers from 512 to 4194303 can be used for the device producers.
• Array index: some properties may be defined as value array. The particular item of array can be read or written.

• Kotva
  application_tag application_tag

  Application tag: must be specified when writing the value (Request type=WriteProperty) and possibly for other types of requests, if parsed response contains the context tags which application type is unknown because it is the extension of messages defined by implementer. The exception is an output text tag that is considered to be 'AnyTree', as regards the unspecified application tag, and is used to write any user-specified ASN sequence.
  
  Note: If the the value is Invalid, it is not written as the defined Application tag, but as Application tag "Null".

• Kotva
  complex_address complex_address

  Complex address: address of tag in a 'tree' in connection with the extension of messages that have been defined by implementer.
  Example of address: [1].[3].2.1
  Description:
  [1] - context tag No.1 (it is assumed that it is the sequence),
  [3] - it is the context tag No. 2 in this sequence (it must be the sequence),
  2 - it is the second tag in order in this sequence (it must be the sequence),
  1 - it is the first tag in order in this sequence.
  The address in 'tree' starts from the level propertyValue (see the examples below). The easiest way to view the parsed message is to turn on a debug on the line and watch the debug info on the console or in the log of line.
  
  Example 1: There is a device that contains the object of type 2 (Analog Value) with the instance number 1. It is assumed that the device sends the object value as a triplet of numbers. The first number is the current value, the second one is one-minute average and the third one is ten-minute average. The log of parsed message could be the following:

   === ASN Body beg ===
   objectIdentifier (tag 0) OBJID 2 analog-value,1
   listOfResults (tag 1) SEQUENCE {
    propertyIdentifier (tag 2) ENUM 85 present-value
    propertyValue (tag 4) SEQUENCE {
     REAL 1.40000E+00
     REAL 1.10000E+00
     REAL 1.30000E+00
    }
   }
   === ASN Body end ===
  

  If you wants all three values, you must configure three I/O tags (Object type=analog_value, Instance=1, Property-identifier=present-value, Property-type=complex), which differ in the complex address (for the first I/O tag = 1, for the second one = 2, for the third one = 3). Tick off the checkbox Subscribe/read only in one configuration of these I/O tags, because the response to one request is the message with three values. When sending the messages ReadProperty-Request, ReadPropertyMultiple-Request, SubscribeCOV-Request, SubscribeCOVProperty-Request and WriteProperty-Request, the complex address is not used.
  
  Note: If you configure the I/O tag with Property-type=simple, its value would be set on the first found value after parsing of the message (see the example, it is 1.40000E+00).
  
  Example 2: Siemens Desigo PXC64-U contains I/O tag (Object type=schedule, Instance=6, Subscribe-read is ticked off, Property-identifier=weekly-schedule, Property-type=complex, Array index=1, Complex address=1). A debugging has been started on the line. After the I/O tag is saved, KOM process sends the request and writes the response:

   === ASN Body beg ===
   objectIdentifier (tag 0) OBJID 17 schedule,6
   propertyIdentifier (tag 1) ENUM 123 weekly-schedule
   propertyArrayIndex (tag 2) UNSIGNED 1
   propertyValue (tag 3) SEQUENCE {
    SEQUENCE {
     TIME 0:0:0.0
     UNSIGNED 2
     TIME 4:0:0.0
     UNSIGNED 3
     TIME 22:0:0.0
     UNSIGNED 1
    }
   }
   === ASN Body end ===
  

  In propertyValue there is the sequence of 6 values (time and positive number alternately). If you want to access to the first time, you have to set Complex address=1.1, if to the first positive number, set Complex address=1.2. I.e. the first element - sequence - the second element in the order within it (UNSIGNED 2). If you need to access to more times and/or values at the same time, you must configure several I/O tags and tick off the checkbox Subscribe/read only in one of them.
  
  Note 1: The value of I/O tag remains Unknown, after creating and saving it with the complex address 1, because this address matches with 1. element in propertyValue, which is the sequence but not a simple typ.
  
  

  Kotva
  pozn2 pozn2

  Note 2: The I/O tag of Text type are able to cover not only simple value but also any ASN sequence. The values are written according to rules for record of ASN sequence. If you set Complex address=1 and change the I/O tag to text input or text output in the previous example, its value will be a string " T0:0:0.0; u2; T4:0:0.0; u3; T22:0:0.0; u1; ". If Property-type=complex, but Complex address is not defined, a result is "0{ T0:0:0.0; u2; T4:0:0.0; u3; T22:0:0.0; u1; }".
• Increment: increment of value change in the object property which causes the reporting of change (see SubscribeCOVProperty).
• Confirmed: if the checkbox is ticked, it specifies whether the device will send the confirmed notifications (ConfirmedCOVNotification-Request) or unconfirmed one (UnconfirmedCOVNotification-Request) for the configured Request types SubscribeCOV and SubscribeCOVProperty.

• Kotva
  subscriberead subscriberead

  Subscribe/read: if the checkbox is ticked, the proper messages for reading/registration of value changes are sent for the configured Request types:
  ReadProperty: the message ReadProperty-Request
  ReadPropertyMultiple: the message ReadPropertyMultiple-Request
  SubscribeCOV: the message SubscribeCOV-Request
  SubscribeCOVProperty: the message SubscribeCOVProperty-Request
  ReadWriteScheduler: the message ReadProperty-Request

...

• Period from: if the nonzero value is set and the checkbox Subscribe/read is ticked, the messages Subscribe/read will not be sent in the interval Polling period, which has been configured on the station, but in the defined period (in seconds). In this way you can configure various Polling periods for different objects on one station. Moreover, you can detect with the help of one I/O tag with Request type ReadProperty and small Period whether the station communicates.
• Local time: if the checkbox is ticked, the recorded respectively read times and dates are in a local time. If not, they are in monotonous UTC time.
• Flags-to-flags: if the checkbox is ticked, it causes that besides of I/O tag value, its user flags FA,FB,FC,FD are set for the Request types SubscribeCOV and SubscribeCOVProperty. The value status-flags (BACnetStatusFlags type) is mapped to these flags, if they are sent. BACnetStatusFlags is a quaternion of bits (in-alarm, fault, overridden, out-of-service) that support extra information about the object value.
• Write priority: for the record of 'commandable' properties, you can specify the priority 1-16. 1 = top priority, 16 = the lowest priority, 0 = none priority.

...

Note: In versions from 20th December 2018 and newer, recycling of browser dialogue has dialog has been implemented. If the dialog is closed by the Cancel button or after selecting an object, it is actually only hidden and it is available for browsing by another I/O tag within the same station so that the tree structure of the browsed objects is preserved. Clicking on the close icon at the top right corner will cause the dialog to be really closed.

...

Reading of scheduler (the attribute weekly-schedule)

• Value after value: a dynamic change of complex address (1.1, 1.2, 1.3 etc.) in a script enables to read all values and times similarly as for other properties.
• All times and values for one day at the same time:
  • Value type: a text input (reading of scheduler) or text output (read/write)
  • Request type: ReadProperty (reading of scheduler), ReadWriteScheduler (read/write)
  • Subscribe/read: Y
  • Object type: schedule(17)
  • Instance: number of instance (e.g. 6) which is found from Desigo configuration or with the help of WhoIs request.
  • Property type: Complex
  • Property identifier: weekly-schedule(123)
  • Array index: 1 up to 7, it depends on the
loaded
• • day being read
  • Application tag: if it is not defined, Unsigned is used (it is necessary only when writing
of
• • the value)
  • Complex address: 1 (address of sequence)

The times and values separated by semicolon are

...

read into the text value (

...

see Note 2).
When recording the value of scheduler you should realize that the value can be sent with various application tags (Unsigned, Signed)

...

, however the device

...

expects a particular tag (the easiest way to find it, is

...

reading of the value 

...

while logging is active on the line). The application tag of value is defined by the item Application tag in the configuration. The valid value of Application tag can be Boolean, Unsigned, Signed, Real and Double. If any other type is set, Unsigned value is automatically sent. A value type can be changed dynamically - if the first character of text value is B,U,S,R or D, it stands for (B)oolean, (U)nsigned, (S)igned, (R)eal or (D)ouble.

Recording of scheduler (the attribute weekly-schedule)

You must configure Request type=ReadWriteScheduler and assign the sequence of time-value pairs separated by semicolon into I/O tag of text output (e.g. "0:0:0; 1; 2:30:40.5; 2; 5:00:00;1".

The text string with the length=0 is ignored so that the "empty sequence" will not be recorded to the scheduler after saving the D2000 configuration or starting KOM process. For this reason, if the time plan of scheduler must be deleted for the particular day, the string of nonzero length (it contains neither time nor value: " ") must be assign to I/O tag.

Kotva
note_schedulersiemens note_schedulersiemens

Note: Another possibility, besides the special request ReadWriteScheduler, to write weekly-schedule is recording of ASN sequence, e.g. the sequence "{ T0:0:0 u1; T2:30:40.5 u2; T5:0:0 u1 }" corresponds to the value "0:0:0; 1; 2:30:40.5; 2; 5:00:00;1". The I/O tag configuration differs only in Request type=ReadProperty. You can also write the time frame for whole week, if Array index is not set and the value contains 7 sequences for the individual days, e.g. "{ T0:10:0 u3 T1:3:0 u1; } {T2:0:0.0 u2 T5:30:10.0; u3; } { T6:0:0.0 u2 T7:0:0.0 u3} { T20:0:0.33; u1} { T21:0:0.0; u1} { T22:0:0.0; u2} 0 { T0:0:0.0; u3; T1:2:0.0; u1; T2:0:0.0; u2; T5:30:10.0; u3}".

...

The recording of the exception-schedule is supported over the recording of ASN sequence.
Example: I/O tag configuration:

I/O tag type: text output (TxtO)

Request type: WriteProperty

Subscribe/read: Y

Object type: schedule(17)

Instance: 6

Property type: exception-schedule

Application tag: not defined (write the whole ASN sequence)

With the help of this string "0{ 0D2.10.2005 } 2{ T1:0:0; u1; T12:0:0; u3 } 3u10" you can write the time frame for the day October 2, 2005. The scheduler has the value 1 from 1:0:0, the value 3 from 12:00:00. The priority exception-schedule is 10. When rereading of value (Subscribe/Read was configured) with the activated debug on the line, you can see the following log:

...

Kotva
events events

Information about events

...

The request GetEventInformation-Request is intended to call for the list of objects that are in the state Offnormal or Fault or whose change to Offnormal, Fault or Normal has not been acknowledged from the device.
Example of I/O tag configuration:

I/O tag type: text input (TxtI)

Request type: GetEventInformation

Subscribe/read: Y

Object type: undefined

Instance: undefined

Property type: complex

Application tag: undefined

The message GetEventInformation-Ack is a reply to GetEventInformation-Request, which contains the list of objects and the list of properties for each object:

objectIdentifier: identifier of object

event-state: object status (0=normal, 1=fault, 2=offnormal, 3=high-limit, 4=low-limit, 5=life-safety-alarm)

acknowledgedTransitions: 3 bits that define whether the last transition to the offnormal, fault or normal status was acknowledged

eventTimeStamps: the time stamps of last transition to the offnormal, fault and normal status

notifyType: defines whether it is a notification of alarm (0) or event (1)

eventEnable: 3 bits that defines whether the events report to to-offnormal, to-fault, to-normal

eventPriorities: 3 unsigned values defining the event priority

At the end of list, there is the attribute moreEvents that is non zero if the list of events is incomplete (e.g. the exceeding of length of maximum message, etc.). For this reason, you must reconfigure I/O tag and set Object type and Instance on the last object in the list. It causes the generation of new message GetEventInformation-Ack.

Example of response GetEventInformation-Ack:

...

You can acknowledge the events and alarms, whose list has been loaded by the request GetEventInformation. According to BACnet protocol, the format of this request is (the record in ASN.1 syntax):

...

The more detailed description of the parameters is stated in a literature.
The acknowledgement is executed by the writing of above mentioned sequence to the text of output I/O tag according to the record of any ASN sequence.

Example: The loading of list of alarms and events with the help of GetEventInformation:

   ===  ASN Body beg ===
   listOfEventSummaries (tag 0) SEQUENCE 0 {
    objectIdentifier (tag 0) OBJID 0 analog-input,1
    event-state (tag 1) ENUM 4 low-limit
    acknowledgedTransitions (tag 2) BITSTRING 0,1,1 to-offnormal(0),to-fault(1),to-normal(2)
    eventTimeStamps (tag 3) SEQUENCE 3 {
     dateTime (tag 2) SEQUENCE 2 {
      date DATE 25.11.2005 Fri
      time TIME 11:54:23.0
     }
     dateTime (tag 2) SEQUENCE 2 {
      date DATE 25.11.2005 Fri
      time TIME 10:4:37.0
     }
     dateTime (tag 2) SEQUENCE 2 {
      date DATE 25.11.2005 Fri
      time TIME 11:54:23.0
     }
    }
    notifyType (tag 4) ENUM 0 alarm
    eventEnable (tag 5) BITSTRING 1,1,1 to-offnormal(0),to-fault(1),to-normal(2)
    eventPriorities (tag 6) SEQUENCE 6 {
     eventPriority UNSIGNED 3
     eventPriority UNSIGNED 3
     eventPriority UNSIGNED 7
    }
    objectIdentifier (tag 0) OBJID 0 analog-input,2
    event-state (tag 1) ENUM 3 high-limit
    acknowledgedTransitions (tag 2) BITSTRING 1,1,1 to-offnormal(0),to-fault(1),to-normal(2)
    eventTimeStamps (tag 3) SEQUENCE 3 {
     dateTime (tag 2) SEQUENCE 2 {
      date DATE 25.11.2005 Fri
      time TIME 10:41:59.0
     }
     dateTime (tag 2) SEQUENCE 2 {
      date DATE 25.11.2005 Fri
      time TIME 10:12:20.0
     }
     dateTime (tag 2) SEQUENCE 2 {
      date DATE 25.11.2005 Fri
      time TIME 10:12:21.0
     }
    }
    notifyType (tag 4) ENUM 0 alarm
    eventEnable (tag 5) BITSTRING 1,1,1 to-offnormal(0),to-fault(1),to-normal(2)
    eventPriorities (tag 6) SEQUENCE 6 {
     eventPriority UNSIGNED 3
     eventPriority UNSIGNED 3
     eventPriority UNSIGNED 7
    }
    objectIdentifier (tag 0) OBJID 214,1
    event-state (tag 1) ENUM 2 offnormal
    acknowledgedTransitions (tag 2) BITSTRING 0,1,1 to-offnormal(0),to-fault(1),to-normal(2)
    eventTimeStamps (tag 3) SEQUENCE 3 {
     dateTime (tag 2) SEQUENCE 2 {
      date DATE 25.11.2005 Fri
      time TIME 11:54:23.0
     }
     dateTime (tag 2) SEQUENCE 2 {
      date DATE 25.11.2005 Fri
      time TIME 10:12:20.0
     }
     dateTime (tag 2) SEQUENCE 2 {
      date DATE 25.11.2005 Fri
      time TIME 10:12:21.0
     }
    }
    notifyType (tag 4) ENUM 0 alarm
    eventEnable (tag 5) BITSTRING 0,0,0 to-offnormal(0),to-fault(1),to-normal(2)
    eventPriorities (tag 6) SEQUENCE 6 {
     eventPriority UNSIGNED 3
     eventPriority UNSIGNED 3
     eventPriority UNSIGNED 7
    }
   }
   moreEvents (tag 1) BOOLEAN FALSE   === ASN Body end === 

The object is the first in list
objectIdentifier (tag 0) OBJID 0 analog-input,1
which is in the status low-limit
event-state (tag 1) ENUM 4 low-limit
and contains unacknowledged transition to the offnormal status (i.e. according to D2000 terminology it is an active alarm low-limit which requires the acknowledgement):
acknowledgedTransitions (tag 2) BITSTRING 0,1,1 to-offnormal(0),to-fault(1),to-normal(2)
This transition occurred in time
dateTime (tag 2) SEQUENCE 2 {
date DATE 25.11.2005 Friri
time TIME 11:54:23.0
}
The alarm is acknowledged with the record of text value
0u1; 1o0:1 ; 2E2; 3{ 2{ D25.11.2005 T11:54:23} } 4C'D2000' 5{ 2{ D25.11.2005 T11:55:23 }}
and the individual items are as follows (see the definition of AcknowledgeAlarm-Request):

0u1u1 - tag 0, unsigned value 1 - acknowledgingProcessIdentifier = identifier of process which acknowledges the alarm (it could be optional)

1o0:1:1 - tag 1, the identifier of object of type 0, instance 1 - eventObjectIdentifier = the identifier of object which contains the alarm

2E2 - tag 2, enum value 2 - eventStateAcknowledged = the acknowledged value (BACnet standard defines the following events that can be acknowledged):
normal (0),
fault (1),
offnormal (2),
high-limit (3),
low-limit (4),
life-safety-alarm (5)
acknowledge the transition to the offnormal status in this case

3{ 2{ D25.11.2005 T11:54:23} } - timeStamp = the sequence with date and time which must be acknowledged (it must match to date and time which has been loaded)

4C'D2000' - acknowledgmentSource = a source of alarm acknowledgement (obviously it is any string)

5{ 2{ D25.11.2005 T11:55:23 }} - timeOfAcknowledgment = date and time when the alarm was acknowledged

After acknowledging of alarm and loading the list of alarms and events by the request GetEventInformation, you will see the alarm has been acknowledged.
This record:
acknowledgedTransitions (tag 2) BITSTRING 0,1,1 to-offnormal(0),to-fault(1),to-normal(2)

will change to:

acknowledgedTransitions (tag 2) BITSTRING 1,1,1 to-offnormal(0),to-fault(1),to-normal(2)

If the object had been in normal state, it would not have been listed in the list of alarms. In this example it is in low-limit state, i.e. it is an active acknowledged alarm.

To load the list of alarms, their record to a browser and acknowledgment of alarm, you must write the service scripts which parse the text value of the request GetEventInformation and compound it for AcknowledgeAlarm.

Kotva
cache cache

Comment on address cache

...

If the station has at least one I/O tag with Address Type = Name, the numerical address is detected by Who-Has-Request from ObjectName when initializing these I/O tags. After getting the address, the data (ObjectName; Object Type; Instance; DeviceInstance) are saved to cache file and are available for next starting of KOM process.
For each station there exists one cache file. It is placed in an application directory, subdirectory Cache. Its name is Cache_station_name.txt, e.g. Cache_B.StationX1.txt.
When saving BACnet station, the data are reloaded from file. If the file was not found, the Who-Has messages are generated to all I/O tags that contain Address Type = Name in this station.
This behavior may be used after changing the configuration of the device which communicates with KOM process (if the addresses of objects was changed when changing the configuration). Just delete the cache file in this station and save it - the cache file occurs again and is filled with the acquired data.

Note: the interaction of cache and I/O tags with Request type = WhoHas.

If the parameter Subscribe/read is marked off in the I/O tag, the cache is not searched and the Who-Has-Request message is sent to the communication. The obtained information is not written to the cache. It is important only for the objects that generate and vanish dynamically, which would overflow the cache.

If Subscribe/read is not marked off, the cache is searched. If ObjectName or ObjectIdentifier was not found, the Who-Has-Request message is sent to the communication. If the respond comes, the information is written into the cache.

Kotva
delta delta

Comment on Delta Controls devices

...

The test configuration included DSC-1212E device connected to the local network Ethernet and DAC-633 device connected to DSC-1212E over MS/TP interface (RS-485). D2000 KOM communicated directly with DSC-1212E and DAC-633 over DSC-1212E (it performed the function of BACnet router).
We used the software ORCAview 3.30 Build 1481 from which we detected the following configuration information:

Kotva
dsc-1212e dsc-1212e

DSC-1212E
I logged on to ORCAview and found DSC-1212E device. Then the object BACnet Settings 3200 (3200 is a software address of the particular device) occurred in the right panel in Navigator dialog window. Clicking on BACnet Settings 3200 opened the dialog window which contained several tabs. The Setup tab included also the port UDP/IP. After I had clicked on it, its parameters displayed in the bottom of the window, e.g. Network, IP Address and UDP Port.
When communicating with DSC-1212E, in D2000 configuration of station I could set Source network to the value of Network or not. The parameters IP Address and UDP Port must be used to set the parameters Address and Port in the station configuration in D2000. A station type was BACnet/IP.

Note: On the tab Advanced - BACnet Properties, the parameter Local Netwok Number was set on 10032 (it was the same as the parameter Network of the port Ethernet on the tab Setup). This port is used for communication BACnet over Ethernet (without use of IP protocol), which is not supported in D2000 yet.

Kotva
dac-633 dac-633

DAC-633
I logged on to ORCAview and found DAC-633 device. Then the object BACnet Settings 3202 (3202 is a software address of the particular device) occurred in the right panel in Navigator dialog window. Clicking on BACnet Settings 3202 opened the dialog window which contained several tabs. The Setup tab included also the port MS/TP with the attribute Status, the value Active, and the attribute Status Reference of value BACnet Settings 3202 (NET1). After I had clicked on it, its parameters displayed in the bottom of the window, e.g. Network and MAC Address.
When communicating with DAC-633 I had to set the following station parameters in D2000:

Station type: BACnet/IP

Address: the parameter IP Address in configuration DSC-1212E

Port: the parameter UDP Port in configuration DSC-1212E

Source network: the parameter Network in configuration DSC-1212E

Destination network: the parameter Network in MS/TP port in configuration DAC-633

Destination address: the parameter MAC Address in MS/TP port in configuration DAC-633

As D2000 communicates with DAC-633 over DSC-1212E, the parameters Address, Port and Source network, which correspond to DSC-1212E, and Destination network and Destination address, which correspond to MS/TP network between DSC-1212E and DAC-633, must be set in the station configuration.

Both devices support the polling and change method of reading of data (both ReadProperty and SubscribeCOV).
The parameters Object type and Instance in the configuration of I/O tag was detected in ORCAview from the attributes Object and Description (e.g. object 3200.AI12 is Analog Input, Instance 12; the object 3202.PG3 is Program, Instance 3). The parameter Address type is Object type+Instance and Request type is SubscribeCOV, if it is not defined other parameter.

I/O tags:

Analog-input

Analog-output (Application tag: Real - possibility to write)

Analog-value (Application tag: Real - possibility to write)

Binary-input

Binary-output (Application tag: Enum - possibility to write)

Binary-value (Application tag: Enum - possibility to write)

Calendar (Request type: ReadProperty, Property type: Complex, Property identifier: datelist(123), Application tag: Date, Complex address: 1,2,.. etc. - gradual reading from the array; possibility to write the whole calendar with the help of ASN sequence but Complex address is not entered, e.g. "0D1.9.2006; 0D3.10.2006; 0D8.9.2006")

Event-enrollment

Schedule (Request type: ReadProperty or WriteProperty - possibility to write; Property identifier: weekly-schedule(123))

Program (Request type: ReadProperty, Application tag: Boolean - possibility to write - stop and start the program)

Multi-state-value (Application tag: Unsigned - possibility to write)

Trend-log (the cyclic buffer of values that are saved with the configured interval)

Property identifier: 1074 - array of trend time stamp in tens of milliseconds since a time of data reset

Property identifier: 1076 - bit string array (attributes of values?)

Property identifier: 1077 - array of trend values

Property identifier: 1105 - time of resetting

Kotva
e-ddc3.1 e-ddc3.1

Comment on E-DDC3.1 devices

...

The communication was revived according to the following configuration:

Line: TCP/IP-UDP

Station type: BACnet/IP

Address: 10.0.6.23 (IP address E-DDC3.1)

Port: 47808

Source network: not defined

Destination network: not defined

Destination address: 2001 (this was acquired from BACnet OPC server - the parameter "Device ID")

We tested ReadProperty, SubscribeCOV, WriteProperty (in the objects of Binary Output, Binary Value, Analog Value type).
The defined I/O tags (the test configuration contained only these types):

Analog-input

Analog-value (Application tag: Real - possibility to write)

Binary-input

Binary-output (Application tag: Enum - possibility to write)

Binary-value (Application tag: Enum - possibility to write)

The device (2.01.05) with the original firmware did not work with Who-Is. We had to upgrade this firmware to the version 2.01.16. Then everything, including WriteProperty, worked properly.

...

Based on document "DESIGO INSIGHT: Installation, setup and communication - Engineering guide", the recommended address settings for LonWorks communication are:

DomainID: 0x49

SubnetID: 1

NodeID:

1..100 - range reserved for automation stations (PX) and system devices (BACnet routers)

101..120 - operating devices and DESIGO INSIGHT management stations

121..127 - temporary operating devices (e.g. the PXM20 operator unit) and tools (DTS)

Kotva
mbg-mstp mbg-mstp

Comment on Klimasoft MBG-MSTP devices

...

The test configuration contained Moxa NPort 5150 (a converter from UDP to RS485) connected to the converter MBG-MSTP, which communicated with a heat meter Siemens UH50-A21R-SK06-G. Only analogue inputs was detected. The converter MBG-MSTP supported only ReadProperty.
The communication was revived according to the following configuration:

Line: SerialOverUDP Device Redundant with IP address and Moxa NPort 5150

The parameter of BACnet protocol that are configured on the line:
MS/TP address: 6 (any address 1-254 that does not clash with other addresses on RS485 bus)
MS/TP N max_info_frames: 20. Default value is 5. If this parameter exceeds the number of I/O tags, it causes that all I/O tags are loaded in one cycle (as regards the periodical loading), which is not interrupted because of sending a token. We recommend you not to increase the value of parameter if other devices are connected with RS485 and they could have problems if they do not receive any token for a longer time.
MS/TP usage_timeout: 99. According to a standard, the value must be under 100 ms. Default value 20 ms caused the problems with communication (MBG-MSTP did not manage to react till timeout).

Type station: MS-TP

Address: 1 (according to configuration MBG-MSTP)

I/O tag configuration:
Request type: ReadProperty
Object type: analog-input(0)
Instance: according to configuration MBG-MSTP or device which is behind it

Kotva
ilon10 ilon10

Comment on iLON 10 Ethernet adapter

...

When using iLON 10 Ethernet adapter for communication you should realize that the communication processor of this device (Neuron 3120) has relatively short default buffers (network buffer is 66 bytes. Therefore it does not receive the longer packets. It can be seen in the web interface iLON 10 - tab Status and the parameter Missed Messages increases when trying to read the value (e.g. always after saving the I/O tag if its parameter Subscribe/read is marked). This problem occurred when schedule of scheduler contained more than 4 pairs time-value. When there were 4 pairs, the length of LON message was 63 bytes. After adding next pair via PXM20, the loading of schedule failed.

Warning! The utility Nodutil enables to increase the size of received packet by increasing of both the network and application buffer. However, if you set improper values, you can damage iLON 10 device (Neuron 3120 stopped communication with the user processor).
If you decide to preset the size of buffers, just change it from 66 bytes to 88 (and reduce the number of buffers) because KOM process informs, in its packets, that it is able to receive 50-byte ASDU (+ BACnet header 3 bytes and LON header 16 bytes).
The buffers of PCLTA-10 ISA adapter (built on the communication chip Neuron 3150) had the long enough buffers (255 bytes).
After we bought the new iLON 10, the configuration was successful with these parameters:

configuration software: Echelon Node Utility Release 1.82

size and quantity of buffers:

    DEVICE:0> (B)uffer configuration
    Node buffer configuration
    Type			Count	Size	Bytes
    Receive transaction	11	13	143
    Transmit transaction	2	28	56
    App buffer in		2	82	164
    App buffer out		2	82	164
    Net buffer in		5	82	410
    Net buffer out		2	82	164
    App buff out priority	1	82	82
    Net buff out priority	1	82	82
    ==> Total bytes = 1265
    

Kotva
mstp mstp

Comment on BACnet MS/TP implementation

...

ANSI/ASHRAE Standard 135-2001: BACnet - A Data Communication Protocol for Building Automation and Control Networks

ASN.1 Complete by Prof. John Larmouth

Info
title Blogs
You can read blogs about BACnet protocol (for now, in Slovak language only): Communication - BACnet protocol  Communication - BACnet protocol, part 2 Communication - BACnet protocol, part 3

Kotva
zmeny_upravy zmeny_upravy

Changes and modifications

...

Kotva
revizie revizie

Document revisions

...

Ver. 1.0 - August 30, 2005 - first version

Ver. 1.1 - October 20, 2005 - support of schedulers, reading and writing of ASN sequences

Ver. 1.2 - November 22, 2005 - support of a dynamic detection of I/O tag address from object name, address cache in a file

Ver. 1.3 - June 14, 2006 - support of BACnet router (tested with PXG80-N)

Ver. 1.4 - April, 02, 2008 - a partial support of BACnet MS/TP protocol (tested on BACnet MS/TP MICROGATEWAY on the cooler produced by York company)

Ver. 1.5 - June 25, 2010 - testing the cooperation with E-DDC3.1 from SE-Elektronic GmbH

Info
title Related pages:
Communication protocols

...