01-05-2014 01:18 PM - edited 01-05-2014 01:26 PM
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.
01-05-2014 01:23 PM - edited 01-05-2014 01:36 PM
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... 🙂
01-05-2014 01:39 PM
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. 😞
01-05-2014 01:44 PM
Good luck with your application. I hope you are able to figure out the way to make it work like you want.
01-05-2014 01:47 PM
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 !!! 😞 😞 😞
01-05-2014 01:48 PM
RavensFan, for sure, if I can manage this correctly, I'll show you the final result... 😉
01-06-2014 12:05 PM
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.
01-07-2014 04:01 AM - edited 01-07-2014 04:26 AM
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... 😞
01-07-2014 11:15 AM
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?
01-07-2014 11:20 AM
@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.