Wednesday, November 15, 2006

VI Linkages and Cross-linking

I want to talk about libraries and projects, but I think first I should set the stage by talking about cross-linking.

VIs are different than most document files because they refer to each other. A VI cannot run unless LabVIEW can find all of its subVIs.

A VI referring to another VI is called a link. When a VI links to a VI other than the one the developer intended it to link to, that's called a cross-link.

Imagine you have a VI with a subVI:

In the beginning, the VIs are on disk. They are are in “Disk World” (with apologies to Terry Pratchett).

When you open the main VI, LabVIEW needs to bring the VIs into “Memory Land.” So it needs to load the main VI and the subVI as well. That means the VI needs to store information about the subVI, particularly where it is on disk.

How does LabVIEW store that information?
  • As an absolute path (e.g. C:\Project1\ Not if there’s any other choice. Imagine how brittle it would be if we always stored absolute paths. If you renamed your Proj1 folder, LabVIEW wouldn't be able to find any subVI of main.VI. However, in some cases, it is not possible to use a relative path (such as when the subVI is on a different network drive), so LabVIEW has to store an absolute path.
  • As a relative path (e.g. .\ Sometimes. In fact, this is how the path is stored in most cases, except when the subVI is in certain “special” locations.
  • As a pseudo path (e.g. \ Sometimes. If the VI is in one of the “special” locations defined by pseudo paths.

In Disk World, a VI remembers its dependencies by path. But once in Memory Land, a VI tracks its dependencies by references to linker identities, which are unique by qualified name (in a given application instance). [I'm not going to talk about application instances in this post, but they have to do with projects. I'm also not going to go into more detail about qualified names now, but they have to do with libraries. In the absence of libraries, you can think of the VI name as the file name].

Why is cross-linking a problem?
  • If you have two copies of and one has a bug fix and another doesn’t, and you accidentally link to the one that doesn’t, you can be quite puzzled as to why your VI is executing incorrectly.
  • If you edit a subVI, thinking that it is part of your current hierarchy when it’s actually loaded from a completely different one, you might save your changes without realizing you’re overwriting a VI you needed for that other hierarchy. If you didn’t keep backups, you could end up losing work as you have to recreate the original subVI when you go back to working on the other set of VIs.
  • If you mass-compile a copy of your VIs, and they're accidentally linked to the VIs you meant to leave in a prior version, you can inadvertently bring all your VIs into the current version.
  • etc.

How does cross-linking arise?
  • When a VI that satisfies the “link to” requirements is already in memory when the referring VI loads. (See section below for more details).
  • Copying files on disk instead of using File>>Save As.
  • Using File>>Save As incorrectly.

How LabVIEW finds a subVI:
  1. Look in memory for a VI of the requested qualified name. If that VI comes from a path other than the one LabVIEW expected, it will post a load warning, but it will still go ahead and use the VI in memory.
  2. Look in memory for a VI that was loaded from the requested path. If the caller expected a VI that wasn’t in a library and we find a VI that’s in a library but otherwise of the correct name, we will use it. However, if we find a VI that’s otherwise of the wrong name, we will not link to it.
  3. If still not found, look at the expected disk location (using the stored relative, pseudo, or absolute path).
  4. If still not found, look for the file in each directory of the VI Search Path.
  5. If still not found, prompt the user.
  6. Again, check memory for the requested name (in case the user selected a file with a different name).

In future posts, I plan to talk more about how to avoid and fix cross-linking.



Anonymous Anonymous said...


Great blog, and great NIWeek presentations. Thanks for your ongoing help in getting people acquainted with the slings and arrows of the LV8.x project environment.

As you talk more and more about projects, I'd like to see a brief discussion of how Classes/lvlibs/etc. can fit nicely into re-use libraries. I have my library functions in user.lib, but there doesn't seem to be a corresponding place for Classes & associated .lvlibs. In some ways it seems to not matter because the .lvproj remembers the paths, but that somehow feels... incomplete. How do you organize the Classes you re-use across multiple projects?

2:34 PM, November 16, 2006  
Blogger Christina said...

Excellent question! Classes and libraries are still new enough that "best practices" for them haven't been universally agreed upon yet.

I'll see what some of the other VI developers at NI think and post my resulting suggestions.

Thanks for the comment!

9:29 AM, November 19, 2006  
Blogger Brad said...

This would be a GREAT topic to cover in detail as I have been bitten by this a handful of times. It really can get frustrating to learn the hard way as to what on earth is happening when cross-linking is the evil culprit. Disappointingly, the LV Basics 1 and 2 CBTs did NOT cover this problem at all and how to avoid it (at least not that I remember). BTW, the CBTs are fairly decent, but they need a bunch of additions and corrections to make them what I would consider really good, but that's another subject for another time.

8:40 PM, January 14, 2007  
Blogger Christina said...


If you have specific questions about linking and cross-linking, please let me know so I can cover them in future posts.

Also, I can route feedback on the CBTs to the right people inside NI, so feel free to send me your suggestions (either by e-mail or by posting them here).


3:51 PM, January 25, 2007  

Post a Comment

<< Home