Please Note This forum exists for community support for the Mango product family and the Radix IoT Platform. Although Radix IoT employees participate in this forum from time to time, there is no guarantee of a response to anything posted here, nor can Radix IoT, LLC guarantee the accuracy of any information expressed or conveyed. Specific project questions from customers with active support contracts are asked to send requests to support@radixiot.com.

Radix IoT Website Mango 3 Documentation Website Mango 4 Documentation Website

Pulling data from Fuji Ultrasonic Time Delta C flow meters

Hardware
Log in to reply
  • M

    Ok, I will keep this post as short as I can. I can connect to the meter and pull simple 2-byte data just fine.

    There's a couple of registers that I just can't figure out what settings to use to get the data, and I feel like I've tried all the ones that I can think of.

    I've attached the whole communications manual if it's useful to anyone.

    0_1485965603594_Time Delta-C Flow Transmitter Communications Manual.pdf

    Here's one part of the puzzle:

    0_1485965239419_data types.png

    Here's the other part of the puzzle. I'd like to pull the registers in red:
    0_1485965347555_addresses.png

    The following are my assumptions.

    For Data Type = float

    32-bit = 4 byte float
    Input Register

    For Data Type = double

    64-bit = 8 byte float

    0
  • C

    a byte is 8 bits. so the flow rate is a 4 byte float and the total is an 8 byte float. There are two settings in mango for each of these, 4 byte float and 4 byte float swapped, and 8 byte float and 8 byte float swapped. Try both, see which if any works.

    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.

    0
  • M

    Hey Craig,

    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 =(

    0
  • C

    if you want to work strictly in mango you could read the 4 byte value as an unsigned long integer and then use a meta point to mask off each byte and try reassembling different arrangements of bytes and converting types to float until you find the float that has the correct value.

    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.

    0
  • phildunlap

    @mihairosu

    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?

    0
  • M

    Craig,

    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.

    0
  • phildunlap

    I suspect Craig is correct. The various bitshifts and orderings can be found in this class in Modbus4J: https://github.com/infiniteautomation/modbus4j/blob/50d7dfe6c0330bf720ae97492c9213c21fdb8d5f/Modbus4J/src_cdc/com/serotonin/cdc/modbus4j/locator/NumericLocator.java

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

    0
  • M

    Much thanks, especially to the guys at IA, for helping me diagnose this issue off thread.

    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.

    0
  • phildunlap

    Thanks for sharing the resolution Mihai!

    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!

    0