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

Similar Messages

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

Controlling property node inside a arrayed cluster

I need help on how can i change programmaticaly a color of led/boolean on a specific element in an arrayed cluster.
attached is sample vi, i need to change the color of the status led boolen to yellow if the sn = 'No Unit'.
tried to use property node but it did change all the element in an array.
mytestautomation.com
...unleashed the power, explore and share ideas on power supply testing
nissanskyline.org
...your alternative nissan skyline information site
Solved!
Go to Solution.
Attachments:
try.vi ‏12 KB

Arrays must contain identical elements. If those elements are clusters its not an issue but lets simplify your array to an array of booleans for clarity. but each element in an array most have the same properties. You will not be able to change the Colors4[] property on one element of the array although you can set the Colors4[]property on ALL elements of the array.
In your case- it sounds like you need a control type that can have multiple values (color box) to display one of several colors (Green=good ser, Yellow = No ser, Red = Bad ser, ect.) and not a boolean that has exactly 2 possible values. Here's a custom button I got as a gift a while back. See if it helps
Jeff
Attachments:
Round Color Box.ctl ‏4 KB

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

Tentative bug report: property node (and other objects) resizes structure in which they are dropped even when this is not needed

This one has bugged me for a while, so, since I am in a mood to report annoying features, here it is:
On the diagram, when you drop an object that could have its size increased by user action (for instance a property node in which you chose "Value", which is a short property, but you could later change this to a "longer" one, which admittedly might require more space on the diagram), a case structure in which you drop it, will automatically increase its size.
Let me illustrate this with ONE example (can be reproduced with other objects such as enums, clusters, etc...).
Here is a simple diagram:
Note that I am going to create a property node from the front panel. This, for a reason that makes the beauty of this "feature", is very important. Apparently, if you create the property node from the diagram, nothing weird happens. The exact location where I will drop the node is not very important but needs to be close enough from the border.
Here is the result (LV 2011 but as I said, this has bugged me for a few versions already):
Basically, the case structure (and the whole diagram as a matter of fact) has expanded.
This is particularly annoying, say, when you are creating a diagram with 10 cases in a case structure and you start dropping things such as property nodes in each case: the structure keeps growing, and growing, and growing...
That also works with Event structure, and I am ready to bet, with other as well.
As I said, it is also not limited to Property nodes. I have noticed that this happens if you drop a cluster constant that contains an enum (presumably because some of the enumerated strings are longer than others).
I could speculate why this is the case, but that is not my job.

Actually, this might not be true. I found a variant of this behavior. With "Place Structure with Auto Grow enabled" unchecked, here is what I observed while dropping a property node on my diagram:
Before:
After:
This is the expected behavior. The Property Node is partly hidden inside the Case Structure I dropped it in. Now that's not what I wanted to do. I wanted to drop it in in the innermost Case Structure:
The problem is that now this Structure has grown (as has the whole diagram) to leave space for the whole Property Node:
It is a subtle bug in the sense that I tried to reproduce it on a new VI with a series of nested Case Structures, but it did not result in this behavior.
Anybody caring to comment?

Property nodes are severely affecting performance

