From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Static VI Reference

Solved!
Go to solution

I'm dynamically calling a VI so I used the call by reference and dragged the VI into it, the question is if I have to use the open VI reference or not because I ran the Main VI twice, using the open VI reference wiring the call by refence and the path of the VI and the second time I omitted the open VI reference and I just used the Call by reference and it worked exactly the same as the first time.

The other question is what happen if I close de reference of the VI once I open the front panel  and run the VI with a property node

 

Download All
0 Kudos
Message 1 of 5
(9,002 Views)

You have a Static VI Reference, so there is no need to open the reference again. You already have one. In your example, you have the Static VI Reference wired to the type specifier input. This is mostly useful if you need a strict VI reference, like if you were going to use the Call by Reference or Start Asynchronous functions.

 

As it is, as soon as you load your calling block diagram, LabVIEW is loading the "Admin" VI too - because it is a static reference. This reference will not be closed until the calling VI is dismissed from memory, so in your example, the Close Reference on the VI ref is a no-op.

 

If you are truly wanting to load the "Admin" VI dynamically and do exactly what you're doing here, delete the static VI reference. You don't need it to do what you are doing there. If your ultimate goal is to use the Call by Reference or Start Async, then you'll need to create a type specifier or a strictly typed VI reference in order to tell the function node how to populate.

 

Any time you use a static VI reference, strictly-typed or not, the VI that it is pointing to is loaded into memory as soon as the parent VI is loaded into memory. If you use a Type Specifier VI refnum (see image below), it only loads the basic connector pane data, and not the VI itself. In that case, the VI would only be loaded at run-time. I've attached a little example below. It loads all VIs in memory and displays those in a list. As you can see, in the first example, "Dummy VI" is not yet loaded. In the second example it is loaded as soon as the VI starts. (Note that since I didn't wire a valid path in to the Open VI ref, you will get an error, but it is irrelevant to the demo.)

 

Reference Demo 1.png

 

Reference Demo 2.png

Wes Pierce
Principal Engineer
Pierce Controls
Download All
Message 2 of 5
(8,992 Views)

So, Am I not calling the "Admin" dynamically? Inside of my main VI I have an event structure so when I click on the administrator button it executes the case where I'm calling the "Admin" VI, when I run the Main VI Am I loading the Admin VI too? or it is loaded until the event is triggered. I'm a little confused about when I have to use de Open VI Reference, as you said if I want to use the call by reference it is useful wire the strictly typed reference to the open VI reference but it isn't necessary, is it? becasue I wire the strictly typed reference to the call by reference and it worked well.

0 Kudos
Message 3 of 5
(8,978 Views)
Solution
Accepted by topic author givanps

Good questions. The way you have it now, in the snippets you provided, Admin is loaded at the same time that Main is loaded. You are not loading it dynamically. You are calling it dynamically in the sense that you are using VI Server to do it as opposed to a subVI. In other words, Admin comes into memory as soon as Main comes into memory. Admin does not begin running when Main begins running though.

 

The only difference between doing it the way you have it and using a subVI is that with a subVI, Admin would be reserved as soon as Main started running. The way you have it, Admin is not reserved or running until it is called, but it is loaded into memory.

 

The reason Open VI Reference isn't doing anything for you right now, is because the reference is already open. The reason you would call the Open VI reference is to get a reference that you don't already have, based on a file path. But since you have a static VI reference, you already have the reference open, so Open VI Reference isn't giving you anything you don't already have.

 

If you want to use the Call by Reference node, you must have a type specifier wired to the type specifer input of Open VI Reference. A type specifier is a special type of VI Reference that is only concerned with connector pane information, but not witih any particular VI. Any VI with the same connector pane could be opened that way. Thus, you would need to use Open VI Reference to get a VI Reference pointing to a particular VI, given by the file path.

 



if I want to use the call by reference it is useful wire the strictly typed reference to the open VI reference but it isn't necessary, is it? becasue I wire the strictly typed reference to the call by reference and it worked well.

There are two main ways to call a VI dynamically. The first is the way that you have done it - using the Run VI Method. This does not require a strictly typed VI reference. The second main way is by using the Call by Reference Node. The Call by Reference Node is different, because it uses the connector pane information to pass arguments in and out of the VI. For this, you must have a strictly-typed VI reference. It doesn't have to be a static reference though - the output of the Open VI Reference is strictly typed if you pass in a type specifier as an input.

 

You could think of a VI Reference containing some or all of the following information: path to the VI, connector pane info. Thus,

 

Weakly-Typed VI Reference - Path to VI

Type Specifier - Connector Pane Info

Strictly-Typed VI Reference - Path and Connector Pane Info

 

Call by Ref 2.pngCall by Ref.png

 

I hope this helps!

Wes Pierce
Principal Engineer
Pierce Controls
Message 4 of 5
(8,966 Views)

Thanks a lot, it was an excellent explanation.

 

0 Kudos
Message 5 of 5
(8,924 Views)