LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

dynamically load a VI by library reference

We are very excited by the introduction of project libraries in LV8 and what it means for project management and building multiple custom distributions using libraries of dynamically called VIs from within a single project.  We now have our VIs arranged by VI "type" in the directory structure and by logical "function" with the project libraries that make up the project.  It sure wold be nice if we could dynamically load VIs from the library reference rather than trying to keep up with the actual paths.  I can get a reference to the library using and invoke node and "open.library" with a path wired in.  Is there any way to use this library reference to do an "open vi reference" to a VI within that library?
0 Kudos
Message 1 of 4
(3,936 Views)
Hello Lee,

This invoke node returns a reference to the libray, with this you can browse throught the library just like a tree control. It is usefull to open the .lvlib file with a text editor to see what 'Type string' options you have. If you get to the right VI use the 'VI Reference' property from the 'Library Item'-class, this will get you a reference to the VI which you can open, edit, save or whatever VI-server offers you.

Good luck

Ton


PS I'm using in this in a tool to duplicate the .lvproj structue into the hard-drive, I'm not fully done but getting there!
PS This screenshot was made with Starware

Free Code Capture Tool! Version 2.1.3 with comments, web-upload, back-save and snippets!
Nederlandse LabVIEW user groep www.lvug.nl
My LabVIEW Ideas

LabVIEW, programming like it should be!
Message 2 of 4
(3,935 Views)

If you have the Internet Toolkit, you can take this process one step further and automatically parse the Library file in search of the correct VI reference. Project Library files have .lvlib extensions, but they are actually just XML text files. As such you could parse through them using the XML functions in the Internet Toolkit.

The basic idea would be to get an array of references to all nodes with the tag "Item." This will correspond to the Children[ ] array output by a Library property node. You can then parse through this array of nodes in search of nodes whose "Type" is "VI". The basic idea here is to output this data, so when you search for a particular VI in the library, you can output the correct item index. It gets a little more complicated if the VIs are embedded within virtual folders in the Project Library.

This will solve the problem of calling VIs dynamically using only Library references. This technique just helps you figure out which reference in the library is which. Which are VIs? Which are documents or shared variables? Of the VI references that are there, what are the paths or names of the VIs? And so on... All of this can be extracted programmatically during run-time from the library file itself.

Jarrod S.
National Instruments
Message 3 of 4
(3,911 Views)
Thanks, we have explored both using using property nodes (open.library->children->VI names and paths) as well as reading the XML (.lvlib file) directly and parsing the information ourselves.  Both strategies work.  We chose to parse the XML files directly because it is much faster -- it was taking ~4 seconds per VI to determine its path using property nodes which is unacceptable if you have a few hundred of these to process at startup.  Processing the XML file directly does them all in only a couple of seconds.
 
To implement this in our project, we have written a VI that is essentially a Name Space aware version of build path.  It needs a little more work to make it more robust in terms of case sensitivity, extra white space, etc., but it is working very well.  I have attached the VI.  The Base Path is the path to the folder containing the top level library (not the library itself).  Example inputs -- Base Path = "C:\TopLevelLib", Name="top_library.lvlib:sub_library1.lvlib:sub_library2.lvlib:sub_library3.lvlib:example.vi"  The VI returns the full path to the requested VI or "Not A Path" if the operation fails. 
 
Please have a look and see what you think.  If anyone has a clever way to deal with the backslash craziness (/ vs \\) of the string input to Build Path, I would be grateful if you would share it.
 
--Lee
Message 4 of 4
(3,896 Views)