Jump to content

openG Configuration Library, error post build


Recommended Posts

Hello All! 

First post here, please go easy and I look forward to learning from you all!

I have a vi that is using the open g configuration library to save and load a number of controls.  More precisely, I have 1 cluster of 3 numerics, and 3 separate numerics.  I have all my code working wonderfully before I compile it, but once I compile it I get the following error when I try to load from the file:

Get Queue Status in NI_LVConfig.lvlib:Get File Path.vi->NI_LVConfig.lvlib:Close Config Data.vi

Additionally, while I have the 'Create File if necessary' input wired True, the vi never creates the file.  Again, this all works pre-compiled, but fails in the compiled code. 

I've attached some screenshots of the code in question, please let me know if I can provide further info.

Thanks,

Nate

Screen Shot 2020-09-03 at 10.03.01 AM.png

Link to post
Share on other sites

You are trying to create your ini file adjacent to your vi; in your exe that path is inside your exe, which cannot have files created in it.  You need to have your ini file in a different place.

  • Like 1
Link to post
Share on other sites

I think that the error is in the use of "Current VI's Path".  When you strip up one level in development mode (when the Current VI is directly in a folder) then you get the folder where the VI is located. For an EXE, the VI's path will be nested inside some virtual folders inside the EXE file.  Try using the OpenG VI "Get Current VI's Parent Directory.vi" this is a bit smarter in terms of getting the actual OS folder where the VI/Code is located.

image.png.2651393c3f9b33e103fe59ae10d7c5fd.png

 

You can call it like this -- both of these snippets are equivalent.

image.png.49123a9ab519731aafe4207e02392d46.png

Edited by Jim Kring
  • Like 2
Link to post
Share on other sites

Why not use the LabVIEW's native Application Directory VI?  This automatically takes into account if you are in development mode or runtime (exe). 

image.png.dacf3618cf97079e9142782cb439eb7e.png

Application Directory VI

Owning Palette: File Constants

Requires: Base Development System

Returns the path to the directory containing the application.

If you call this VI from a stand-alone application, this VI returns the path to the folder containing the stand-alone application.

If you call this VI from the development environment and the VI is loaded in a LabVIEW project file (.lvproj), this VI returns the path to the folder containing the project file. If the project is not saved, this VI returns <Not a Path>.

  • Like 1
Link to post
Share on other sites

@LavaBot - I can't speak directly for @nrosenberg, but from my experience, one of the challenges in creating applications is creating code that works in both the development environment (source code) AND in a built applications (exe). So, if Application Directory is used, then the path will point to the LabVIEW installation location when running from source code. So, we don't want to use that node/function when running code in development. Instead, we would probably want to test for whether the code is running in development or the build application and then build our path differently.  However, simply putting our file in the folder next to wherever the VI is running (by using "Get Current VI's Parent Directory.vi") is an OK solution to this problem.  Yet, in most larger applications that I see, a more specific solution is used, as to where files should be placed in development vs deployed environments, since there are often a lot of files and we generally want to organize them all a little bit better (under some base folder of settings), even in source mode (and not have a bunch of important files sitting next to VIs throughout our project source code folder).

Link to post
Share on other sites
21 hours ago, LavaBot said:

Why not use the LabVIEW's native Application Directory VI?  This automatically takes into account if you are in development mode or runtime (exe). 

Generaly speaking this is fine for configuration or even data files that the installer puts there for reading at runtime. However you should not do that for configuration or data files that your application intends to write to at runtime. If you install your application in the default location (<Program Files>\<your application directory>) you do not have write access to this folder by default since Windows considers it a very bad thing for anyone but installers to write in that location. When an application tries to write there, Windows will redirect it to a user specific shadow copy, so when you then go and check in the folder in explorer you may wonder why you only see the old data from before the write. This is since on reading in File Explorer, Windows will create a view of the folder with the original files in the folder if they exist and showing the shadow copy files version only for those files that didn't exist to begin with. Also the shadow copy is stored in the user specific profile so if you login with a different user your application will suddenly see the old settings.

Your writeable files are supposed to either be in a subdirectory of the current users or the common Documents folder (if a user is supposed to access those files in other ways, such as data files generated by your application), or in a subdirectory inside the current user or common  <AppSettings> directory (for configuration files that you rather do not want your user to tamper with by accident). They are still accessible but kind of invisible in the by default invisible <AppSettings> directory.

The difference between current user and common location needs to be taken into account depending if the data written to the files is meant to be accessible only to the current user or to any user on that computer.

