From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Best way to distribute configuration values to subVIs

I have a main VI with ~10 subVIs, all of which have a number of default constants embedded. I want to change my architecture so that all the constants are moved to a single ASCII text file which is not changed during program execution. I'm trying to decide the best way to do this:

- Read the file every time a subvi is opened (this is frequent).
- Use the "Read Key" function (this may be essentially the same).
- Read the file once at the beginning of execution, and store the values in a cluster which is passed to each subVI.
- Read the file once at the beginning of execution, and store the values in several clusters, passing only the needed values to a given subVI.
- Read the file once at the beginning of execution, and store the values in a functional (LV2) global which is read by each subVI when it is called.

I think all of these would work, but what would be the most efficient in terms of programming time, execution time, memory usage, and ease of future modification? I'm leaning toward the multiple clusters approach so that I'm not constantly reading a file each time a subVI opens.

Thanks to all,

James
0 Kudos
Message 1 of 5
(2,470 Views)
I have had exactly the same problem and over the years I tried various solutions, mostly based on an .ini file. The solutions using a cluster (read config file into a cluster at the start of business) work fine until you think of another parameter. My current solution is a configuration file toolkit which stores the variables and their names in parallel string arrays. You can read them quite easily, and even write them for temporary storage.
John Brohan www.tradersmicro.com check in the downloads section.
0 Kudos
Message 2 of 5
(2,458 Views)
Consider using what I call a "manager" VI. Its purpose is to manage the file for you.

You call it whever you want to know one of these parameters.
It knows whether it's read the file yet or not. If not, it does so on first call.
After that, it simply keeps all your values in its own memory (shift registers).
When you call it, it simply gives you the value(s) out of its memory, either as a big cluster, or as separated values.

That way, you only read the file once.
Steve Bird
Culverson Software - Elegant software that is a pleasure to use.
Culverson.com


Blog for (mostly LabVIEW) programmers: Tips And Tricks

Message 3 of 5
(2,445 Views)
I would go with the write/read keys to/from an *.ini file. Then use a cluster with the enhancement of creating a typedef control and/or indicator for the cluster. If more fields are needed later, you just edit the typdef once and it applies the changes throughout all the vi's. You just then have to unbundle and bundle (preferably by name) your new field and wire where needed.
Since you are just reading, then you only have to deal with unbundling.
~~~~~~~~~~~~~~~~~~~~~~~~~~
"It’s the questions that drive us.”
~~~~~~~~~~~~~~~~~~~~~~~~~~
Message 4 of 5
(2,435 Views)
Thanks to everyone for writing in. I looked at the options some more, and the "manager VI" with uninitialized shift registers for each subVI seem like the way to go. The application will run for a long time (weeks) and will not be writing to the configuration file. This approach will allow the file to be read just once, and then the shift registers will "remember" the values from then on. Any changes will be localized to the subVI.

James S
0 Kudos
Message 5 of 5
(2,402 Views)