Porovnávané verzie

Kľúč

  • Tento riadok sa pridal
  • Riadok je odstránený.
  • Formátovanie sa zmenilo.

...

    • 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 polling period is configured on the Time parameters tab of station. The ReadProperty-Request message is used for the request and the ReadProperty-Ack message is the response from the device. The periodic reading burdens 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 requests.
        The ReadProperty-Request message is sent if the Subscribe/read checkbox is checked.
      • ReadPropertyMultiple - the functionality is similar to the previous parameter. Unlike ReadProperty, more object properties are sent in one request/response, so communication is much more effective. The ReadPropertyMultiple-Request message is used for the request and the ReadPropertyMultiple-Ack message is the response from the device.
        The ReadPropertyMultiple-Request message is sent if the Subscribe/read checkbox is checked.
      • WriteProperty - the WriteProperty-Request message is used for writing the values. The Application tag parameter must be specified as well. If Subscribe/read is checked, the written value is verified by reading from the station using the ReadProperty-Request message after writing.
      • Kotva
        subscribecov
        subscribecov
        SubscribeCOV - activation of reading of object value when they change. If the Subscribe/read checkbox is checked, after starting, the KOM process sends the SubscribeCOV-Request message which asks the device to send information about the change of object value. You can specify whether the device will send the confirmed notifications (ConfirmedCOVNotification-Request message) or the unconfirmed ones (UnconfirmedCOVNotification-Request). The confirmed notification requires an explicit confirmation from the KOM (the BACnet-SimpleACK-PDU message), so puts more load on the network. However, the probability that the notification will be lost is lower than in case of using unconfirmed notifications (if the device does not receive a confirmation, it repeats the message).

        Note 1: Besides the dynamic registration by the SubscribeCOV-Request message, some devices can support also a static one (it is saved in the configuration). So the registration is not required and the checkbox Subscribe/read may be left unchecked.
        Note 2: The registration can be sent at regular intervals (e.g. because of a potential failure of the device power supply). You can set this interval on the station - the Resubscribe interval parameter.
        Note 3: SubscribeCOV-Request messages (and also SubscribeCOVProperty-Request messages, see the following point) are also sent after the connection with the station is re-established (after a failure or after switching from the StOFF state to the StOn).
      • Kotva
        subscribecovproperty
        subscribecovproperty
        SubscribeCOVProperty - the functionality is similar to SubscribeCOV. Moreover, you can specify the Property identifier (so you can monitor also the changes of other object properties than the present value) and Increment - a size of increment which causes the change to be sent (i.e. a dead band).
        The SubscribeCOVProperty-Request message is sent.

        Note: The Siemens PXC64-U device did not support the Increment parameter.
      • Kotva
        whois
        whois
        WhoIs - the identification message Who-Is-Request to detect the type of Device Object in a device. The I-Am-Request message is the response (it contains the iAmDeviceIdentifier, maxAPDULengthAccepted, segmentationSupported, and vendorID fields). If the I/O tag is TxtI, this information is extracted to the value of the I/O tag in a text form. After you identify the Device Object, you can configure the 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 query 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 the 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 I-Have-Request message (it contains the fields deviceIdentifier, objectIdentifier, and objectName). The Who-Has-Request message 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 the object depending on whether the Address type has been configured as Name or Object type+Instance in I/O tag.
        If Subscribe/read is checked, you can use the information from the BACnet cache, which is much faster than detection from the communication.
      • Kotva
        readwritescheduler
        readwritescheduler
        ReadWriteScheduler - the ReadProperty-Request message is used for the request, the WriteProperty-Request message is used for write (it writes N time-value pairs). The configuration is used for the reading and writing of objects of schedule type - the weekly-schedule(123) attribute, see the the Scheduler in Siemens Desigo devices paragraph.
      • Kotva
        geteventinformation
        geteventinformation
        GetEventInformation: 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 acknowledgment of alarms that have been read by the GetEventInformation request. See the section Information about alarms. I/O tag must be the text output (TxtO).
    • Kotva
      addresstype
      addresstype
      Address type: Each object in the BACnet protocol is addressed by an Object identifier. When designing the application in the Desigo system, the objects are represented by a name, but the object address is not accessible and can vary following the changes of application. On the other hand, the Delta Controls devices 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 instance number is queried dynamically from the communication. To avoid the overloading of communication lines when starting the KOM process, data is stored in a BACnet cache.
      • Object type + Instance: enter the type of object and an instance number. This is recommended for BACnet objects with constant addresses.
    • Object type: type of objects, whose properties will be read/written. You can use the predefined types or write the number of a new type of object which has been defined by a producer. The type of object is a 10-bit number.
    • Instance: an object identification number 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 the object, when Address type = Name, i.e. it means the I/O tag address [Object type, Instance], is detected dynamically from the communication. Object Name must be specified exactly, i.e. spaces in the beginning and at the end are not tolerated, and the upper and lower case letters must correspond to the object name that is stored in the BACnet device.
    • Property type: type of property - only PropertyIdentifier is specified for Simple, and both PropertyIdentifier and Complex address must be specified for Complex. The complex type of property is necessary for the parsing of OEM-extended standard messages (items of 'Abstract Syntax & Notation' type). When sending the ReadProperty-Request, ReadPropertyMultiple-Request, SubscribeCOV-Request, and  SubscribeCOVProperty-Request messages, the Complex address is ignored.
    • Property identifier: identifier of an object property. You can use the predefined properties or configure a numeric identifier of new property which was defined by the OEM manufacturer. 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 by the OEM manufacturer.
    • Array index: some properties may be defined as arrays of values. In this case, a particular item of an array can be read or written.
    • Kotva
      application_tag
      application_tag
      Application tag: it must be specified when writing the value (Request type=WriteProperty) and possibly for other types of requests if the parsed response contains context tags which application type is unknown because it is the extension of messages defined by the OEM manufacturer. The exception is an output tag of text type that is considered to be 'AnyTree', if the application tag is unspecified, and it can be used to write any user-specified ASN sequence.

      Note: If 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 a tag in a 'tree' in connection with the extension of messages that have been defined by the OEM manufacturer.
      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. 3 in this sequence (again, it must be a sequence),
      2 - it is the second tag in order in this sequence (again, it must be a sequence),
      1 - it is the first tag in order in this sequence.
      The address in 'tree' starts from the propertyValue level (see the examples below). The easiest way to view the parsed message is to turn on debugging for a line and watch the debug info on the console or in the line log file.

      Example 1: Let's have a device that contains the object of type 2 (Analog Value) with instance number 1. Let's assume that the device sends the object value as a triplet of numbers. The first number is the current value, the second one is a one-minute average and the third one is a ten-minute average. The log of the 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 want 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 specify 1, for the second one specify 2, and for the third one specify 3). Tick off the checkbox Subscribe/read in a configuration of one of these I/O tags only, because the response to one request is the message with three values. When sending the ReadProperty-Request, ReadPropertyMultiple-Request, SubscribeCOV-Request, SubscribeCOVProperty-Request, and WriteProperty-Request messages, the complex address is not used.

      Note: If you configure the I/O tag with Property-type=simple, its value would be set to the first found value after parsing the message (in the previous example it is 1.40000E+00).

      Example 2: Siemens Desigo PXC64-U contains I/O tag (Object type=schedule, Instance=6, Subscribe-read is checked, 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, the 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 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 more times and/or values at the same time, you must configure several I/O tags and check the Subscribe/read checkbox in one of them only.

      Note 1: If the I/O tag was created with a complex address 1, its value would remain Unknown, because this address matches the 1st element in propertyValue, which is a sequence, not a simple type.

      Kotva
      pozn2
      pozn2
      Note 2: The I/O tag of Text type is able to contain not only simple value but also any ASN sequence. The values are written according to rules for the writing 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, the value will be "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 a change (see SubscribeCOVProperty).
    • Confirmed: the checkbox specifies whether the device should 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 respective messages for reading/registration of value changes are sent for the configured Request types:
      ReadProperty: the ReadProperty-Request message
      ReadPropertyMultiple: the ReadPropertyMultiple-Request message
      SubscribeCOV: the SubscribeCOV-Request message 
      SubscribeCOVProperty: the SubscribeCOVProperty-Request message 
      ReadWriteScheduler: the ReadProperty-Request message

...