Closing control[] reference

If I have a main VI that calls sub-VI's, and I pass the control[] refereces of the controls in the main VI to the sub-VI. Should I use a for loop to close the control[] reference? And should I close the control[] referece in the main VI or the sub-VI?

My understanding of what you are doing is building an array of the control references in the main vi to pass to the sub-vis. Is this correct? If so, why not bundle the references instead? This way you could easily pull out the required reference by name.
Aside from that, if you are passing references to the front panel objects you shouldn't need to close them at all. The following links should be useful in helping you to understand when to close references:
http://exchange.ni.com/servlet/ProcessRequest?RHIVEID=101&RPAGEID=135&HOID=506500000008000000834C0000&UCATEGORY_0=_49_%24_6_&UCATEGORY_S=0&USEARCHCONTEXT_QUESTION_0=closing+references&USEARCHCONTEXT_QUESTION_S=0
http://www.ni.com/devzone/lvzone/dr_vi_archived4.htm
Hope that helps.
John

Similar Messages

  • Opening/Closing Queue Reference By Name

    I'm curious if opening and closing a queue reference to put information onto the queue, using the queue name -> obtain queue -> enqueue -> release queue(Non Force) is problematic.  I thought i saw a thread a long time ago that opening/closing a reference to a queue over and over could lead to a memory leak, even if the original queue never was released.  Obviously, i'm ignoring the general pass the wire(by value) correct labview way. 
    Instead of opening/closing using the queue name i could also wrap the queue reference in a FG after originally creating it and work on the reference that way. Ignoring the "right way to do it" are there still downsides, other than programing correctly, to open/closing queue reference's in this fashion such as memory leaks.

    PaulG. wrote:
    I have never heard of any unwanted consequences of repeatedly opening and closing any reference. The trick is to make sure a reference gets closed when no longer needed. I don't see any reason not to implement queues the ways you describe. I've done all three and haven't had any issues that I know of. If opening and closing a queue reference repeatedly caused a memory leak that would be considered a bug.
    I have to disagree here. A couple of years ago I was using a DAQmx Write with "autostart" option set to TRUE in a loop (ca. 100ms timing) to constantly make sure, that in application standby my Digital Outputs kept the values they ought to have. This reproducibly caused a blue screen on Windows after 6 hours of the program running in standby. As it turned out, LabVIEW was using a new reference to the task for every call of the Write, because with autostart set to TRUE it had to create the task beforehand and close it afterwards. After the mentioned peroiod of time, LabVIEW ran out of reference numbers, as the support explained to me.
    Of course, even LabVIEW Help says to avoid using autostart=TRUE with DAQmx VIs in a loop, but only because of the overhead the repeated Create and Clear is consuming. Naturally, I have learned that the hard way now.
    So - Create the reference once, use that same reference all the time (FG is fine, I think - I use this method for obtaining my logfile reference all over the place!) and close it only, when you don't really need it anymore.

  • Closing ActiveX references correctly in Simple UI

    Hi,
    I am currently trying to modify the Simple UI provided with Teststand 2013 in order to access global station variables through LabVIEW.  As a simple test, I am trying to access the LastUserName value.  When I run the VI for the first time after opening LabVIEW, I get no error messages and the program runs as required.  Stopping the VI execution returns no errors, but when I try to run the VI and run the Teststand sequence again, the execution stalls and I get a waiting status.  I must then close the VI execution by killing all Teststand threads  I believe the PropertyObjects are not released properly and I find the event structure quite puzzling to deal with.
    My attempt at closing the references within the while loop looks like this : 
    The rest of the program is exactly as provided with Teststand 2013.
    Any input on how to properly close the ActiveX references and retrieving station globals within LabVIEW would be much apreciated.
    Thank you for your help,
    Christian
    Solved!
    Go to Solution.

    First of all, I would like to thank you for your answer.
    I understand that repeatedly opening a reference inside the while loop does not represent a viable solution.  This morning I found a very handy reference that explains how to pass data from the Teststand API through custom UI user messages.  This allows a more elegant and robust way of handling data that is retrieved from Teststand.  I'll use a custom event call back that will trigger on any custom message.
    Here are the references ( which are IMO clear enough for someone with very little LabVIEW experience) : 
    http://www.ni.com/white-paper/4532/en/
    https://decibel.ni.com/content/docs/DOC-21047
    So far, I have been able to create a dummy Teststand sequence that sends a custom UI message containing the string ''Hello, world!''. The UI can accordingly retrieve the string and display it in a dialog box.
    I still have to find a way to pass the data from the subVI to my UI.  I am investigating the use of global variables, but there may be a better solution that I am not aware of.  Any input on how to pass information between two active VIs would be much appreciated!
    Christian

  • 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

  • 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

  • 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?

  • Event applied to control references

    Hello!
    I built a VI that can run on its own or controlled by a superordinated VI. If there are valid references comming into the subordinated Vi these are used exclusivly, otherwise references to the controls of the superordinated VI are used.
    So inside my program I exclusivly use references and property nodes to access or change data.
    My first question is if you think that is a bad solution concerning the performance of the VI and if you have any improvements?
    The next problem is that my VI is quit slow now (there is a while loop checking all the time if there are changes made to the controls (via their references) and acquiring data (using RS232) and updating controls. Thereby I use a 20 frames long sequence inside the loop.
    Is that the reason for slow performence?
    To speed things up I considered to us an event structure instead of the sequence to check the changes and only to do the acquisition every cycle.
    But I don't see a possibility to use the event structure to check events on value changes of controls via their references.
    Any idea?
    Thank you,
    Alexandra

    > But I don't see a possibility to use the event structure to check
    > events on value changes of controls via their references.
    >
    With LV7, it is possible to use an event structure on control references
    to another panel. As for whether this is the reason for performance
    problems, that is hard to say without seeing your application.
    First suggestion is to use the profiler. Tools>Advancec>Profile VIs.
    It should help you start looking in the right place and run informed
    experiments.
    Another way of doing this is to send it to [email protected] and let me use it
    as part of the VI critique going on at NIWeek. We will keep the names
    anonymous and find the best technique we can for the problem you are
    trying to solve. This offer goes for anyone with a VI t
    hat they'd like
    to see NI try to improve upon.
    Greg McKaskle

  • 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

  • Accesing controls (references) from several VI's

    Ok I have this small problem:
    I have a large program
    and have put serveral "advanced settings" in a different VI.
    Result
    is that the values entered here need to be passed to controls in
    different other VI's
    The way I use this now is using 1 element
    queues to pass the control
    value. 
    For one VI I can create control
    references, call a sub vi and put here the control that can manipulate
    the value.
    How do I achieve this for multiple VI's? Is
    there a way to make control values from ANY running VI available? Maybe
    using xcontrols? I have no idea how to achieve this though.
    thanks!

    Ben wrote:
    I will typically use a GUI controller in my apps to accomplish that type of thing.
    GUI Controller
    I develop an Action Engine  that will cache a cluster of control references when an Init method is invoked. This put all references in a SR that can be accessed from any place the Ae is used.
    I add methods to the AE to take care of screen settings associated with changes of state ("Set Visability Edit Mode", "Set Visablilty Login", etc).
    I also add a method to return the cluster of refs so I can use them to set-up dynamic event registration in sub-VI etc.
    A side benfit of using a GUI Controller is that you have a single point where you can add a "stack" of screen views so functions like "Back" and "Forward" can be added easily. 
    So...
    trying using a GUI Controller.
    Ben
    This an excellent method for achieving what you want. A variation of it would be to use LVOOP instead of the AE. The two approachs are essentially the same but with some thought on the definition of the classes I imagine you can create a general purpose base class to handle most of the common aspects. Customizations can be achieved using derived classes.
    Further adding to Jeff's comments about the up front hit in the schedule. When done right you will see the benefits of shorter schedules for future projects. The first time is the hardest sell to management. However once you get a couple of successes under your belt future requests will be much easier since you now have a track record of benefits achieved by using reusable code libraries.
    Message Edited by Mark Yedinak on 03-30-2010 08:55 AM
    Mark Yedinak
    "Does anyone know where the love of God goes when the waves turn the minutes to hours?"
    Wreck of the Edmund Fitzgerald - Gordon Lightfoot

  • Main VI stops when using control references.

    Hi, This is my first question on this forum. I've created an engine simulation VI which uses control references. The main VI has a data acquistion loop and control references. The control references link to another VI that runs an equation loop which continuously calculates engine speed base on data collected in the main VI. The control references work but the main VI data is collected and updated only once when the main VI starts. If I remove the control references from the main VI the daq loop runs fine. Thanks in advance for your help.
    Mike

    Joe,
    Thanks for the response. I do not load the subvi dynamically. I have attached a similar vi to show what I'm trying to accomplish. The DAQ vi reads the input and calculates the power. The power is sent to the "engine momentum sub" vi where the speed, as a function of time, is generated and sent back to the DAQ vi. I created the sub vi to clean up and isolate the DAQ vi from the subvi. I wanted the sub vi to run at a certain speed (by adjusting the wait time)and not affect the DAQ vi. If you input a value of 10 into the DAQ vi and then start it you will see the speed ramp up to 100. While the DAQ vi is running, I need to be able to change the input which would cause the power to change and in turn change the speed. I thought the control r
    eferences were the way to go. In my real DAQ vi, I have many more inputs, all which do not update after the first reading. I considered putting the DAQ functions in another subvi and reading the outputs through control references but that seemed too cumbersome.
    Thanks again,
    Mike
    Attachments:
    DAQ.vi ‏27 KB
    Engine_Momentum_Sub.vi ‏33 KB

  • Pass control references to subVI using Invoke Method

    Hi guys,
    Can I use <Control Value Set invoke method> to pass some control references to a sub VI, then use the <Run VI invoke method> to run the sub VI with the previously passed data?  The control refnums are for some frontpanel controls in the Main VI.
    I was able to pass other data but the refnum didn’t work.
    Thanks

    Hi there, There are a couple examples that use the same method. Check them here:
    - Set Control Values and Trigger UI Events in Another VI        
    - Set Values and Properties of Controls in a SubVI
    - Save and retrieve front panel control values
    Alejandro | Academic Program Engineer | National Instruments

  • 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

  • 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.

Maybe you are looking for