Property node to cluster element

Hello All
When clicking at the control cluster element you can create a property node.
But if right click on property node you can NOT Link to the cluster element.
How it is possible, that you can do it only in "one direction"?
Pawel

Have you looked at creating a property node for the cluster and using the Controls[] property? Controls[] is an array of control references for the elements in the cluster. The array is ordered in the cluster order. If you're doing the same operations on each cluster element, you can put the operations in a loop autoindexed by Controls[]. If you're doing different things for each cluster element, you could create a state machine controlled by the Controls[] index. The property nodes for the indiviual elements will be disconnected from the controls, then the control reference indexed (or autoindexed) from Controls[] will be wired to the reference input of the property node.
You can get a disconnected property node from the Commun
ication >> ActiveX function palette, or your can create a property node for any control, then right-click on the property node and select Disconnect From Control. Don't worry about the label on the disconnected property node until you wire the control reference to it. It will automatically adjust based on what it's wired to.

Similar Messages

Problem with the Value property node (MacOS)

As far as I have tested it, Value Property nodes (and Value (signaling)) don't work in MacOS : The value property appears as a boolean, the value(signaling) as a cluster (width, height).
Even with boolean controls, the node is not working.
No such problem in LV 8.6.
Am-I missing something ? Is that some "intended use" ? Or simply a bug ?
Chilly Charly (aka CC)
E-List Master - Kudos glutton - Press the yellow button on the left...
Solved!
Go to Solution.

That sounds like some sort of indexing problem with the property nodes like somesort of corrupted installation. What if you just delete the property node and recreate it?
I dropped a numeric control and looked at the shortcut menu for the list of property nodes. Right below Value and Value (signalling) are Visible (which would be a boolean) and Xcontrol, which when you step down through the submenus, the first choice is Container bounds, a cluster of Width and Height. So these 2 datatypes that are 2 lower on the list match the ones you are getting.
What happens if you pick another property node a few elements up or down on the shortcut menu? Does is happen for some other properties, and if so, are thereany properties that are okay?
Here is what my property nodes look like for a numeric and I draggged the box up and down to show the natural order of the property nodes. Note that I have scripting installed, so there are a few more property nodes (and the blue box at the top) that you might not have.
PS. Check you signature. The Kudos button is now moved to the left since the forum upgrade.
Attachments:
Example_VI_BD.png ‏4 KB

Change properties of a cluster element withing an array of clusters

Hello all,
I have an array of cluster that is shaped as a line with different display elements.
A list or a tree wouldn't have made it, so I had to use a cluster and make a table.
The problem is that I want to change not only the text but also the text color.
Individually.
I found this :
http://www.ni.com/example/30904/en/
But it change the property in all the clusters in the array, not just the one I need.
Some people have the same problem :
http://forums.ni.com/t5/LabVIEW/Reference-to-Array-of-Clusters-with-an-array-element/td-p/1006427
http://forums.ni.com/t5/LabVIEW/Different-set-of-values-for-two-rings-in-an-array-of-clusters/m-p/10...
http://forums.ni.com/t5/LabVIEW/array-of-clusters-get-references-to-all-the-clusters/td-p/1079456
http://forums.ni.com/t5/LabVIEW/How-can-I-reference-the-properties-of-a-control-in-a-cluster-in/m-p/...
http://forums.ni.com/t5/LabVIEW/Writing-only-to-certain-cluster-elements-in-an-array-by/m-p/2200728
http://forums.ni.com/t5/LabVIEW/Update-Properties-Of-One-Control-In-An-Array/m-p/3015501
http://forums.ni.com/t5/LabVIEW/Array-of-clusters-and-in-the-cluster-is-a-bar-meter-how-can-I/m-p/15...
http://forums.ni.com/t5/LabVIEW/Property-node-of-a-control-inside-of-cluster-inside-an-array/m-p/946...
Obviously, while in a list/table or tree you can change the property of an individual
cell (font, color) you cannot do it within an array of cluster, by some sort of magic,
the property of a cluster element (font, color) are all linked together, hence rendering
the use of an array worthless.
A possible hack is proprosed by using control masking, setting one visible and the
other invisble, swapping their position, whatever. It's a hack you have to perform,
hence add another code to maintain.
Is that still the case or is there now a more official way to handle individual cluster
properties, not just its data ? After all that's a common real-life example that should
be handled by Labview. In my opinion.
David Koch
Solved!
Go to Solution.

