 |
 |
|
This app is a gadget and not optimized to have the ultimative performance (a lot of UI updates!) but for the one or the other it might be food for a thought
ThSa
says
in response to nrp:
whenever you work with shared variables (SVs) the tagger (variable) engine hosts all the libraries with its variables until you undeploy them. The tagger (veriable) engine is a windows service which is launched per default automatically when windows launches. You can find the service here: Control panel -> Administration -> Services. Look for "National Instruments Variable (tagger) Engine". The more libraries are hosted and the more variables each library has the longer is generally the boot time of windows. To undeploy them it's the easiest way to do it by using the "Variable Manager" in LabVIEW (Tools -> Shared Variable -> Variable Manager). This manager displays all deployed libraries on the host and even the one of specific RT systems. To get the network-published SVs from an RT system you need to add manually the RT system to the tree (right click on RT systems -> Add RT system).
Formerly the variable engine service was called tagger engine, therefore I've used both in this context.
In LV 8.0 to 8.2 the overhead of each shared variable was amazing, that meant to get the best performance it was better to have only one cluster-shared variable which contains all valuable elements (of course, this cannot be used as an RT FIFO shared variable). In 8.5 the performance increased drastically respectively the overhead got decreased, therefore it's not mandatory to take care of the amount of SVs.
nrp
says
in response to ThSa:
Thanks for that insight, I did not know about the Variable Manager!
My question about the performance of the shared variables was that I had read forum posts, then experienced it myself, that the project I was working on became really sluggish. Not when running, but actually during edit mode. I removed the SVs and it seems to be better again.
I won't be relying on them too much, and I prefer a cluster based approach anyway, so hopefully when the time comes to include them back in the project it will be ok.
Legal
This content (includes attachments) has been made available by community members, whom are solely responsible for such content. National Instruments does not support this content, and does not guarantee its quality in any way. NATIONAL INSTRUMENTS MAKES NO WARRANTIES, EXPRESS, STATUTORY OR IMPLIED, WITH RESPECT TO THIS CONTENT, INCLUDING WITHOUT LIMITATION ANY WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE, NON-INFRINGEMENT OF INTELLECTUAL PROPERTY, OR ANY OTHER WARRANTIES THAT MAY ARISE FROM USAGE OF TRADE OR COURSE OF DEALING. For details regarding support of such content, please contact the author. For further legal information, please visit http://ni.com/legal/termsofuse/unitedstates/us/.
ThSa,
Nice gadget!
A question regarding shared variables, I ran your application, and it listed all the shared variables from old projects I worked on. Why are these being picked up when the project has not even been opened for months? Is there a performance penalty on my PC if all these old shared variables are floating around inside the OS? I am fairly new to shared variables, so I probably don't know how they work properly.