Redflow BMS MODBUS-TCP operations guide

Concurrent MODBUS Master and Slave support

The BMS can operate as a MODBUS-TCP Slave (being queried over ethernet from a MODBUS-TCP master).

The BMS can operate as a MODBUS-TCP Master, 'pushing' updated outward to another ethernet-attached MODBUS-TCP Slave.

The BMS can do both of these things at once.

Redflow BMS as a MODBUS-TCP Slave

The Redflow BMS contains internal self-documentation regarding the MODBUS register maps that it supports for lookup from a remote MODBUS Master.

Simply log in to the Redflow BMS and go to the "Help" menu, and select 'Data Access Information'.

The resulting page (see screen shot below) contains two tabs. The first tab ("Field Access Information") lists the MODBUS (and JSON) access details to retrieve system-wide summary data for the entire storage array. 

The second tab ("Battery Access Information") lists the MODBUS and JSON access details to retrieve 'per battery' status information.

An example of this page is shown below, however you should simply bring this page up on any active BMS to obtain the latest version.

Importantly - as noted below - the MODBUS unit number to retrieve the 'System Level' information is '201', with the Modbus Register Address and Multiplier and Type fields being as shown. Most field names are self-explanatory.

Contact Redflow support if you require more information about a specific field or if you need to have additional fields created to suit your application.

The fields commonly accessed include:

• soc_all: The default system State-Of-Charge field - appropriate for most purposes
• ah_all: The default system charge energy total in Amp Hours
• Any_Alarm: A boolean that indicates whether any battery is logging an operational alarm at this time
• Voltage, Current: internal (stack) battery voltage and total system current measured (positive means discharging, negative means charging)
• Bus_Voltage: external battery voltage observed
• Permitted_Charge, Permitted_Discharge: Present capabilities of the battery array in terms of charge and discharge maxima (in amps). 

Redflow BMS as a MODBUS Master

The Redflow BMS is capable of operating as a MODBUS-TCP Master, 'pushing' data to one or more remote MODBUS-TCP Slaves.

It can push MODBUS-TCP data to multiple different MODBUS-TCP Slaves at once.

The BMS configuration section that drives this behaviour is under the "Configuration -> Digital I/O" menu:

The tabs shown above provide access to a sophisticated and flexible capability for sending both event-based and periodic (repeated interval) MODBUS-TCP data sending to external devices.

Fields

This tab shows the current values of all available system data fields. The list of fields is the same as noted above for the MODBUS-TCP 'Field Access Information" table. Selecting the Field tab shows you the current (live) values of all of the fields concerned.

Endpoints

This tab shows your existing endpoints and lets you create new ones. An endpoint is a named data structure that defines a remote MODBUS-TCP destination (IP address, unit, register, multiplier).

Once defined, you can manually test your endpoint by using the Tools->DIO Endpoint Tool BMS menu. This menu lets you select an endpoint and write a manual value to that endpoint over the network.

Once you have tested that the endpoint works as intended, you can then automate the process of sending data to that endpoint via the tabs described next.

Here is an example of creating an endpoint to an ethernet-based MODBUS-TCP relay control box (a MOXA iologic E1214). In this case, the designated relay output on the MOXA unit is intended to drive a 'Generator Call' function on a telecommunications site:

Rules

The Rules page lets you create a list of 'event based' triggers, built upon the 'Field' table and express the outcome via an endpoint.

When a given rule-based trigger 'fires', the selected endpoint is used to send out a MODBUS-TCP field update to a remote system. The MODBUS-TCP value 'pushed' can be the current value of the Field concerned, or it can be a manual value.

Here is an example of Rules that implement on/off over a generator, based on complex criteria including state of charge, time of day and bus voltage:

Periodic

The Periodic rule set allows you to list any Field value you wish to transmit on a regular (periodic update) basis to a remote system.

Here is a simple example, that simply writes the current value of the 'Any_Alarm' field to a defined remote endpoint every 60 seconds:

Another common use of this capability is to push the value of the system SoC (usually 'soc_all') to a remote system as a way to keep that remote system updated regarding the SoC of the Redflow battery array. 

(That said, an even better way to communicate SoC, in particular, is via use of the industry standard Smart Battery "CANBus" interface included in the BMS, or to have the remote system poll the SoC as required via the MODBUS-TCP slave path described earlier).

Apply Changes

This tab contains a button to apply the Digital I/O rule-set changes to the BMS. Any Periodic or Rule entries you create, modify, or delete will not take effect until you use the 'Restart' button on the Apply tab to commit these changes into to the BMS system configuration.

 

Debugging

You can manually test an endpoint using the 'Tools -> DIO Endpoint Tool"

If you are wondering whether the Digital IO system is working as you expect, you can check the outcome of its operation very easily. Just go to the BMS "Logs" menu and select "BMS Logs". From there, the "Events" page will show you the decisions being made by the BMS over time, including the outcome of any BMS Rules that trigger over time. 

Any failures to successfully send data to remote MODBUS-TCP endpoints are also show in this log.