altenbach wrote:
One of the elements could be a 2D picture indicator of about the same size. You can write text in any color using picture functions.
Here's what I had in mind. Seems to work just fine (I would fine-tune the font, picture border, etc. but this should get you started).
LabVIEW Champion . Do more with less code and in less time .
Attachments:
ColorText.png ‏13 KB
ColorText.vi ‏9 KB

Multiplot waveform graph plots are different colors when set to be the same with a property node.

The graphs were working yesterday. I made a few changes to another part of the block diagram and now the graphs do not plot all of the plots the same color. I am using a for loop with a property node with the elements active plot connected to the iteration terminal, and plot color to a color box. My for loop increments programmaticaly from another part of the code to create plots as it runs. I have replaced the graphs with new ones and they will work sometimes.
I am using Win2k and LV 7.1
Thanks,
Brett

Hi bh3560,
Have you tried chaging the color by right clicking on the line in the plot legend. There is an option to change the color of the plot.
Brian K.

Property nodes to items in cluster are FRAGILE

This issue has bugged me for a long time . I just got bit again and I wonder if anyone else has a workaround.
I just checked and LV 2009 has it too.
Create a custom control of a cluster with three elements named A, B, C (numeric controls, booleans, whatever, it doesn't matter).
Make it a TYPE DEF (non-strict) and save it.
Put an instance of it on a new VI panel.
Create a PROPERTY NODE for item B and set it to DISABLED property.
Wire a constant to that property node.
Now, if you run the VI, it sets the DISABLED property of item B to the value of the constant. Fine.
Now go to the TYPEDEF, and add another item, called A2 to the cluster.
Re-arrange the cluster order so that it's A, A2, B, C, and save the type def.
Look at your diagram. The property node is no longer linked to B, it's now linked to A2.
Apparently, LV uses the cluster order internally to keep track of the links. So now I'm linked to A2, not B.
If A2 was a different type of object from B, then you MIGHT get lucky and the diagram breaks. At least then, you can see the fact that it changed.
But almost everything has a DISABLED and a VISIBLE property, if that's the one you're using, then you won't notice that it was changed behind your back.
I have taken to adding a free label with the name of the expected control (in parentheses) next to the property node, along with the true label. So if I see a discrepancy between the true label and the free label, I can recognize such a case.
But that's only if I remember that this crap happens.
Anybody got any better ideas? How can I prevent, or at least recognize, such an unwanted change?
Bonus question: the same thing happens with events, for the same reason (I suppose). If I tied an event to item B, that event switches to item A2 behind my back.
Steve Bird
Culverson Software - Elegant software that is a pleasure to use.
Culverson.com
Blog for (mostly LabVIEW) programmers: Tips And Tricks

CoastalMaineBird wrote:
This issue has bugged me for a long time . I just got bit again and I wonder if anyone else has a workaround.
I just checked and LV 2009 has it too.
Create a custom control of a cluster with three elements named A, B, C (numeric controls, booleans, whatever, it doesn't matter).
Make it a TYPE DEF (non-strict) and save it.
Put an instance of it on a new VI panel.
Create a PROPERTY NODE for item B and set it to DISABLED property.
Wire a constant to that property node.
Now, if you run the VI, it sets the DISABLED property of item B to the value of the constant. Fine.
Now go to the TYPEDEF, and add another item, called A2 to the cluster.
Re-arrange the cluster order so that it's A, A2, B, C, and save the type def.
Look at your diagram. The property node is no longer linked to B, it's now linked to A2.
Apparently, LV uses the cluster order internally to keep track of the links. So now I'm linked to A2, not B.
If A2 was a different type of object from B, then you MIGHT get lucky and the diagram breaks. At least then, you can see the fact that it changed.
But almost everything has a DISABLED and a VISIBLE property, if that's the one you're using, then you won't notice that it was changed behind your back.
I have taken to adding a free label with the name of the expected control (in parentheses) next to the property node, along with the true label. So if I see a discrepancy between the true label and the free label, I can recognize such a case.
But that's only if I remember that this crap happens.
Anybody got any better ideas? How can I prevent, or at least recognize, such an unwanted change?
Bonus question: the same thing happens with events, for the same reason (I suppose). If I tied an event to item B, that event switches to item A2 behind my back.
For the disabled property inside of cluster whos definition hcanges... we are screuued.
For the events your idea to include the text name, is the same technique that Jim Kring shared with us when he discovered the same thing can happen with dynamic event references. I belive that was CAR'd.
No solutions so no bonus points.
Ben
Ben Rayner
I am currently active on.. MainStream Preppers
Rayner's Ridge is under construction

Problem in writing to a property node of a cluster

Hello together!
I have a problem in writing to a property node of a cluster which contains several control elements, such as combo boxes or string controls.
I would like to set the options to choose for an array of such clusters.
I tried to do this by writing to property node --> value, but the the control element in the cluster does not remain a control, but instead an indicator. The can't choose one of
the options that I set. So I further set the property node --> indicator (of the cluster) to "False", with the purpose to keep the control as a control. This results in a comment from Labview,
that this is not possible as long as the Vi is not in edit mode. I don't understand this comment. If I look to Labviews toolbar "Operate", I see that I am obviously in edit mode.
If anybody could help me, or suggest a better solution to solve my problem I would be very glad.
Thanks a lot!
Woodi
An example of what I tried to do:
Attachments:
How to write to a cluster.vi ‏42 KB

I took the liberty to modify your VI for an alternative approach (LabVIEW 7.1). You should keep your array of 32 clusters in a shift register and show only a single cluster as a front panel control.
Selecting a different transducer from the listbox on the left will load its settings into that control via a local variable.
Any changes to the settings will modify the currently selected array element
At any give time, a boolean array shows which transducers have changed settings
At any given time, a listbox summarizes all settings.
Let me know it this makes sense to you. These are just some ideas, modify as needed. Good luck!
LabVIEW Champion . Do more with less code and in less time .
Attachments:
How_to_write_to_a_clusterMOD.vi ‏87 KB

Condense property node elements

Hello,
Attached is a snippet of a program in which after the program goes into a specific state, the front panel elements are made either visible or invisible or there are value changes.
In my actual VI, I have a lot more front panel elements, and in trying to keep my code consistent and easy to follow, if I line up the propery nodes of the elements in the block diagram, the block diagram can extend to over 2 screens.
I would like to know if there is a procedure that I can adopt where I can condense the activation of the property nodes of elements from the front panel so that the property nodes do not extend over 2 screens as it makes it harder for my collegues with a laptop to follow.
Thanks,
hiNi.
Attachments:
Visibility.llb ‏39 KB
Visibility.llb ‏39 KB

I would suggest that instead of using property nodes in each state to update the values of your indicators, you could just place the indicator terminals outside of your state structure (but within the while loop) and pass whatever value is appropriate for the state out of the case structure. Writing directly to the control instead of using property nodes will be faster and will save you a lot of space. It also generally scales better, as you've found out. You're already doing something like this for your status updates- why not the rest of the indicators? For hiding/showing elements, it would be more compact to use explicit instead of implicit property nodes and for loops. You can also use explicit property nodes within subVIs, which will go a long way towards making things smaller and neater.
Control References: Overview (Creating and using Implicit vs. Explicit nodes)
http://www.ni.com/white-paper/3159/en/#toc3
This may be oversimplifying things on account of your basic example, but in general you'll be better off grouping your indicator values into a cluster that's stored in a shift register (like your status string) and then modifiying the cluster contents as needed. This allows you to start adding logic in subVIs much more easily. It's a lot easier to avoid race conditions caused by writing values from multiple locations as well as things get more complex.
Regards,
Tom L.

Can we change the property of each element of an array using property node or by other methods?

Hello all,
Can we change the property of the elements of an array. For example:
I have an array of combo-boxes. Can i have such a scenario that different combo-boxes of the array will have different items to select an item.
I am able to set the different "values" in different combo-boxes bu using "to be more specific class" property node.
But i could not set the different item list in different combo-boxes.
Please give me the solution.

Thanks a million dave!!!!!
I have learnt a very new and innovative thing...
I just wanna ask you one more question in the above context.
Can i have listbox or combo-box in a table just like in an excel sheet where we can have listbox by using "data validation" property for different cells having different list.Can i have this in labview. Because for this i have to super-impose the combo-boxes on the table and treat them separately.
We have to take those combo-box values and put in table and then store it.I have attached one VI to show the scenario.
And this is the alternative solution of the array problem which u have already given. So please suggest me between the two or any alternative solution.
Thanks,
Ankit Madaan
Attachments:
Recording _Table.vi ‏19 KB

Why can't I create property nodes for item in STRICT typedef cluster?

I've tried this in LV7.0/WIN2k and LV 7.1/OSX - both versions work the same.
I have a TYPEDEF consisting of a cluster of items A, B, and C.
I have a front-panel instance of this typedef.
Under certain conditions, I want to disable and gray Item C, because it's not applicable.
So I need a property node connected to item C.
If the typedef is STRICT, then I cannot create such a property node - the menu item to create anything is just not there.
If I change to NON-STRICT, then I can create the property node.
I can change it back to STRICT, and the property node works just fine.
The question is, if the nodes WORK normally, why can I not CREATE one?
If there's some sense behind this, someone please point it out to me...
Steve Bird
Culverson Software - Elegant software that is a pleasure to use.
Culverson.com
Blog for (mostly LabVIEW) programmers: Tips And Tricks

I agree with you, It would be nice to be able to keep the non strict typedef auto-update and extend it to properities which effect the look of a control. I am not sure why you can change the properities on a strict typedef. A strict typedef should have private properities (can only be changed from within the definition and no public other vi scope for writing these values. I have in the past used a custom control for presentation purposes and contained the structure of the data to be displayed within the typedef cluster. This is not all that automatic since we need vi's to convert between the definition and control. Seperating data structure from presentation is much like XML where the file only contains data structure and a reference to a style for presentation. It would be a very nice option to allow nonstrict typedefs to have an additional auto-update properities which could be toggled on and off. I would be curious to here others opinions on how to keep data structure and presentation consistant across an application without being tied down to a strict typedef (allowing the optional change of teh presentation at runtime).
Paul
Paul Falkenstein
Coleman Technologies Inc.
CLA, CPI, AIA-Vision
Labview 4.0- 2013, RT, Vision, FPGA

Using LV Class Property Nodes in In-place Element structure causes the code to halt

I have some code written in LV RT 2010 that uses property nodes from a LVOOP class that I created. I am using access the property node from inside an in-place element structure. When the code reaches the property node, LabVIEW stops running. (as if the abort button was pressed). I verified this behaviour using highlight execution. When I remove the in-place structure code runs fine.
Is this is know bug in LabVIEW? Is there a CAR to resolve this created for a future release?

Bob,
I tried to reproduce the behavior you're seeing by recreating the Trigger and Trigger List classes, but I have not been able to reproduce it. Please take a look at my version of the project in the attached zip file. Take a look at Test.vi, and feel free to modify and repost it to show me how to make the problem occur. I would like to file a CAR to make sure we get the problem fixed, but I will need to be able to reliably reproduce it first.
On a similar note, you can get much better performance out of the Process Triggers VI by preallocating the list array, instead of using build array in a loop. Take a look at Process Triggers2.vi in my project. You can run Benchmark.vi to see the performance difference between the two different approaches.
Chris M
Attachments:
triggerlist test.zip ‏165 KB

How to change value of array element using property node

hello all : )
im using an array of combo-box. the size of array is not fixed.
i want to use the strings[ ] property of combo-box to enter selection texts but since i have placed it inside the array im unable to use this property.
i used 'arrayelem' reference property and connected property node to it but didnt got strings [ ] in the selection.
so is there any way i can use the strings [ ] property
Solved!
Go to Solution.

the picture what I posted is a snippet. It is a png file which also contains a vi:
http://www.ni.com/tutorial/9330/en/
I have found this post. I am just reading it:
http://forums.ni.com/t5/LabVIEW/combobox-in-array-why-does-it-work-this-way/m-p/2146916/highlight/tr...
It might help...
hmm, it is more complicated as I thought )
edit: just to be CLEAR: so you want to create a new selection LIST for each of the array elements (comboboxes)) OR you just want to set all the comboboxes to a particular value which is ALREADY in the combobox list??

