Offline configuration and import/export

From firmware v4.x,Offline configuration had been introduced. Now user could configure a BACRouter without device on hand, then export configuration to a file. When commissioning on the field, user just need to import previously exported file, “Save&Reboot” to take effect the configuration.

From v4.04,The object definitions for Modbus gateway could be import/export as CSV format. User could effectively setup object to Modbus address mapping In batches with Excel/WPS/Libreoffice, then import it to WebUI for detailed modify.

Offline configure on our website

Download and extract it to disk, open index.html by your web browser (Because IE/Edge doesn’t support Local Storage for file:// URL, the user library for binary text and most used engineering unit will not be kept after leaving the web page)

There are 3 types of configuration file:

BACRouter Configuration File

This type of configuration file keeps all settings in BACRouter. If the firmware version of exporting one is same to importing one, WebUI should not complain of the configuration file.

Modbus Master Configuration File

This type of configuration file keeps setting under the scope of Modbus master.  When importing it, collision detecting logic based on current mapping mode will check every enabled slave in this master, if collision is found, the slave will be disabled.

If the master is RTU/ASCII type, it may also be disabled if there are contention for RS485 port.

With these problem, WebUI will prompt user to re-check configuration.

Modbus Slave Configuration File

This type of configuration file keeps setting under the scope of Modbus slave.  When importing it, if collision detecting logic based on current mapping mode found problem, the slave will be disabled.

It is allowed to import TCP salve configuration file in RTU/ASCII master, and vice versa, but the slave may be disabled if Modbus parameter setting do not work.

With these problem, WebUI will prompt user to re-check configuration.

Modbus Gateway in BACRouter

Update on 2021-06-07  for version 4.05

From firmware version 4.x,  BACRouter has builtin Modbus gateway functionality. This article will try to explain the underlying mechanism.

Modbus Read

BACRouter will periodically read point’s value and cache it.  “Update interval” defines how often BACRouter update the value.

To improve performance, BACRouter will read as more as possible data in one transcation. In Modbus standard, at most 2000 bits (coil or discrete) or 125 registers (input or holding register) could be read in one request, but specific Modbus slave device may only support a lower value.  In BACRouter’s WebUI, there is a Modbus parameter edit dialog in “Slave Settings”, “Multiply read bits” and “Multiply read registers” parameters define the ability of the slave device.

BACRouter will not segment reading of single point even the “Multiply read registers” is less than registers used by the point.

Usually the data we care for has discontinuous Modbus address, for example, We only care for coils on address 1 and 2000, though we could read coil data from address 1 to 2000 in one request and skip returned data from address 2 to 1999,  sending two requests independently for coil on address 1 and coil on address 2000 maybe more efficient. “Bits skipped” and “Registers skipped” parameter define how many unused data units between 2 cared data units are allowed to be skipped. As previous example, if “Bits skipped” is set to 1998, the BACRouter will try to read coil 1 and 2000 in single request. If “Bits skipped” is set to 1997, then BACRouter will read Coil 1 first, then Coil  2000, because bits skipped is 1998 and is greater than the setting of 1997.

On the WebUI page for slave, the “Read Group” button will show how the BACRouter will group the reading and test it. User should pay special attention on server exception of “Illegal data address”.

Modbus Write

BACRouter will not combine multiple writing demand into one writing request. It always queue write request immediately after receiving command.

For writing single data unit, there are two Modbus function codes available. For example, function code 5 is writing single coil,  function code 15 is writing multiple coils but the quantity of coil to write could be assigned to 1. Some devices only support one of them.  “Coil write singly” parameter will specify which function code is used.

In the same way, “Register write singly” is applied to register writing. If any BACnet output object maps to multiple holding registers, it implies the slave device support function code 16 for write multiple registers, function code 16 will be used for writing any register whatever “Register write singly” is set.

Offline

If any read/write request failed, BACRouter will retry it, when the continuous fail count reachs 3, BACRouter will regard the slave device as offline. In offline state, BACRouter will retry the request every “Offline update interval”.

The BACnet side reaction for offline event will be described later.

Modbus Serial Bus

BACRouter supports serial slave devices with different baudrate, parity, RTU/ASCII mode on same RS485 bus. Before sending request, BACRouter will change it serial port parameter based on slave device’s settings.

It should be safe to have 2 devices with same slave address but different baudrate or RTU/ASCII  mode, but preventing collision based on different parity might not be enough, because some devices do not examine parity error.

Single Device Mapping Mode

If VBUS network port is not enabled, BACRouter will work in single device mapping mode, every Modbus slave device will be mapped into exclusive object instance space of 1000 in the only BACnet device defined in “Application Settings”.

The actual BACnet object name will be organized as “master_name|slave_name|object_name”,  The delimiter “|” is select-able by user.

As recommended by standard, BACRouter will create one StructuredView object for each slave device.

When the slave device turn to offline in this mode, all points’ reliability will be set to “COMMUNICATION_FAILURE”, if slave device is back to online, upon updating of point value, the point’s reliability will be set back to “NO_FAULT_DETECTED”.

Virtual Device Mapping Mode

If VBUS network port is enabled. Each slave device will be mapped to a virtual BACnet device on VBUS network. The MAC address will start from 1.

In this mode, each slave shall has a unique “Device instance”. The actual device name will be “master_name|slave_name”, The delimiter “|” is select-able.

When the slave device turn to offline in this mode, as recommended by standard, the virtual BACnet device will stop sending/receiving any packet to simulate offline state. if slave device is back to online, after updating all point’s value, the virtual BACnet device will quite offline state.

Slave Device’s Status

For every slave device, BACRouter will create 3 objects in gateway device, one object is Binary_Input with name of “online”, which represents online/offline status of slave device. another object is Analog_Input with name of “update_delay”, which is recently average update time delayed over “”Update interval”, the last one is Analog_Input with name of “fail_rate”,  which count a relative long time fail rate on Modbus side.

Those objects’ name have prefix of “master_name|slave_name|comm|”, where “|” is select-able delimiter.

Object Instance Assignment

Object Instance is defined for every object. When the editor dialog for a object is submitted and the object is enabled, the object instance claimed by the object will be assigned, if that assigning fail, a automatically selected instance will be used.

Value Object

AV/BV/MV is behaving same as AI/BI/MI, except that when AV/BV/MV is mapped to writable Modbus address (0X or 4X), the present value of the object is writable, the writing will be forwarded to Modbus side.

Output Object

The value of output object is still being polled from Modbus side and set to object’s Relinguish_Default property. If the value read back does not match last value written, BACRouter will set the reliability of that object to “UNRELIABLE_OTHER”,  and BACRouter will queue another write after a certain time.

Because of above verifying mechanism,  the BACRouter will prevent defining two output objects with overlaping Modbus writable address.

NaN For Float And Double

NaN is a special value defined by IEEE-754, BACRouter does not accept NaN (Infinite is still valid for BACRouter).

When a point is defined as Float and Double, but NaN is read from slave, BACRouter will set the reliability to “UNRELIABLE_OTHER”.

Interoperability between extended MS/TP frame capable devices and legacy devices

Original BACnet MS/TP data link specification only supports NPDU length up to 501 bytes, which is much shorter than 1497 bytes of Ethernet and IP data link. It limits transmission performance, increases complexity on application layer, especial when two IP/Ethernet networks are conjoined by a MS/TP network.

Extended frame was designed to solve this problem. The detail could be found here. Briefly, this addendum added two new frame types as:

  • 32: BACnet Extended Data Expecting Reply
  • 33: BACnet Extended Data Not Expecting Reply

Frame type 32 is extended from frame type 5 (BACnet Data Expecting Reply),  the special of it is that it is encoded by COBS and the NPDU length it carried is in range of 502 to 1497 bytes.

In the same way, frame type 33 is extended from frame type 6 (BACnet Data Not Expecting Reply)

Extended frame support was added into BACnet standard since revision 16. There are still lot of devices installed or on the market that do not support it. The interoperability between extended frame capable devices and legacy device is discussed below.

  • Non-router legacy device and extended frame capable device: Because all messages sent to legacy device are application layer message, the “Max APDU Length Accepted” from Device object property or confirmed service request primitive should be respected, the NPDU length will not exceed 501 bytes. So there are no problem with this configuration.
  • Legacy router and extended frame capable device: NPDU that should be relayed to other network through legacy router with length over 501 bytes will be discarded, no reject-message-to network with reason “Message Too Long” will be responded. Even more, the “Max APDU Length Accepted” of legacy router may be determined by other port that has a NPDU length larger than 501 bytes (It is allowed by standard), so NPDU for local application layer sent to legacy router will still possibly be carried by extended frame and discarded. So this configuration may cause problem in field.

BACRouter supports extended frame from very early version. From firmware version 3.18, we introduced “Extended frame” option on BACRouter’s MS/TP configuration, if there are legacy router that does not support extended frame on the bus, this option should be disabled to avoid Interoperability issues.

It’s worth noting that even “Extended frame” option is disabled, unlike legacy router, BACRouter will still be interoperable with extended frame capable devices.

(Screenshot has been updated on Aug 5, 2021. Because extended frame is mandatory from standard revision 16, from firmware 4.13, we move this option to extended configure mode.)