I am currently working on a project in which a Linux box is to communicate to a Building Management System (BMS) via Modbus over RS-485. The Linux box has its own private ethernet on which multiple UPSs and other power management devices are connected. The Linux box gathers the information from these devices and passes it to the BMS upon request. My question is this: is there a way to sub-address these private network devices? My initial though was to have the Linux box respond to multiple slave addresses, referencing a different register set for each device. However, the number of devices on the Linux box's private network can reach into the hundreds, leaving no free addresses for the BMS to communicate with its other vital systems (since Modbus valid slave addresses are 1-247). The devices on the private network will not be attached to the BMS system directly, therefore all communication must go through the Linux box. The number of private network devices, and the type of those devices can vary from one installation to the next, so hard coding all their data points into one register set isn't really an option either. I'd appriciate any thoughts on the issue.

 

Though problem...
Idea No 1:
You can multiplex the modbus address space (40xxx) assuming each device would not "show" more than n registers. so, the first device would map its registers from 40001 to 40001+n, the second 40001+n to 40001+2n and so on.
If that´s insufficient, you could multiplex it again with MB slave addresses.

Idea No 2:
The BMS writes in the (say) 40001 register the device number to access, and inmediately it request the real data.

[email protected]

 

> You can multiplex the modbus address space (40xxx) assuming each device would not "show" more than n registers. so, the first device would map its registers from 40001 to 40001+n, the second 40001+n to 40001+2n and so on.

That is how the Liebert SiteLink handles the problem. The SiteLink collects data from various Liebert devices using their native protocols, and maps the data from each device into the range of registers associated with that device. Polling those registers in the SiteLink gets you the most-recently collected data from the associated device.

You'll probably want to allocate a couple of registers in each bank for comm status / error code and timestamp of the Linux box's last poll of the device. The program polling the Linux box will be able to determine, by inspection of the contents of specific registers, whether the data received from the Linux box is any good.

> The BMS writes in the (say) 40001 register the device number to access, and inmediately it request the real data.

The write-and-immediately-request is a native Modbus capability; Read/Write Multiple Registers (Function Code 23) allows you to do this in atomic fashion.

Regards,

Greg Goodman
Chiron Consulting

 

> > You can multiplex the modbus address space (40xxx) assuming each device would not "show" more than n registers. so, the first device would map its registers from 40001 to 40001+n, the second 40001+n to 40001+2n and so on.
>
> That is how the Liebert SiteLink handles the problem. The SiteLink collects data from various Liebert devices using their native protocols, and maps the data from each device into the range of registers associated with that device. Polling those registers in the SiteLink gets you the most-recently collected data from the associated device.
>

Do you know if the range of registers for a device is fixed in the Liebert SiteLink? We have a number of different device types that can be monitored by our system, and the setups vary from one installation to the next, depending on what the end-user needs the system for. Also, we allow multiple devices of the same type (i.e. multiple UPSs) to be connected simultaneously. If there is a fixed section in the registers for each device type, how does the system determine which device's data populates those registers?

> > The BMS writes in the (say) 40001 register the device number to access, and inmediately it request the real data.
>
> The write-and-immediately-request is a native Modbus capability; Read/Write Multiple Registers (Function Code 23) allows you to do this in atomic fashion.
>

This sounds like it might be a better solution to my problem. If I understand this correctly it populates the registers only after receiving the device number of the device for which the BMS wants to retrieve data. Is that correct?

Thanks again,
Paul Fazio

 

> The write-and-immediately-request is a native Modbus capability; Read/Write Multiple Registers (Function Code 23) allows you to do this in atomic fashion. <

wow, I didn´t know that, is this feature supported in the majority of modbus master systems?

(digression)
It resembles the way many "ancient" ISA cards work, you write the command in a specific port (or mem address) and the card answers writing in other port the status and eventually passes data through a buffer. I don´t know if PCI cards work in the same manner.

 

