Control Solutions is your source for LonWorks I/O.

How do Modbus registers map to OIDs?

The Babel Buster SP functions as a stand-alone server device. It can be configured as a Modbus RTU master or slave. It is also concurrently a Modbus TCP client and server. When the RTU side is configured as the master, it automatically polls the various Modbus devices periodically. The TCP client, if used, will also automatically poll various Modbus TCP devices periodically. This data is stored in local registers in Babel Buster SP. This data is simply saved, waiting for SNMP to Get the data. When SNMP does a Set, this results in data being written to the Modbus device once per update, or repeatedly if configured to do so.

To begin the process of mapping Modbus to SNMP, you need to obtain documentation from the device manufacturer telling you which registers contain what data. You will also need to see that baud rates are matched, and you know or can set the RTU slave address (or unit number, comparable to a shortened IP address).

There are technically four types of Modbus "registers"; however, most of the time you will be dealing with "holding registers". If no mention is made of register type, you can reasonably assume holding register.

Modbus register numbers are the Modbus equivalent of the SNMP OID, but simply much shorter, having only a single number rather than a string of numbers like the OID. There is no concept of a tree structure to the numbering scheme in Modbus. It can be thought of as a simple array of numbers, and the register number is your index into that array.

The screen shot clip below illustrates setting up read map #1 to get register 1 from remote device 1 and storing its data in local register 1. Check out the web page demo above for a more in depth look at this.

If we now want to see the OID list where we find this data, look at the MIB View page. The OID for reaching the data obtained from register 1 at device 1 is 1.3.6.1.4.1.3815.1.2.2.1.1.1.1.1.2.1.

Can I read floating point registers?

Yes. Although floating point is not standardized in Modbus protocol, it is a widely accepted standard that Modbus uses IEEE-754 32-bit floating point notation. But you do need to know some details and pitfalls to watch for.

Modbus protocol defines "registers" as 16-bit entities. This means devices will use two consecutive registers to provide access to a 32-bit floating point number. This concept is widely recognized; however, the definition of whether the high order register is first or second is not at all standardized. Since the Modbus protocol is by definition "big endian", Control Solutions treats big endian register ordering as "normal". If the low order register comes first, Control Solutions calls this "swapped". Other companies may define swapping opposite this. It doesn't matter, because each read or write map allows you to specify whether the target remote register is swapped or not and it becomes a relative thing.

If floating point registers are incorrectly swapped, a floating point value of 1.0 will become 2.27795e-41, which will most often be rounded to zero. In case you are tempted to draw a simple conclusion about the pattern of 1 displayed as zero, here is another example: Incorrectly swapping registers will turn the value 1.1 into -107084896.

How do the two registers containing a floating point value map to an OID? The pair of registers are treated as one entity by Babel Buster SP any time you specify a 32-bit register format. Provided you select a floating point local register as the destination for reading Modbus, or as the source for writing Modbus, that local register is accessed as a single floating point OID.

How do I handle 32-bit integer values?

Local registers in Babel Buster SP are either 16-bit integer or 32-bit floating point. If you are interested in a large value provided by the Modbus device as a 32-bit integer, we recommend you map it to a floating point local register. You will end up with approximately the same data.

There are times when "approximately" isn't good enough, particularly when the 32-bit register is a bit mask and you are interested in each individual bit. In this case, you can usually read the 32-bit register as two consecutive 16-bit registers (that's what they are in the protocol to begin with), and map them to two separate 16-bit local registers.