Problems and cautions when communicating with TAC (Viconics) Bacnet communicating thermostats

[Product_Support]

Issue

Problems and cautions when communicating with TAC (Viconics) Bacnet communicating thermostats

Product Line

Andover Continuum

Environment

• BACnet
• Continuum
• Viconics

Cause

Need troubleshooting and cautionary information when working with Viconics Stats and Continuum

Resolution

Integrating SE/Viconics' Devices on an MSTP Network

SE7000 Series Room Controllers do not support the COV service but SE8000 do support it. For the SE7000 controllers, 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 room controller object.

Enhanced MSTP

Continuum BACnet devices support enhanced MSTP, which is a proprietary service which allows the BCX level controller to receive the MSTP token between every MSTP controller on the network. This feature allows the BCX to have speedy access to send and retrieve data to any MSTP controller on the network for such things as graphics and data polling. The SE/Viconics stats, as well as any other 3rd party BACnet device, does not support this feature. So a network of stats will perform normal BACnet token passing and for instance, if you had 100 stats on the MSTP, the BCX controller would only be allowed to talk once for every 100 token passes on the network. This will make for slow responses to such things as graphics requests for data. Sending too many requests for data on the network will bottleneck the requests.

Graphics

Continuum graphics will poll the SE7000 series because they do not support COV. It is very important that you set the request interval on the Thermostat device object editor to a large number such as 5000 ms. This will avoid overwhelming the stat with poll requests. This becomes even more critical in area graphics where a single graphic might poll many devices. If proper poll rate is not respected, devices may be reported offline by saturating the traffic handling capacity of BACnet MSTP without COV subscription.

Plain English programs

As for the application programming, you should be very careful when programming things such as sending setpoints, or mirroring the Stat's points in the BCX controller for such things as trend logs or graphics polling. You will need to write the setpoint change programs to send only on change, and any data mirroring on a once in a while basis. Otherwise, any read or write request will occur at the controller's scan rate, which might 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 hundredths of milliseconds.

Programs writing to the devices should have a structure similar to the following:

Line setschedule
  Numeric ScheduleState
  Schedulestate = Schedule
  If Schedule = On then MV11 = Occupied
  If Schedule = Off Then MV11 = Unoccupied
  goto TestForChange

Line TestForChange
  if Schedule <> Schedulestate then goto setschedule

line E
  if ts>5 then goto setschedule

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:
   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. Number of APDU Retries:
   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, 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 device editor since the workstation will likely issue requests to any MSTP devices when the graphics are used.

For more detailed information on programming for these stats see the installation guides and instruction manuals for these devices.