> Do you know if the range of registers for a device is fixed in the Liebert SiteLink? We have a number of different device types that can be monitored by our system, and the setups vary from one installation to the next, depending on what the end-user needs the system for. Also, we allow multiple devices of the same type (i.e. multiple UPSs) to be connected simultaneously. If there is a fixed section in the registers for each device type, how does the system determine which device's data populates those registers?>

If I recall correctly, the SiteLink connect to as many as 12 different Liebert devices. Each connection (or 'slot') corresponds to N consecutive registers. (Let's assume, for the purposes of this discussion, that N=24.) The same number of registers is associated with each slot, regardless of what type of device is connected at that slot. For each different Liebert device that a SiteLink can talk to, there is a register map describing which data from the device is stored in which of that slot's 24 registers.

All you need to do is decide, for each device you might want to connect, what data you want to present, and in what order. If you want to keep it simple, allocate as many registers for each slot as the largest number of registers required for any of your devices. (Think of the N registers as a fixed-length record of N fields in a flat database.)

The trade-off is between efficient use of register space / complexity of implementation and inefficient space / simple implementation.

If you want to make it more complex, you can define variable-length "records" (register sets) based on the type of device. The program that maps device data into registers must already know what type of device is associated with each slot; there's no reason your Modbus slave module can't use the same information.

> This sounds like it might be a better solution to my problem. If I understand this correctly it populates the registers only after receiving the device number of the device for which the BMS wants to retrieve data. Is that correct?>

The simple answer is 'yes'; your implementation would allow the master to provide you a value (slot number or device id or whatever) and request the same span of 4x registers (say, 40001-40024). You would reply to each request with data that is a function of the supplied slot number. (The complicated answer is 'well, sort of'. You don't actually have to 'populate the registers'. you just have to populate your response message. Nothing says your source data has to live in a data array that mimics Modbus register memory.)

An advantage of function 23 is that you can serve the data with a very minimal implementation of the protocol. Another advantage is that you need not define the same number of registers for every device. If all devices start at 40001, then queries for different devices can request different numbers of registers.

There are also a couple disadvantages. This approach requires that the master be able to request (and possibly store/present) different data from the same source registers. Not all SCADA software can do that. If the software you're serving to can handle it, then that's not a problem.

Using function 23 also implies that the master can only poll for one device worth of data at a time. A single Modbus response can carry 100 registers worth of data; if your device slots are much smaller than that, you give up a potential efficiency by insisting on single-device polls. (ie If your 'slots' are 10 registers long, then you could support function 3 polls of up to 10 devices at a time, versus 10 function 23 requests to get the same data.)

Hope this helps,

Greg Goodman
Chiron Consulting

 

Hi Paul,
Given the number of devices, you may want to consider an alternative protocol for the BMS link. BACnet would be a likely candidate but getting a BACnet stack that runs under Linux could be a challenge. Try looking at "bacnet4linux.sourceforge.net/":http://bacnet4linux.sourceforge.net/ .

Or you could use an SNMP to OPC gateway since many BMS can accept OPC and most UPS etc can generate SNMP.

Other possiblity would be to run Modbus/TCP between the BMS and Linux box and to implement a seperate virtual Modbus link for each end device.

Regards
Peter Whalley
Magenta Communications Pty Ltd
Melbourne, VIC, Australia
e-mail: peter*no-spam*@magentacomm.com.au
delete *no-spam* before sending

 

Modbus serial "sub-addressing" is done by using multiple serial channels. So if your Linux box had an 8-port serial card, it would be able (even with the reduced range of 1-247) support 1976 slaves. Keep in mind that at 9600 baud, a Modbus/RTU RS-485 line can only manage from 2 to 10 polls per second, so few BMS would try to put 240+ slaves on a SINGLE RS-485. Doing so could mean it takes several minutes to poll the entire group. So I'd assume most BMS will be using many serial channels as they all can work in parallel.

So I'd suggest:
1) From the start, assume support for many serial ports on your Linux "proxy/gateway"
2) Consider the Linux Box "caching" data - prefetching it so the BMS response is faster
3) Creating creating some virtual "alarm or problem" devices which the BMS can poll more frequently to see concentrated "Important Data", verse it having to poll 50 or 100 individual devices to see the same info.
4) Creating data concentration - say 50 of your devices are motors, likely each has only 4-5 words of really useful data. Thus all 50 motors could be represented as a few hundred registers when packed.
4) support direct Modbus/TCP access on a 2nd (or 3rd ENet adapter) - some BMS may chose to use that.

