Viconics VTR7300 BACnet Integration Manual - Manual (Page 29)

29
Integrating Viconics’ Devices on an MSTP Network
Before doing any BACnet integration, make sure to have Viconics’ PICS (Protocol Implementation
Conformance Statement).
This PICS document lists all the BACnet Services and Object types supported by a device and can be
found at www.viconics.com.
Viconics’ devices do not support the COV service. COV reporting allows an object to send out notices
when its Present-Value property is incremented by a pre-defined value. Since this is not supported at
Viconics’ end, special attention should be given to the polling time settings at the Supervisory Controller
and Workstation level when using a graphic interface or an application program to read or write to a
Viconics’ object.
Graphical interfaces
For example, some graphic interface might poll every data linked to the graphic page on a COV basis. If
the 3
rd
party device does not support COV, the graphic interface then relies on a pre-configured polling
interval, which is usually in hundredths of milliseconds. Any device containing a monitored object could be
subject to network traffic congestion if such a polling interval is used. Viconics strongly recommend a
polling interval of 5 seconds minimum for any graphic interface. This becomes even more critical in area
graphics where a single representation might poll many devices. If proper poll rate is not respected,
devices may be reported offline by certain front end by saturating the traffic handling capacity of BACnet
MSTP without COV subscription.
Free programmed object or loops
As for the application program, you might want to read and write any MSTP data on an “If Once” basis or a
“Do Every” loop basis instead of reading or writing to a 3
rd party device’s object directly in the program.
Otherwise, any read or write request will occur at the Supervisory Controller’s program scan rate, which
might as well be in hundredths of milliseconds. This can easily bog down a network as single commands
can be sent to all ASC devices down the MSTP trunks every hundredth of milliseconds
Programs writing to the devices should have a structure similar to the following:
If Once Schedule = On then
MV13 = Occupied
End If
If Once Schedule = Off Then
MV13 = Unoccupied
End If
OR
Do Every 5min
If Schedule = On Then
MV13= Occupied
Else
MV13 = Unoccupied
End If
End Do
Retries and Timeouts
Another thing to look for in a BACnet integration is the Device object of the Supervisory Controller (and the
Operator’s Workstation). This object contains the 2 following required properties:
1)
Retry Timeout;
2) Number of APDU Retries;
1) The Retry Timeout property specifies the time between re-transmissions if the acknowledgement has not
been received. When you are experiencing problems with controllers dropping off-line, increasing this value
may help.
2) The Number of APDU Retries property specifies the number of times unsuccessful transmissions will be
repeated. If the receiving controller has not received the transmission successfully after this many attempts,
no further attempts will be made.
For example, if one of the thermostats does not reply to a Supervisory Controller (SC) request, and the
SC’s Retry Timeout is set to 2000 msec and the Number of APDU Retries is set to 1 (still at the SC level),
then the SC will send one other request, 2 sec later. If the MSTP device does not reply, it will be
considered Off-line by the workstation.
So having a Retry Timeout value of 10000 msec and a Number of APDU Retries property set to 3 at the
SC level may prevent device from dropping Off-line. These properties should also be changed at the
Workstation level since the workstation will likely issue requests to any MSTP devices when the graphics
are used.