LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

shared variables location

   I'm starting a fairly large project and wanted to organize it properly.  When I needed a shared variable, I first created a new library.  I was able to specify the location of this library in a sub-directory within my projects file structure.   Then I made some shared variables (single process).  After saving the project, the shared variable files appeared in the main project directory, at the same level as the .lvproj file, not in the subdirectory where the library was created.
   Any tips for orginizing shared variables?

Thanks,
    Dave
-------------------------------------------------------------
David Thomson Original Code Consulting
www.originalcode.com
National Instruments Alliance Program Member
Certified LabVIEW Architect
Certified Embedded Systems Developer
-------------------------------------------------------------
There are 10 kinds of people: those who understand binary, and those who don't.
0 Kudos
Message 1 of 6
(2,882 Views)
Hello,
 
The following two ideas together should clarify any confusion:
 
1. Variables live in libraries, and you can save libraries to the location of your choosing.
2. Your file/directory structure on disk does NOT necessarily have anything to do with your project view structure.
 
The project file is an xml file, which provides you a convenient way to collect the parts of your project for development.  If you CHOOSE to, you can create a file/directory structure on disk which matches that of your project structure, but you are not required to.  As general advice, if you have many shared variables you may consider grouping them logically, and created a library for each group.
 
Best Regards,
 
JLS

Message Edited by JLS on 04-18-2006 12:11 PM

Best,
JLS
Sixclear
0 Kudos
Message 2 of 6
(2,863 Views)
   Thanks for the reply.  Unfortunately, the problem remains:
   I first create the library explicitely, before creating any variables.  I saved the library to a subdirectory.  Then I create variables.  When the variables are instantiated within a VI, at some point LabVIEW automatically creates vi files on the disk corresponding to these variables.  These VI files were placed in the main directory with the project file, not in the subdirectory where I put the library.  This is surprising to me and I would think this is a bug.
    My solution at this point was to create a "Project" subdirectory.  I put the .lvproj and the .lvlib file in that subdirectory and now the shared variable vis appear there as well.  This is a kludge.
   My main question at this point is:  can you specify where these shared variable VI's get created and stored?  I suspect that you could edit the .lvproj file or other xml files to change the share variable paths, but that is inappropriately difficult.  I tried just moving the files to where I wanted them, but then the variables don't load.  I managed to reload them, but at some point, they recreated themselves in the original location.
   At a minimum, the shared variable VIs should create themselves in the same directory as the .lvlib file that they belong to.  At least you can specify where the .lvlib file lives.

Regards,
   Dave
-------------------------------------------------------------
David Thomson Original Code Consulting
www.originalcode.com
National Instruments Alliance Program Member
Certified LabVIEW Architect
Certified Embedded Systems Developer
-------------------------------------------------------------
There are 10 kinds of people: those who understand binary, and those who don't.
Message 3 of 6
(2,859 Views)
Hello,
 
I understand and see the problem you describe.  It only occurs with single process variables, because those are essentially just global variables.  As a workaround, you can use the old global variables, and add those to your libraries; you can save them to the location of your choice, and they won't be recreated in the project's owning directory.  I have filed a corrective action request to R&D on the matter - if it is deemed a bug then it should be fixed for a future version.  I agree that by default the behavior should be to save at the same level as the owning library.
 
Best Regards,
 
JLS
Best,
JLS
Sixclear
0 Kudos
Message 4 of 6
(2,840 Views)
JLS wrote "...a corrective action request"
 
And the CAR# is ?
 
Ben
Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 5 of 6
(2,839 Views)
Hello,
 
The CAR number is 3WICRJSQ, and it has been rightly deemed a legitimate problem (ie. the CAR was accepted :)).
 
Best Regards,
 
JLS
Best,
JLS
Sixclear
Message 6 of 6
(2,814 Views)