Modbus Enron/Daniels


Thread Starter

Curt Jeffreys

Can anyone explain to me the difference between vanilla Modbus RTU and the Enron/Daniels flavor? I'm planning to modify my existing Modbus code
to support floating point and I understand Enron/Daniels allows single register access to floats. Is it as simple as it sounds?


Curt Jeffreys
CW Industries
Lakewood, CO USA

Darold Woodward

If you want to be "generic" with floats, there is an important precedent that should be observed. The storage order of the two sixteen bit halves of the 32-bit IEEE representation is defined in the PLC. The result is that the order in a Modbus response is therefore also "defined."

The Modbus/TCP spec. has an Appendix that documents how to store information that requires more than one 16-bit register and complies with the Modicon PLC precedent (not in the Modbus specs).

For Modicon PLCs, the number is stored in two registers and the first register address is used as the "location," but both registers together are read and then treated as 32-bit floating point. Therefore, Modicon Modbus messages will alway request two registers starting at the first address of the number.

If your intent is only to read floating points from Enron/Daniels FCs (then you are on the right track to code to their standards.

I did some research on it earlier this week and was only able to determine that it looks like the number of bytes per reigister in the Enron/Daniels varies and is not fixed at 2 like Modicon PLCs. Therefore you can request and get a 32-bit IEEE floating point number using only one address. This will lead to serious
interoperability problems if the master and slave do not agree on how to read these registers.

Darold Woodward PE
Schweitzer Engineering Laboratories
[email protected]

Steven E. Braun

IN THE BEGINNING there was no folating point so as a result the Modbus protocol had no functions for reading or writing floating point values. As things progressed, it became obvious that something had to be done in order to handle floating point. Despite what Modicon decided to do, values greater than a 16 bit number were
handled differently by other interested parties.

Essentially, there are two ways to view 64 bit values with the Modbus protocol. They are either two 32 bit values that need to be integer order reversed or they are a single value that are 4 bytes in length.

Reading and writing 64 bit values from the perspective of the Master is fairly simple to solve. My company supplies an RTU Master for
the GE Fanuc PLC Series 90. One of the options available for each functional query is conversion. The user defines whether the
read/write command is to be 32 bit (double integer or floating point) and a 2 byte or 4 byte read/write. The Master program will then
integer swap the resulting values (and convert to another format if required) and calculate the CRC based on a length of 4 bytes per read or 2 bytes per read.

The Slaves on the other hand really never know who or what the Master will be. As a result the methods devised for the Slave to handle floating point will vary. Sometimes the register addresses
are reserved. For instance, the Omni flow meter will reserve address locations 3XXX as 16 bit integer, the 5XXX resgisters are 32 bit double integer, and 7XXX registers are 32 bit float. There is also an option for either a 2 byte or 4 byte read/write (sometimes referred to as 984 mode). A 4 byte read/write means that the
number of values that are asked for within the formulated query are 4 bytes in length not the usual 2 as specified by the ORIGINAL protocol specification. With function 16 (Write Multiple Registers) sometimes the length parameter coupled together with the number-of-bytes-being-sent parameter tells the Slave that the values are 32
bit. The last (and worst) method is to implement a custom command number. This is almost always guaranteed to cause compatibility problems.

Steven E. Braun
SEBraun, Inc.
1126 Sudden Valley
Bellingham, WA 98226
Office 360.734.4817
FAX 360.647.0910
[email protected]

Greg Goodman

Several years ago, we modified our Modbus protocol driver to support the Daniels 2500 flowmeter.

I've inspected the code, and these are the accomodations we made:

1. Daniels apparently numbers all registers, coils and digital inputs from one, not from zero.

starting_reference = configured_reference - 1;
if (box_type == DANIELS)

2. Daniels apparently returns 4-byte values for HOLDING REGISTERS (4x registers).

reference_count = configured_register_count;
if (box_type == DANIELS)
reference_count /= 2;

3. There was no special handling of data format for floats received from the Daniels. That is, we accepted the 4-byte value "as is" on big-endian machines, and byte-swapped it on little-endian machines, same as for any other Modbus device.

memcpy(local_buf, rx_buf, sizeof(float));
swab(rx_buf, local_buf, sizeof(float));

Hope this helps.

Greg Goodman
Chiron Consulting
(713) 869-6876
Thread starter Similar threads Forum Replies Date
N Modbus 1
E Modbus 2
M Modbus 1
K Modbus 4
M Modbus 6