Modbus is a protocol, a set of rules, that defines the rules for how data is transferred between master and slave and how the data bits are 'packed' for data transmission.
To Modbus, all data is just bits; the bits have no meaning to Modbus. Modbus rules define an input or holding register (used for data values as opposed to discrete on-off states) as 16 bits. But Modbus does not define how the data is represented in a 16 bit register.
It's up to the 'application', the firmware/software of the devices on each end, to interpret what the 16 bits in a register mean, or what value the combination of 32 bits in two registers is [32 bit floating point uses 2 consecutive 16 bit registers).
Hence, the Modbus spec does not define data formats; the device manufacturer implements a format and defines what the bits in a register (or multiple registers) represent. Hopefully the mfg describes in the documentation what their format is, what the units are and things like any multiplier needed to interpret the bits.
Modbus can carry all sorts data like
- a signed integer
- an unsigned integer
- real or floating point value
- time stamp
- model ID
- alphabet characters (text)
- whatever
as long as the devices at both ends can interpret the data properly.
The issue of data interpretation is the firmware/software tools that one has to interpret data.
Any industrial Modbus-enabled PLC is likely to interpret a Modbus input or holding register data as a signed integer, most handle one of 4 floating point formats, many handle alternative floating point formats, many handle long integers (32 bit integers).
From just a casual reading of threads on this forum, I believe that Red Lion devices can handle floating point values, whether the values come over Ethernet (Modbus TCP) or RS-485 (Modbus RTU).