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
Similar Messages
-
HELP! I am new to LV programming and have a problem. First of all I
only have the evaluation version of LV 6i. I have looked through the
online doumentation and the PDF manuals. What I am trying to do is
have the fill color of a thermometer change when a certain temp is
reached. This has got to be simple and I think property nodes are
involved. This can't be too hard!Another alternative is to create a relationship between the current temperature and the color. Colors are made of the combination of Red, Green and Blue, each of them ranging from 0 to 255 (usually). If your temperature goes from 0 to 100 C, you can use the relationship 255/100.
Attached is an example.
Regards;
E. Vargas
www.vartortech.com
Attachments:
thermometer_example.vi 34 KB -
Hi,
I have about 10 or so numeric indicators that I modify their properties so I can change the background colors etc. The problem is, these indicators are not bundled or anything, so I bascally have 10 different property nodes that I have to wire and it looks bad in the block diagram. I was wondering if there is a way to bundle only the property nodes in the block diagram and apply the changes directly to the bundle so my code would be cleaner. Hope my question is clear enough. BTW, the changes made to every indicator property nodes are the same.
Thanks
YohanAttached is a vi and an image of the block diagram.
Edit: The VI will not run as is, you need to wire something to the property node in order for it to run.
Message Edited by Novatron on 06-23-2006 09:21 AM
Message Edited by Novatron on 06-23-2006 09:22 AM
Attachments:
Properties.vi 11 KB
Properties.jpg 55 KB -
I have a graph chart with 3 plots. I can make any of the plots visible or not using property node as shown in the attached file.
Is there a any way I can scale the block diagram and use less case structure . for instance is it possible to use just one case structure to set the plot visible property of the three plots.
Thank you.
Attachments:
PropertyNodeChartAssign.vi 29 KB(You are using way too much code for these cases! Your true and false cases only differ by the boolean, which you already have from the control. In a first cleanup, you can delete the case structure and wire the button directly to the "visible" property. Same functionality! Right?)
Still, that's not the way to go!
Property nodes are expensive! You only need to write these properties if one of the selector changes, and not with every iteration of the loop! You should handle these thing in a seperate loop using an event structure. Attached is a simple example. See if it makes sense.
Notice that the bottom loop waits until needed and rarely spins.
Also: Instead of a column of similar controls, use an array of controls. Instead of using thee sets of "dices" use one in a FOR loop.
Message Edited by altenbach on 05-18-2007 08:32 PM
LabVIEW Champion . Do more with less code and in less time .
Attachments:
ChartVisible.png 16 KB
PropertyNodeChartAssignMOD.vi 28 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 -
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 TricksCoastalMaineBird 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 -
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? -
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,
BrettHi 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. -
Is it better to use Invoke nodes or property nodes to set/get control values?
I have a series of VI's that run in parallel, each to manage different functions- pumping, sensing, a fluid flow model, an experiment generator/runner.
These need to exchange data, which I am currently doing using invoke nodes (that are all in subVIs), using methods "Set control value" and "Get control value". I find that every now and then (perhaps 1% of the time) the data isn't exchanged correctly and therefore the system doesn't work. I can imagine how "set" could go wrong if they happen simultaneously, and can devise ways of preventing this. However, the "Get" method suffers from the same problem. This is a major problem, because I want to leave it running for several hours.
I could in
principle achieve the same thing using property nodes and find myself wondering if this might be more reliable. But I don't want to change over only to find it makes no difference!
Can anyone advise?You can use some kind of syncronization such as queues, occurances, or notifiers but I think the easiest way would be to create and action engine. This was only one action can execute at a time avoiding a "race condition". Possibly a write action and a read action might help. You also can add queues or notifiers into this concept. hope this helps.
BJD1613
Lead Test Tools Development Engineer
Philips Respironics
Certified LV Architect / Instructor -
How can I make a "property node" for a VI?
Hello!
If I add a boolean button on the FP then I am able to make a property node for that button in the Block Diagram. But how can I make a property node for a VI? I have several VI:s an that together is one program. What I need to do is to verify what kind of VI some of my VI:s is. I need to verify if it is .exe or .vi-file, and if it is .exe then I want to disable run, abort, run continuously bottons otherwise not. I have hard that this is possible to do programmaticaly but I can´t figure out how. I am aware that I could do that manually in the File->vi properties->customize->windows appearance but theese choises makes it last forever.
I want to be able to stop and run and everything if it is a .vi file, but if it is .exe-file then all those buttons should be disabled.
Anyone have an example on this?
In an other message at this Forum I read "You can use the `Front Panel Window. Allow Runtime PopUp`" property to disable run-time shortcuts menues programmaticaly, but still I dont know how to create this property node.
/AmirYou really shouldn't open a new thread. If you don't understand something, ask and we will explain it.
Like I said in the other thread, you can check if you are running in LV or an EXE by using the Application>>Kind property. To get it, place a property node (from the Application Control palette) on the diagram, click it and find the property.
To set the properties for the VI, place another property node, right click it and select Select Class>>VI Server>>VI. You should have the properties you want under Front Panel Window.
To learn more about LabVIEW, I suggest you try searching this site and google for LabVIEW tutorials. Here and here are a couple you can start with. You can also contact your local NI office and join one of their courses.
In addition, I suggest you read the LabVIEW style guide and the LabVIEW user manual (Help>>Search the LabVIEW Bookshelf). I believe chapter 17 of the user manual explains about programmatic control of VIs.
Try to take over the world! -
Need to input a value in a Property Node that doesn't have "Change All to Read" property.
Hi,
I am developing an remote panel application that have 3 vi's.
1 - Login vi => If username and password is OK, then the login vi add the Main vi to access list, and the user can access it.
2 - Main vi => Is the main code
3 - Supervisory Panel => Have a property node (RP.Conn.To.Clients), that searches (with a for loop, number of interations = number of online users), and compares the online users to a condition: if the user is controlling the Main.vi, if yes, I display the user information(IP, Status, Port) on the Supervisory Panel.
My issue is, I need to display also the username(inputed in Login.vi), togheter with IP, Status, Port, that are provided by Rp.Conn.To.Clients.
So i need to know if there's a way to attach the username string with the information provided by RP.Conn.To.Clients, in the same index, because my application will be accessed by many people, and I need to attach several usernames with the information that the property node provides, in the same index.
Any help will be appreciated, im stucked on this for almost a week!Not sure if this is what you meant, but you can change the read/write for each property on a property node individually.
Bill
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all. -
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 -
How to find Property Nodes in other VI's
I am working on an application that I have inherited from others. It has huge, and in my opinion, very complicated and difficult to follow block diagrams. Here is the essence of the problem I am facing. On the main front panel there are various controls and indicators, but on the block diagram, none of them are wired to anything. So that means that (whomever it was before me) used property nodes on these controls and indicators. However, it looks like none of the references exist anywhere within the same .vi.
I have used the "Find reference" selection, but that only seems to work within the current .vi that I am already in. So I guess I have two questions...
1 Is there a way to search aross multiple VI's for a reference to a conrol or indicator?
2. To set up a program in such a way seems completely "bonkers" to me, as there is now no easy way to find where any of the controls or indicators are actually being set from. Considering there are something like 100 .VI's in this project, finding something is a bit challenging. Of course, there is not documentation of any sort. I am certainly NOT a labview expert. Perhaps there really IS a reason to set things up this way, that I am just not thinking of. Can anyone think of reasons why it might be a good idea to set things up that way? I would think that whenever possible you would want to wire directly to a control or indicator. And if you cannot do that, at least have the reference in the same .vi, and pass it into something else if needed.
Thanks....
DanFinding the where used cases for named queues and where obtained cases for vi server references to controls can get frustrating. The "find" feature in LabVIEW does allow text searches with several options.
Finding the String "<QueueName>" within the application instance on BD only and ignoring hidden stuff gets you to string constants that are exact matches to the queuename:
Searching for property node to a specific FP Object throughout a hierarchy can get devistating. Especially if the developer used the call chain to obtain a ref to the top level vi panel and pulled a rerence to a control that way
(DO NOT DO THIS) but I've seen it done:
Its "Legal" but almost garunteed to cause the guy who inherits your code to denigrate your parentage and intelligence. HOWEVER: that same text search for the control label text will find those string constants too.
Then document that code when you find out who is messing with what and how.
Chart it out over the app and e-mail that scribbling to the original developer too! Feel free to add a thank you note.
Jeff -
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 KBI 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 -
Performance penalty with property nodes?
In a specific application I have a front panel with three combo boxes and another three string indicators. Based on the selections made in the combo boxes, various messages will have to be displayed in the string displays. This naturally calls for multiple instances in the same VI where the combo boxes will have to be read and string display updates.
One choice would have been local variables ( of combo boxes & string indicators ) for passing the values around. But since this is going to make several copies and hit performance, I decided to use property nodes. And it works fine.
The question is, whether excessive use of property nodes has any adverse effect on performance ?
Thanks
Raghunathan
Raghunathan
LV2012 to Automate Hydraulic Test rigs.Thanks! I would suggest to just do the experiment.
The attached little demo (LabVIEW 7.1) does the same thing (increment a I32 variable in a loop) in three different ways:
-- shift register
-- local variable
-- value properties
On my slow laptop, 10000 iterations take the following total time in ms.
shift registers: 3ms
Local variables: 5ms
Value Properties: 1891ms (!!)
Notice that the shift register solution would be much faster (more than 10x (or 1000000 in 20ms)) if the indicator is placed outside the loop, the only thing slowing it down is the update of the indicator.
In conclusion value properties are much more expensive than local variables or shift registers. If you just write once e.g. at the beginning of the program, it does not really matter, but once you do things repetitively in a loop, the costs add up. I always prefer wires because they also make the diagram easy to follow. Local variables break the dataflow and can cause race conditions. They have their limited use, especially in user interface related code. They have no business in pure computations.
LabVIEW Champion . Do more with less code and in less time .
Attachments:
timers.vi 47 KB
Maybe you are looking for
-
Data source for Commitments COSS-WRTTP 21,22
Hello all, Is there a CO datasource where can I get a deeper detail of commitments (value type 40) than 0CO_OM_CCA_1? I need to trace which values come from purchase order and which from purchase order request. Information is stored in COSS-WRTTP bu
-
Errors on open large jpeg files in Windows 2000
Q. I am having problems opening large jpeg files (eg 40"x30" @270 ppi) after having saved them in Windows 2000 A. This is a known issue and can be resolved either by turning off thumbnails for JPEGS or by using the JPEG2000 file format. The Photoshop
-
hei , i was window user an just switched to ipone 6 , can i merge my contacts group from windows to IOS ? please quide
-
Configurable data-source in orion-ejb-jar.xml
Hi, In my orion ejb-jar.xml file, I have hard coded data-source entries for all entity beans , i.e. <entity-deployment name="Customer" data-source="jdbc/slldev02DS" table="CUSTOMER"> Is there any way, I can make this customizable, i.e. feed in or def
-
How to activate existing domain
Hi, I already created one domain, but now its not active , but i am try to create domain with same name its coming error message domain already exist. Please give me solution how to activate existing domain. Regards janardhan