Jump to content

Search the Community

Showing results for tags 'ini'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • Software & Hardware Discussions
    • LabVIEW Community Edition
    • LabVIEW General
    • LabVIEW (By Category)
    • Hardware
  • Resources
    • LabVIEW Getting Started
    • GCentral
    • Code Repository (Certified)
    • LAVA Code on LabVIEW Tools Network
    • Code In-Development
    • OpenG
  • Community
    • LAVA Lounge
    • LabVIEW Feedback for NI
    • LabVIEW Ecosystem
  • LAVA Site Related
    • Site Feedback & Support
    • Wiki Help

Categories

  • *Uncertified*
  • LabVIEW Tools Network Certified
  • LabVIEW API
    • VI Scripting
    • JKI Right-Click Framework Plugins
    • Quick Drop Plugins
    • XNodes
  • General
  • User Interface
    • X-Controls
  • LabVIEW IDE
    • Custom Probes
  • LabVIEW OOP
  • Database & File IO
  • Machine Vision & Imaging
  • Remote Control, Monitoring and the Internet
  • Hardware

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


Personal Website


Company Website


Twitter Name


LinkedIn Profile


Facebook Page


Location


Interests

Found 2 results

  1. "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
  2. 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
×
×
  • Create New...

Important Information

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