When oneLabVIEW VI needs to call another VI, LabVIEW makes that “just work” without asking the user to specify additional information. This is great for the domain user who doesn’t want to be distracted by the noise of file management. To make it “just work,” the linker inside LabVIEW may store an absolute path to the called subVIs inside the VI itself. This often makes it simple and fast to load dependencies.
However, things get complicated when a dependency isn’t found where it is expected to be.During the process of loading a VI, LabVIEW may launch various helpers to locate the missing dependencies.
The first helper searches the VI Search Path for files that match the expected name:
If that helper finds a VI with a matching name, another helper informs you about the path discrepancy:
We’ve observed users struggle to keep their VI dependencies from getting cross-linked when going down this path, so we evolved the linker in LabVIEW NXG to prevent encountering missing dependencies at VI load time in the first place.
We did this with a few key design decisions:
VIs hold only names, not paths.
As long as your VIs are part of a Project or Component, creating VIs that call other VIs still “just works.”
The Project and its Components serve as the Linker, resolving names to paths and loading SubVI dependencies as needed. This is done without user intervention.
Project files hierarchy mirrors project disk folder hierarchy 1:1.
The LabVIEW NXG Project is required for loading and editing VIs.
By consolidating dependency resolution responsibilities into LabVIEW NXG Projects and Components, they’re the only things responsible for knowing the paths to the files they “own.” If a project expects a VI to be at a certain location on disk and it’s not there, you don’t search disk looking for the missing file or files. Instead, you look at the navigation pane on the left side of the IDE to identify errors displayed directly on any missing project items:
By hovering over a broken item, you’ll see a tool tip that should help you diagnose what went wrong.
This should help you take corrective action by either:
Deleting the broken project item and creating a new project item that points to the file in its new location.
The result: LabVIEW NXG VI hierarchies often load faster than the equivalent LabVIEW 201x VI hierarchies.
We’re excited to hear what you think about the LabVIEW NXG project and linking strategy we’ve described here. Will you miss writing code outside a project? Have you struggled with missing dependencies in the past and look forward to LabVIEW NXG ending those struggles?
Your feedback is essential to influencing our plans, as we are committed to do our best to deliver an IDE that stays out of the way while you do the heavy lifting writing code.