Porovnávané verzie

Stará verzia 8

changes.mady.by.user D2000 Dev Team

Uložené

porovnané s

Nová verzia 9

changes.mady.by.user D2000 Dev Team

Uložené

Kľúč

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

...

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
Comment on BBMD (BACnet Broadcast Management Devices) support
Tell commands
Literature
Changes and modifications
Document revisions

...

KeywordFull nameMeaningUnitDefault value
Kotva
mstp_br
mstp_br
BR
MS/TP baud rateBaud rate of the line. This parameter helps to recalculate some timeouts that are defined in a bit time in the communication line protocol. The bit time is a multiple of the period which is required 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 the KOM process before it must send a token. The standard does not specify a 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_octetsA 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_abortA minimum time (the unit is the length of bit transmission, i.e. it depends on MS/TP baud rate), after the expiration of which, the whole frame is discarded if no character was received. According to standard, the value may be higher but it cannot exceed 100 ms in absolute time.bits60
Kotva
mstp_tnt
mstp_tnt
TNT
Tno_tokenTime (in milliseconds). After it expires, without receiving any data, the token will be considered lost.ms500
Kotva
mstp_tr
mstp_tr
TR
Treply_timeoutThe 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_timeoutA minimum time (specified in ms) for which the KOM process must wait while a partner starts to use a token or responds to a Poll for master frame. The standard value is 20 ms. According to the standard, the value may be higher - a maximum of 100 ms.ms20

Kotva
komunikacna_stanica
komunikacna_stanica
Communication station configuration

...

Note: In versions from 20th December 2018 and newer, the recycling of browser 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 with , containing the browsed objects, is preserved. Clicking on the close icon at the top right corner will cause the dialog to be really closed.

...

D2000 supports the reading and writing of schedulers. A scheduler contains BACnet attributes weekly-schedule(123) and exception-schedule(38).
Weekly-schedule is an array of 7 items (one item for each day of the week). Each item represents a sequence of time-value pairs that define the value changes of the scheduler in a given time. When reading and writing, you can configure also an Array index and access individual items of a weekly-schedule(123) array. The array index is 1-7 for individual days (1=Monday), the index 0 contains a size of the array (value 7 for the weekly-schedule(123) attribute, value 0 up to N for the exception-schedule(38) attribute).
Exception-schedule is intended for the holidays that require a different mode as is configured for common days. Exception-schedule is the sequence of 0 up to N items. An item always contains a date (or range of dates), several time-value pairs (as in a weekly-schedule), and a priority (1= top, 16= the lowest). The priority defines which of the items will be used if they overlap.

...

Writing to the scheduler (the weekly-schedule attribute)

  • You must configure Request type=ReadWriteScheduler and assign a sequence of time-value pairs separated by semicolon into I/O tag of text output type, 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 written to the scheduler after saving the D2000 configuration or when the KOM process is started. For this reason, if the time plan of the scheduler must be deleted for a particular day, the string of nonzero length (it contains neither time nor value: " ") must be written to the I/O tag.

Kotva
note_schedulersiemens
note_schedulersiemens
Note: Another possibility to write weekly-schedule, besides the ReadWriteScheduler request, is writing of an 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 schedule for the whole week, if Array index is not set and the value contains 7 sequences for 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}".

...

We also tested the reading and writing to the scheduler in the Delta Controls DAC-1146 device. Only the BACnet attribute weekly-schedule(123) was tested. The weekly-schedule is an array with 7 items (one item for each day in the week). Each item is the sequence of time-value pairs that define the value changes of the scheduler in given at a specific time. In contrast of to Siemens Desigo devices, the schedulers are implemented with Boolean values True/False that are externally presented as Enum values 0/1. This is the example of scheduler Delta Controls:
"{ T0:10:0 E0 T1:3:0 E1; } {T2:0:0.0 E1 T5:30:10.0; E0; } { T6:0:0.0 E0 T7:0:0.0 E1} { T20:0:0.33; E0} { T21:0:0.0; E1} { T22:0:0.0; E0} 0{ T0:0:0.0; E0; T1:2:0.0; E1; }"
The writing has done and then as well as subsequent reading of E2 value E2can be performed, however the interpretation by , we don't know the DAC-1146 is unclear's interpretation of E2 :-) .

Kotva
events
events
Information about events

...

The request GetEventInformation-Request is intended to call for ask the list of objects that are in the state Offnormal or Fault states 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 A reply to GetEventInformation-Request is the GetEventInformation-Ack message, 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

...

  • timestamps of the 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

...

  • define whether the events report to to-offnormal, to-fault, to-normal
  • eventPriorities: 3 unsigned values defining the event

...

  • priorities

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

