27
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
MV11 = Occupied
End If
If Once Schedule = Off Then
MV11 = Unoccupied
End If
OR
Do Every 5min
If Schedule = On Then
MV11= Occupied
Else
MV11 = 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 controllers 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.
