LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

How to pass a graph to another vi without stripping off the properties????

Can I ask one question?  Are you a "seasoned" text-based programmer?

Just curious 😉

Message 11 of 21
(1,981 Views)
I guess I'm seasoned but a bit rusty,  My experience goes back to the early '80's, programming in FORTRAN and basic, then about 15 years of programming in MATLAB and C, and more recently in C++, CORBA and Java.  Each of these have there own specialized jargon, and I find that I'm always mixing myself (as well as others) up by borrowing and sometimes misusing terms from one of the many languages I've programmed in.

I've been trying to get my mind around LV for the last year and find that I often reach a point where I feel quite clueless, but I'm starting to catch on.  LabView's "rich" command (tool?) set, and sometime tortured abstractions have presented a challenge though.
LV 8.6 on Windoze XP
Message 12 of 21
(1,981 Views)

LOL!!  😄  You've answered my question.  And are probably on the right track... 😉

I didn't realize it, but we all seem to try to program Labview as if it was a text based language..  But it's not.  The approach is (how to say this) "completely" different..  Although "completely" is a bit harsh.. 

You have to think in terms of dataflow.  And the variable is the wire.  Forget all you know about Globals & Locals, which were your friends and are now your enemy.  Forget about the sequence (and especially the Sequence Structures (Stacked) ).  The execution is based on available data.  The flow is based on data availability on the wire.  Any portion of code will execute as soon as all the data it requires (to execute) is available.  So race conditions become an important issue.

A good place to see a lot of common mistakes is to visit the Rube Goldberg thread  in the Breakpoint forum..  but don't forget to laugh... we've all been there.. 😄

 

Message 13 of 21
(1,965 Views)

@JoeLabView wrote:

 but don't forget to laugh... we've all been there.. 😄

Oh, how I wish that weren't so true, me included! The number of times I've looked at my own code and said "What the heck was I thinking?!?!?!" Smiley Very Happy
Message 14 of 21
(1,956 Views)

As mentioned, the key here is the difference between the data and the control - since controls and indicators can also double as function parameters and return values, this might be a bit confusing.

First, it is important to understand that a wire passes only data of its type - it has no meta data which relates to the control it came from (that's not actually correct, but we won't go into that), so you can wire any two controls and indicators as long as their data types are compatible.

As for your questions:

All front panel objects must be allocated in the vi that owns the front panel and they only exist in that panel. 

That's essentially correct, but the only thing you need to do to "allocate" them is to drop them on the front panel. When they have data put into them and you change the values of their properties, they will need more area in memory to hold that, but LabVIEW takes care of that behind the scenes.

Objects that are "passed" as indicators(outputs) of the parent into the control (input) of the subvi(child)  are  not pointers but cause a memcopy into a new instance of the object. 

In LabVIEW, the control itself is an object, but the data that comes out of it is separate from the control itself. LabVIEW tries to schedule the execution of the code so that it will have a single copy of any piece of data in memory, but that's not always possible. A reference is a pointer to an existing object. When you use a reference of a certain control class as an input to a subVI, the reference needs to point to an actual existing control. If it does not, any property or invoke node will return an error telling you that you are trying to work on an object which does not exist.
That was kind of stream of consciousness, so feel free to ask for more specific details. If you want, this article explains this in some more detail.

___________________
Try to take over the world!
Message 15 of 21
(1,951 Views)
So, the bottom line is that an object, comprised of three kinds of data - 1.properties, 2. methods and 3. wirable data (which is also available as a property)  can only exist in the context of it's owning vi front panel.  References may be passed to sub or super vi's where the properties and methods may be manipulated, but, the object can only have one frontpanel control/indicator. 

Is there a way to clone an object in another programming unit (vi) that inherits all of the properties of the object pointed to by a reference to an object that resides in another vi?

Am I right to think that there is no difference between a control and indicator object other than it's read or writability?

 
LV 8.6 on Windoze XP
0 Kudos
Message 16 of 21
(1,946 Views)
Thanks tst for the very elegant description. 
 
Clueless...  humm..  there's no short answer.. becuase you can talk above native LV objects and then external objects that can be accessed and or manipulated within LV, such as MS Active-X. 
 
Basically, a control reference is a reference to a specific front panel object, which allows to access the property of Front Panel objects (controls or indicators) of a sub-VI.
 
However, nothing prevents you from using a control reference within the same VI where the control resides..  As for cloning... Well... that's another can of worms..  😉  I only have 1 minute to reply to this, and explaining "clones" would be rather lengthy (subroutines, VIT, etc..)
 
 
Message 17 of 21
(1,936 Views)


Clueless1 wrote:
So, the bottom line is that an object, comprised of three kinds of data - 1.properties, 2. methods and 3. wirable data (which is also available as a property)  can only exist in the context of it's owning vi front panel. 

That's correct, as long as you replace "an object" with "an object of the Control class or any of its inherited classes". As Ray mentioned, the property and invoke nodes are also used for accessing other class hierarchies.
 
The short answer is that there is no built in way to copy a control from one VI to another, other than copying it after it has been set the way you want it. That said, there are ways of accessing the same controls in different VIs. One example would be XControls, which are custom controls which have code behind them. Another would be using subpanels, which allow you to access the GUI of a single VI in more than one place. Another (which JLV mentioned) is using VI templates. Another would be using a subVI to set the properties of the control and calling it in both VIs, etc.
 
The best way depends on the application.

___________________
Try to take over the world!
Message 18 of 21
(1,930 Views)


tst wrote:
...One example would be XControls, which are custom controls which have code behind them. Another would be using subpanels, .... Another (which JLV mentioned) is using VI templates. Another would be using a subVI to set the properties of the control and calling it in both VIs, etc.

You can also get an image of the graph and then draw it in a picture indicator. Would look the same. (But you cannot interact with it in the same way, of course)
Message 19 of 21
(1,927 Views)


You can also get an image of the graph and then draw it in a picture indicator. Would look the same. (But you cannot interact with it in the same way, of course)


Well, this would solve the problem i just encountered whereby you cannot have an array of graphs.  I assume it would be OK to have an array of pictures of graphs.  Yes?

LV 8.6 on Windoze XP
0 Kudos
Message 20 of 21
(1,913 Views)