LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Project Expects nonexistant, uncalled VI

Hey Y'all,

         I've been struggling with this issue for a little bit now, and have finally decided to do something about it.  Every time I load up this specific LabVIEW Project, claims it can't find a specific VI.  This VI does not exist at the path, so it would make sense to raise this error, however, it isn't used anywhere in the code.  After clicking "Ignore Item" it finished loading correctly and there are no errors in the project.  This problem doesn't really stop me from coding, but instead is just a slight annoyance that I'd like to get rid of.  After the first time booting it up and clicking Ignore Item, all subsequent loads of the project won't search for the file, however since I use Git, every time I pull new code/switch branches, it pops up again.  It also pops up if I clear the Compiled Cache.  This VI used to be a property node accessor for a class, but I decided it didn't make sense for that class to have the accessor and moved it to another class.  Therefore, there is a VI named Write Encryption.vi that belongs to another class and is in a different spot.  Any help would be greatly appreciated.  Thanks!

EthanHenry_0-1691080606445.png

 

0 Kudos
Message 1 of 15
(1,002 Views)

Does the VI show up in the "Dependencies" section of the project, presumably with a yellow "!" on it?

 

If so, can you right-click it and choose "Why is this item in dependencies"?  If so, it should at least point you towards the file(s) causing this to pop-up to narrow the search.

 

Also, you could do a search in all VIs in your project for code in diagram disable structures.  I've had ghosts like this one show up because of forgotten code in those before.

0 Kudos
Message 2 of 15
(966 Views)

Following up from Kyle's remark, if you don't see "Dependencies" at the bottom in Project View, in the Project Window, click on "Project" (at the top) and choose "Filter View" to turn "Dependencies" on.  This shows you things your Project "asks for" that you don't specify as "code in the Project", such as vi.lib and user.lib.

 

Bob Schor

0 Kudos
Message 3 of 15
(960 Views)

There is a "Write Encryption.vi" in dependencies, however it belongs to a different class.  It doesn't have any error mark, and appears just fine.

0 Kudos
Message 4 of 15
(941 Views)

What about diagram disable structures?

 

You can use the standard LabVIEW search to look for them like so:

Kyle97330_0-1691095829053.png

You will want to make sure every file in your project is included in your search.  This might be mostly done by opening your main VI and choosing to search it and all subVIs, but you would miss any VI in there that isn't a dependency of your main VI, so you might need to add in anything missing manually.

 

Also, have you tried just opening up your project file in a text editor to see if there's a reference to that path anywhere in it?  LVPROJ files are just XML so it's no problem to do in a text editor.  You'll probably want to only search the last couple elements of the path since a lot of files are stored via relative paths so you couldn't want to miss it by searching for the complete path.

0 Kudos
Message 5 of 15
(926 Views)

@Kyle97330 wrote:

Does the VI show up in the "Dependencies" section of the project, presumably with a yellow "!" on it?

 

If so, can you right-click it and choose "Why is this item in dependencies"?  If so, it should at least point you towards the file(s) causing this to pop-up to narrow the search.

In my experience, selecting "Why is this item in dependencies" always causes LabVIEW to crash. All versions.  Always.

Some people claim that it works, but I've never seen any evidence that it works; or has ever worked.

0 Kudos
Message 6 of 15
(919 Views)

 


@paul_a_cardinale wrote:

@Kyle97330 wrote:

Does the VI show up in the "Dependencies" section of the project, presumably with a yellow "!" on it?

 

If so, can you right-click it and choose "Why is this item in dependencies"?  If so, it should at least point you towards the file(s) causing this to pop-up to narrow the search.

In my experience, selecting "Why is this item in dependencies" always causes LabVIEW to crash. All versions.  Always.

Some people claim that it works, but I've never seen any evidence that it works; or has ever worked.


I've used that right-click option probably hundreds of times.  At least 5 different PCs, 4 different LabVIEW versions over the last 10 years.  At least a dozen times just this past week.  Never one crash from it.  I don't know what you're doing different than I am, but it can work perfectly fine...

0 Kudos
Message 7 of 15
(915 Views)

I'll take a look at the dds, but as for the project file in a text editor, I didn't see the Write Encryption.vi referenced anywhere.

0 Kudos
Message 8 of 15
(901 Views)

@EthanHenry wrote:

I'll take a look at the dds, but as for the project file in a text editor, I didn't see the Write Encryption.vi referenced anywhere.


That's very possible. The reference is generally stored in the VI not in the project. You can add them to the project to have another explicit reference in your project view. If you don't do that it will be listed in the Dependencies section automatically as soon as the VI that references it gets loaded. With VIs in Diagram Disable structures or Conditional Disable structures things can sometimes get a little weird as LabVIEW considers them as dependency even though it does not really load them.

 

And yes the project option to see Why is this VI in Dependencies definitely works for me. I use that quite often when inheriting projects where the previous programmer thought that it is absolutely unnecessary to add any but the top level VIs to the project tree. Together with the option to show unreferenced VIs in the project tree. That is quite handy to find cruft that has accumulated over time during project development.

Rolf Kalbermatter
My Blog
0 Kudos
Message 9 of 15
(884 Views)

Two points.

First, try opening each individual lvlib or class without opening anything else. One of those is probably claiming a member that lost its bidirectional ownership mark. Simply add it back to the library or class it belongs to.  The inverse is also possible, someone accidentally moved a dependency improperly into a class or library.  Hard to tell which without remote access to your machine.

Paul uses a lot of scripting and other features most of us don't use. I can easily imagine that a mad hatter would show up at a tea party he walks into now and then.


"Should be" isn't "Is" -Jay
0 Kudos
Message 10 of 15
(860 Views)