weird VI path names

[vivante]

Hallo people,

I am using "TRef Traverse for References.vi" to get a complete list of subVis in my application. I need something like a VI hierarchy which I will use to get statistics on my code.

well, I've found a strange result: "TRef Traverse for References.vi" returns some vi name with appendix like ":Instance:0" or ":Instance:Instance 1 29..."

strange thing is that vi names appear many times but subVi are called only one time. Below you find an extract of my VI hierarchy which is alphabetically ordered so can see that "___T4SM_CalibrateTrasducer.vi" appears three times, but in my code is called only one time in one VI.

.......

D-GraphSize.vi

XYGraph.vi:Instance:1

openTDMSFile.vi

...

___T4SM_CalibrateTrasducer.vi

___T4SM_CalibrateTrasducer.vi:Instance:Instance 1 29Saved ___TSM_D-Calibrazione .vi

___T4SM_CalibrateTrasducer.vi:Instance:Instance 2 29Saved ___TSM_D-Calibrazione .vi

___T4SM_D-LanguageSelection.vi

...

of course I can remove the unused part of Vi name before using my file list, but I am curious to understand the real meaning of it.

does anyone of you know the meaning of this appendix?

thank you in advance,

Vivante

getVINames.vi

[asbo]

Is that VI reentrant or have any other unique execution settings?

[vivante]

Oh, you are right: I didn't write about their VI properties: fewof them are reentrant and most are not reentrant,

some are in my user.lib and some in my project subfolders. Below you see a screenshot of Vi properties.

bye

Vivante

[smenjoulet]

does anyone of you know the meaning of this appendix?

thank you in advance,

Vivante

You're using Express Vi's in your application. This is the naming you'll see for express VI's when you list them out.

-Scott

[Darren]

When processing an array of SubVI references, I always pass each of them through this VI (included in LabVIEW 8.6 and later...prior versions require the VI Analyzer Toolkit to be installed):

vi.lib\addons\analyzer\_analyzerutils.llb\VIAnUtil Valid SubVI.vi

This VI will return FALSE if the SubVI reference is an Express VI or a "?" missing subVI. It returns TRUE otherwise.

-D

[Graeme]

Hmmm, interesting. I've noticed this too. I was just about to start a thread on it myself as it's been bugging me for a few years. I see this:

TestExecutive.vi\Instance 1 26Saved MultiTestTemplate2 .vi

Maybe some of my history can shed some light. As probably many do, I've written a test executive to suit my needs as I didn't fancy TestStand. The top level VI was originally called "MultiTestTemplate.vi". Being a bit slap-dash regarding revision control (shame on me) I just added a number to the end of it as its revisions went up. At some point I Saved-As (or did I just re-name it, could be important but I can't remember) "MultiTestTemplate2.vi" to "TestExecutive.vi" as that name seemed more industry-standard and meant more to people.

Anyway, there you have it. It's my top level VI that the "instance" is referring to and as far as I know I'm not using any Express VIs in it. As a parting shot what about this? If someone wants to use my test executive they run my cloner on it so they've got their own project-specific copy and hierarchy. A guy with his own copy has recently been developing on several different computers (very unusual for us). I ran a subVIs list on it out of curiosity and then I saw additional "Instance0", "Instance1" etc. (I'm not at work and can't remember so don't take as Gospel what I've just put in quotes).

To close I should say that I'm not using the "Traverse for GObjects.vi" but the "VI:Get VI Dependencies" method recursively, but what from what's been reported the result looks pretty much the same. Further information appreciated.

Regards.

[vivante]

well, odd Vi names refer to those VIs which have inside one or more Express VI calls.Thanks Scott!

Now I have checked every VI name with

vi.lib\addons\analyzer\_analyzerutils.llb\VIAnUtil Valid SubVI.vi

as Darren says, and my Hierarchy seems to work fine. I didn't know vi.lib\addons\analyzer\_analyzerutils.llb where I have found very interesting functions.

it seems that powerful vi functions are somehow hidden or not documented....

thanks to everybody.

Vivante