LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Getting Calling VIs "Refnum" or "File Path"

Is there a way for a sub-VI to get either the calling VIs "refnum" or "file path" without having to input one of the two from the calling VI?

It seems like this information should be available, but all I've been able to get is either the calling VIs name or the call chain, neither of which helps me get the calling VIs refnum or file path.
0 Kudos
Message 1 of 8
(4,355 Views)
Use the "Call Chain" VI and wire 1 into it. I think it's located in the app control palette, but I'm not near a PC with LV at the moment.

___________________
Try to take over the world!
Message 2 of 8
(4,346 Views)
The "Call Chain" VI is under "Application Control" but I do not understand your reply.

"Call Chain" has no inputs. It returns the names of the VI from lowest level called to highest level called.

I need the VI file path of the calling VI, which would be the VI named in the second element, index 1, of the Call Chain.

I'd like to get the calling VIs file path without having to input it from the calling VI or input the calling VIs "Refnum".

The reason I want the file path for the VI is because there can be more than one VI of the same name under different file paths which are different VIs, probably different due to old version versus new version.

The reason I want the file path of the calling VI without inputting it from the calling VI is to simplify the use of the called VI. If the calling VIs file path or refnum must be input into the called VI, then every time the called VI gets used in the wiring diagram of another VI, added code would be required, either adding a "Current VI's Path" function or opening up a VI refnum.
0 Kudos
Message 3 of 8
(4,339 Views)
The attached code should help you out. But don't credit me with the solution, I'm not that sharp. I found it here. It also lists a number of caveats that my code would never be able to handle.

Tim
0 Kudos
Message 4 of 8
(4,325 Views)
Unfortunately I only have LabVIEW version 6.0/6i, so I can't open that example.

To give a better idea of what I am trying to do, consider this.

There are two VIs which are exactly the same, except for version changes. Unfortunately, the version changes can cause a serious error if the older version is used.

The paths to the VIs is as follows.

\\QDI_0031\C:\Projects\QDI3752\Eye Pattern Analysis\CSA7404B Main.vi

\\QDI_0000\C:\Backup 2005.03.04\Projects\QDI3752\Eye Pattern Analysis\CSA7404B Main.vi

The subVI I want to get the calling VIs file path from is an error catching VI which, when an error occurs uses a "Call By Reference Node" to launch the larger portion of code which collects information, generates an error report and logs the error report. This subVI would be used in many locations within a projects code. If the calling VI must use "Current VI's Path" and input it into this subVI it adds the hassle of having to repeatedly do this every time the subVI is used and allows the possibility the programmer using it could wire in the wrong path, which one would think would not happen, but it can.

Maybe you have not had such problems as mixing of older version VIs with newer ones, but if you did, an error catching routine that includes the file path to the VI the error was generated in might very quickly point out what the error is.

Here is an example of how this error has occured.

On one computer linked to others on a LAN, one programmer opens an older version VI to look at it for whatever reason. Then, while looking at it, the programmer opens some newer code that has the same VI in it. If no broken wire is generated, the programmer may not realize what they are doing.

Then, the programmer closes older VI, which just close. But when the programmer closes the newer VI is asks whether to save changes. This can happen even when no change has occured except that the VI was opened on a different computer within the network. If the programmer saves the changes, then the path to the older VI would now be used.

I'm not sure I explained that clearly, but it is a big hassle when it happens, particularly when you don't know it happened but must figure it out because some project that was working fine suddenly stops working correctly when no changes were made to it.
0 Kudos
Message 5 of 8
(4,319 Views)
Hi JOP,

tst pointed you in the correct direction.

Attached you will find a jpg and a zip of what SHOULD (Sorry oldest I have on this machine is LV 6.1) be a LV 6.0 version.

You start with the call chain that, as you said, returns an array of VI names odered from current VI through the top level VI.

Index element "1" for the current callers name.

This can be passed to the "Open VI Reference" via the VI path control.

You can get away with just passing the name because LV limits only one VI of a name to be loaded into memory at a time. I believe if you specified a full path other than the path from which the named VI was actually loaded, the bad path would just be ignored (please verify this yourself. I am going from memory.)

The returned reference can then be passed to a property node configured to return the "VI Path". (Ignore the other property, VIType, I over-looked that until I looked back).

Done!

I hope this helps,

Ben

Message Edited by Ben on 06-18-2005 09:54 AM

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
Download All
0 Kudos
Message 6 of 8
(4,316 Views)
Thanks to all of you. That worked.

The input for "vi path" into the "Open VI Reference" is typed as a path. I would never have thought I could just take the VI name change it's type to a path and input it to get the same result as inputting the acutal path.

If not for your telling me I could do it, I don't think I would ever have tried it.

PS: I wish I had a higher version of LabVIEW, but until finances change, 6i is the version I'll be using.
0 Kudos
Message 7 of 8
(4,302 Views)
Sorry about that. I meant the answer Ben gave you. I didn't see you mentioned the call chain in your question and I though you knew how to get a VI's path dynamically because you said you could pass it to the subVI (I'm assuming now that you used the Current VI's Path constant). Plus, I wasn't near LV that time.

___________________
Try to take over the world!
Message 8 of 8
(4,294 Views)