Why does the "Callees" property return a name with *:Instance:0?

[ejb068]

I'm building a VI that returns a list of all the sub-VIs and their sub-VIs, etc, of a given top level VI.  I first open a reference by giving the path to the top level VI, then use the "Callees" property to get the subVIs. I then (within a loop) get all the callees of each subvi by opening reference using the string name from the previous callees output. I've noticed at one point that when I ask for the callees using the string name of XYZ.vi, that I get all its subvis but I also get a XYZ.vi:Instance:0 name returned. What is the purpose of the Instance:0 and why does this occur? I really like to understand why Instance:x would ever get appended to the name and also why VI would return its own name in the Callees property? The VI is not set as re-enterent or calling itself dynamically or anything.

Hope someone can explain this.

Thanks,

James 

[Hillman]

Hi James,

Thanks for the post and I hope your well today.

I cant say I've used this property before and I am currently out of the office, so I dont have  Labview at the moment. 

XYZ.vi:Instance:0 - instance like this is for sure related to re-enterent VIs. I have seen this when using a property node to generate a list of VIs in memory. I feel it should be noted that 0 is clearly the first instance.

However, tomorrow I can try this out to confirm. What version of LabVIEW are you using? and do you have some example code I could use? I will update you more tomorrow once I am back in the office. 

[ejb068]

Hi,

Thanks for your help. I'd like to send an example but it is part of a large program and I'm not seeing the issue with a simple VI. I do know for sure that the VI that is returned (ex. XYZ.vi:Instance:0) is not re-enterent. There probably other subvis that are re-enterent though. The is a long list of subvis so I can't easily look through every one.

Having said that, if re-enterent vis only the only reason that "Instance:x" is reaturned after a subvi name, then I could easily remove this from the name when I use else where in the program. I just want to make sure I understand why this occurs so that I can consider the implications of just ignoring the instance number for my application.

Thanks,

James 

[Hillman · Accepted solution]

Hi ejb068,

Good Morning and I hope your well today.

I have continued investigating your issue now I am back in the office, with my LabVIEW machine and NI resources. I have concluded and also since found some confirmation of this issue. 

For a top-level VI that has some express VIs on its block diagram, the Callee's Names property currently includes one instance of the top-level VI for each express VI.
For example if a VI has two ExpressVIs on its block diagram. The Callees property node will return two instances of the toplevel VI.

Top-level VI = mainVI.vi

Express VI =  Time Delay

Result from Callee's Name:  mainVI:Instance0 (number enumerates based on the order Express VIs are dropped on the diagram. 

                                              :  top-level VI name:InstanceX

The issue with this is if your going to use VI Server that this name isn't valid - and will cause a VI Server Error. So I believe it would be safe enough to filter out these names.

Please let me know what you think, 

[ejb068]

Thanks! That would make sense and I checked the VI was calling an express VI. It would be easy to filter then out, but I want to be sure there aren't other circumstances that would produce the instance:x? Would you know that express vis are the only cause of the instance:x?

Thanks very much. You've been very helpful and extremely quick with you responses.

Thanks,

James 

[Hillman]

Hi ejb068,

Thanks for your kind words and your prompt reply. I hope your well this afternoon. 

I have also tested reentrant VIs, which didnt cause this issue. All my other research only suggested Express VIs are the only cause of this. Logically, I cant think of anything within LabVIEW that would cause a similar results to the Express VIs, be it, that the Express VIs are subVI but they are 'special'. Hence the wierd string result for them.

So I cant be 100% sure, but the current research and findings seem fairly reassuring.

Can I ask why you need this information? I assume your using VI Server...

Thanks,  

[ejb068]

Hi,

We are building a "bundling" feature that looks at all the VIs associated with a program, and then moves all the necessary files into searchable directories. This is useful for two reasons, 1) to clean up a program so all VIs needed are in a known location and not scattered across your hard-drive, and 2) these programs are called dynamically from high-level GUI interface and when deployed as an exe all sub-vis need to be in the vi searchable path, because we can't define these programs as dynamicallly called at the time of building the exe.

Thanks for you help!

-James