Link to post
Share on other sites

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.

  • Similar Content

    • By neunited
      Dear All, 
      I'm new to this forum and I'm really glad I became a member.
      I am currently in the phase of designing a simple program which can control all the DAQmx channels using a configuration file (.ini) which is capable of change voltage range during mid-simulation. 
      At the moment my .ini file reads as follows: 
      [AO Channel 1] 
      Name = T2
      Physical Channel = cDAQ1Mod1/ao0
      Max Value = 10 
      Min Value = 0 
      [AO Channel 2] 
      Name = T3
      Physical Channel = cDAQ1Mod1/ao1
      Max Value = 10 
      Min Value = 0 
      [AO Channel 1] 
      Name = T2
      Physical Channel = cDAQ1Mod1/ao0
      Max Value = 5 
      Min Value = 0 
      [AO Channel 2] 
      Name = T3
      Physical Channel = cDAQ1Mod1/ao1
      Max Value = 10 
      Min Value = 0 
      My LabVIEW VI for the .ini script  is attached. I'm relatively new to using configuration file functions and I don't really understand where "Get Key Names" section should be wired to. I have placed a constant on it for now which reads the "AO Channel 1" but how can I get it to read all the channels in the .ini file.
      I am welcome to all suggestions here, I just want to make sure that I don't cause any problems to any of the channels and use best practice methods. All constructive criticism welcome!
      Thank you. 
       
       

      Read Configuration (INI) File (1).vi
    • By Taylorh140
      So for a while, I have wanted a good way of identifying my builds and one way is to add build date to the front panel. Typically I had done this manually, I have searched for a good solution for automating this but, but typically the answer is very obfuscated. Then one day I had a thought, I could use VI scripting to generate a VI holding a constant and in a way use it as a pre-processor to make things happen. I'll provide a rough outline and a project of how I made things work. And who knows maybe someone has an even better solution.
      I suppose it was kinda obvious that this could be done, now that I think of it. I think lv scripting was introduced in 2012 and is needed for this example. 
      First Create A VI that generates a constant via LV script.
      Use it in your Top Level VI or wherever you would like the compile time constant to be visible.
      Generate a A Pre-build Action.vi that calls your VI generator.
      Now you can have compile time constants that are up to date!
      I included an example project let me know if the same thing works for you.
       





      BuildDateOnPanel Ver12.zip

    • By dterry
      Hello again LAVAG,
      I'm currently feeling the pain of propagating changes to multiple, slightly different configuration files, and am searching for a way to make things a bit more palatable.
      To give some background, my application is configuration driven in that it exists to control a machine which has many subsystems, each of which can be configured in different ways to produce different results.  Some of these subsystems include: DAQ, Actuator Control, Safety Limit Monitoring, CAN communication, and Calculation/Calibration.  The current configuration scheme is that I have one main configuration file, and several sub-system configuration files.  The main file is essentially an array of classes flattened to binary, while the sub-system files are human readable (INI) files that can be loaded/saved from the main file editor UI.  It is important to note that this scheme is not dynamic; or to put it another way, the main file does not update automatically from the sub-files, so any changes to sub-files must be manually reloaded in the main file editor UI.
      The problem in this comes from the fact that we periodically update calibration values in one sub-config file, and we maintain safety limits for each DUT (device under test) in another sub-file.  This means that we have many configurations, all of which must me updated when a calibration changes.
      I am currently brainstorming ways to ease this burden, while making sure that the latest calibration values get propagated to each configuration, and was hoping that someone on LAVAG had experience with this type of calibration management.  My current idea has several steps:
      Rework the main configuration file to be human readable. Store file paths to sub-files in the main file instead of storing the sub-file data.  Load the sub-file data when the main file is loaded. Develop a set of default sub-files which contain basic configurations and calibration data.   Set up the main file loading routine to pull from the default sub-files unless a unique sub-file is not specified. Store only the parameters that differ from the default values in the unique subfile. Load the default values first, then overwrite only the unique values.  This would work similarly to the way that LabVIEW.ini works.  If you do not specify a key, LabVIEW uses its internal default.  This has two advantages: Allows calibration and other base configuration changes to easily propagate through to other configs. Allows the user to quickly identify configuration differences. Steps 4 and 5 are really the crux of making life easier, since they allow global changes to all configurations.  One thing to note here is that these configurations are stored in an SVN repository to allow versioning and recovery if something breaks.
      So my questions to LAVAG are:
      Has anyone ever encountered a need to propagate configuration changes like this?   How did you handle it?   Does the proposal above seem feasible?   What gotchas have I missed that will make my life miserable in the future? Thanks in advance everyone!
      Drew
    • By ASalcedo
      Hello to all.
      I would like to know hoe can open my VI with the same configuration. I mean with every indicators, controls, graphs... are equal than when Labview was closed the las time.
       
      Is it that possible?
      I am asking this because I am developing a vision application with vision and motion toolkit. And a ROI is changed every time when I run again Labview in the same position of display.
       
      Thanks a lot.
    • By doradorachan
      Hey guys,

       

      I am currently having some issues with a FPGA program with Softmotion not compiling.

      We are running out of options in terms of how to get this FPGA program compiled.

       

      So my question is does compiling on Linux have a different probability of compiling FPGAs?

      I have heard that Xilinx Compiler is meant for Linux so it runs more efficiently and faster,

      so I was just wondering if the compile method was different as well

×
×
  • Create New...

Important Information

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