Commanding MS/TP BACnet Objects Directly on Tridium AX

On a recent integration project, we encountered some unexpected problems when trying to send commands from E2H directly to a field device connected to an MS/TP comm trunk on a Tridium JACE controller.  In this particular scenario, the following hardware was used:

  • Building Controller: Tridium AX JACE with BACnet MS/TP drivers (no BACnet server)
  • Field Controllers: BACnet MS/TP controller with on board control logic and without priority array support
  • Events2HVAC (E2H) BACnet/IP client - Configured to send a write command directly to controller's resident OccupancyCmd point, in this case (BV01).

E2H was able to discover all the points it needed to control over BACnet/IP. The JACE has a BACnet router built into the MS/TP driver that allows direct communication. However, the BV01 BACnet object did not support the Priority Array property, so it had to be handled differently.

Here is what we learned in completing this integration in Events2HVAC.

When you are setting up the BACnet actions in E2H to control the end device's BACnet object, you can use the BACnet Explorer to view devices on the network and all visible BACnet objects. Figure 1 shows the BV01 object in the controller. As you can see in the properties list, Priority Array is not shown. This indicates that it does not support priority command handling.

Figure 1 - E2H BACnet Explorer Showing BV01

You can also see in the Action dialog (Figure 2) that the Priority Array property is shown as "Unknown" after verifying the point in E2H.

Figure 2 - E2H BACnet Action - Point Properties

The Problem

When you send a test command to this point, the results of the command will indicate the BACnet controller accepted the command and that it was successfully executed, which it was.  The problem is that if there is anything in the JACE writing to the priority array of the OccupancyCmd's proxy point, it will override the E2H command at the BACnet object on the controller.

When you discover the BACnet objects in an MS/TP field device, the JACE creates a proxy point for each object you bring in. For a Binary Value (BV) object, the proxy point includes a priority array (1-16) that the JACE uses internally to manage commands and operator overrides to that controller's object.  The following screenshot (Figure 3) shows what the proxy point looks like once it is discovered and brought into the JACE.  In this example, something has written to IN16 from within the JACE so the output is sending an Enable command to the BV01 point.

Figure 3 - AX Workstation View of BV01 Proxy Point

Notice that the proxy point has a priority array very similar to the BACnet priority array, but they serve a different function. The proxy point is not a BACnet object that can be written to by another BACnet client. If any programming commands are written to the IN1-IN16 slots, the output is written directly to the controller BV01 object. Operator commands will also be added to the appropriate priority slot to allow overrides to occur.

Since this proxy point is not visible to other clients viewing the JACE from BACnet/IP, E2H only sees the MS/TP BACnet objects directly on the field device.  The field device point BV01 does not support a property array, so if multiple BACnet clients try to write to this point, the last command will win. The JACE proxy point appears to constantly keep the output of the proxy in sync with the field device BV as long as their are commands in one of the IN1-IN16 slots.  Therefore, any direct command that E2H issues to BV01 will get overwritten with the JACE proxy point.  When all of the IN1-IN16 slots are cleared (null) from any commands, E2H commands written to BV01 will stay commanded.

 The diagram below (Figure 4) shows how the routing appears to operate when there is no BACnet server driver installed on the JACE.  

Figure 4 - JACE controller w/o BACnet server drivers and with MS/TP drivers

The Solution

The solution to this issue is to design the control logic on the JACE to always write a null value to the priority array input when the command expires, so the proxy point should always look like Figure 5.  One way to accomplish this is create two BVs on the target controller and write to both of them from the E2H. One BV is the occupancy command that is written to by the E2H and can be overridden by Kit Control on the JACE, this should be configure on the JACE as a writable point.  The other BV is a “flag” that is written to by the E2H but is configured in the JACE as a read only point. 

Figure 5 - Proxy point with null inputs

At the conclusion of any override the Kit Control should release (write a null value) to any input in the priority array linked to the Kit Control's blocks.  Use the flag to write a true value to the OccupancyCmd thru the Kit Control if the E2H is calling for the room to be in use, but release the command after enough time has passed for the value to be written to the controller resident BACnet object so that the E2H can command the OccupancyCmd when the next scheduled event occurs.  

Figure 6 shows how the additional action was configured for the zone in E2H.

Figure 6 - Proxy point with null inputs

Was this article helpful?
0 out of 0 found this helpful
Have more questions? Submit a request

0 Comments

Article is closed for comments.