Check project for missing VI's

Anyway easy way to check a project for VI’s that are outside the project file structure?

Recently I transferred a project to my team remotely. There were several VI’s that I had copied from a different project.

I didn’t know that these VI’s were being referenced from this different location until the code wouldn’t build onto our cRIO.

If I read your question right, you want to view all the VIs referenced in a project so you can ensure you copy all the necessary ones before you try to build?

In that case, open the VI Hierarchy, which will display which VIs are called by which other VIs (link). Go to View-> VI Hierarchy to view it.

Also, the Run arrow will show as broken when you’re missing VIs, so you could just click on it and use the debugging tools to see which VIs are missing and then go get them.

In the Project Explorer window, the one that starts up after you’ve opened a project, there are two tabs: Items (the default) and Files.
Files lists all the project files that are being linked in, and exactly where in the disk file structure they are coming from.

In the first attachment all the (non-library) project files are located together in the directory: C/Users/Developer/Documents/LabVIEW Data/Golf v6
Developer is the Windows user account.

In the second attachment I’ve added a couple of files from another directory called: 2010 T358-Robot v4-Cam indicator
So you can see that the files are not all together in a single project folder, but spread across two project folders.

The easy answer is to be sure to copy or move files via Windows into your LabVIEW project folder before adding them only from there to your LabVIEW project. Any common vi’s you want to share across projects, and don’t want to have multiple copies, should go into the custom vi user library (C:\Program Files\National Instruments\LabVIEW 8.6\user.lib), that way they’ll be readily available via the palette too. If you do have shared vi’s you will have to remember to copy them along with your project folder when you transfer or backup a project.

I can’t test if my code using the run button because I’m working remotely…

In the attached explorer window I have one VI purposely placed in the project that is linked from my desktop. Aside from exploring it there isn’t a clear way to tell that it doesn’t belong.

Also, what is special about the VI’s listed under “dependencies?”

The LabVIEW project folders are actually lists of references, sorta like shortcuts or aliases. It allows you to link together virtually anything from anywhere and call it a project. When things are not moving around much, this works very well and is ultimately flexible. But when files move, it more or less tells you that and expects you to resolve or fix the project.

The way to tell where files come from is to flip to the files tab in the explorer window. Pretty quickly, you will see that most of your files come from one folder hierarchy, and then there is this special one that is on the desktop. That doesn’t make it a mistake or cause any problems, but it lets you know that your files are in more than one location, and which is the odd bird.

They are files that your project needs/uses that you have not added to your project. If you start a new project and create a new VI called Untitled, then place a subVI called A out of some library on the diagram. You are dependent on A, so it must be in the project somewhere. But since you didn’t write it or explicitly add it to your project as a source file, LV instead puts it into the dependency folder. If A internally calls B and C, you will find them there too, which is the more useful element of dependencies. If you learn that C had a bug in it, you may wonder … I don’t remember using C … I wonder if the bug impacts me. If it is in dependencies, then there is some form of dependency, and you can open C and learn about the calling instances.

You can also drag dependencies up into your project folders to declare that you want the file to be added to the project and tracked regardless of whether it is being called. I occasionally make my own folders and drag things from dependencies to put then into my own organization and tidy things up.

Greg McKaskle

Excellent…much more clear now.