Providing dry-contact relay status signals using a MODBUS-TCP relay module

It is often helpful to be able to provide one or more dry-contact relay outputs to external devices, from the Redflow BMS.

The BMS can drive its own on-board relay, USB-attached relay modules, or external MODBUS-TCP relay units.

The steps to achieve this outcome are as follows:

1) Configure the endpoint(s) required

2) Test the endpoint(s)

3) Configure the required Digital IO "Rules" and/or "Periodic" table entries

BMS endpoints can be created in the Digital IO "Endpoint" tab to use the built-in BMS relay, to use attached USB-serial relays, or to use MODBUS-TCP Slave relay/switching devices:

As many endpoints can be deployed as are desired, of the same or of mixed types.

The examples in this article cover the use of an external MODBUS-TCP control box, but other than creating the endpoint type differently, the functional outcome is identical using the BMS relay or USB relay paths.

Note that the MODBUS-TCP endpoint can actually send arbitrary values (including any of the system summary 'field' values known to the BMS), but in the example on this page, we will be sending manual '0' and '1' values to cause relays to turn 'off' and 'on' as appropriate.

Now we will follow the 3 steps noted above to set up two example relay outputs on a BMS.

The examples here are a 'Rules' based "Generator Call" relay signal, and a 'Periodic' signal expressing a "Master Alarm" signal to an upstream system.

Note that this technique is not vendor-specific, and it can be applied to any MODBUS-TCP Slave unit that can accept on/off commands.

In this example we are using a MOXA iologic E1214 MODBUS-TCP digital I/O box. The MODBUS-TCP unit number and register number values will differ for each brand of external box being used, but the method remains the same.

Configure the Endpoints

First, we need to turn on the MODBUS-TCP endpoint device and configure it with a known (static) IP address appropriate to the local operating environment. It is important that the IP address of the MODBUS-TCP slave(s) is static, so that the endpoint will continue to work in the long term (e.g. across system reboots/restarts).

On the ioLogik, this is what the TCP/IP configuration page looks like:

Once the IP address has been changed, reboot the unit and reconfigure your web browser to reconnect to the unit on the IP address you have assigned to it. Then continue the configuration process.

Next, we need to determine the required MODBUS Unit numbers and Register numbers to operate the relays on the device.

In the case of the ioLogik, the register table is shown inside the web interface on a 'Default Modbus address' page:

From this page, we can see that the digital output ("DO") devices start at register 0 (for Relay output 0), and so on (i.e. register 1 for relay 1, etc).

Simply write a '1' to turn a relay on, or write a '0' to turn a relay off.

On this particular unit, the relays are wired via a plug with screw terminals.

An ioLogik E1214 unit is pictured below, with the operation of Relay 0 and Relay 1 being checked on a test bench:

To drive Relay 0 and Relay 1, we set up two endpoints in the BMS, as follows (via the BMS Configuration->Digital IO->Endpoints page):

We have set up two endpoints - one called "GeneratorCall" to drive Relay 0, and one called "MasterAlarm" to drive Relay 1. 

You should of course substitute your chosen IP address for your ioLogik unit in place of the address shown above.

Testing the endpoints

These endpoints can be immediately tested by using the "DIO Endpoint Test" function in the BMS "Tools" menu. In the example below, we are turning on the "GeneratorCall" endpoint (Relay 0 on the ioLogik).

Configure the required Digital IO "Rules" and/or "Periodic" table entries

Now we can automate the operation of these relay outputs.

Examples of a "Periodic" Digital I/O rules entry to drive the Master Alarm signal, and a set of event-based control "Rules" to drive the Generator Call output are provided in the companion article, "Redflow BMS MODBUS-TCP operations guide"

Monitoring the outcome

The BMS has an event log, accessed via Logs->BMS Logs->Event, that is helpful when the functionality of the system needs to be confirmed.

Periodic entries operate automatically, and will not generate any information in the Event log unless a Periodic update operation fails.

"Rules" based triggers generate an entry in this event log each time one of the rules 'fires'. 

Hence the Event log can be used to keep track of - and to understand - the reasons why the BMS triggers its endpoints (and the values that were present when those rules triggered).