List all (expected) subVI paths

[IrishJimJitsu]

Hello,

I'm piecing together a relatively large application (let's say a single, main VI) by piecing together somewhat large chunks of other builds, totally maybe a few or several thousand VI's.  The folder hierarchy nomenclature of the component builds isn't entirely logical, and there is some cross linking or duplication of subVI's between the component builds.

Ideally, to get the whole application organized, and later for documentation purposes, I'd like to be able to generate a file list of ALL subVI's in the main VI.  I know about this gem:

http://forums.ni.com/t5/LabVIEW/Paths-of-the-called-files-How-to-see-them/m-p/2721289/highlight/true...

However, this build is in process and I CAN'T execute the main VI to get a list this way, mostly because it won't execute if subVI's are missing, some just one layer deep (on the block diagram of the main VI), others multiple layers down.  Being able to get a list of where it EXPECTED these subVI's to be would be immensely helpful to fix this.

Is there any way, without executing a VI, to display a list of all expected filepaths of all subVI's?  For the sake of future organization/documentation, it'd be nice if it were a list of BOTH subVI's that were found as well as the (MANY) subVI's I have to tell it to ignore while loading to load the main VI.

Thanks!

[mikeporter]

A few THOUSAND VIs?!? that's not relatively large, that huge! In fact, it is way too big -- I don't care what it's doing.

You need to be looking at starting over.

Mike...

[Hooovahh · Accepted solution]

---

@mikeporter wrote:
A few THOUSAND VIs?!? that's not relatively large, that huge! In fact, it is way too big -- I don't care what it's doing.

You need to be looking at starting over. 

---

I do not agree with this statement.  Several projects I would call medium size loaded 4,000 VIs into memory, probably about 2,000 or more were written for the project and the others were from variousl libraries, toolkits, vi.lib and user.lib.

If you add your VI to a project, you can go into the Files tab and it will show you the folder structure of all depenedency code.  Of course if VIs are missing it can't say where on disk those dependencies were loaded from.  Starting in LabVIEW 2014 NI has the ability to know the expected loading path of missing VIs.  You can see this when you have context help open on a missing VI.  In the help window it will tell you the expected path.  

But still I don't see why this function can't work for you.  I just tried it and it found the expected paths of missing components on a broken main VI.

[IrishJimJitsu]

Thank you, Hooovahh, for posting an actual ANSWER to my question and not just an opinion!

I'm currently using LV13, so it looks like making the jump to 14 would be a huge benefit in this case.  Currently, whenever I hover over a VI that wasn't found (in LV13), the Context Help just says something like "SuchAndSuch.vi was not found", so if it told me where it expected to find it and I could load another large set of files so that it works for that one VI, it'll take care of a lot of other VI's that it couldn't find when I reload the main VI (then do that a few times to find what pieces I'm missing until it can load everything without prompts).  This is something I wish that NI would've added a LOT sooner than 2014!

The VI's you uploaded were in 2014, so I couldn't open them.  Was it the same as the snippet I linked to in my original post?  I'm ashamed to say that I had a complete brain fart when I tried it the first time when I (for some reason) was thinking that you could only execute it IN the VI whose dependencies you were trying to get, then (after that "well DUH!" moment), I was able to get what I needed when I executed it in a blank VI with my main VI's filepath.

Thanks again!

[mikeporter]

Oh, I gave you an answer too. It was just an answer you didn't like.

Mike...

[IrishJimJitsu]

Answering the question "Is there any way, without executing a VI, to display a list of all expected filepaths of all subVI's?" with "You need to be looking at starting over" is like answering the question "How do I access the spark plugs on a 2010 Ford Escape" with "You need to buy a Honda CRV" in that starting over won't display a list of expected filepaths, as buying a Honda CRV won't change the spark plugs on a 2010 Ford Escape.  Using that example, while I agree that the Honda would be much simpler to do things like change spark plugs, buying one wouldn't fix the problem at hand, and I might not be able to buy one for many reasons, time and resources being biggies, much like an individual developer wouldn't have the time or authority to restructure a pre-existing software library.

[tst]

