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\Sub1.vi)? 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. .\Sub1.vi)? 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. \Sub3.vi)? 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 foo.vi 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:
- 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.
- 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.
- If still not found, look at the expected disk location (using the stored relative, pseudo, or absolute path).
- If still not found, look for the file in each directory of the VI Search Path.
- If still not found, prompt the user.
- 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.
Labels: linking
