Emerson Exchange 365

Converting Floating Point with Status to 16 Bit Signed Integer

Hi All,

We have a data conversion inaccuracy while converting a floating point with status value to 16 Bit Signed Integer. See Screenshot below. Is there any other method to convert?

Thanks!

Best regards,

Daniel Oh

WSoon

• 24 Apr 2019 9:43 AM
• Cancel

6 Replies

• Andre Dicaire

  

  • 24 Apr 2019 1:00 PM

  I'm unable to make out the FB names in your example. Can you explain these pictures?
  
  As long as the Float number is whole and is within the range of 16Bit(-32767 to +32768) it will accurately represent the integer.
  
  But if you use a math block to add a smaller value to it the result may not be correct. You have convert to integer first.

  Andre Dicaire

  • Cancel
• WSoon

  

  • 26 Apr 2019 6:09 PM

  In reply to Andre Dicaire:

  Hi Andre,
  Apologies for the unclear picture.
  I have internal parameter (floating point with status) connected to a mutiplier block. The OUT is connected to external reference. The path is 16bit signed integer with status register in the vim card. The floating point value will have decimals... I guess this contributes to the inaccuracies. In the screenshot, 0.53 becomes 52 after converting to integer and multiplying by 100.
  
  Our current solution is to add an ACT block and round the input floating point...
  
  Daniel

  • Cancel
• Andre Dicaire

  

  • 26 Apr 2019 6:28 PM

  In reply to WSoon:

  So, in my world 0.53 is not an integer...
  
  Still not clear what you are trying to do.

  Andre Dicaire

  • Cancel
• István Orbán

  

  • 29 Apr 2019 7:56 AM

  Hi Daniel,
  
  This is similar to what I saw here: emersonexchange365.com/.../10154 . I also had a call open for this, but not much has come out of it.

  • Cancel
• WSoon

  

  • 29 Apr 2019 4:44 PM

  In reply to Andre Dicaire:

  Hi Andre, we are going to multiply by 100 as well to make an integer :D

  • Cancel
• Andre Dicaire

  

  • 29 Apr 2019 10:28 PM

  In reply to WSoon:

  I did a quick test. The problem is two fold.
  
  First, the floating point number created by multiplying 2.34 by 100 will not be exactly 234. The accuracy of the number is affected by the accuracy of the 2.34 value, and it's manipulation by multiplying 100. The result is awfully close to 234 and for all intents and purposes, is treated as 234 in the floating point world.
  
  Integers on the other hand are precise. when you wire a float to an integer, DeltaV will coerce the source value to fit the format of the destination. It so happens that the mechanism truncates the value.
  
  My test was to wire a Float directly to an Integer, and enter 234 in the float. The Integer comes out as 234.
  
  However, if I use 2.34 and multiply by 100 and wire the MLTY1/OUT to the integer, 2.34 * 100 = 233 (integer).
  
  So although we see 234 on the out put of the MLTY1 block, it is likely 233.999something. This truncates to 233.
  
  When I enter 234, I am able to get exactly 234 as a representation of the number. But when a math function is applied, especially when a value is a different magnitude than the other, the number is manipulated in a common precision that can result in a slight skew. I'm thinking that 2.53, might actually be showing up as 2.52999something, and that keeps the result from being exactly 234. The display of the float number is rounding to 234 as it is closer than 233.9999, or what ever.
  
  Point is, it is predictable and you have to deal with it. As you mentioned, rounding the float value to a whole number before writing to the Integer parameter should get you valid Float to integer conversion.
  
  As a test, I used a CALC block were FLOAT value is 2.34:
  '^/Int16.cv' := ('^/FLOAT.CV' * 100) REM result is equal to 233
  '^/Int16.cv' := ROUND ('^/FLOAT.CV' * 100) REM result is equal to 234
  
  The ROUND function will bring you to the nearest whole number, and this will work for the range of a 16 bit signed integer number (-32767 to +32768)

  Andre Dicaire

  • Cancel