Mike, I completely agree with the others - such a comment is completely baseless (the fact that you with all your experience don't write such apps doesn't mean that they don't exist) and it certainly doesn't help to tell someone to start over without knowing a lot more details about their application.

That said, YellowDart, I think you are in above your head and should take a step back. If I'm understanding the gap between you and Hooovahh correctly, the problem is that you're trying to run the main VI to get this list. The VI you should be running is actually another VI which opens a reference to the main VI and calls the method on it. That's exactly what the code you linked to does and it's what Hooovahh's code does as well. The fact that you don't know this should be a red flag suggesting that maybe you should not be attempting what you're attempting, as that is the kind of thing which requires more intimate knowledge with how things work.

For example, even if you do understand what I explained now and run the code, you will probably find that you don't have the entire list you want, because each VI only references the VIs it calls. It knows nothing about the subVIs of those subVIs. Because the first subVI is missing, you won't be able to find the paths of the other missing subVIs, because you have nothing which even knows they exist.

You also seem to have a misunderstanding of how LV treats missing VIs. LV does know exactly where the VIs are supposed to be, because it needs that to load them in the first place. If the VI isn't there, you get a search dialog telling you that LV is looking for the VI in other places (defined in the LV options) and showing you where it was supposed to come from. The new functionality in 2014 is less about displaying the expected path of the missing VI in the context help and more about showing you which component that VI belongs to, so you can install it. This won't apply to your code, so it won't help you.

There are many other things that we could tell you about the subject. For example:

• If you load VI A which calls VI B, and VI B is missing and not found (or you tell LV to stop searching) and then load VI B from another path, VI A will automatically call the new B, with all its dependencies.
• In projects of this size it can be common to call things dynamically rather than statically, to make builds simpler or improve load times, etc.
• Dealing with conflicts can be difficult.
• Sometimes people use multiple projects to build components or use namespacing to avoid conflicts.

Rather than trying to tell you these things, though, my bottom line is the one I started with - I think you're in over your head. I would suggest you talk to your local NI branch to see if they can help you. A better alternative (which they would probably recommend too) would be to find a LabVIEW constultant in your area which has experience with this type of thing and can come and look at your code and give you some concrete advice. The NI branch probably knows who's relevant in your area, and I expect they would point you toward some alliance partners. Another option is to search for LV user groups in your area and see who the participants are.

[IrishJimJitsu]

As I stated in an earlier reply, it was a brain fart, highlighted by the fact that I said I'm ashamed to say I made that mistake.

I understand that, if LV can't find a subVI, there's no way (outside of a project) that, upon loading the main VI, that it will know ALL dependencies, as it can't know what else the missing subVI's are going to call.  However, if you were to know where the main VI was expecting to find a VI (that it can't find) that calls a (relatively) large number of subVI's, knowing the expected filepath of that first missing subVI that the main VI can't find would be VERY useful if that missing subVI most likely called its subVI's in some logical corresponding hierarchy in the file structure.  let's say I have a main VI, XYZ_Test performing a test on a part with model number code XYZ, and I'm missing XYZ_Data_Analysis.vi (a subVI of XYZ_Test.vi).  XYZ_Data_Analysis might call three subVI's, Data_Analysis_Formatting.vi, XYZ_Data_Analysis_Math_Stuff.vi, and XYZ_Data_Analysis_Units_Stuff.vi.  On disk, there's a high probability that, relative to some path, the file structure in my master library is something like:

\XYZ_Data_Analysis.vi

\XYZ_Data_Analysis\XYZ_Data_Analysis\XYZ_Data_Analysis_Math_Stuff.vi

\XYZ_Data_Analysis\XYZ_Data_Analysis\Math_Stuff\

....

\XYZ_Data_Analysis\XYZ_Data_Analysis\XYZ_Data_Analysis_Units_Stuff.vi

\XYZ_Data_Analysis\XYZ_Data_Analysis\Unit_Stuff\

...

\XYZ_Data_Analysis\XYZ_Data_Analysis\XYZ_Data_Analysis_Formatting.vi

\XYZ_Data_Analysis\XYZ_Data_Analysis\Formatting\

...

So, if I know where it's expecting to find XYZ_Data_Analysis.vi, I can move the folder containing XYZ_Data_Analysis.vi into my build, in that expected location, and I'd be resolving a good chunk of the dependency conflicts in doing so.  In a way, it's a problem of trying to find out where several pieces are supposed to go in the overall hierarchy.  Then, once the build is made as expected, running that snippet of code one last time for documentation/organization.  Of course, as you said, this can fall apart in the case of dynamic calls if you're not careful, but luckily, in this project, I've never seen it used in any part of the master library.

[tst]

I seem to have my own problem, since I missed that part of your paragraph even though I saw the paragraph itself.

Anyway, the way it's built still sounds overly complicated to me, but if you're managing to make it work, then at least you saved however much that consultant would have cost. Depending on how messed up your architecture is and how you're going to interact with this app, it might still be worth it to get someone to help you with it, but you know the details, so that's your call.

[Hooovahh]

Resaved in 2013, the only thing I had to remove was in 2014 there is a new private method for getting just the missing VI information, where in 2013 and newer there is a method to get all subVIs including missing ones.  You can probably get the same information but might take a bit more work.

And yes it is the same function just being ran in a different VI, looking for subVIs in a non-running VI.