Search the Community

"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

What am I doing wrong? I'm using the JKI "Write INI Cluster__ogtk.vi" and "Read INI Cluster__ogkt.vi" and I can't read back what I wrote. First I "Set" and then "Get". When the "Get" state pushes to the "Variant to Data" I get an error 91 (variant doesn't match type input). Is my cluster too complex? Noticing that the type variant being written doesn't match the variant data being read. It's missing section names. Can I do any complexity cluster or must it be formatted in a specific manner? I saved the hierarchy in this zip so you can see the very JKI libs I'm using. JKI Cluster to INI issue.zip One responder in the JKI forum indicated no problem. Another surmised that the IMAQdx reference was causing the error. Thanks in advance, JF