Fix broken symbolic paths

[TurboPhil]

Is there a way to see/modify the absolute paths corresponding to symbolic paths in LabVIEW?

I recent installed 1 new NI package (RT module) and 3 new JKI VIPM packages on a machine, and after doing so, my standard symbolic links are all broken. LabVIEW (2019) is looking for vi.lib in

C:\Program Files (x86)\National Instruments\LabVIEW 2019\Targets\vi.lib

instead of

C:\Program Files (x86)\National Instruments\LabVIEW 2019\vi.lib

Same for instr.lib, etc.

So now I can't even open a new VI without the search dialog coming up asking to find basic vi.lib stuff it wants to load in the palettes (example: "Trim Whitespace.vi").

Is there any way to dig myself out of this hole, short of completely uninstalling and reinstalling LabVIEW?

[paul_cardinale]

Here

[paul_cardinale]

Here

[TurboPhil]

Upon further investigation, I don't think the problem is with the symbolic links. I think something got screwed up during a JKI VIPM package installation that had a bad path to some common VI, and the affected item is being loaded early in the process of loading my lvproj.

If I completely quit LV and then reopen fresh, I can actually open a new VI without it failing to find items for the palettes. The "missing VI" prompts only start showing up when I open a particular lvproj.

The problem is definitely not with the lvproj file itself, because it is under version control (Git), and I can open the same revision on other machines without this issue. The same goes with all the user VIs within the project, as they are also SCM controlled and I verified no local modification are in place.

So the problem must be somewhere in the LabVIEW distro, or in any other folders that the JKI packages installed into.

I'll try using the "Linker.Read Info From File" method on the top-level VI of the lvproj and see if I can figure out where the bogus paths are getting introduced.

[TurboPhil]

One more followup, in case anybody stumbles on this.

Attempts to open the .lvproj files were resulting in an infinite prompt-for-missing-vis loop (the "ignore", "ignore all" and "stop" buttons were all worthless), so I was having problems gaining insight into the specific problems. I finally tried running LabVIEW in "unattended" mode, and was thus able to get the lvproj opened (since that was the only way to silence the infinite prompts).

Once I got the project open, I was able to open a top-level VI and show the error list to see what it was complaining about. Sure enough, the error list reported a lot of "missing" VIs, like Trim Whitespace.vi, but only for callers that fall under RT targets within the project. Any caller of Trim Whitespace.vi that lived under "My Computer" in the lvproj was fine; callers under FlexRIO or other targets were broken due to the "missing" VI.

The lvproj also flagged all the RT targets as "features not available"

https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z000000P6ycSAC&l=en-US#

So the problem ultimately appears to be because our CI worker machines where we were encountering this issues do not have licenses for the Real-Time Module. We are in the process of getting those licenses, and hopefully that will fully resolve this problem.

This is still a big shortcoming in terms of error reporting, and it resulted in days of wasted time investigating.

[rolfk]

In case anyone else wonders about this, this is a document from a LabVIEW developer describing the pseudopath feature in LabVIEW. It's specifically targetted at using packed libraries on different platforms but the underlaying mechanisme is more generic.