OpenG Toolkit "Write INI Cluster__ogtk.vi" number precision loss

[jfrancis]

     "Write INI Cluster__ogtk.vi" is rounding numbers in several 1D arrays buried in my super cluster.  I am using Producer-Consumer with Supercluster archtecture, so my SC is somewhat deep.  The numbers being affected are doubles within arrays within a cluster within a cluster within an array within the Supercluster.  I created a work-around in the attached vi with standard NI config file libs.

     My desire was to have Scientific notation with 7 significant digits. The number was 2.002252E-3. The JKI routine converted this into 0.002002 and dropped 3 digits that were significant parts of a calibration polynomial. The anomoly occurred for only in numbers with "E-3" values. E+n, E-6, E-9 values were not affected although the system would change the exponent and shift the decimal sporatically.  The standard LabVIEW NI_LVConfig.lvlib:Write Key.vi does not have this problem as you will see in the work-around but does also have the habit of changing the Sci notation around to something other than n.nnnnnnE-n. It hasn't cause any loss in precision but had done things like changing -1.78569E-5 into -17.856900E-6. I guess it prefers the standard 3, 6, 9 format for exponents.

This utility happens to be my number one library for saving all system settings of interest between runs.  Designed to work with a SC.  Went thru much gnashing of teeth to fidure out what is acceptable items to put in the cluster.  Dynamic variables like DAQmx Task references will just cause "Write INI Cluster__ogtk.vi" to fail.  Since I don't need dynamics, this is fine.  Every time the user edits a GUI cluster (system settings), I kick off an even that pushes all settings of interest out to the config.INI file.

 

Hope This Helps and Enjoy,

Jeff Francis

Stanley Black & Decker

JKI INI File Save - Number Precision issue.zip

[drjdpowell]

   The numbers being affected are doubles within arrays within a cluster within a cluster within an array within the Supercluster. 

Wow, that's really pushing the INI file format; what do the files look like?  

 

Personally, I switch to JSON format once I need to store arrays, let alone arrays within a cluster within a cluster within an array within a cluster.

 

Note> the JSON package above saves DBLs with 15-digits.

 

 

[jfrancis]

The attached zip includes the config.INI file along with the VIs and controls.  Also see the VI for the Supercluster itself.  The element I was referring to is as follows.

 

AI Bridge Torque (Poly) Setup Cluster Array 0.Scaling Information.Forward Coeff = "<size(s)=3> -17.856503E-6 2.002252E-3 1.205196E-9"

[hooovahh]

Wow, that's really pushing the INI file format; what do the files look like?  

Yeah I have used these OpenG functions on clusters of arrays, of clusters etc...

 

It stores and opens it fine (other than the issues OP mentions) but it tends to get very slow.  The OpenG read/write INI stuff uses the NI INI stuff under the hood so each line in the INI is a call to that NI function which gets very slow quickly.  We found the MGI read/write anything to be a much faster solution, since they re-wrote the INI parsing stuff and use the normal File I/O instead of the NI INI.

 

As for the original question, this is to be expected.  You aren't saving the data as a binary format, you are converting it to ASCII then back, and in that you loose precision, that can happen in the type of conversion you are doing here.  One thing that might help is if you use the Floating Point Format input and specify there the number of digits of precision to use on the read and write.  Or convert the number to a string of your own choosing, and write that instead of the number.

[drjdpowell]

 

The attached zip includes the config.INI file along with the VIs and controls.  Also see the VI for the Supercluster itself.  The element I was referring to is as follows.

 

AI Bridge Torque (Poly) Setup Cluster Array 0.Scaling Information.Forward Coeff = "<size(s)=3> -17.856503E-6 2.002252E-3 1.205196E-9"

 

 

For comparison, here is the JSON-format of your config file:

 

ConfigJSON.txt

 

An excerpt: 

"AI Bridge Torque (Poly) Setup Cluster Array": [
    {
      "Bridge Information": {
        "Bridge Configuration": 10182,
        "Nominal Bridge Resistance": 350,
        "Voltage Excitation Source": 10200,
        "Voltage Excitation Value": 10
      },
      "Channel Name": "Bridge_Torq(Poly) - PCB Model 039201-53102 Serial 127511",
      "Channel Selected": true,
      "Custom Scale Name": "\u0000\u0000\u0000\u0000",
      "Fwd or Rev Coefs": "Use Fwd Coefs to Gen Rev Coefs",
      "Maximum Value": 1000,
      "Minimum Value": -1000,
      "Physical Channels": "\u0000\u0000\u0000\u000BMFDAQ-X/ai2",
      "Scaling Information": {
        "Electrical Units": 15897,
        "Forward Coeff": [-1.78569E-5,0.002002252,1.205198E-9],
        "Physical Units": 15884,
        "Reverse Coeff": [0.008918318,499.437845,-0.150141962]
      },
      "Units": 15884
    }
  ],

