Delta with Tridium Front End

[controlstec]

I am working on a site that has had problems with communication between Tridium R2 and Delta 3.30. There are two things happening, one, the Delta controllers have been dropping offline on a consistent basis for about 3 years now. The solution provided to me from Delta for this particular problem has varied and I've tried all of them, but none has been totally successful. The second thing that has been happening is that the Tridium Jaces have been locking up. The Jaces stop polling data from the Delta controllers and therefore none of the data from the Delta controllers is read at the Jace or the Front End graphics. The only way to get communication between the two systems going again is by cycling power to the Jace. In the standard output of the Jaces, I get the following error for just about all the controllers onsite:

WARNING: BACnet Read Property Multiple Error: presentValue [/AJJC_Support/BACnetTemp/Alameda_Reheat_VAV_A3_6R]
WARNING: BACnet Read Property Multiple Error: statusFlags [/AJJC_Support/BACnetTemp/Alameda_Reheat_VAV_A3_6R]
WARNING: BACnet Read Property Multiple Error: priorityArray [/AJJC_Support/BACnetTemp/Alameda_Reheat_VAV_A3_6R]
WARNING: BACnet Read Property Multiple Error: presentValue [/AJJC_Support/BACnetTemp/Alameda_Reheat_VAV_A3_7R]
WARNING: BACnet Read Property Multiple Error: statusFlags [/AJJC_Support/BACnetTemp/Alameda_Reheat_VAV_A3_7R]
WARNING: BACnet Read Property Multiple Error: priorityArray [/AJJC_Support/BACnetTemp/Alameda_Reheat_VAV_A3_7R]

I have been in contact with Tridium support and they tell me that the Jaces are trying to communicate to the Delta controllers using the read property multiple type of BACnet message and they don't support read property multiple. They recommend I set the ReadPropertyMultiple value on each of the Delta controllers to false.

My questions are, why are the Delta controllers still dropping offline and is the assessment of the ReadPropertyMultiple function the actual cause for the Delta/Tridium communication problems and if that is the problem, what is the fix? Can the ReadPropertyMultiple function be set to false in the Delta controllers?

[jriley]

Do you know what version of the R2 BACnet file you are using? I would recommend 514 or 527i. All others seem to not work properly.

[BACnet]

Controlstec- The controllers should declare themselves to either support RPM or not. This is specified in the "Protocol Services Supported" variable in the Device object. The variable is a Bitstring value and it is bit 14 (they start at 0) that you are interested in.

If the devices say they support it, they are required to support it. If they say they don't support it, they don't. If they are not reporting this bit properly then you need to get Delta to give you a firmware update that fixes the problem.

I have not heard of any controllers that allow you to write to the "Protocol Services Supported" property, that would likely be problematic for many reasons.

To check to see what the device declares about itself, do a manual read of property 97 of the Device object of one of these devices. Then check to see what bits are set. If it says that it doesn’t support RPM, then the tridium side may be at fault. If it says that it does support it but then doesn’t, Delta should get a phone call.


Here is the master list of each of the (up to) 40 bits in this required property:

Bit 0- acknowledgeAlarm
Bit 1- confirmedCOVNotification
Bit 2- confirmedEventNotification
Bit 3- getAlarmSummary
Bit 4- getEnrollmentSummary
Bit 5- subscribeCOV
Bit 6- atomicReadFile
Bit 7- atomicWriteFile
Bit 8- addListElement
Bit 9- removeListElement
Bit 10- createObject
Bit 11- deleteObject
Bit 12- readProperty
Bit 13- readPropertyConditional
Bit 14- readPropertyMultiple
Bit 15- writeProperty
Bit 16- writePropertyMultiple
Bit 17- deviceCommunicationControl
Bit 18- confirmedPrivateTransfer
Bit 19- confirmedTextMessage
Bit 20- reinitializeDevice
Bit 21- vtOpen
Bit 22- vtClose
Bit 23- vtData
Bit 24- authenticate
Bit 25- requestKey
Bit 26- i-Am
Bit 27- i-Have
Bit 28- unconfirmedCOVNotification
Bit 29- unconfirmedEventNotification
Bit 30- unconfirmedPrivateTransfer
Bit 31- unconfirmedTextMessage
Bit 32- timeSynchronization
Bit 33- who-Has
Bit 34- who-Is
Bit 35- readRange
Bit 36- utcTimeSynchronization
Bit 37- lifeSafetyOperation
Bit 38- subscribeCOVProperty
Bit 39- getEventInformation

[checkvalve]

In R2 there is a Niagara property for each bacnet device that is modeled in the station which controls whether the station will try to use read property multiple requests when polling data from the bacnet device. This is separate from the protocols and services which the device supports, which also happen to be shown under each bacnet device. It sounds like tech support was telling you to change the Niagara property under the bacnet device such that the station was not trying to perform a rpm request.

Note that the Delta device most likely responds with a message stating that the rpm was not supported, which in turn should make the station perform individual read requests. However, it is still probably trying to send out rpm on occasion which you know are going to fail.

Depending on what version of the bacnet module that you are using, there are some known issues with the bacnet poll thread dying. There is a workaround available that monitors the status of the poll thread and restarts it if fails. The latest bacnet module should correct the actual issue.

If the problem happens again I would suggest trying to just disable the bacnet polling in the station and then re-enable polling. If it starts working again without power cycling the Jace, then you are likely having the issue with the poll thread dying.