Cluster Control References

The Controls[] property of a cluster will provide an array of generic
references to the cluster elements.  However, each element must have
its own "Type Cast" or "To More Specific Class" node, and the resulting
type must corresponding to the order of elements in the cluster.    
An "Unbundle By Name" or "Bundle By Name" node will respectively read or write typed values of cluster elements.
Is there an "Unbundle References By Name" node or VI to obtain a cluster of typed (not generic) references from a cluster?

Attached is a very quick toy example of using a cluster's element references.
Paul Falkenstein
Coleman Technologies Inc.
CLA, CPI, AIA-Vision
Labview 4.0- 2013, RT, Vision, FPGA
Attachments:
element ref example.vi ‏14 KB

Similar Messages

  • 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

  • Strange Problem - Cluster of References

    Hello guys
    I had a strange problems using a cluster with references.
    How to reproduce the problem:
    - open a blank VI;
    - create two graphs in the front panel;
    - in the block diagram, create references for both graphs;
    - connect these references to a bundle (not bundle by name);
    - create an indicator for the bundle;
    - run the VI once;
    - right click on the bundle indicator and change it to a control;
    - delete references and bundle;
    - select the control in the front panel, go to EDIT, CUSTOMIZE CONTROL;
    - change to strict type def;
    - save this control as Control1.ctl;
    - connect the control to a unbundle by name;
    - right click on the unbundle by name and select one of the two graphs as an item (doesn't matter which one you select);
    - create a property node and feed its reference terminal with the reference from the unbundle by name;
    - use the property "Label.Text" in the property node;
    - create an indicator for the the property node;
    - run the VI;
    - the indicator will show the correct label for that graph;
    - perfect!!!
    If you save the VI and run it again, everything is fine.
    But............... if you close it, open again and run.... you will get an error 1055 "Object reference is invalid".
    Why it was working before closing?
    Find attached the VI and the Control.
    Thanks
    Dan07
    Solved!
    Go to Solution.
    Attachments:
    Cluster References.vi ‏11 KB
    Control1.ctl ‏7 KB

    Let see if I can answer before I have to start working.
    Do a quick experiment.
    Use a Type cast to cast your ref as a U32 and show that value on the FP.
    Save the VI run it and record the number on the FP.
    Mod the vi save it clsoe it open it and run again. The number should have changed.
    That is the issue you facing, the ref number changes so you need one that is valid when you run.
    How I do it;
    I use an Action Engine (see this Nugget to learn what an Action Engine is) that servse as a GUI controller and lets me get at refs where even I need them. The following is a case study.
    First I collect all of th refs I will need and bundle them in a type def. I sue a state machine to do the bundling if there are a lot.
    THe bundled clsuter get passed to an GUI Controller Action Engine
    Inside the Init I check the refs to make sure they are vlid. THis has saved a lot of wated time chasing invalid refs.
    If they were valid I cache the refs.
    For major mode changes that demand a lot of GUI punching I create sub-VI to do the dirty work.
    When ever other codes needs a ref to the GUI I have a method that returns the refs.
    THe following shows another VI using those GUI refs.
    I hope that helps,
    Ben
    Ben Rayner
    I am currently active on.. MainStream Preppers
    Rayner's Ridge is under construction

  • 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

  • DAQ device control reference bug

    I have found a bug when using a reference to a DAQ (8.3.0f3) physical channel control. We have a control that is hidden from view in a tab container and we have found that until the control is painted on the screen, we cannot extract the "value" property. Attached is a VI to illustrate the problem. To replicate the problem, do the following.
    1) Open the VI - you should see only the text control.
    2) Run the VI a number of times - the text control will not update.
    3) Scroll left and bring the DAQ control into view.
    4) Scroll right and bring the text control into view.
    5) Run the VI - everything works fine.
    I can force the control onto the screen and make it briefly visible to get around it, but it looks sloppy.
    Brian Rose
    Attachments:
    test1.vi ‏8 KB

    Just curious, though: is there a reason you can't
    just read the value from the terminal instead of a reference and
    property node and pass that value to wherever you need it?
    We are using a cluster of references to the front panel controls to pass to various subVIs that perform the operations. Since we have many controls that are manipulated at various times, we decided it was easier to just pass them all around and dereference them where we needed them. This way we have one wire connecting the various VIs instead of a ratsnest of wire and logic.
    The problem is that our main program front panel is a tabbed container. Our main window is in tab 1 and various other configuration controls are in the other tabs. We can't hide the control under something because the user may need to change it, so it would have to be accessable. The main front panel VI also does very little work and instead simply handles button presses and control updates and calls the appropriate subVI.
    Brian Rose

  • Re-casting of object from control reference

    I feel like this question is likely answered elsewhere, but after days of searching I couldn't find an answer. Sorry if I'm missing the answer in some obvious place.
    I'm given a reference to a cluster control and told that the elements of the cluster are all children of parent class A. Using the controls[] property I get an array of the elements, and the value property of each of those elements gives a variant that can be turned into class A. At that point, all of the object oriented overriding and private data stuff works as expected.
    So far so good.
    But one method I call on those objects changes the private data, and I need to update the control with the updated object. There I get a runtime error because the control isn't A but some child class of A.
    I think this is where Preserve Runtime Class comes into play, but since I only get a reference to work with, what do I do? This is especially frustrating because debugging probes show that LabVIEW knows the child class on the wire, but I can't see how to tell LabVIEW to cast down to the class that it knows it has.
    For example, is there some way to use the ClassName property of the control to cast the object of class A into the child that the control is expecting?
    Solved!
    Go to Solution.

    nathand wrote:
    So your trying to write to the specific control within the cluster, by reference, as a variant, and you're getting an error? What's the actual text of the error?
    Really you shouldn't ever be using a front panel object this way, especially one where the user never sees the data in it. For passing data around you should use a wire. Neither a wire nor a DVR will get you the ability to pass an arbitrary cluster, though, which it sounds like is what you're trying to do. With a bit more information we might be able to suggest a better approach.
    I don't have the text of the error handy, but it comes from the write value property node and basically says the given variant can't be converted to the type of the control. It happens only when the value is cast to the parent class, which makes sense.
    In other words, given a control of child type,
    control.value ---> variant ---> to parent ---> variant ---> control.value     failes with the error
    control.value ---> variant ---> to child ---> variant ---> control.value       succeeds
    So a solution would be a way to cast to the child instead of to the parent. LabVIEW knows what class the control contains; it is listed in a number of places from the ClassName property through the probe window. The problem is I know of no way to bridge the gap from "LabVIEW knows what class this thing is" to "have LabVIEW cast the variant to that class."
    I completely agree that I shouldn't have to ever be using a front panel control this way, but I don't want to get sidetracked into talking about the shortcomings of LabVIEW that have required such a use. Suffice it to say, that is the assignment.

  • Given array control reference, how do I obtain array size programatically

    If an array control reference is passed to a sub-vi, how do I obtain the current length of the array within the sub-vi?  I've tried two properties:  "NumRows", which as documented, contains the visible number of rows in the array control.  "IndexVals" contain the indices of the array element in the upper left corner of the array control.  There seem to be no methods for obtaining the current array length.  I tried changing the class of the array reference to cluster then using the "Controls[]" property... but this generated a runtime error.  What am I missing?  Thanks.
    Solved!
    Go to Solution.

    Taki1999 wrote:
    There's a lot of casting going on in your subvi.
    What is the actual use case?  There might be a way to do this which doesn't require the casting and you could work just with the reference that is passed in.
    For your method you need to wire in a strict class specifier into the To More Specific Class conversion.  I'm not sure how to make the strict class specifier.
    I can help with that but first...
    Working with arrays on unknown data types is no esy task and determining the size is a special challenge and I did just that in this Nugget that talks about using control references. This task is much easier when you know at development time what is in the array. That is where the strict type casting comes into play.
    What I would do...
    1) Make sure the contents of the array is a type def (to support data strcuture changes in the future).
    2) Go to the FP of the VI that has the array in question and drop a generic control ref control.
    3) Ctrl-copy and drag the array in question INTO the the generic ref (still working on the FP). You can tell when you find the "sweet spot" in the ref control because it will switch it appearence. See this mini-nugget for an image where the same thing can be done with que refs.
    4) Make the now strict ref a type def.
    5) Use the type-def'd ref from step #4 in the sub-VI as the proptype used by the "To More Specific...."
    After those changes you should be able to work with array in the sub-VI as if it were in the top level.
    BTW:
    Doing the above on the control in the sub-VI that brings in the ref would allow skipping the "To more Specific..."
    Have fun!
    Ben
    Ben Rayner
    I am currently active on.. MainStream Preppers
    Rayner's Ridge is under construction

  • Cluster of References Constant

    I want to do UI control of my front panel within a subVI.  Hence, I need to pass a number of references to front panel objects to a subVI.
    See the attached (simplified) example to illustrate my point.  Everything that lies within the sequence structure frames would reside in the subVI.
    In the top part of the block diagram, the references are explicitly bundled together, before being passed to the subVI to be applied to property nodes.  This works fine.
    However, if I want to define a constant cluster of references, as in the bottom part of the block diagram, it returns an error: "Object reference is invalid".  How would I make this work?  Note: I created this constant by right-clicking on the cluster wire in the top part of the diagram.
    Many Thanks,
    Dan
    Message Edited by DanB1983 on 04-20-2010 07:08 AM
    Message Edited by DanB1983 on 04-20-2010 07:09 AM
    Dan
    CLD
    Attachments:
    cluster of refs.JPG ‏63 KB

    You can pop-up on the middle input of teh bundle to create a constant. See this mini-Nugget.
    This thread may help, here is a preview.
    Ben
    Ben Rayner
    I am currently active on.. MainStream Preppers
    Rayner's Ridge is under construction

  • 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

  • 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

  • Printout a cluster control

    Hello,
    has anyone an idea how to printout a cluster control. When I print it with
    "Append Control Image to Report" the I only have the empty frame printed
    out.
    regards
    Marco

    Are you using labVIEW 8.0??
    There was a bug where in, the cluster was not properly saved while using append to control image.vi / get image method.
    This was fixed in LabVIEW 8.2
    Read this link for a suggested workaround in LabVIEW 8.0
    Hope this helps,
    Regards,
    Dev

Maybe you are looking for