Error cluster in XControls Property node

Hello!
Property Nodes of XControls do have Error Clusters, but how can I change those out of the Facade? I'm setting an object through a property node for tree data. It is possible that some of the object methods generate an error while executing in the facade and I would like to catch this error in the VI containing my XControl.

You can't change the error output from a property node from within the facade since the facade only gets called after the property VI has run and modified the contents of the display state information. If possible try to catch invalid values in the property VI itsefl. If there are errors that the xcontrol will need to report you will need to provide a separate mechanism.
Something that I have used in the past to good effect is the idea of an error stack. The error stack itself is an array of error clusters that resides in the display state data and is maintained as a circular buffer by the xcontrol code. To access this value from the calling program create a read-only property that reads the contents of the buffer and then clears it.
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

Changing the property node from an control in an cluster raises an error in LV2011

Hi, all
when I run the code in LV2010 SP1 no problems.
But in LV2011 it gives an error.
Is this an BUG
Attachments:
test.vi ‏18 KB

Franzo,
It certainly is strange. The error comes from the Width property node, but it occurs when ReadoutMode is clicked. It does not need to be changed.
Wrapping it in an event structure (ReadoutMode: Value Change) seems to eliminate the error.
Questions for someone at NI who knows how these things work internally: It is also interesting that the data type of the Maximum property is always DBL, regardless of the datatype of the control. Should not a U16 control have a U16 Maximum? And what about the Extended datatype? How can a value larger than the maximum for a DBL be set via a property node of type DBL?
Lynn