LabVIEW Gurus,
I am continually running into some serious performance hits using property nodes to update attributes of FP objects. Attached is a classic example.
I have 8 XY plots that are being fed 600 SGL points every 200 msec - a very modest data rate. Each plot is a dynamically instanciated .vit placed into one of 8 subpanels in a container VI. The container VI also acts as the data server for the charts, sending each one their data in their own single element queue. The entire architecture runs great (~4% CPU load, see attached picture) until I being updating a property node to display the value of the cursor y-value. When I enable the "Caption.Text" property node of the XY Graph to display the cursor value, the CPU usage soars to over 30%.
As an aside, I am developing on a dual core 2.1GHz platform with 4G memory with LV8.5.1, and the target machine is not nearly as beefy. That's why 30% CPU on my powerhouse is an issue - it basically brings the embedded target to its knees.
I have included an example VI for you to run on your machine. Consider it "representative" of my bigger issues. The VI runs about 10% CPU without the caption update, and 20% with the caption updates.
Finally, I have tried putting the VIs into the UI execution system. I have also tried Defer Panel Updates, but this actually slows down performance.
Best regards,
Jack Dunaway
With Captions
Without Captions:
Message Edited by mechelecengr on 10-10-2008 11:23 AM
Message Edited by mechelecengr on 10-10-2008 11:27 AM
a.lia-user-name-link[href="/t5/user/viewprofilepage/user-id/88938"] {color: black;} a.lia-user-name-link[href="/t5/user/viewprofilepage/user-id/88938"]:after {content: '';} .jrd-sig {height: 80px; overflow: visible;} .jrd-sig-deploy {float:left; opacity:0.2;} .jrd-sig-img {float:right; opacity:0.2;} .jrd-sig-img:hover {opacity:0.8;} .jrd-sig-deploy:hover {opacity:0.8;}
Solved!
Go to Solution.
Attachments:
WithCaptions.png ‏102 KB
WithoutCaptions.png ‏96 KB
GraphPerformanceProblems.vi ‏23 KB

Yes, property nodes force synchronous execution and if you do that too often, other things suffer.
The above solution is good. You can simplify things even more by removing all that unneeded extra code that just complicates things.
Here's a quick draft. Let me know if you have questions.
Message Edited by altenbach on 10-10-2008 09:58 AM
LabVIEW Champion . Do more with less code and in less time .
Attachments:
samewithlesscode.png ‏9 KB
GraphPerformanceProblemsMOD.vi ‏19 KB

What are the alternatives to updating indicators using property nodes?

Hello,
I'm building a VI which needs to update several controls/indicators at multiple points throughout its execution. It also needs to be able to accept new values from the controls at any given time.
The problem with this is that all of these controls and indicators are on the front panel of another VI which is calling my VI. The current version of my program updates all of these controls and indicators using references and property nodes (each indicator/control that needs to be used has its own reference control on my VI, and these references are then sent into property nodes), which naturally makes it slow.
At the moment I'm considering rebuilding my VI in such a way that the main one is able to retrieve the data without using references, but this will be not only very time-consuming but also difficult and possibly even impossible without my code turning into a massive disorganized pile (especially since the lab computer is slow enough, and the main VI large enough, that pressing the 'clean/reorganize block diagram' button causes a crash).
Any alternatives to this? Queues?
Solved!
Go to Solution.

This (my Event nugget) is the best general solution I came up so far.
Felix
www.aescusoft.de
My latest community nugget on producer/consumer design
My current blog: A journey through uml

When i change the value of a combo box using a property node it displays the value not the item label

I am using a combo box as a select list for text serial commands. I have items like "engineering", "GUI", and "Scan" for the commands "MDE", "MDN", and MDS respectively which i have input as the corresponding value in the combo box. so for example the label "engineering" has the value "MDE" in the combo box items list. when the Vi starts it needs to read the current value MDE, MDN, or MDS and then i want it to display on the front panel the item text corresponding to that command value.
To do this i have tried to read the serial command, ie MDS and then wire that to a "value" property of a property node of the combo-box, but instead of displaying the corresponding item label, "Scan", it displays the value "MDS" on the front panel instead. i want the front panel to use the label text when choosing and displaying but the block diagram to use the serial commands. Can this be done with a combo box? I'm trying to use a combo box so i can keep it all text and avoid having to build a case statement to convert enums or rings from a numerical value to the text command.
The correct text value is wired to the value property and it does exist in the combo-box. I have unchecked "values match items" and selected to not allow undefined values.

Don't use the value property node. Use the Text.Text property node. When creating the property node, select Text, then in the next pop-up box, select Text.
- tbob
Inventor of the WORM Global

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

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.

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.

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

Using a property node of a menu ring to generate a secondary address does not work in a subvi unless the subvi has been or is opened. Why?

