I'm working through some of my oldest code right now, looking to increase performance where I can. Here's my situation:
1. I used Global Variables to propogate a few constants into my VIs, instead of an appropriate typedefed cluster.
2. Execution doesn't take any additional time, but any time I save the project, I'd say 50-60% of the saving/compling time is spent on the 300 or so VIs with the global variables. I suspect this has to do with the linking overhead associated with the global.
3. Ideally I'd like to replace this:
With something like this:
While also setting the connector pane from this:
Is this something the VI Server is capable of? You can assume that the VI's in question have very predictable names, matching the regex:
Is this even worth it to replace?
Solved! Go to Solution.
You might be able to do a search and replace. Then fix up each instance because it probably won't replace correctly. But then again, the broken arrow will be your guide. I'd probably stay away from "replace all" if your global has more than one element.
I'm guessing you hoping to replace a bunch of Globals with a single Cluster whose elements are all of your (former) Globals. I'm not sure why you are passing this "Constant Cluster" as an input/output through your various sub-VIs. How about writing a Constant VI, a VI that has a single output that is "fed" by your Constant Cluster? Now, every place you use your Global, replace it with your Constant VI (which outputs the Cluster), unbundle the Cluster to get the parameter(s) you want, and you are done. The calling VI uses no Connectors (you put the Constant VI inside the calling VI, just as you did the Global).
You mentioned using VI Server to do a multi-VI "edit". Huh?
Let me know if this makes any sense to you.
Every time I thought I had to modify something during runtime, I found a simpler - and less obfuscated - way of doing things.
The constant cluster needs to be modifiable at runtime, initialized at the beginning and then held. In which case the only way to not wire it all the way down is to use a functional global, which kind of defeats the purpose.
Why does a write-once, read-many FGV "defeat the purpose"? I guess I don't understand the Purpose, as this is precisely what I do, and what I've seen recommended by others on the Forum far more experienced than I (usually in conjunction with discussions of Configuration Files as a way of doing the definition).
I asked about the VI server on the off chance there was some edit-mode method to setup the connector pane.
Have you looked at LabVIEW Scripting? You need to enable it (it is disabled by default) by going to Tools, Options, VI Server (aha -- maybe that's where the reference to VI Server comes from ...) and checking VI Scripting. There are examples out there that show how to use it. I have a little experience with it -- I've used it to create a "Custom LabVIEW Cluster" based on an Excel Workbook used to define the variables needed for a Data Acquisition/Control routine (it's a moving target -- just when you think you've defined all of the Experimental Parameters, some graduate student says "But why don't we also flash a light during the Trial", and you need to add four more entries to handle the Flashing Light parameters ...").
The purpose, as stated in the original post, is to decrease the time spent saving and compiling these VIs, which take a disproportionate amount of time as compared to the ~700 other VIs in the project. Functional globals, I thought, were about on par with normal globals in terms of that time, though I could be wrong.
I don't know what you mean by compile time. One of my larger LabVIEW RT Projects, which has about a thousand VIs, has plenty of VIGs (FGVs), Action Engines, even a few Globals and Shared Variables. In my case, the thing that seems to "slow down" the Compile the most is the links to the Report Generation Toolkit (I use Excel Workbooks to "drive" the Experiment and also save a little data). If I do a Build All, to build this routine and about 6 "support" routines (Data Analysis, Configuration Utilities, etc.), it might take a minute, but I don't find this excessive nor a burden (compared with the ease of isolating/encapsulating functionality in sub-VIs such as FGVs). So I guess I don't understand the "real problem" ...