Save / Load VI's program settings

[Tofr4n]

I would like to see an option or VI that save / load the state of a VI and there SubVI's at a certain time (all controls I guess).

Background:

In the development of measurement software it is important, in terms of reproducibility of measurement results, to implement an option that save all scalable objects at a certain time (device settings also program settings) which depending a measurement.

Save program settings:

I know there is a way to do this by calling the VI reference and get the control values with property node and save them. But I don't think that's an accurate way because you have to manually do this with every SubVI's reference if you won’t to save them too.

Btw: in LabVIEW NXG, which I really like, it seems no way to do this because there is no 'Get Control' property node?!

Suggestion:

- two VI's which save/load all scalable program settings to/from file (hopefully in the standard data save VI Palette)

[AristosQueue (NI)]

If you have to save the settings of your subVIs, I'm going to strongly argue that there's something severely broken about your test hierarchy. What are you doing such that that is a requirement? It's a pretty exotic requirement, and rather than discuss how to achieve it, I'd rather find out how to get you out of needing it.

(Note that I think most G architects will agree that having to save off the control settings of the top-level VI is a bit of a hack also -- it would be far better to have those "settings" read from and written to files as part of the test harness. But there's a time and a place for such hacks, so I'm not objecting to anyone using that approach. But subVIs are a different story.)

[AristosQueue (NI)]

Tofr4n, I noticed that you're a new user on the forums, so I figured an introduction was in order. I'm a senior developer with LV R&D who frequently kibitzes on the feasibility of ideas that appear on the Idea Exchange. I believe users when they tell me they have a problem. I often push back on the particulars of the solution requested in an effort to find the best solution for the users.

[Tofr4n]

Thank you for your reply.

Ok I see l doesn’t make the right explanation:

If you have a program that have a huge amount of controls and you don’t won’t to handle this all alone on the top-level VI. For example each device has his one SubVI which his depending controls.

And then you won't to save this settings in runtime.

Is that such an exotic thing? Or do I completely miss something in my architecture?  

[wiebe@CARYA]

>Is that such an exotic thing? Or do I completely miss something in my architecture?  

Of course there are patterns we all use for this.

Read\Write to ini\xml\json\db\whatever, by getting all control references, and in a for loop go over each one of them and "read and set" or "get and write" the value. Use the labels to get a name\value pair. Hardest thing is to convert every data type to text and back. But this has been done and this is available.

Note that a 'build in' solution that pleases all will be near impossible. There are simply too many variants in doing this. For instance, saving all controls is probably not desirable. After the user presses 'save' you would not want save=true to be stored, as save will be set to true automatically after a load. If you have 5 graphs showing the same data, you wouldn't want all 5 graphs stored (maybe 1 or maybe none).

[Tofr4n]

>Read\Write to ini\xml\json\db\whatever, by getting all control references, and in a for loop go over each one of them and "read and set" or "get and write" the value. Use the labels to get a name\value pair. Hardest thing is to convert every data type to text and back. But this has been done and this is available.

How I try to mention in my first post, the current way to save controls is known to me.

>Note that a 'build in' solution that pleases all will be near impossible.

I mean the option ‘make current value default’ is somehow similar.

>There are simply too many variants in doing this. For instance, saving all controls is probably not desirable. After the user presses 'save' you would not want save=true to be stored, as save will be set to true automatically after a load.

Of course this makes no sense for Button-Controls. I have thought about controls which are more scalable, maybe then there has to be the option for every control to save them or not. For Buttons this would be non-saving by default.

>If you have 5 graphs showing the same data, you wouldn't want all 5 graphs stored (maybe 1 or maybe none).

I don’t get this one. Saving results have to be handling different of course but that’s not my point here.

Thank you for the discussion.

[wiebe@CARYA]

What makes a 'button' stand out from a Boolean option?

What makes results different from values?

What format to save in?

How to handle recursive data?

What to do with enums (store text or number)?

>>Note that a 'build in' solution that pleases all will be near impossible.

>I mean the option ‘make current value default’ is somehow similar.

I mean this is typically something that every programmer wants to do in a specific way. A general feature probably won't be used, as it doesn't match any of those specific ways.

You can get very close to the scenario you describe. If you make a right click menu or quick drop plugin, and use tags to mark the controls. Then make a VI that traverses the VI(s) and reads the tags.

I'm not convinced NI should make things like this. Or rather, I think NI shouldn't or can't.

[Intaris]

Depending on what you're trying to do, right-click the sub-VI and choose "Enable database access". I don't know if this works in NXG.

That'll open a can of worms.

I'll get my coat.

[Tofr4n]

Maybe here is some misunderstanding.

Following scenario:

If I start loading the program, Labview preloading all controls to their default values (that Labview internal saved before somehow).

Now I won’t to load different values that I have saved at a certain time. That’s all.

I don’t see that this is such a big deal. For example it doesn’t care which format to save in. It can be a format where NI has the best way to deal with this, maybe the same way in which the default values are saved.

Sorry if I miss something here or have the wrong perspective on this.

[crossrulz]

Again, that is the point of everybody using ini/xml/json/csv files to store those settings.  I much prefer having full control over what needs to be saved, what the default values should be, how to handle bad values, etc.  And most of those settings, at least for me, do not end up on a front panel.  They go straight into a class private data and/or a shift register.  This is not something NI should be spending their time on.  As wiebe already stated, there are way too many variables for NI to handle this well.

[wiebe@CARYA]

>I don’t see that this is such a big deal. For example it doesn’t care which format to save in. It can be a format where NI has the best way to deal with this, maybe the same way in which the default values are saved.

Where to store this data? (It won't be available to others unless stored in the VI (like the default values). This will mean SCC hell). 

When to clear this data? (We don't want this growing forever)

When to store? (When values change? When LabVIEW closes? When the VI is closed? Or when VIs leave memory?)

Users will also want to revert values and cancel storing values...

Users will also want to pick a settings file, and choose names to save settings

All these issues are solved by investing a little time to make it yourself. And that will work for everyone.

Any build in solution will be limited, and only useful in trivial cases.

IMHO, of course.