LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Preventing LabVIEW from automatically choosing replacement subVIs

I open my VI; then LabVIEW tries to load the subVIs which are called in the VI. But it cannot find them for whatever reason; perhaps I moved them or changed their names, for example. So, it automatically goes hunting through my hard-drive, trying to find them. If it finds something close, it automatically chooses and loads it, even though that subVI might be complete garbage--it just happened to have a close name.

There is no easy way for me either to stop it from automatically loading or to correct the damage once it is done. To correct the damage, I have to open each subVI and subsubVI and subsubsubVI (you get the picture) to replace it with the proper file. This is tedious, stupid, and annoying.

Please advise as to how to easily correct this problem. Please also force future LabVIEW editions to ask the user if the suggested replacement is correct before automatically loading it. The user should also be able to browse and choose the correct subVI file. Thank you.
0 Kudos
Message 1 of 4
(3,008 Views)
You're correct that it can be tedious but I don't believe you're correct about it loading a VI of a similar name. LabVIEW will only load a VI of the exact same name. If you could post an example where a top level VI will load a subVI of a "close name", I'd like to look at it.

If you're quick enough, while the main VI is doing it's search, you can click the browse button. You can minimize the problems by leaving your top level VI open and when you do a move or rename of a subVI, the path to it will be modified in the main.
0 Kudos
Message 2 of 4
(2,994 Views)
Agreed, this is an annoying feature of LabVIEW and can cause headaches until you learn how to handle it.

The first thing you need to realize is that LabVIEW has only a single memory space. This means that no two VI’s can be loaded at the same time if they have the same name. It’s similar to the directory structure on any OS, you can’t have duplicate filenames in a directory.

Next is how does LabVIEW load sub VIs. The first place it looks is in its memory space. If it sees a VI with the name of the one it’s trying load, it must use that. Again, because it can’t have duplicate names in memory. If it’s not in memory, it looks for the sub VI at the path where it was when the top level VI was last saved. If it’s not there, it starts searching through a specified set of directories (that you can modify. Go to Tools>Options>Path>VI Search Path) for the VI. If you’re quick enough, you can hit the Browse button on the search dialog and find it yourself. If it doesn’t find it in the specified search paths, you then get a browse dialog to allow you to try and find it yourself.

To avoid problems like this, there are a couple things you need to keep in mind.

  • Don’t have duplicates of a VI on your hard drive. This will ensure that a top level always loads the correct one. If you have a sub VI that you use often, put it in the user.lib directory that’s located in the LabVIEWx.x directory.
  • Don’t have two VIs with different code use the same name. Even if they are used in different applications, you still have the possibility of getting the VIs cross linked.
  • Don’t rename a sub VI from outside of LabVIEW. If you want to rename, open it from the block diagram and do a “Save As”. This will relink everything correctly. If you change the name outside of LabVIEW, it has no way of knowing what you did and can’t track it.


Also realize that LabVIEW will only load a sub VI with an exact name match (not counting letter case). It won’t load something just because it’s close.

I’ve always thought they should have the search dialog ask you if you want to browse for the missing subVI or have LabVIEW search for. At least that way you would always have a chance to browse yourself.

Ed


Ed Dickens - Certified LabVIEW Architect
Lockheed Martin Space
Using the Abort button to stop your VI is like using a tree to stop your car. It works, but there may be consequences.
Message 3 of 4
(2,987 Views)
Thank you very much for your excellent replies, Ed and Dennis.

Best regards,
A.B.
0 Kudos
Message 4 of 4
(2,968 Views)