Here is an overview of the typical scenarios for referring to remote Bacnet and Modbus devices in the T3000 programming environment. Be sure to update FIRST your T3000 front end, and then also update the T3 controller firmware as some features are recent.
Two T3 controllers on the LAN
For the two T3 controllers on the Ethernet lan at tabs1 and 2, we use programming lines 1 and 2 to read data from another controller. VAR1 = 2IN1 where 2 refers to any other panel ID on the lan.
Special note about bacnet AI, BI, AO, BO naming: You could also refer to the bacnet equivalent, VAR1 = 2AI1 but you have to be aware of the range. If you switch any item from analog to binary your program may need to change as well. When you use the T3000 internal naming convention, INx, OUTx and so on, you don’t have to worry about the range setting.
There will be situations where you need to address i/o on a remote lan, this isn’t supported for now.
Modbus Devices on the LAN
The Chiller at tab3 is a modbus device connected to the LAN, you can read and write modbus registers to this device over the Ethernet lan with the convention showing in line 3, as in VAR2 = 30.3.MB_REG1. The 30 is the last IP of the chiller IP address and 3 is the modbus network ‘ID’. The chiller and T3 controller need to be on the same Ethernet Subnet, 192.168.0.XXX in this example.
Final note about Modbus Ethernet programming: the port number is assumed as port 502, you can adjust it in the advanced dialogs for the T3 controllers.
Bacnet Devices on LAN
The VFD showing at Tab4 is an example device, a variable speed drive from Honeywell which supports bacnet protocol over the LAN. If the device at Tab4 supports “Bacnet IP” or BIP protocol you can directly refer to the Bacnet objects in this device by their Bacnet instance and object number. The program at line 4 shows the simple example,
VAR1 = 400AI1
Where 400 is the bacnet instance and AI1 is a typical bacnet object on the VFD.
Bacnet Devices on RS485 Subnet
The Tstat8 at Tab5 and VFD at Tab6 are two typical bacnet devices on the RS485/ MSTP subnet of a T3 controller. The example program at lines 5 and 6 shows how to address bacnet objects in these subnet devices, ie:
VAR5 = 500AI1
VAR6 = 600AI1
Where the numbers 500 and 600 refer to the bacnet instance of the two devices. The AI1 refers to any of the various bacnet objects supported by the devices: AI, BI. AO, BO and AV are supported in the programming.
Notice how the programming for all the bacnet devices is the same no matter where the programming is done, whether in Panel 1 or Panel 2, the lines 4, 5, and 6 use the same structure. And the same goes for the network layer, whether the device resides on the main Ethernet Lan or RS485 subnetwork. This is the strong point of bacnet, we just have to know the bacnet instance and the T3 controller takes care of the routing behind the scenes.
Modbus Devices on RS485 Subnet
The example devices at Tabs 7 and 8 reside on the RS485 subnet of controller #2. You can refer to the modbus registers of these items in the example program at lines 7 and 8, ie:
VAR7 = 2.7.MB_REG100
VAR9 = 2.8.MB_REG100
The MB_REG command is used to refer to the modbus registers of the device, the numbering system uses base 0. Only the master controller at Tab2 can refer to these modbus subnet devices in the programming directly, if you find the need to use data from the subnets in a program residing on device #1 you can refer to VAR7 and VAR9 as described earlier in the T3 to T3 example.
Note that data can flow well using standard bacnet and modbus programming on any of these networks from 3rd party devices, the above examples show how to program and integrate from within the T3 controller programming environment.
As an example of 3rd party modbus integration, the T3 will transparently route Modbus packets in gateway mode from the chiller at Tab#3 to the power meter at tab #8 for a load shedding application. The Modbus TCP protocol provides for a “Network ID slot” in each TCP packet for the ‘network ID’, if the ID is a match for the controller #2 it will reply directly, otherwise it will pass the message on to the subnets and the subsequent reply back to the Lan. No setup is required to take advantage of this feature except to configure the T3 subnet as modbus master at Tab9. The other screen shots at Tabs 10 and 11 show the Poll definition setup from a typical Modbus polling program, as you would set it up to poll the device at Tab8 from the Ethernet lan.
One more note about Modbus subnet routing, the Modbus TCP ‘network ID slot’ mechanism means that we cannot talk to a controller with ID=2 on the subnet of a controller with its ID=2, the controller will reply itself.
You can check the network is passing the data around by checking the network activity grid here. Any points passing into and out of the T3 controller over the network will show up here.
