Porovnávané verzie

Stará verzia 4

changes.mady.by.user D2000 Dev Team

Uložené

porovnané s

Nová verzia 5

changes.mady.by.user D2000 Dev Team

Uložené

Kľúč

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

...

  • Communication in Ethernet (BACnet/IP) and LONTalk networks.
  • Limited support of MS/TP network (master-slave token-passing on RS-485): without automatic searching of Master stations.
  • Support of BACnet router (the connection between BACnet/IP and LONTalk networks).
  • Reading and writing of simple values (binary, integer, real, strings, date, time, etc..) and any ASN sequences.
  • Support of the polling method of data reading (messages ReadProperty-Request and ReadPropertyMultiple-Request messages).
  • Support of change method of data reading (an optional registration by SubscribeCOV-Request or SubscribeCOVProperty-Request and next following processing of ConfirmedCOVNotification-Request and UnconfirmedCOVNotification-Request).
  • Writing the values by WriteProperty-Request.
  • Dynamic change of I/O tag address by TELL command SETPTADDR (to read the values of Schedule objects).
  • Work with objects of Schedule type (schedules).

BACnet protocol consider considers 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 within 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 or optional. Moreover, each producer of BACnet devices can implement other properties when necessary.
The messages in BACnet protocol relates are related to the manipulation with objects and their properties. They are defined by with 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 of 'Abstract Syntax & Notation' type. It means that any sequence (or "tree"), the meaning of which meaning is defined by an implementatorimplementer, can be on the given in its 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 context tags depend on the context (on the position in the message). Without knowing the context (a description of message that is being parsed), you can it is possible to find out that on the particular position is the context tag No. 5 of with the length of 4 bytes is on the particular position , but you need an additional information whether the value is Unsigned, Signed, Real, Bitstring or other onea different type of value.
Besides the simple application and context tags, the properties may be also complex:

...

Example - a dump from trace file of a KOM process with the debug enabled:

  === ASN Body beg ===
  objectIdentifier (tag 0) OBJID 0 analog-input,10
  listOfResults (tag 1) SEQUENCE {
    propertyIdentifier (tag 2) ENUM 85 present-value
    propertyValue (tag 4) SEQUENCE {
     ENUM 1
    }
  }
  === ASN Body end ===


ExplanationInterpretation:
It is the Sequence of two tags: objectIdentifier is a contextual tag with the number 0, of Object Identifier type. Its value is Object type=0 (analog input), Instance=10.
The tag listOfResults contains the is a contextual tag with number 1 which and it is a Sequence of two tags. First The first one is propertyIdentifier. It is the a contextual tag No. 2,  Enum type, value = 85 that correspond corresponds to "present-value". A second tag is a contextual one, No.4. It the is a sequence that contains one Enumerated Value tag with the value=1 (application tag).
To parse this message, KOM process must know ASN.1 definition of message. Without it, the process can find out that the message contains the contextual tag 2 (value=1 byte) but cannot know that it is Enumerated Value. It is not able to interpret this byte (it could be Enumerated Value, Unsigned or Signed number) and do does not know that the name of this contextual tag is propertyIdentifier and the value 85 correspond corresponds to "present-value".

The properties of objects are mapped on to I/O tags in the 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 implementatorimplementer.

Kotva
komunikacna_linka
komunikacna_linka
Communication line configuration

...

  • Communication line category: TCP/IP-UDP, LonWorks, Serial, SerialOverUDP Device Redundant.
  • TCP/IP-UDP parameters:
    • Host: IP address or of network interface that is used for communication by KOM process. A symbolic name that can be translated to an IP address can be entered too.
      Note: a symbolic name ALL can be entered - in which case all available interfaces are used.
    • Port: UDP port number that is used for communication by KOM process (according to standard 0xBAC0, i.e. 47808).

Note: The parameters of the backup server (Host and Port) are not used in this protocol.

...

KeywordFull nameMeaningUnitDefault value
Kotva
dbgi
dbgi
DBGI
Debug InputDebug information about the input data. Meaning of the bits:
  • 1. bit - debugging of  ASN message parsing
  • 2. bit - debugging of the I/O tag names that received a new value
  • next bits - not used
-0
Kotva
dtq
dtq
DTQ
Debug Timeout QueueDebug information about messages in time queue.-False
Kotva
di
di
DI
Device InstanceNon-zero value causes that KOM process answers to Who-Is request by I-Am message. It contains a defined Device Instance. Zero value causes that Who-Is request is ignored.-0
Kotva
rb
rb
RB
Receive Buffer(only for TCP/IP-UDP line lines only) Size of received the receive buffer which is set on UDP socket. Zero value means the buffer size remains unchanged. 8192 bytes is a normal size in Windows. If there are more stations or more intensive communication, the buffer should be enlargedenhanced.bytes0
Kotva
ro
ro
RO
Receive OnlyIf the value is True, any no messages are not sent to any station on the line. This parameter may be used when listening to the LonTalk communication LonTalk: Configure the address, which is the same as the address of an existing LonTalk device, on the line. Also configure the station with the device address which communication you need to listen to. The communication between devices is recorded to the log file of the line. RO=True ensures that KOM process does not influence the communication by its commands and respondsresponses.-False
Kotva
sc
sc
SC
Send Count(only for LonWorks line lines only) The retry count of one packet - default value is 1. However, in some situations when using iLON(tm)10 Ethernet Adapter, the first message did not pass and the communication started to work correctly when SC=2.
Note: Later we found out that this was caused because the Free topology bus had not been ended by a terminator. However, this parameter had been already implemented (úsmev).		-1
Kotva
sd
sd
SD
Send Delay(only for LonWorks line lines only) A complement to the SC parameter that defines a delay (v in ms) after each sending of packet.ms0
Kotva
vi
vi
VI
Vendor IDParameter Vendor ID of I-Am message (see the parameter Device Instance).-1