I am writing drivers for third party equipment using LabView 6.1. I am using the property node, digdisp.text, to get the item number of menu ring. This number is being used as the GPIB secondary address for the equipment. This vi is one many subVIs like it in a main vi.
The only way the main vi works consistently is if I open all the subVIs, otherwise the secondary address isn't picked up and I get a EARG and ENOL error in NISpy and a GPIB write error in the Error Out cluster.
I have attached an example of a NIspy capture of a failed attempt.
Attachments:
Capture.spy ‏9 KB

Hi,
EARG (4)
Error Condition: Invalid argument to a function call.
Description: EARG results when an invalid argument is passed to a function call.
Possible Cause: The following are some examples: you call ibtmo with a value not in the range 0 through 17 (possible timeout values correspond to a table of values ranging from 0 to 17, where the default is 13, which represents a 10 second timeout); you call ibeos with meaningless bits set in the high byte of the second parameter; or you call ibpad (or ibsad) with invalid addresses.
The reason you are getting the error is because not only is your secondary address invalid, but your primary address is also invalid. Lines 14 and 16 of your attached NI-SPY capture set
the primary address (ibpad) and secondary address (ibsad) respectively. You need to make sure that you are passing the addresses properly to the subVIs using a connector. It seems like your programming when sending and receiving data (like the addresses) from your subVIs is not correct. You have to be sure to pass the data back and forth in the proper method using connectors.
A.S.
Anu Saha
Academic Product Marketing Engineer
National Instruments

Why knob need to use property node to change its value

Refer boiler vi in CLD exam sample question.
In the vi the knob vlaue is changed with a property node, it is not wired directly to a constant. The comment in the vi is something like "writing using property node because of the latch action of the booleans in the cluster"...
Huh? How do the booleans influence the knob even though they are in a same cluster? What principle is this called? I need to google this up, I didn't read it in.
my Labview books.
Attachments:
Boiler Main LV86.zip ‏61 KB

That comment doesn't make any sense.
There are two main reasons I can think of why you want to use a Value property node.
1. You want to control the order of execution by using the error wire.
2. You want to use a property node on multiple controls by feeding it references to different controls.
Neither of these appear to apply in the screenshot you show.
However, looking deeper, it looks like you can set the value of a specific item in the cluster by way of the property node. Check out the Link to section of its shortcut menu. I don't think you can use a local variable to set a given element of the cluster. Now you could change the value of the entire cluster. Read the cluster, bundle the new value for that one element, write to a local variable of the cluster. But you won't be allowed to do that because of the latched booleans that are a part of the cluster. Hover over the context help of that property node and read the description there as well.

Error 1055 occurred at Property node

Generating the error:
"Error 1055 occurred at Property Node in ... Possible reason(s): LabVIEW object reference is invalid."
when I try to wire the IMAGE OUT output from the IMAQdx Snap vi to the value property of an externally referenced image display control.
To describe in more detail, I have a parent vi with an image display control and a child vi which has a control refnum linked to the parent vi display. In the child vi I create a value property for the refnum and try to write images to it, essentially to drive the parent display from the child vi.
The technique works elsewhere, though I can't think of what I could have done differently to generate this error?

Hi Mike - looks like I may not need to. I've been working away at this and have found the original cause and something else a bit weird...
I deleted the objects from the sub-VI that was giving me errors, then cut and pasted the objects (image display refnum and value property) from a VI that was working and this solved the problem. So you might think that the issue was just some obscure configuration item, or I'd used the wrong type in my reference or something.
I found the display reference in the parent VI was not even wired to the sub VI - duh! Error between keyboard and chair. So at least the original error message made sense, but I have no idea why it actually worked after pasting in the new objects. Are these references using some sort of auto-magic? Who knows. Safer to wire up my sub-VI's properly methinks.
Sorry for wasting forum time on this one.

Property nodes to items in cluster are FRAGILE

Similar Messages

Maybe you are looking for