what is the logic for the behavior of LV9 when opening vi references?

[dbrewe]

I recently started using LV 9 and I can't figure out what the rationale is for the LV 9 behavior when opening references to vis. The way I understand it, LV9 looks up vis using the absolute path on the disk where they came from when opening references, even if they are in memory. If just a vi name is given, LV9 tacks on the path of the referring vi on disk when trying to open the reference. So, as far as I can see, either an application opening references to vis needs to specify absolute paths to the location on disk and be modified whenever a dynamically called vi's location on disk is changed, or a dynamically called vi has to be saved in the same directory as the vi doing the calling or in a rigid and inflexible directory structure.  

Example:

I am trying to use a 3rd party library whose vis open a reference to a vi that I create, the name of which is obtained from those in memory using a name pattern. The library vis get the name of the vi I created and try to open a reference to it. Previously this worked because LV looked in memory for "my.vi" when opening the reference but this fails with LV9 because it apparently looks for, e.g., "D:\VI\3rdparty.llb\my.vi", not "my.vi". So, as far as I can see, I have to save my.vi in 3rdparty.llb in order to use it. And, if I want to use 3rdparty.llb in another application, I have to save other vis to 3rdparty.llb or create a new copy elsewhere and save to that copy for the new application. A similar situation would occur if I passed the name of my vi to the 3rdparty.llb vis - either I would need to pass an absolute path and modify my application if I ever want to move my.vi, or save it in 3rdparty.llb.

Another example:

I have a large application built into an executable that calls up to ca. 60 vis  using references.  Previously I could just specify the path to the executable, and I could easily open references to my vis. Now  (if I try to use the LV 9 file structure), I can't figure out the paths I need to open references. Either I have to specify the absolute path to the original location in my development directories, or I have to store all my source vis in some particular directory structure. If I want to reuse my vis in other applications (which I do) things would get pretty complicated. Likewise if I want to optionally open references in other vis than my top level vi (which I do), it seems well nigh impossible.

Basically I am struggling with the concept that an application remembers the directory structure where the source files were located, and/or depends on a particular directory structure of the source files to work. Maybe I'm missing some tricks that would make things easier, but someone will have to explain to me why these are good things. 

[tst]