...

KeywordFull nameMeaningUnitDefault value
Kotva
mstp_br
mstp_br
BR
MS/TP baud rateBaud rate of the line. This parameter recalculates helps to recalculate some timeouts that are defined in a bit time in the communication line protocol. Bit The bit time is a multiple of period which is required when transferring for transfer of 1 bit at the particular baud rate.bits/sec9600
Kotva
mstp_mif
mstp_mif
MIF
MS/TP Nmax_info_framesMaximum of information frames that may be sent by KOM process before it must send a token. The standard does not specify the particular value. It recommends that the value must be 1 if this value is not configurable in a device. The higher value is set, the less time remains for other Masters. But on the contrary, it reduces the number of frames without information.-5
Kotva
mstp_mo
mstp_mo
MO
MS/TP Nmin_octetsMinimum A minimum number of data (bytes) received on the line to be received by the KOM process before it indicates the line as "active".-4
Kotva
mstp_addr
mstp_addr
MY
MS/TP my addressAddress of the KOM process on the line RS-485. The valid value is from the interval 0 - 127. It must be different from the addresses of other devices on the line (their addresses are defined in the station configuration).-1
Kotva
mstp_tfa
mstp_tfa
TFA
Tframe_abortMinimum A minimum time (the unit is length of bit transmission, i.e. it depends on MS/TP baud rate), after it expiresthe expiration of which, the whole frame is discarded if it does not receive other tokenno character was received. According to standard, the value may be higher but it cannot exceed 100 ms in the absolute time.bits60
Kotva
mstp_tnt
mstp_tnt
TNT
Tno_tokenTime (in milliseconds). After it expires, without receiving any data, the token disappearswill be considered lost.ms500
Kotva
mstp_tr
mstp_tr
TR
Treply_timeoutMinimum reply time of stationThe minimum time (specified in ms) that the KOM process must wait for the station to respond to the request.ms255
Kotva
mstp_ts
mstp_ts
TS
Tslot

Time (specified in ms) during which the station can generate a token.

ms10
Kotva
mstp_tu
mstp_tu
TU
Tusage_timeoutMinimum time time (specified in ms) for which KOM process must wait while a partner start starts to use a token or respond on responds to a Poll for master frame. A standard value is 20 ms. According to a standard, the value may be higher - maximum 100 ms.ms20

...

  • Value after value: a dynamic change of complex address (1.1, 1.2, 1.3, etc.) in a script enables us 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: an instance number of instance (e.g. 6) which is found from in a 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 day being read
    • Application tag: if it is not defined, Unsigned is used (it is necessary only when writing the value)
    • Complex address: 1 (address of sequence)

The times and values separated by a semicolon are read into the text value (see Note).
When recording writing the value of to a 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 a text value is B,U,S,R or D, it stands for (B)oolean, (U)nsigned, (S)igned, (R)eal or (D)ouble.

...


Writing to the scheduler (the

...

weekly-schedule attribute)

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

...

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} { T0:0:0.0; u3; T1:2:0.0; u1; T2:0:0.0; u2; T5:30:10.0; u3}".

...


Writing to the scheduler (the

...

exception-schedule attribute)

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

...

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

...

  • read)
  • 4C'D2000' - acknowledgmentSource = a source of alarm acknowledgement (

...

  • it

...

  • seems any string is ok)
  • 5{ 2{ D25.11.2005 T11:55:23 }} - timeOfAcknowledgment = date and time when the alarm was acknowledged

After acknowledging of alarm and loading reading the list of alarms and events by the request GetEventInformation, you will see the alarm has been acknowledged .as 
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 read the list of alarms, their record to show them in a browser and acknowledgment of to acknowledge the alarm, you must write the service ESL scripts which will parse the text value of the GetEventInformation request GetEventInformation and compound it for AcknowledgeAlarmand compose a text value for AcknowledgeAlarm.

Note: in the specific case, when acknowledging the alarm, the DESIGO PXC device required the day of the week to be specified within the date (eg D8.6.2020.1 for Monday). A default value of 255 (unspecified) of a day of the week, which is sent when the day is not specified, did not suit the device when acknowledging the alarm.

Kotva
cache
cache
Comment on address cache

...