Control references and XY graph

hi there,
I was wondering if somebody can help me with passing data to a " XY graph
" not waveform graph [ in a main VI ]
from a sub vI using the concept of a control reference..
p.s: I dont intend to flatten data .
It works fine with waveform graph but there is nothing to show ( even
examples ) me how to do it with XY
graph.
thanks.
ananth

In the example, why is the control reference outside the case statement, since the graph
is only updated when plot=true the ref belongs inside or did I miss something?.
ananth wrote:
> thanks
> and you said it right. that was the problem.
>
> "John Lum" wrote:
> >>>I was wondering if somebody can help me>>with passing data to a " XY
> graph" not>>waveform graph [ in a main VI ] >>from a sub vI using the concept
> of a>>control reference.. >>I don't see any problems here using LabVIEW 6.0,
> and I'm wondering if you're>having trouble with a Variant input or something.>>Here's
> an example of a subVI that spits data into a main VI's XY Graph by>way of
> a control reference>ftp://ftp.ni.com/incoming/xy.zip>>Regards,>John Lum>Na
tional
> Instruments

Similar Messages

Can you use a control reference for a graph with two channels of data?

when i try to wire a 2-D array of data to the value property of a graph(strict control reference), it shows a conflict. The value data type only shows up as accepting a 1-D array input. I want to use control references to pass the chart data to my main vi. Will I have to change the waveform graph control reference into an array control reference to make this work?? This would require adding a while loop in the main vi to read the array data and update the graph data??

> when i try to wire a 2-D array of data to the value property of a
> graph(strict control reference), it shows a conflict. The value data
> type only shows up as accepting a 1-D array input. I want to use
> control references to pass the chart data to my main vi. Will I have
> to change the waveform graph control reference into an array control
> reference to make this work?? This would require adding a while loop
> in the main vi to read the array data and update the graph data??
I think the problem is that your waveform graph is set to take one type,
a 1D array of doubles, and you are wiring a different type. While
charts adapt to type when the data is wired to their terminal, they do
not adapt to data wired to their value property. If you change the
datatype of the graph from its terminal, then you should see the value
property change type also and you are set.
Greg McKaskle

Control references and sequence structures

My supervisor and I were discussing one of his programs, and he asked
me if I knew why he kept getting "Object reference is invalid" on a
property node that was using a reference. I couldn't figure it
out either, and eventually I said to try moving the actual control
itself (on the block diagram), into the first pane of the sequence
structure, and just feed the wire through.
This solved all of our problems... however both of us were
stumped with why what I suggested actually made it work. Anyone
know why this is?
Oops... I just realized that I made this on the breakpoint board
instead of the LabVIEW board...sorry. Although I suppose that the
people who frequent this might be the best to answer this...
Message Edited by Novatron on 07-14-2005 05:24 PM

There should be no difference between the two code versions IF you adhere to proper dataflow.
(Of course it is conceivable that the program is a mess and there is a race condition, e.g. if the reference is initially invalid and you set it elsewhere in the code via e.g. a local variable of the reference. In this case, a subtle change (e.g. the sequence structure) can rearrange the execution order for it to suddenly work by accident.)
I would be very curious to see a working example that demonstrates your described behavior.
LabVIEW Champion . Do more with less code and in less time .

Control references vs. global variables