Grouping property nodes

Hi there, I'm creating a DAQ application wich reads in 64 channels. Now I want to enable and disable certain items in the front panel using property nodes. You may understand that this would take a lot of time considering it's a 64-channel DAQ application. Does someone has any idea how to group certain front panel objects so I can use only one property node for multiple objects? Or is there another way?
Another question:
How can I automaticaly read in a front panel datalog file so it remember names I entered last time I used the application?
thanks, Bert.

> What I'm trying to do is:
> Grey out all 64 channels (1 channel = a string control, numeric
> indicator and two check boxes) when the acquisition begins (pushing a
> button). So this would take me 64*4 = 256 property nodes and I thought
> that there must be an easier way.
>
Consider putting the string, numeric, and check boxes in a cluster.
Place the cluster in an array, and grow it vertically to show 64
elements. If your layout has several columns, make a copy of the array
and make say four of them with 16 rows each.
On the diagram you will be able to set the array properties easily, but
you will not be able to set properties for individual cells within the
array.
This will also affect how you access the controls. Instead of 64x4
terminals all over the diagram, you will just have the arrays, and you
can index and unbundle when you want a data element. If you normally
deal with the 64 displays, this will be very convenient. If you often
need access to individual elements, I'd recommend making a subVI icon
where you pass in the array and the index and it returns the four
subelements as outputs. This will probably clean up your diagram as
well as simplifying the graying of the display.
Greg McKaskle

Change a cluster element value

I have an array of clusters and each cluster has dozens of controls in it. I want to go through all the array clusters and change the value of a specific control. Right now, I am using the value property node of the array to get a 1-d array of clusters, looping through it, unbundling each cluster, change value of one element, bundling it back into a cluster, and then giving it back to the array using the value property node again. This works fine but maybe there is a simpler way to do it. With the current method, it is probably using more RAM too because it has to copy all the data.
Message Edited by abdel2 on 12-24-2008 11:44 PM
Solved!
Go to Solution.

(Please always attach an actual VI. It is very difficult to troubleshoot or edit a code image. )
Anyway, your use of value property nodes is completly misguided here, they just introduce additional overhead and complicate the code! Why???
All you need to do is (1) read fom the input terminal, (2) modify the array element using "replace array subset", and (3) write the result to the output.
If you want to also write it back to the control, use a local variable.
(Depending on the rest of the code, you might also want to keep the array of clusters in a shift register.)
Message Edited by altenbach on 12-25-2008 10:12 AM
LabVIEW Champion . Do more with less code and in less time .
Attachments:
ModifyCluster.png ‏7 KB

Property node to cluster element

Similar Messages

Maybe you are looking for