Jump to content

Recommended Posts

     "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

Link to comment

   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.

 

 

Link to comment

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"
Link to comment

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.

Link to comment

 

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
    }
  ],
Link to comment

 

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

 

attachicon.gifConfigJSON.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 by ShaunR
Link to comment

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
    }
  ],
Link to comment

Hooovahh mentioned it on the side after ranting a bit about how bad the NI INI VIs were  :D , 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. 

Link to comment
  • 1 year later...

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.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.