I guess my question centers on the appropriate application of control references.
I am writing a complex program that has a state machine at the top level, and, for one frame of the state machine, a while loop containing a couple subVIs, each of which contains many subVIs. The lower-level subVIs are affected by buttons on the top-level VI. Information from the lower-level VIs must be shown on the top-level front panel within the loop. My question is: what is the best way to do this?
(I have a previous version of the program that I wrote that keeps just about everything on the top level so that I can update the front panel, but this is not at all modular.
In addition, I considered breaking things up into more than on
e front panel, but this doesn't seem to be a good option for this section of this program.)
Last week I read about control references, and decided that this could be the way to deal with this issue. I have not worked with them before, so I want to know: Are control references an appropriate solution for this issue? Is it good programming practice to use them, especially to update data on charts and graphs? How do they compare programming-wise and efficiency-wise to global variables?
Global variables are another solution, I think, but I would have way too many variables to update. I think the advantage with global variables is that one could just insert a global variable in a subVI and not have to wire it up through the different subVI levels, which one would have to do (I think) with control references.
Can you offer any advice?
Thanks!

Paul,
The actual implementation of the solution is up to you. This is indeed a complex question.
I would offer the following advice:
On globals:
Try to avoid them. I try to restrict the use of globals to unidirectional. If you have ever dealt with a race condition, you will know why. Mistakes are often made with globals, and they are quite apt to become the biggest source of bugs in a program, especially in one as large and/or complex as your appears to be. If you must use globals, try using a shift register, or LabVIEW 2 style global instead. Basically, you use an unitialized shift register with two (or more) cases: Read and Write. This prevents race conditions, but only if the VI is non reentrant. However, implementation is still difficult.
Control References:
I also have read and heard about control references. I have had much use for them, for controlling the appearance of controls and indicators (and decoratiopns too, I guess...). However, I would caution you on using them to pass data around. This violates dataflow in a big way, as you are passing around pointers, instead of data. I believe this is difficult to implement, and even more difficult to keep straight. I personally recommend using them only for attributes of FP components, not for passing data.
So, what do I believe is the most elegant solution? I think a data server is your best bet. This is close to a LabVIEW 2 style global, but a little more active. Simply write all of your data into a subVI in any manner, a queue, a FIFO, LIFO, etc. Then, retrieve the data as desired. Buffering, queuing, etc are all handled by the data storage and retrieval subVI. It becomes sort of a small active database. The two sides (storage and retrieval) are independent of each other, and the code is all handled in the function. A basic version is a LIFO, Last In First Out, wherein the data is overwritten constantly. The data is then read by the reading VI, the front panel VI in your case, at any time, and the data is always the latest. You can add complexity as you need, such as making it a FIFO. This is done by simply writing the data to an array, then reading back the oldest value (by reversing the array and reading index 0.)
I believe this is an elegant solution to your problem. It does maintain dataflow, except that time is taken out of the equation, depending on how you look at it. It simplifies your program because you only need to do three things. Write the data handler, then drop in the function into the VI that writes, and the one that reads. It is also flexible in handling the data.
Good luck, and let us all know how you do.

In-Place Element Structures, References and Pointers, Compiler Optimization, and General Stupidity

[The title of this forum is "Labview Ideas". Although this is NOT a direct suggestion for a change or addition to Labview, it seems appropriate to me to post it in this forum.]
In-Place Element Structures, References and Pointers, Compiler Optimization, and General Stupidity
I'd like to see NI actually start a round-table discussion about VI references, Data Value references, local variables, compiler optimizations, etc. I'm a C programmer; I'm used to pointers. They are simple, functional, and well defined. If you know the data type of an object and have a pointer to it, you have the object. I am used to compilers that optimize without the user having to go to weird lengths to arrange it.
The 'reference' you get when you right click and "Create Reference" on a control or indicator seems to be merely a shorthand read/write version of the Value property that can't be wired into a flow-of-control (like the error wire) and so causes synchronization issues and race conditions. I try not to use local variables.
I use references a lot like C pointers; I pass items to SubVIs using references. But the use of references (as compared to C pointers) is really limited, and the implementation is insconsistent, not factorial in capabilites, and buggy. For instance, why can you pass an array by reference and NOT be able to determine the size of the array EXCEPT by dereferencing it and using the "Size Array" VI? I can even get references for all array elements; but I don't know how many there are...! Since arrays are represented internally in Labview as handles, and consist of basically a C-style pointer to the data, and array sizing information, why is the array handle opaque? Why doesn't the reference include operators to look at the referenced handle without instantiating a copy of the array? Why isn't there a "Size Array From Reference" VI in the library that doesn't instantiate a copy of the array locally, but just looks at the array handle?
Data Value references seem to have been invented solely for the "In-Place Element Structure". Having to write the code to obtain the Data Value Reference before using the In-Place Element Structure simply points out how different a Labview reference is from a C pointer. The Labview help page for Data Value References simply says "Creates a reference to data that you can use to transfer and access the data in a serialized way.". I've had programmers ask me if this means that the data must be accessed sequentially (serially)...!!! What exactly does that mean? For those of use who can read between the lines, it means that Labview obtains a semaphore protecting the data references so that only one thread can modify it at a time. Is that the only reason for Data Value References? To provide something that implements the semaphore???
The In-Place Element Structure talks about minimizing copying of data and compiler optimization. Those kind of optimizations are built in to the compiler in virtually every other language... with no special 'construct' needing to be placed around the code to identify that it can be performed without a local copy. Are you telling me that the Labview compiler is so stupid that it can't identify certain code threads as needing to be single-threaded when optimizing? That the USER has to wrap the code in semaphores before the compiler can figure out it should optimize??? That the compiler cannot implement single threading of parts of the user's code to improve execution efficiency?
Instead of depending on the user base to send in suggestions one-at-a-time it would be nice if NI would actually host discussions aimed at coming up with a coherent and comprehensive way to handle pointers/references/optimization etc. One of the reasons Labview is so scattered is because individual ideas are evaluated and included without any group discussion about the total environment. How about a MODERATED group, available by invitation only (based on NI interactions with users in person, via support, and on the web) to try and get discussions about Labview evolution going?
Based solely on the number of Labview bugs I've encountered and reported, I'd guess this has never been done, with the user community, or within NI itself.....

Here are some articles that can help provide some insights into LabVIEW programming and the LabVIEW compiler. They are both interesting and recommended reading for all intermediate-to-advanced LabVIEW programmers.
NI LabVIEW Compiler: Under the Hood
VI Memory Usage
The second article is a little out-of-date, as it doesn't discuss some of the newer technologies available such as the In-Place Element Structure you were referring to. However, many of the general concepts still apply. Some general notes from your post:
1. I think part of your confusion is that you are trying to use control references and local variables like you would use variables in a C program. This is not a good analogy. Control references are references to user interface controls, and should almost always be used to control the behavior and appearance of those controls, not to store or transmit data like a pointer. LabVIEW is a dataflow language. Data is intended to be stored or transmitted through wires in most cases, not in references. It is admittedly difficult to make this transition for some text-based programmers. Programming efficiently in LabVIEW sometimes requires a different mindset.
2. The LabVIEW compiler, while by no means perfect, is a complicated, feature-rich set of machinery that includes a large and growing set of optimizations. Many of these are described in the first link I posted. This includes optimizations you'd find in many programming environments, such as dead code elimination, inlining, and constant folding. One optimization in particular is called inplaceness, which is where LabVIEW determines when buffers can be reused. Contrary to your statement, the In-Place Element Structure is not always required for this optimization to take place. There are many circumstances (dating back years before the IPE structure) where LabVIEW can determine inplaceness and reuse buffers. The IPE structure simply helps users enforce inplaceness in some situations where it's not clear enough on the diagram for the LabVIEW compiler to make that determination.
The more you learn about programming in LabVIEW, the more you realize that inplaceness itself is the closest analogy to pointers in C, not control references or data references or other such things. Those features have their place, but core, fundamental LabVIEW programming does not require them.
Jarrod S.
National Instruments

Data acquisition with control references

I'm a new LabView user and I would like to acquire data in a subVI and display that data in the main VI. I think that I need to use control references and refnums, but I just haven't been able to figure it out. I would GREATLY appreciate any help I could get.
Thank you!

From your description I would guess that the "subVI" has a loop in it that repeatedly reads the FP hardware, and the indicator is inside the loop. Right?
The thing to do is move a lot of the logic in the subVI up to the Main VI--or add the Main's added logic to the subVI, whichever is easier. In the first case, the subVI would go away, in the second, the subVI would become the Main VI.
If you're confused, post your code in V6.0 format and I'll show you what I mean.
Mike...
Certified Professional Instructor
Certified LabVIEW Architect
LabVIEW Champion
"... after all, He's not a tame lion..."
Be thinking ahead and mark your dance card for NI Week 2015 now: TS 6139 - Object Oriented First Steps

Getting control references which are in tabs

Hello,
In a labview vi, we can successfully get all the control references, including references to tab controls. We would also like to get at the control references of controls which are contained within the tabs. We've been hunting around the methods/properties of the vi pane references (where we found the controls[]) reference, and can't seem to find how to access the control references within tabs. Does anyone know the method/property to do this?
Thanks
David Jenkinson

The Pages property will return a 1D array of references to each page. Then you can autoindex this to get the controls for each page reference:

Difference control refnum and control reference

Hi guys.
I am new on labview reference, can you explain difference between control refnum and control reference.
Gary Wang

Are you sure you don't mean "refnum control"? That is a front panel control that can be selected as a reference to any one of several data types such as application, VI (including strictly typed), control or indicator. Whereas the "control reference" is a block diagram object that points to a specific control on your front panel (it can also be "linked" to other objects so it is similar to a "refnum control" in that respect).
“A child of five could understand this. Send someone to fetch a child of five.”
― Groucho Marx

Control references/refnums: general info

Please forgive this question, I am a relatively new LV programmer and the help files & manual seem quite poor to me!
I am after some basic information about control references & refnums as I am sure they would be of help to me.
1. What are the main advantages in using them? (i.e. what they can achieve)
2. How are they implemented?
3. How is a control refnum/reference passed from one VI to another programmatically?
Huge thanks to anyone who may be able to shed some light on this topic.
Dan

> 1. What are the main advantages in using them? (i.e. what they can
> achieve)
The references let you access properties and methods of controls on a
front panel. Previously, the access was limited to the diagram of that
panel, and each property node accessed a single particular control.
With control refnums, you can have one property node access an arbitrary
control with the refnum parameter controlling which one. You can also
send the refnums to subVIs meaning that the code can be abstracted to
simpolify your diagram and shared with other panels.
> 2. How are they implemented?
I assume you want to know how to use them. You right click on the
control or its terminal and under the create menu, next to where you can
create an implicit property node, you can also create a Reference node.
The datatype of this node is unique to the type of control that you
created it from, and when wired to a property node, the property node
will show the same properties as an implicit one. As an example, if you
have 8 Boolean buttons on your panel that need to be enabled, disabled,
hidden, colored, labeled, or whatever based upon the state of your
application. You can right click on the eight buttons creating
Reference nodes and build an array of the references. You can now loop
through your array and with one property node, set the properties of the
buttons based upon whatever logic or table of information that you need.
You can also do this in a subVI by passing the array of references to
the subVI.
It is also possible to get control refnums/references from other
properties. For example, a slider will give the reference to its
digital display, a graph will give references to its cursors, etc. It
is also possible to loop through the references of all objects on the
panel inspecting names or types rather than using the Create Reference
popup, but this is more advanced and requires casting the references.
If you really want to know how they are implemented, it is much like
file refnums or VISA refnums. I can give more info if you ask a more
specific question.
> 3. How is a control refnum/reference passed from one VI to another
> programmatically?
>
In the refnum palette there is a Control/VI refnum control. You drop it
on your subVI and right click to set the class. Note that there are
lots of classes arranged from basic to very specific. Class refnums
will convert to more basic automatically, but will not wire if they are
incompatible. So, if you are careful, you can select the class from the
menu and create the control refnum that you can wire to the connector
pane allowing you to pass refnums into the VI. A shortcut that is a bit
simpler is to draw the reference from the diagram to the subVI panel.
It will make the correctly typed control refnum for you, ready to wire
to the connector pane.
That is sort of the basic overview. You probably want to look at the
example -- general/cntrlref.llb/Property Nodes.vi. I also suspect that
the devzone contains other examples showing how they can be used.

Advanced ?? Control Reference Update - Too slow.

I have a main VI which controls a bunch of SubVIs. Each of these subVIs
get data from the DAq and generate the plots and intensity graphs. I
use a control reference to display these plots and graphs on my main
VI. This is really slow. When I compare the speed at which the main VI
is updated and the subVI is updated, there is a significant difference.
Is this usually the case or am i missing something ?
Thx
Kudos always welcome for helpful posts

I agree with tst, your PP VI runs at unlimited speed for no good reason. You should pace it with a small delay so it will release the control to other processes after each iteration.
Also your DAQ part seems inefficient. Why do you configure the DAQ task from scratch, acquire, and close at every iteration? This is way too much work. You should flatten this out to the PP vi. Configure outside the loop on the left and close outside the loop on the right. Place only the ACQ part inside the loop.
Also, place the real terminal of the graph inside the loop and clear it once at the beginning using a local variable. A local variable is always more expensive and less efficient.
I don't understand why you need a timeout event in the main VI, it does not do anything except spin the loop, right? Just delete the timeout event.
LabVIEW Champion . Do more with less code and in less time .

Get All Controls References

Hi all
If somebody know how can i get all controls references of VI (including controls that founds in Tabs and Clusters). I need generic method, because i haven't information about VI (reference to VI i get only at run-time).
Thanks, Nadav

To include the controls on Tabs, pass the array from my previous answer into a for loop, use auto-indexing. Place a Class Specifier Constant in the loop, right click on it and set it's type to a Tab Control. Place a "To More Specific Class" function below the constant, and wire the constant into the top.
If the control from the array that you pass in is a Tab Control, "To More Specific Class" will NOT return an error. Use a case statement and use the No Error case to expose the Tab Control properties. Return the "Pages" property (an array) and pass this into a for loop. Connect a property node to the indexed pages, then select Controls On Page to return an array of controls ON EACH PAGE. You need to set up a shift register and use build array to return all of the controls from all of the pages. Make sure you close the Page Reference. You can concatenate the array of Tab Control Page items with your original FP Controls.
Now is the right time to use %^<%Y-%m-%dT%H:%M:%S%3uZ>T
If you don't hate time zones, you're not a real programmer.
"You are what you don't automate"
Inplaceness is synonymous with insidiousness

Photoshop and elements 13 Working in iPhoto Want to edit image using photoshop elements Did the following IPhoto Preferences Advanced Edit Photos: In drop down menu chose in Photoshop Elements Also control click and chose edit in external editor Drop

Photoshop and elements 13
Working in iPhoto
Want to edit image using photoshop elements
Did the following
IPhoto>Preferences>Advanced>Edit Photos: In drop down menu chose in Photoshop Elements
Also control click and chose edit in external editor
Drop down menu edit photos in external program>photoshop Elements
Go to to the image I'm working on --- selected the image, the clicked on edit. When nothing happened I double clicked the image. Still elements didn't open. Then I opened the Elements editor, went back to iphoto and tried the entire process again. the photo still didn't open on Elements 13 for editing.
I have 3 Elements 13 books as well as looked on line--all my references say the exact same thing ---- iPhoto>Preferences>advanced>edit in external program>photoshop Elements
I uninstalled and reinstalled both iPhoto as well as Elements.
I spoke with application technical support. There appears to be nothing wrong with my copy of iPhoto. However there is no support from Adobe. I waited for over 1.5 hours for chat support several days ago, and finally gave up.

You are probably choosing the obvious file rather than the correct file as the PSE editor. The actual editor is hidden away inside the Support Files folder. The PSE file at the top level of the PSE folder in Applications is just an alias for the welcome screen and what you're describing is exactly what happens when you choose that. You want this one:

Cluster of control references: want to access the control value

I want to be able to save and set control values that are saved (XML). I have my controls on about 5 sub vi's. So I thought it'd be a good idea
to put all the control references in a cluster from the several sub vi's and save and read from one point.
I can get the cluster values (i.e. the references to the controls), but how to proceed from here? If somebody has a better idea it is very welcome.
I have also read Ben's nugget here, but it deals with references to controls in a cluster, not references to a reference of a control in a cluster

Thank you for reading that Nugget!
I use a GUI Controller in many apps so I can grab refs in sub-VI's.
Here are some screen shots of them in use.
The first "GUI Cnt" is a wrapper around the AE and invokes the action "Set Analysis mode" then another call let me get a cluster of the refs so I can choose based on the name.
This image shows what that action does.
THis is what happens when going into collection mode.
That is a small set of what you will find in my image gallery Feel free to browse (yes I know there is a lot of Olivia in there ) and ask if anything catches your interest.
Ben
Ben Rayner
I am currently active on.. MainStream Preppers
Rayner's Ridge is under construction

Help!: Control reference seamingly "lost" in run-time execution mode

Hi!
The Facts:
LabView 6.1 PC under NT.
I've been using "Vi loader" technique since a few month s to distribute a LabView application on severals PCs without having to re-compile it each time. My application uses more than 500 VIs so I can't build it directly. The directories/Vis of the application are simply copied on the target PC and run through the Vi loader technique instead of using the development environnement.
The problem:
Since the last release of the my application, differences between the application running in development mode or run-time mode have appeared:
One VI reading a .ini file does not act the same way if runned in the developpment environnment or
runned in the run-time environnment. This VI uses control-references from its front-panel and passes them to sub vis. In run-time execution those references seems to be perverted: the sub-vis get them but can't access their properties like Label Name, Values,...
All works perfectly fine if the VI is runned in the environnment developpment.
Moreover the same sub-vis called with other control references in other VIs work fine.
Question:
Has anyone seen any behavioral difference between run-time execution and development environnement execution?
Are there any differences in the linkage process between those 2 execution ways?
Is there any labview Feature that would automaticaly "de-allocate" references at run time and would do so "too early"?
Is there any know problem with poly-morphique VIS in run-time execution mode.
That's all, any idea, lead, wellcome!

Hi Andrew!
I've allready had a look at the "Problem with VI Loader technique". It only deals with top vis not working (ie broken) when called from loader in Run-Time mode because of ill declared vi.lib path.
It's "unfortunately" not my problem: My VI is not broken, it's kind'a working, but not as it does in development environment execution mode.
If NI people are reading this, I would like to send them the VI and it sub-VIs to understand if something has been perverted .
The problem is seen on all three target PCs.
Moreover, a new one has appeared: in run-time mode, the standard "file dialog" vi called to prompt the user for a file with a given extension pattern sends back the file name with the extension "double dotted" (exemple: anything..data
instead of anything.data).
About the first problem, does any know why a Ctrl Refnum would loose its parent information (name, value...) in run-time execution mode?
Bye!

Performance issues using control references in Analog control loop?

My main vi of a tensile tester control application calls a number of sub-vi's, including a analog control loop which controls the test. The control loop must update some boolean and digital indicators and respond to user input on the front panel of the main vi during a test.
To simplify my main vi, I moved the control loop code into a sub-vi, and used control references to access the controls and indicators on the front panel. However, this has dramatically affected my loop performance, and the loop can no longer keep up with the acquisition speed.
Do control references always cause such a slowdown? Is there anything that I can do besides moving the code back into the main vi?
Thank You,
David Creech

I have had the same problem. I have discovered other funny things about references also; some kind of memory management (or mismamagement?) is taking place behind the scenes.
Regardless, you can often do away with the references by passing the initial state of a control or indicator into the subvi, changing it inside, and passing the altered state back to the caller. Once back in the caller you update the front panel control or indicator by using a local variable.
One thing to watch out for if using this scenario is the dreaded race condition; this can be avoided using a state machine. Check out
http://www.advmeas.com/goodies/statemachine.html
for a good example. It is a shame that references behave in this way; it limits thier usefulness.
Perhaps someo
ne else will point out a way to utilize them more sucessfully?

Control references and XY graph

Similar Messages

Maybe you are looking for