LV inexplicably finds dependency (sub vi) in incorrect folder

[DrOnline]

Hi!

I am running LabVIEW 2020 SP1 32-bit on Windows 10 64-bit.

Trying to do the Core 2 exercises for my CLAD exam.

When I open the supplied exercise VI's, they keep finding whitespace.ctl in the repository folder for our company software. Where we keep all our TestStand/LabVIEW programs for automated tests. It should be finding it under <vilib>:\Utility\error.llb\whitespace.ctl, but it doesn't.

If you look at the three images below, you see:

1) The problem popup

2) <vilib> is in the search directories (I've obscured part of the path name as it contains customer info)

3) error.llb is indeed in C:\Program Files (x86)\National Instruments\LabVIEW 2020\vi.lib\Utility\error.llb, and it does contain whitespace.ctl

What could cause this?

[tst · Accepted solution]

---

@DrOnline wrote:

What could cause this?

---

You have an open VI which calls c:\develop\...whitespace.ctl.

Then, you open another VI (specifically, Filter Hex From Message.vi) which wants to load whitespace.ctl from vilib.

LV has the concept of a fully qualified name, which uniquely identifies each VI in memory. In the case of your ctl, which is not in a library, that is simply the file name of the ctl. Because the fully qualified name has to be unique, LV uses the ctl it already has loaded and tells you that it did that.

You can open the ctl and see who's calling it in the View menu, or you can right click it in the project window and find its callers. That will tell you who calls it. You can also delete your copy (make sure you have a backup) and then reload the project and see which VI will complain (and probably search and automatically load the copy from vi.lib).

Note that in general, it's not a good idea to have copies of VIs in vi.lib. If you want to do that for some reason, you should namespace them by adding them to a library or renaming the file, so that you don't run into these conflicts.

[DrOnline]

Thank you for your answer, tst.

To be clear, I have nothing open before doing this. Everything is closed. LabVIEW is closed. I double click on "main.vi", and it gives that dependency path popup. I understand about name uniqueness. So If I already had whitespace.ctl loaded from the wrong folder, then opened this vi as well, it would assume it should use the same asset. But this is not the case. I would expect it to open it from error.llb since it is in the paths list. Why would it not look in <vilib> first? I'm sorry, I just don't understand. If you could explain in another way I'd appreciate it.

Years ago, my company started doing automated testing with zero preconceptions. My colleagues probably copied out that file with some kind of "self contained system" in mind, that nothing is required, if you move the program to another computer. It's clearly the wrong way to go about it. Just want to clarify that I didn't do this. "Not my fault", if you will 😄 I don't understand why LabVIEW goes into C:\Develop first, though. In TestStand, we can control the order of priority for search folders. Doesn't LabVIEW do the same?

Its two callers are:
C:\Program Files (x86)\National Instruments\LabVIEW 2020\vi.lib\Utility\error.llb\Trim Whitespace.vi

C:\Program Files (x86)\National Instruments\LabVIEW 2020\vi.lib\Utility\error.llb\General Error Handler Core CORE.vi

Are you perhaps saying that Trim Whitespace.vi has already, in a previous situation, been compelled to use whitespace.ctl from C:\Develop? Maybe that's the case.. let me see if I can force it.... and then reload and see if it still gets the "wrong" file. (I say "wrong" because it works fine, just very inelegant, the VI is the same).

[DrOnline]

Hmm, 

Trim Whitespace.vi gets the control from:

C:\Program Files (x86)\National Instruments\Shared\System Manager\20.0\vi.lib\Utility\error.llb\whitespace.ctl

General Error Handler Core CORE.vi:

I can't seem to be allowed to do anything to this VI. Some level of protection?

So strange that it says "the control expected to be at <vilib" [...]"... it IS there.

[tst]

To be clear, when it says "expected" it doesn't mean "not found". It means "I'm supposed to take it from A, but took it from B because it's already loaded from there". When a VI loads, it remembers where its subVIs are and will attempt to load them from there, but will be preempted if there is already another VI loaded with the same name.

Only if the VI can't be loaded then LV will start searching for it in other places.

It's certainly possible that the VIs were pointed to the wrong VIs in the past and then saved, although I don't know why the trim whitespace VI would go to the system manager folder.

In any case, as you suggested, you can force it by loading the specific ctl first and then load the VIs that are wrong and save them. If you can't edit the VI for some reason (it's not locked in 2015, which I have open), you can also try repairing the LV install, which I believe should reinstall the vi.lib VIs from scratch, with all of the correct links. I would consider doing that anyway, since you don't know what other VIs might have been modified.