LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

How to get for a VI instance its own SubVI Refnum

Solved!
Go to solution

You say you want to determine the reference while running, and then use it later in another VI when it is not running.  I really don't know whether that would work or not.  It could be very risky.  Something tells me that a reference number that may be generated while a VI is running may no longer be valid when the VI is in a different execution state.  So trying to use a reference later in a different VI may mean the reference is no longer valid, or it may by chance refer to a different object.

 

I do not agree. If the behavior was the one you are afraid of, then scripting could just not work. Since Scripting is done on VIs who don't run.
Also I've made tests, and the references are still valid after execution, and it's logic. IMHO.


Scripting works because it uses references that are calculated and then used in the same memory state.  If you run a VI with scripting and get a reference to an  object, then stop the V, then run the VI again, the reference you get the second time around may not be the same value even though you are referring to the same object. The reference from the first time the VI was run will be meaningless the 2nd time the VI is run.

 

I'll tell you another reason why I don't think you'll be able to get what you want.  There is a difference between a block diagram and the compiled code that LabVIEW actually runs.  The block diagram is the human representation of what you want to run.  LabVIEW takes that diagram and compiles it into machine code that it actually executes on your PC.  You can't take a set of compiled code and decompile it to get back to the original block diagram.  A lot of information is lost in the compiling process.  If you decompiled, you could come up with several different block diagrams that could all compile to the same code.  The compiled code no longer cares about what the block diagram originally looked like.  It doesn't care whether the subVI functions are from the first instance of the subVI block or the 5th instance of the subVI block.

0 Kudos
Message 11 of 23
(1,009 Views)

What you say is true when you close LabVIEW, but not in a single LabVIEW session...
Anyway, actually it works like this (and since LV6i, yes I use scripting since LV 6i) so I have good hopes that it will continue...
By the way, this is not the purpose of my problem... 🙂



0 Kudos
Message 12 of 23
(1,003 Views)

To follow the discussion (by the way, thank you for your interest), with the following code (just add an input to my famous VI), I can achieve what I want. Except that, for some reasons, I don't want to add any input to my SubVI. 😞


example 2.JPG

0 Kudos
Message 13 of 23
(993 Views)

Good luck with your application.  I hope you are able to figure out the way to make it work like you want.

Message 14 of 23
(988 Views)

I've tried to manage some thing using the property "execution order" or "firing order" (sorry mine is in French so I just imagine the name of the property in english) from the diagram of the VI containing my subVIs, but unfortunately this property gave me back an empty array !!! 😞 😞 😞

0 Kudos
Message 15 of 23
(984 Views)

RavensFan, for sure, if I can manage this correctly, I'll show you the final result... 😉

0 Kudos
Message 16 of 23
(982 Views)

There seems to be some confusion here between what a subVI is and what a VI is as implemented by VI server.  In practice, a subVI is a link between the block diagram and a VI.  That VI could be normal, a reentrant clone, etc.  To VI server, SubVIs do not exist except on block diagrams.  VIs exist in memory, but not on block diagrams.  SubVIs "tell" the execution system what VI to call at a given point in the code. While this explanation is overly simplistic and probably not technically correct, it does provide a working model to overcome some of the problems with using the term "subVI" in several different ways.

 

If you want to find the dependency tree of a set of VIs at runtime, you can use the VI method Get VI Dependencies (Names and Paths) and/or the VI property Callers Names.  This allows you to go up and down the dependency tree, although probably not exactly as you would like to do it.

0 Kudos
Message 17 of 23
(940 Views)

Definitively no confusions...
In deed, in 90% of cases I can achieve what I want : getting THE corresponding of THE considered subVI through the array of subVIs references.

I would have prefered 100 %...
Anyway, it seems that getting 100 % is impossible.
It could have been possible using the "Execution Highlight Object" property but unfortunately this property return an empty array when the main VI containing the SubVIs is running... 😞

0 Kudos
Message 18 of 23
(922 Views)

My first thought was that you could give the subvis different labels, but I see that you can't modify a subvi instance label.  I don't know your app, but if it doesn't need to be general-purpose, can you arrange the subvis in a line or column and sort the references by their block diagram positions?

0 Kudos
Message 19 of 23
(898 Views)

@jdunham wrote:

My first thought was that you could give the subvis different labels, but I see that you can't modify a subvi instance label.  I


 

 

Who says you can't change the label of SubVI instances?  Go to Right Click, Properties.

0 Kudos
Message 20 of 23
(894 Views)