The basic concept (which hasn't changed) is this:

• If the VI is already in memory, you can open a reference to it by name.
• If the VI isn't in memory, you need to provide a path. This path can be relative or absolute, which makes no difference, because in both cases you end up with a full path. 

Here's a reference (ha ha, sorry):

 

If I had to guess, I would guess that you're actually using option 2, which isn't acutally opening a reference by name, but by relative path. Around the 8.5 timeframe, NI changed the behavior for this - if you try to open a reference to a VI from path A, and the same VI is already loaded from path B, you get an error. In previous versions LV simply opened a reference to the VI which was already in memory. If this guess is correct, you simply need to replace the path constant with a string.

One more thing which might help you is using the new Application Directory VI (file constants palette). This will return the folder of the project in the IDE and folder of the EXE in the RTE.

If all this doesn't help, I suggest you upload an example showing exactly what your problem is, because I didn't really understand your setup.

[dbrewe]

Thanks very much for your response. I actually hadn't known (or forgotten about) the option to use a string instead of a path to the function to access specifically vis in memory - I'm guessing this is a relatively newer option (newer than say LV 5 or so when I started using it). I also don't really open references to vis in memory that much. 

The other issue is the way one specifies the path in opening references to vis in an executable. I sort of remember this changing over time and I've always been confused about it. In LV 9 using the LV 8.x file structure, specifying the path to the executable works.  Actually I did some tests and a lot of different paths seem to work, including a relative path, which I'm pretty sure wasn't always the case. It seems like LV 9 has a default set of paths to search that allow it to find the vi in the file (when using the 8.x file structure). This makes sense to me.

To some extent this is a moot point, as right now I can use the 8.x file structure to build my application - BTW it wasn't obvious to me this would work, and  the support engineer I talked to also had to look into it before he was able to explain the issue. 

But just sort of from a philosophical standpoint, I really am puzzled by the way vis are identified in my executable w/ the LV9 file structure:

For example, with the 8.x file structure, if I read the "current vi's path" constant for e.g. Control panel.vi, I get

\\Tacoma\IDBeamline\v13 Applications\Control Panel v13.exe\Control panel.vi

This is eminently sensible to me.  After all, that's where it is, inside the executable. 

However, w/ the LV9 file structure, I get

\\Tacoma\IDBeamline\v13 Applications\Control Panel v13.exe\beamline v13\Control Panel\v13\Control panel.vi

Moreover, there seems to be no default set of paths that LV9 uses to find a vi when opening a reference to a vi - I simply have to know the absolute path to the source file to do it. 

This is kind of bizarre to me that an executable would remember where it came from and that its behavior essentially depends on the organization of the source files it was built from. This is what really doesn't make sense to me, but again maybe I'm missing a technique to make this more transparent. 

[rolfk]

Well the option to opening VIs by name with only a string control is as old as the VI server interface itself. So no it is not something that was added later. The only real change is what tst already mentioned in that when you specify a path the VI already in memory must have the same path or you will get an error.

[rolfk]

The change with internal path in an executable in LabVIEW is due to a change in how an executable is built. Before LabVIEW 9 this was done by putting all VIs into an LLB and embedding that in the executable. But with VI libraries and LVOOP this had the problem that multiple VIs could end up with the same name but inside an LLB a VI must have a unique name. So they added extra directories beside the executable in which those VIs with the same name were placed. Many found that a major disadvantage so NI had to find something to place everything back into the executable. To do that they had to get some file hierarchy inside the executable and they chose to use an embedded ZIP archive that resembles the original file hierarchy, so that is how you end up with the entire file hierarchy inside the exe. You can get back the old behaviour by selecting the option to use the old file layout format in the Build settings.

[tst]

---

dbrewe wrote:

Moreover, there seems to be no default set of paths that LV9 uses to find a vi when opening a reference to a vi - I simply have to know the absolute path to the source file to do it. 

This is kind of bizarre to me that an executable would remember where it came from and that its behavior essentially depends on the organization of the source files it was built from. This is what really doesn't make sense to me, but again maybe I'm missing a technique to make this more transparent. 

---

In addition to what Rolf wrote, it should be pointed out that LV should NOT be looking for files if you built your app correctly. Each VI maintains a relative path to all VI it calls and it should know exactly where to find them (assuming they're there).

This can become somewhat more complicated if you're making dynamic calls in executables, since you will most likely have to create build distributions to make sure each "plugin" has all its dependencies, and if the plugins happen to share dependencies, it could become more complicated.

If you know all the dynamic VIs at build time, the easiest thing to do is to use a static VI reference to those VIs, causing LV to automatically include all the dependencies in the build and not even requiring you to open a reference.

[rolfk]

And yet in addition to what tst said an application can have a search path. Obviously there is no user.lib and vi.lib it can search but if you add a non standard search path in your LabVIEW options and look at your labview.ini file and then copy that entry into your <application>.ini file the LabVIEW runtime WILL search in that location.

However as tst has mentioned having an executable search for VIs is a VERY VERY bad idea as it can break your entire app if it happens to find the wrong VI at some point.

[dbrewe]

I appreciate the responses and explanations. I've certainly learned some things. I have extensive experience using LV but over a fairly narrow set of applications so I'm certainly not aware of many of the possible techniques.  I clearly don't use LV in the same way as what appears to be the mainstream for LV programmers.

I have some additional comments on the various responses:

"But with VI libraries and LVOOP this had the problem that multiple VIs could end up with the same name..."

I'm not clear what this means exactly. My first response would be that it doesn't seem like a good idea in general to use different portions of code with the same name in a single application. I'm surprised this is even possible.  I don't think LV will even let me build from a project in which it finds name conflicts for vis.  

"In addition to what Rolf wrote, it should be pointed out that LV should NOT be looking for files if you built your app correctly. Each VI maintains a relative path to all VI it calls and it should know exactly where to find them (assuming they're there). "

I think this illustrates one thing I was talking about. The assumption appears to be that the organization of your source files is an essential ingredient in the application that is built, which is a foreign concept to me. My project file knows where all my vis are, the applications build correctly, and, using the 8.x and previous file structure for my exe, they work, and have for some time.  As far as I'm concerned the main point of using a project that identifies my source files is to be able to pull in code from different places - if I want to use a different version of one of my dynamically called subvis, from a different location, for example, I tell the project file to use the new version and rebuild.  In your scenario, as I understand it, I'm not sure why a project file in which you identify source files is even needed,  if LV already knows everything about the components of the application you're building.  As I mentioned, my primary application uses ca. 60 dynamically called vis. Most of these control different subsystems of a large distributed hardware control and data acquisition system. All of these are used sometimes when the application is used, but pretty much never all of them at once - typically something like 10-30 of the user-interactive vis are run at once. There is some communication between them using globals, queues, and semaphores and such, but for the most part they are independent and I test them separately. Until the application is built and used, there is no need to run the entire application  including all subvis, and I never do it. When I build my application, the app builder finds all the vis I specify and constructs the exe file including all the vis I've told it about. Before LV 9 it never occurred to me that I might actually have to worry about being able to find vis inside the executable. 

"However as tst has mentioned having an executable search for VIs is a VERY VERY bad idea as it can break your entire app if it happens to find the wrong VI at some point."

 I don't really follow this point at all. Where are these vis masquerading as the ones I want that will break my application? The only vis on the machines where my applications are used are there because I put them there inside the executables. I certainly would never use different vis with the same name in an application - as I said above, I don't even know if it is possible, and don't want to find out.  Search paths to find components like shared libraries are a common thing. It doesn 't seem like a stretch for the run-time environment to define a default search path like "somewhere in the exe file containing the application".

I don't want to make a mountain out of a mole hill here, as I said before, I am happy as long as NI supports the 8.x file structure, but if nothing else I have definitely learned to appreciate how different executables built w/ labview are from executables  constructed in other systems. 

[tst]

---

dbrewe wrote:

"But with VI libraries and LVOOP this had the problem that multiple VIs could end up with the same name..."

I'm not clear what this means exactly. My first response would be that it doesn't seem like a good idea in general to use different portions of code with the same name in a single application. I'm surprised this is even possible.

---

Libraries serve as a namespace mechanism, so you could have a VI called init.vi in the library mydevice.lvlib instead of having something like MyDevice_Init.vi. For some behaviors, such as overriding in LVOOP, this is even required (e.g. dog.lvclass:walk.vi overrides mammal.lvclass:walk.vi).

---

The assumption appears to be that the organization of your source files is an essential ingredient in the application that is built.

---

Only if you're relying on it. For instance, if you call VIs dynamically without explicitly building them, their dependencies would not be built either and might not be found. This doesn't seem to be your case, since you say the 8.x style works, so I'm guess your case is simply a matter of accounting for the location of VIs relative to each other after the build. Usually, this isn't a problem, but if you're using dynamic calls, you have to understand where LV will place each file. In most cases, people don't use dynamic calls or include the dynamic VIs in the build, thus allowing LV to take care of all the path issues.
 

---

Before LV 9 it never occurred to me that I might actually have to worry about being able to find vis inside the executable. 

---

I think this might be the key. Before LV 2009, the EXE had all the files internally as a single folder. That's why library files were placed outside - some of them had the same name and couldn't be placed in the same directory. In a 2009 EXE, the directory structure is preserved inside the EXE, and I have a feeling your code is relying somewhere on having to strip only once (or something along those lines). If you're interested in debugging this, the easiest is probably to place an indicator showing the path where things are expected to be found.

[rolfk]

---

dbrewe wrote:

 I don't really follow this point at all. Where are these vis masquerading as the ones I want that will break my application? The only vis on the machines where my applications are used are there because I put them there inside the executables. I certainly would never use different vis with the same name in an application - as I said above, I don't even know if it is possible, and don't want to find out.  Search paths to find components like shared libraries are a common thing. It doesn 't seem like a stretch for the run-time environment to define a default search path like "somewhere in the exe file containing the application".

---

Well on your system and with your settings there will be nothing else LabVIEW like!  That doesn't have to be the case for everybody though. By default an executable has no search paths, but they can be added to its ini file and that has potential for a big mess if you do so.