[ShaunR]

 

For comparison, here is the JSON-format of your config file:

 

ConfigJSON.txt

 

An excerpt: 

"AI Bridge Torque (Poly) Setup Cluster Array": [
    {
      "Bridge Information": {
        "Bridge Configuration": 10182,
        "Nominal Bridge Resistance": 350,
        "Voltage Excitation Source": 10200,
        "Voltage Excitation Value": 10
      },
      "Channel Name": "Bridge_Torq(Poly) - PCB Model 039201-53102 Serial 127511",
      "Channel Selected": true,
      "Custom Scale Name": "\u0000\u0000\u0000\u0000",
      "Fwd or Rev Coefs": "Use Fwd Coefs to Gen Rev Coefs",
      "Maximum Value": 1000,
      "Minimum Value": -1000,
      "Physical Channels": "\u0000\u0000\u0000\u000BMFDAQ-X/ai2",
      "Scaling Information": {
        "Electrical Units": 15897,
        "Forward Coeff": [-1.78569E-5,0.002002252,1.205198E-9],
        "Physical Units": 15884,
        "Reverse Coeff": [0.008918318,499.437845,-0.150141962]
      },
      "Units": 15884
    }
  ],

The scientific notation is still not 7 digits.

It also looks on the face of it like the precision of doubles is set ti 9 significant digits.rather than 15 decimal places.

Edited November 23, 2015 by ShaunR

[drjdpowell]

The scientific notation is still not 7 digits.

It also looks on the face of it like the precision of doubles is set ti 9 significant digits.rather than 15 decimal places.

Good eye.  It’s because I had to read in the INI config file before writing this JSON, and so inherited the INI’s precision.   Here is a redo where I have manually typed in 123456789 as extra digits before JSON output:

"AI Bridge Torque (Poly) Setup Cluster Array": [
    {
      "Bridge Information": {
        "Bridge Configuration": 10182,
        "Nominal Bridge Resistance": 350,
        "Voltage Excitation Source": 10200,
        "Voltage Excitation Value": 10
      },
      "Channel Name": "Bridge_Torq(Poly) - PCB Model 039201-53102 Serial 127511",
      "Channel Selected": true,
      "Custom Scale Name": "\u0000\u0000\u0000\u0000",
      "Fwd or Rev Coefs": "Use Fwd Coefs to Gen Rev Coefs",
      "Maximum Value": 1000,
      "Minimum Value": -1000,
      "Physical Channels": "\u0000\u0000\u0000\u000BMFDAQ-X/ai2",
      "Scaling Information": {
        "Electrical Units": 15897,
        "Forward Coeff": [
          -1.78569123456789E-5,
          0.00200225212345679,
          1.20519812345679E-9
        ],
        "Physical Units": 15884,
        "Reverse Coeff": [
          0.00891831812345679,
          499.437812345679,
          -0.150142012345679
        ]
      },
      "Units": 15884
    }
  ],

[Rolf Kalbermatter]

Hooovahh mentioned it on the side after ranting a bit about how bad the NI INI VIs were  , but the Variant Config VIs have a "floating point format" input! Use that if you don't want the library to write floating point values in the default %.6f format. You could use for instance %.7e for scientific format with 7 digits of precision or %.7g for scientific format with exponents of a multiple of 3. 

[hooovahh]

Hooovahh mentioned it on the side after ranting a bit about how bad the NI INI VIs were  , 

Didn't mean to rant, I use them, I just know there are better alternatives when making an INI file larger than say 500 rows or so.

[Rolf Kalbermatter]

Didn't mean to rant, I use them, I just know there are better alternatives when making an INI file larger than say 500 rows or so.

 

It wasn't meant in a bad way. Sorry! 

[dterry]

Late to the game here, but I stumbled on this post looking for something else, and had a relevant experience.

Working with the OpenG Variant INI files, I found the floating number format %#g to be very useful.  It stores the number as either f (floating point) or e (scientific) depending on the magnitude, and removes trailing zeros.  This (in my experience) prevents loss of data when working with very small numbers, and keeps the user from having to specify how many digits.

My 2 cents.