Best Regards
Lynn August Linse, alist (at) linse.org
IA Firmware Specialist, Digi Int'l (www.digi.com)
26741 Portola Pkwy, Suite 1E #242
Foothill Ranch CA 92610-1743 USA
Ph/Fx: 949-916-1524 (auto-detect voice or fax)

 

What I would do is build a kind of simple router on the Linux box. Define a range of registers accessible via modbus that can accept a full message from the BMS or a set of parameters to be built into a message by the Linux box, depending on who you want doing the protocol work on that end. Include a header with the network address of the target device. If you have the possibility of multiple BMSes then you might want instead also define a routing table to match BMS addresses to device addresses for routing the responses to the right requester. But if the Linux box is doing the modbus synchronously then you don't need a routing table. (That would be bad but I don't know about your performance requirements.) This sounds like the case if your BMS request will wait until the round-trip is done all the way to
the device and back. You could just put the response in a response buffer in the Linux box and return a status from the original request indicating whether the response in the buffer is valid. Getting the response requires another read of the response buffer by the BMS.

If the requests are limited in nature you can just define a register to send a request by writing the request number and maybe another one for a network address. After which status and response data is available for reading in a
response buffer.

At any rate you can use the Linux box to send and receive data and status by defining a set of registers to do so and command it from the BMS.

 

I didn't realize that Modbus communication could take place over multiple serial connections simultaneously. This potentially makes my problem much easier to deal with. The Linux box we are working with is a 1U rack mounted computer with one RS-232 and one RS-485 port, and no expansion slots for serial cards, so I'm stuck with the 247 slave addresses. However, knowing that the Modbus master (the BMS system) can communicate over multiple serial connections means I don't have to worry about using up all 247 possible slave addresses. I was originally concerned that there would be no addresses left for the other vital system the BMS needs to communicated with. But if the Linux box is on its own serial connection that means I can use all 247 slave addresses. With that in mind, would the idea of having the Linux box respond to multiple slave addresses work? My thought is to have it keep multiple sets of registers, one set for each connected device, and to access the appropriate set depending on the slave address it is responding for. Does this sound like a good idea?

 

That should work fine. The only problem I could see is suppose each of your devices is a simple temperature probe with 10 registers of data - with only two 16-bit integers being dynamic. To poll 200 of these could take several minutes since each poll for 2 (or even 10) registers could take up to 250 msec. This could create grief for the end-user or integrator buying your product and lessen it's market value.

So you may want to consider creating some virtual "concentrated" devices which pack data from many field devices into a continuous range of registers at a special address to allow polling say 20-60 devices in one packed message. This could add great market value over the BMS just buying & accessing directly the 200 devices without your Linux box.

For example one Modbus device I did some work with is Motor/Drive controllers. Although each has nearly 100 parameters, there may only be
4x16-bit registers which were considered important for constant monitoring (1 was 16 status bits, 2nd/3rd were speed and current load, and 4th was a user selected value). One could easily come up with a simple scheme where say drives 1-19 showed as individuals allowing full read/write access to each by slave address 1 to 19, then the 20th "device" was a simple array of
76 registers made up of the 4 critical registers from each of the 19 drives in the group. Drive 21-39 + 40 could be the same & so on. Such a system
would allow the BMS to poll the full system in just a few seconds (as opposed to a few minutes) and justify a price many $1000 more per system.

Best Regards

Lynn August Linse, alist (at) linse.org
IA Firmware Specialist, Digi Int'l (www.digi.com)
26741 Portola Pkwy, Suite 1E #242
Foothill Ranch CA 92610-1743 USA
Ph/Fx: 949-916-1524 (auto-detect voice or fax)