The BB3-3101 is an upgrade to the BB2-3010 Modbus RTU to BACnet MS/TP gateway. The BB3-3101 features a faster processor and more memory, which leads to support for a larger number of BACnet objects. In addition, support for state strings for both Binary and Multi-state objects is added in the BB3-3101.
Key Differences | BB2-3010 | BB3-3101 |
Maximum number of BACnet objects | 315 | 1024 |
Maximum number of State Strings | (none) | 4096 |
MS/TP Port Isolated | No | Yes |
Upgrading: If you have an XML configuration file saved from a BB2-3010, you can directly import that into your BB3-3101 by simply opening that file in the configuration tool (see sections 7 and 8).
Control Solutions gateways are not simple protocol translators. It is not possible to do an effective job of simply converting one protocol directly to another. Any attempt to do so would likely have negative effects on the networks on both sides of the gateway. An effective solution requires an intelligent device that can properly and efficiently act as a native device on each network. Control Solutions gateways function as two native devices, one on each network, with a shared data base in between them. They function as clients and/or servers on each network.
The central data element in every Control Solutions gateway is an “object”. Each object has rules for accessing that object which are specific to the protocol of the network. Each object has at least two sets of rules, one set for each of the two (or more) networks that may access the object. The object model is often optimized to cater to a specific protocol, and will most often favor the more complex protocol. For example, all Control Solutions gateways that include BACnet connectivity will have objects that are defined primarily as BACnet objects, with auxiliary rules for accessing the objects via Modbus (or some other protocol).
Control Solutions gateways will function as servers, providing a copy of the most recent data found in its data base when a client requests that data. In master/slave terms, the server is a slave while the client is a master. Some applications will treat the gateway as a server from both (all) networks connected. But most applications will want the gateway to be a server on one side, and a client on the other side. The most frequent application of the BB3-3101 will have it functioning as a Modbus master (client) and BACnet slave (server).
Client functionality of a Control Solutions gateway is autonomous. In other words, when acting as a Modbus master (client), the gateway will continuously poll the Modbus slave device(s) on its own, and keep a copy of the most recent data obtained from (or sent to) the Modbus slave device(s). BACnet clients may read the data at any time, and write new data to the data base at any time. Most often, the gateway is configured to read slave devices periodically, and write to the slave devices when new data is received from a client.
The BB3-3101 can be configured as a Modbus RTU master or slave (client or server), but can never be both at the same time (as specified by Modbus protocol). The BB3-3101 defaults to being a BACnet server (slave), but can also function, at the same time, as a BACnet client (master). Slave functionality requires no special configuration, but client functionality requires specifying a list of remote devices and data points to read or write. The entries in this list are referred to in BB3-3101 vocabulary as “object maps”.
There are three different realizations of the same data within the gateway. The direct connection to the Modbus network is the Modbus register. The direct connection to the BACnet network is the BACnet object. The translating connection in between is a gateway data object. The internal gateway data object very closely mirrors the BACnet object. The primary difference is that the gateway object can be reassigned to different BACnet object types. The same pool of gateway objects could be assigned to all be BACnet Analog Inputs, or assigned to all be BACnet Binary Outputs, just as an example.
The BB3-3101 gateway will most often be a Modbus master. However, it can also operate as a Modbus slave. When the gateway is operating as a slave, Modbus register numbers and function codes are used to decode which BACnet object is being requested. Any necessary data conversion is done automatically, on the fly. Normally, BACnet Analog objects will be read from the Modbus side as IEEE-754 floating point (register pair). But if the "Alt Map" option is being used, then you can read Analog objects as 16-bit integer Modbus registers.