Find orphan VIs in project hierarchy (on disk)

[LogMAN]

Hello everyone, I want to share a VI that I recently created to search for orphan files in a (very! ) messy project. As it turned out it's actually very easy to do that (if you find super-secret stuff on the net):

This VI will find files (VIs, Controls, Classes, etc...) in your project folder that are not linked by a given top-level VI. This is done by comparing the call-chain of the top-level VI with the files on disk. It assumes your files are in folders relative to the specified root directory. This also means that files outside the hierarchy will be ignored (vi.lib and such).

Be aware of (at least) two things:

1. This VI will return false friends if you happen to have any "Open VI Reference" call with constant VI names or paths connected to it (not a problem if you use static VI references).
2. VIs in diagram disable structures are not listed in the call-chain. So if you use conditional (or regular) disable structures this VI will return false friends.

Does anyone know a solution to number 2. actually?

Hope this proves useful to you too.

[ShaunR]

I do this slightly differently (in Project Probe). Yours might be faster if you only look at link info from the file rather than loading the hierarchy but I have to look at lots of other VI stuff that require opening the VI anyway too (like re-entrancy, debugging enabled, icon, description etc). I also use it to sort VI refnums when force compiling hierarchies.

I create the file list similarly to you then I open each VI and check if it has dependencies (Get VI Dependencies Method Node). The VI opened and its dependencies are added to a [found] list. If a VI in the file list is already in the  list or in memory then it doesn't need to be opened and could be considered already processed (it has a parent that was previously opened). If a VI has no parent and has no dependencies then it is an orphan. It can also find VIs in conditional disables.

So I deduce if it is an orphan from the dependencies of all the VIs 

Edited May 4, 2016 by ShaunR

[LogMAN]

7 minutes ago, ShaunR said:

I create the file list similarly to you then I open each VI and check if it has dependencies (Get VI Dependencies Method Node). The VI opened and its dependencies are added to a [found] list. If a VI in the file list is already in the "found" list or in memory then it doesn't need to be opened and can be considered already processed (it has a parent that was previously opened). If a VI has no parent and has no dependencies then it is an orphan. It can also find VIs in conditional disables.

By the sounds of it your solution is more solid and works with more complex projects, which is very nice. I'll play around with that node for a bit, might prove useful for future cleanups...

Actually the "Linker.Read Info From File" reminded me of how the VIPM generates packages. VIPM has the same issues regarding conditional disables, so I think it uses the same mechanism.

[LogMAN]

Okay, finally found a minute to do this. Here is the same VI but this time with a legit invoke node that doesn't require internet magic:

I find the execution speed slower by a huge magnitude (minutes vs. seconds). That's obviously because everything is being loaded into memory. It can be made faster by unchecking some of the options though. Anyways, this VI returns even more Orphans than the original one which it really shouldn't (it recognizes VIs in conditional disables which the old one didn't).

That was very confusing until I found the reason for it: "Get VI Dependencies" will ignore code that is inside a case structure with a constant wired to it (at least if that's the case in the top-level VI). Don't  know if this is intended, but that's how it works.

[shoneill]

Get VI Dependencies ignoring code inside a case with constant selector sounds like a bug to me.

I presume it works OK with inlined VIs?

Edited May 9, 2016 by shoneill

[LogMAN]

On 5/9/2016 at 10:59 AM, shoneill said:

Get VI Dependencies ignoring code inside a case with constant selector sounds like a bug to me.

I presume it works OK with inlined VIs?

No. I just checked with a dummy project. Any code within unreachable cases is ignored. It doesn't matter if it's directly in the main VI, an inline VI, or a normal sub-VI. You can use Booleans, Numerics or whatever you like. Put code in an unreachable case and it is not listed by Get VI Dependencies. Maybe I should file a CAR and see what NI thinks. In my opinion the dependencies should either be listed, or the VI should break.

[ShaunR]

34 minutes ago, LogMAN said:

No. I just checked with a dummy project. Any code within unreachable cases is ignored. It doesn't matter if it's directly in the main VI, an inline VI, or a normal sub-VI. You can use Booleans, Numerics or whatever you like. Put code in an unreachable case and it is not listed by Get VI Dependencies. Maybe I should file a CAR and see what NI thinks. In my opinion the dependencies should either be listed, or the VI should break.

 

Commented Out Diagrams?

No

Specifies whether LabVIEW returns dependencies that LabVIEW does not invoke, such as those in the Disable case of a Diagram Disable structure. Also, if you wire a constant to the selector terminal of a Case structure, LabVIEW considers dependencies in non-executing cases to be commented out and does not invoke them.

[LogMAN]

9 hours ago, ShaunR said:

Commented Out Diagrams?

No

Specifies whether LabVIEW returns dependencies that LabVIEW does not invoke, such as those in the Disable case of a Diagram Disable structure. Also, if you wire a constant to the selector terminal of a Case structure, LabVIEW considers dependencies in non-executing cases to be commented out and does not invoke them.

Check my last VI above. The terminal is set to 2 => Always include commented out diagrams