Example of response GetEventInformation-Ack response:

 === ASN Body beg ===
 listOfEventSummaries (tag 0) SEQUENCE 0 {
  objectIdentifier (tag 0) OBJID 0 analog-input,1
  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 9.11.2005 Wed
    time TIME 13:28:49.0
   }
   dateTime (tag 2) SEQUENCE 2 {
    date DATE 9.11.2005 Wed
    time TIME 13:25:59.0
   }
   dateTime (tag 2) SEQUENCE 2 {
    date DATE 9.11.2005 Wed
    time TIME 13:25:56.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,0 to-offnormal(0),to-fault(1),to-normal(2)
  eventTimeStamps (tag 3) SEQUENCE 3 {
   dateTime (tag 2) SEQUENCE 2 {
    date DATE 18.11.2005 Fri
    time TIME 12:52:11.0
   }
   dateTime (tag 2) SEQUENCE 2 {
    date DATE 18.11.2005 Fri
    time TIME 11:16:23.0
   }
   dateTime (tag 2) SEQUENCE 2 {
    date DATE 9.11.2005 Wed
    time TIME 12:23:58.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 ===

...

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

  *********************** Confirmed Alarm and Event Services ******************
  AcknowledgeAlarm-Request ::= SEQUENCE {
    acknowledgingProcessIdentifier [0] Unsigned32,
    eventObjectIdentifier [1] BACnetObjectIdentifier,
    eventStateAcknowledged [2] BACnetEventState,
    timeStamp [3] BACnetTimeStamp,
    acknowledgmentSource [4] CharacterString,
    timeOfAcknowledgment [5] BACnetTimeStamp
  }

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

Example: The loading of following list of alarms and events with the help of GetEventInformationwas read using the GetEventInformation request:

   ===  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 first object is the first in list
objectIdentifier (tag 0) OBJID 0 analog-input,1
which is in has the status low-limit status 
event-state (tag 1) ENUM 4 low-limit
and contains has unacknowledged transition to the offnormal status (i.e. according to D2000 terminology it is an active alarm low-limit alarm 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 by writing a 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 above):

  • 0u1u1 - tag 0, unsigned value 1 - acknowledgingProcessIdentifier = identifier of process which acknowledges the alarm (it could can be optionalarbitrary)
  • 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)
    in this case we acknowledge the transition to the offnormal status in this case status 
  • 3{ 2{ D25.11.2005 T11:54:23} } - timeStamp = the sequence with of date and time which must be acknowledged (it must match to the received event date and time which has been read)
  • 4C'D2000' - acknowledgmentSource = a source of alarm acknowledgement (it seems any string is okit's an arbitrary string)
  • 5{ 2{ D25.11.2005 T11:55:23 }} - timeOfAcknowledgment = date and time when the alarm was acknowledged

After acknowledging of alarm and a repeated reading of the list of alarms and events by the request GetEventInformation request , you will see the alarm has been acknowledged, as 
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 a normal state, it would not have been listed in the list of alarms at all. In this example it is in low-limit state, i.e. it is an active acknowledged alarm.

To read the list of alarms, to show them in a browser, and to acknowledge the alarm, you must write the ESL scripts which will parse the text value of GetEventInformation request and compose a text value for AcknowledgeAlarm.

...

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 (the quadruplet ObjectName; Object Type; Instance; DeviceInstance) is saved to the cache file and is available for the next start of the KOM process.
There is one cache file for every station. It is located in an application directory, in a subdirectory Cache. Its name is Cache_station_name.txt, e.g. Cache_B.StationX1.txt.
When saving a BACnet station, the data is reloaded from this file. If the file was not found, the Who-Has messages are generated for 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 the KOM process (if the addresses of objects were changed when changing the configuration). Just delete the cache file in this station and save it the station - within several seconds, the cache file will be created again and it will be filled with the acquired data.

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

...

  • checked in the configuration of 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 can be used for the objects that are generated and deleted dynamically, which would otherwise

...

...

  • not checked in the configuration of the I/O tag, the cache is searched. If ObjectName or ObjectIdentifier was not found, the Who-Has-Request message is sent to the communication. If the

...

  • response comes, the information is written into the cache.

Kotva
delta
delta
Comment on Delta Controls devices

...

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

Kotva
dsc-1212e
dsc-1212e
DSC-1212E
After logging on to the ORCAview and finding a DSC-1212E device, the object BACnet Settings 3200 (3200 is a software address of the particular device) can be found in the right pane of the Navigator dialog window window. Clicking on BACnet Settings 3200 opened the a dialog window which that contained several tabs. The first tab (Setup tab included ) contained also the UDP/IP port type. After clickin clicking it, its parameters are displayed in at the bottom of the window, e.g. among others Network (during the testing, we saw a specific number 40032), IP Address, and UDP Port.
When communicating with DSC-1212E, in the D2000 configuration of the station the Source network could be either set to the value of Network or left empty. The IP Address and UDP Port parameters must be used to configure the Address and Port parameters in the station configuration in D2000. A station type was BACnet/IP.

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



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

  • Station type: BACnet/IP
  • Address: the parameter IP Address in the configuration of DSC-1212E
  • Port: the parameter UDP Port

...

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

...

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

...

  • of the MS/TP port in the configuration of DAC-633

As D2000 communicates with DAC-633 over via 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 both polling and change method of reading of data (both ReadProperty and SubscribeCOV).
The parameters Object type and Instance parameters in the configuration of the I/O tag was were detected in ORCAview from the attributes Object and Description attributes (e.g. object 3200.AI12 is Analog Input, Instance 12; the object 3202.PG3 is Program, Instance 3). The parameter Address type parameter is Object type+Instance and Request type is SubscribeCOV, if it is not defined other parameter.
unless declared otherwise:

Communicated I/O tagstag types:

  • Analog-input
  • Analog-output (Application tag: Real -

...

  • can be written)
  • Analog-value (Application tag: Real -

...

  • can be written)
  • Binary-input
  • Binary-output (Application tag: Enum -

...

  • can be written)
  • Binary-value (Application tag: Enum -

...

  • can be written)
  • Calendar (Request type: ReadProperty, Property type: Complex, Property identifier: datelist(123), Application tag: Date, Complex address: 1,2,.. etc. -

...

  • sequential reading

...

  • of the array; possibility to write the whole calendar

...

  • using the

...

  • ASN sequence

...

  • when the Complex address is not

...

  • specified, e.g. "0D1.9.2006; 0D3.10.2006; 0D8.9.2006")
  • Event-enrollment
  • Schedule (Request type: ReadProperty or WriteProperty -

...

  • can be written; Property identifier: weekly-schedule(123))
  • Program (Request type: ReadProperty, Application tag: Boolean -

...

  •  can be written - stops and starts the program)
  • Multi-state-value (Application tag: Unsigned -

...

  • can be written)
  • Trend-log (the cyclic buffer of values that are saved with the configured

...

  • period)
    • Property identifier: 1074 - an array of trend

...

    • timestamps in tens of milliseconds since

...

    • the time of data reset
    • Property identifier: 1076 - bit string array (attributes of values?)
    • Property identifier: 1077 - an array of trend values
    • Property identifier: 1105 - the time of

...

    • data reset


Kotva
e-ddc3.1
e-ddc3.1
Comment on E-DDC3.1 devices

...

The communication was revived according to worked with the following configurationsettings:

  • Line: TCP/IP-UDP
  • Station type: BACnet/IP
  • Address: 10.0.6.23 (IP address of E-DDC3.1)
  • Port: 47808
  • Source network: not

...

  • specified
  • Destination network:

...

  • not specified
  • Destination address: 2001 (this was acquired from manufacturer's BACnet OPC server - the

...

  • "Device ID" parameter)


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

  • Analog-input
  • Analog-value (Application tag: Real -

...

  • can be written)
  • Binary-input
  • Binary-output (Application tag: Enum -

...

  • can be written)
  • Binary-value (Application tag: Enum -

...

  • can be written)


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

Kotva
desigo
desigo
Comment on Siemens Desigo devices

...

Based on the 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

...

    • operator 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 converter, which communicated with a heat meter Siemens UH50-A21R-SK06-G. Only analogue inputs was detected. The converter The analog inputs were read, the MBG-MSTP converter supported ReadProperty only ReadProperty.
The communication was revived according to worked with the following configurationsettings:

...

  • parameters of BACnet protocol

...

  • which 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.

...

  • The default value is 5. If this parameter exceeds the number of I/O tags, it causes

...

  • all I/O tags

...

  • to be read in one cycle

...

  • , which is not interrupted because of sending a token. We recommend

...

  • not to increase the value of this parameter if other master devices are connected with RS485

...

  • , which could have problems if they do not receive

...

  • a token for a longer time.
    MS/TP usage_timeout: 99. According to a standard, the value must be under 100 ms.

...

  • The default value of 20 ms caused

...

  • problems with communication (MBG-MSTP did not manage to react

...

  • within a specified timeout).

...

  • Station type: MS-TP
  • Address: 1 (according to the configuration of MBG-MSTP)
  • I/O tag configuration:
    Request type: ReadProperty
    Object type: analog-input(0)
    Instance: according to the configuration of MBG-MSTP or a device which is behind it

Kotva
ilon10
ilon10
Comment on iLON 10 Ethernet adapter

...

When using the 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 of iLON 10 - on the Status tab Status and , the parameter Missed Messages increases number 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 during testing when schedule a time plan of a scheduler contained more than 4 pairs 4 time-valuevalue pairs. When there were 4 pairs, the length of the LON message was 63 bytes. After adding next another pair via PXM20, the loading reading of schedule the scheduler failed.

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

  • configuration software: Echelon Node Utility Release 1.82

...

  • sizes and

...

  • quantities 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

...

The implementation of BACnet MS/TP is not complete yet. It was tested only on basic in an elementary configuration (the D2000 KOM against a BACnet MS/TP MicroGateway produced by the York company). The communication works with both the Serial line (RS485/RS232 converter was used) and SerialOverUDP Device Redundant line (Moxa NPort series 5xxx was used).
MicroGateway (York company) implements the communication of an MS/TP Master type (i.e. it sends the frame the Poll for master frame to detect the existence of other Master stations). The D2000 KOM relies on a partner station and does not contain the implement a method of sending of this frame type. Also, it does not solve handle a failure of the station to which it sends a token.
The actual present implementation is applicable only for communication with one Master station. It can be applicable used for communication with one or more Slave stations (not tested). Also, the time ratio could cause some problems in heavily loaded systems, i.e. KOM could answer to the frames the Poll for master or Token frames later than in required time, which may cause the collisions on the line. The time ratios may become worse when you activate the logs on the might cause collisions on the line. The time ratios may become even worse when you activate the logs on the line.

Kotva
bbmd
bbmd
Comment on BBMD (BACnet Broadcast Management Devices) support

The following feature concerning the conversion of text names to numeric addresses of measured points (Siemens Desigo devices) on the TCP/IP-UDP line has been added to the BACnet protocol (and is available in versions published after 17.01.2012): if the KOM process sends a Who-Has request and the I-Have response comes from another IP address, the KOM process searches for the station that sent the Who-Has request with the text name specified in the response (within the line). If such a station is found, the answer is matched to its challenge.
This feature is useful when communicating with multiple Siemens routers (behind which are, for example, BACnet/LON devices), one of which is configured as a BBMD (Bacnet Broadcast Management Device) and the other is not.
Model situation:
The KOM process communicates with two Desigo PXG80-N BACnet routers (Rtr1 and Rtr2). Behind each router is a LON network, for simplicity with a single Desigo PXM20 station (Des1 or Des2). Router Rtr2 is configured to forward BACnet broadcasts from the LON network to Rtr1.

  • Rtr1 has an IP address of 10.0.0.1 and has BBMD functionality enabled. Behind Rtr1 is the LON network with network address 11 and a Desigo PXM20 device (Des1) with address 1.1
  • Rtr2 has an IP address of 10.0.0.2 and has BBMD functionality turned off. Behind Rtr2 is the LON network with network address 12 and a Desigo PXM20 device (Des2) with address 2.2

Let's have one TCP/IP-UDP communication line and on it two BACnet/IP stations representing Des1 and Des2

  • L.Bacnet line:  TCP/IP-UDP type
  • Station B.Des1:
    Station type: BACnet/IP
    Address: 10.0.0.1 (address of Rtr1, behind which Des1 is located)
    Port: 47808 (standard BACnet port)
    Destination network: 11 (address of network behind Rtr1)
    Destination address: 1.1 (address of Des1 in a LON network)
    Register-Foreign-Device: enabled (for the KOM process to register as a broadcast recipient on Rtr1, which has active BBMD functionality)
  • Station B.Des2:
    Station type: BACnet/IP
    Address: 10.0.0.2 (address of Rtr2, behind which Des2 is located)
    Port: 47808 (standard BACnet port)
    Destination network: 12 (address of network behind Rtr2)
    Destination address: 2.2 (address of Des2 in a LON network)
    Register-Foreign-Device: disabled (Rtr2 has inactive BBMD functionality)
  • Any I/O tag M.Des2_test on B.Des2 station (e.g. of SubscribeCOV type) with Address type = Name

The KOM process sends a Who-Has request to the Des2 device to convert the text name configured in the M.Des2_test address. The IP address of Rtr2 (10.0.0.2) is used for sending.
Rtr2 forwards the request to the LON network to Des2 (according to the parameters Destination network = 12 and Destination address = 2.2 specified in the configuration of B.Des2 station ). An I-Have broadcast response arrives from the BACnet/LON device Des2. As the BACnet router Rtr2 is without BBMD support, it forwards the response (assuming it is configured to do so) to the BACnet router Rtr1, which has BBMD support enabled.
Rtr1 forwards the I-Have message as a UDP packet to the KOM process because the Register-Foreign-Device parameter of B.Des1 station is configured and thus the KOM process has registered as a broadcast message recipient at Rtr1. This way, the I-Have message gets to the KOM process with a different IP address than the original request. The functionality described above matches such a response with a request from the B.Des2 station based on the match of the text name of the object in the sent request.

At the same time, one configuration limitation results from the described procedure - all the described activities take place in the context of one line, so it is necessary that all stations that are within the scope of one BBMD device are located on one line.

Kotva
tell_cmd
tell_cmd
Tell commands

...

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 the 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)

...