I'm somewhat surprised the weirdness of the register map didn't factor into the solution. I found it extremely weird that the data types are described with twice as much space as they need in the definitions in 7.2 :

double : Floating data. This data is handled in 4-word units. One data per eight addresses

Eight modbus addresses is 128 bits, when it's definitely spelled out as a 64 bit double. And when I manually decoded the hexadecimal returned in doing a raw read on the first many registers, I found the value you expected to be at 30012 to really be at 30006, which would make sense to me if all that data is in order but the producer of the document got the "Register Number" column wrong because the data type key has the number of registers required for a data type doubled.

But, glad you got the meter reading!

I discovered what my problem was:

Under the modbus datapoint properties:
Max read register count must be a minimum of 4. I had it set at 1.

It's due to my lack of knowledge of modbus and all that but to get a total value for these items, multiple registers are actually read and added together.

The data types that worked were the 4 byte float and 8 byte float as in the original post.

Perhaps we will look into adding more data types to support this situation.

Yeah, I see what you're saying. I've not done that before, but I may have to take that route.

Phil,

I do not get any errors when reading the registers. I tried the first 50 with success.

What is occurring when you try to read the registers normally? I would use the read registers tool on the Modbus data source page to try to read over the entire range. The Modbus protocol is agnostic about the format of the data in the registers, so the decoding of the data type is on our end and the data type shouldn't affect what registers can be read. Do you get an error if you read the first 28 registers in the Input Register range?

Here is an excerpt from another scada system's help file:
Control byte order for floating point values (the Modbus driver supports floating point values).
Some systems expect to use a different byte order for their floating point data.
Allowable Values: 0 to 3, where:
0 - Byte order = 1 0 3 2
1 - Byte order = 3 2 1 0
2 - Byte order = 0 1 2 3
3 - Byte order = 2 3 0 1
Default Value: 0

mango supports option 0 and 1 I think, so it is also possible that the system you have is using option 2 or 3 if you are sure you aren't off by one and neither 4 byte float and 4 byte float swapped worked.

I tried both the swapped and unswapped. I tried every 4 byte option there was.

A simple 2 byte register works, so the connection is fine.

Thanks for the software suggestion. I'll try it out, and see what it does, though I'd assume the communication manual would have everything I need =(

make sure you are not off-by-one with the register addresses. find a simple register that is INT type and make sure you can read it correctly and that you are not getting the register before or after.

If neither work then I would use the program called qmodmaster to connect to the salve and see what the exact bytes are at what address and then you can try different arrangements of bytes to floating point until you find the one that works.