Reading Float32T


I´m having problem reading an input (32FloatT)
I have tried both group and analog input and neither work.

The value I´m sending and then reading can be understood through reading the bits individually and then using an IEEE-754 Floating Point Converter to get the correct decimal value.
But whenever i try reading the whole bytes in either analog or group input the values doesn´t make any sense.
Any ideas how to solve this problem?


  • lemster68
    lemster68 ✭✭✭
    Are you talking about on the robot side or PLC side?
    Lee Justice
  • The robot side, I´m not using a PLC in this case
  • nicolahinssen
    edited April 19
    It might be due to a different endianness of the bytes. Can you try a device mapping like this in the I/O Signal configuration?:
    24-31, 16-23, 8-15, 0-7
  • DenisFR
    DenisFR ✭✭✭
    edited April 19
    Here what I use:
      ! Returns Float value from Group Input (unsigned double integer)
      FUNC num GInputToFloat(VAR signalgi giValue)
        VAR rawbytes rbData;
        VAR num nResult;
        PackRawBytes GInputDnum(giValue),rbData,1\IntX:=UDINT;
        UnpackRawBytes rbData,1,nResult\Float4;
        RETURN nResult;
    You needs a GI with 32 bits.

  • I have now tried the 24-31, 16-23, 8-15, 0-7 configuration but unfortunately it did not work. How should I think regarding the signal scaling here? 
    Converting it in a function won´t be doable in our current application I´m afraid 
  • You're saying the values you receive don't make sense. Can you give an example of a decimal value you're sending, the corresponding bits and what you're seeing when you read the AI/GI signal? 
  • AI = 128-135,120-127,112-119,104-111, max log value = 1000, max bit value = 2147483647, min log = 0, min bit = -2147483647
    GI = 128-135,120-127,112-119,104-111
    Bit wise in order = (128-135,120-127,112-119,104-111)

    Decimal = 1000
    AI = 767,49
    GI = 1148846000
    Bit 0 0 0 0 0 0 0 0  0 0 0 0 0 0 0 0  0 1 0 1 1 1 1 0  0 0 1 0 0 0 1 0

    I´ve noticed that if i read the bits as (128-135,120-127,111-104,119-112) with bit 111 as the sign bit, i get the correct decimal value using an online float calculator
    in that case bit=
    0 1 0 0 0 1 0 0  0 1 1 1 1 0 1 0
  • lemster68
    lemster68 ✭✭✭
    Try bits 135-104 or bits 104-135 mapping.  Since they are contiguous, this is allowed.  Allowed values for max bit value are -2,147,483,648 to 2,147,483,647.
    Do you have these bits mapped as AI and GI at the same time or only one at a time for different trials?  Since you have no PLC, what device is sending these values to the robot?
    Lee Justice
  • I have them mapped as two different signals, one AI and one GI at the same time.
    Decimal still 1000;

    AI 135-104 =247483600
    AI 104-135 =31300

    GI 135-104 =576585728
    GI 104-135 =31300

    I´m using an IO - link master to connect a stepper motor to the robot (over EtherNet/IP)
  • DenisFR
    DenisFR ✭✭✭
    Is your data Float or Integer?
  • My data coming in is float32T
  • DenisFR
    DenisFR ✭✭✭
    So you should find incomprehensible value in your GI.
    Take a look at this site:

    To make sure you don't have byte swap, look at your PLC data in hexadecimal view and compare it with your GI.

    Then if it's correct, you can use my function shown in

  • lemster68
    lemster68 ✭✭✭
    Mapping those signals as both at the same time could be part of your problem.  To eliminate that variable I suggest that you only map as one or the other.
    Lee Justice
  • Unfortunately the problem still remains, I´ve tried only mapping as one or the other and tried all kinds of combination for the mapping
  • DenisFR
    DenisFR ✭✭✭
    @Seb : Did you test -DeviceMap "0-31" with my func?