Setting and saving values on Dashboard

[fovea1959]

we're doing vision on our DS, and we're going to need to save all the vision parameters when we get to the venue and do calibration, then load them when we load the DS before a match.

I'm thinking about the best way in LV to pick up the initial values of a lot of controls on the DS (and some subVis). I saw this article Remembering Control Values, and am also aware of the ability to put the control values into a cluster and use cluster-to-XML and XML-to-cluster to save and load.

If I do XML cluster save and load, it looks like load would have to (for each saved value) get the value from the bundle, explicitly get the appropriate control refererence, and set the value). Do I have this right, or is there an easier way to load?

Making the cluster and saving the values looks simpler, just bundle up the values and write them.

Am I barking up the right trees, or is there an easier way to do what we need? We will *not* be running the development environment on the field for calibration, so saving current values as default is not an option.

[Mark McLeod]

The current default dashboard already uses an .ini file to save camera settings, located in

C://Users/Public/Public Documents/FRC/DashboardSettings.ini

You could just add your values to that and keep them all in one place.
You can just follow the example that reads both the .ini file or the team Checklist text file down at the bottom of the Dashboard block diagram.

[Greg McKaskle]

The white paper introduces the ini VIs, or the Config VIs I think they are called. As you said, XML, a text file, or even a binary file will work. I chose the ini file for the driver station and dashboard for the occasions when people want to view or edit it by hand. People may claim that XML is human readable, but not by normal humans.

The biggest difference in the approaches is that XML can encode more data types than ini, but ini is more human readable.

The other axis of this is how you read and write to the controls and indicators. You can use locals, value properties, or even VI server methods that are name and variant based. In my opinion, it is really a personal preference as to which to use. All of them work fine. The value and method allow the code to go into a subVI and are therefore more compact and more extensible, but are initially a bit harder to read and somewhat more brittle when things change.

Greg McKaskle

[fovea1959]

Greg: Your last paragraph (writing the freshly read "initial" values to the controls) is what I trying to figure out. XML doesn't scare me if it makes everything else easy and robust.

When you write

The value and method allow the code to go into a subVI and are therefore more compact and more extensible, but are initially a bit harder to read and somewhat more brittle when things change.

I'm having trouble interpreting "value and method". Are you referring to one of the methods in Remembering Control Values?

[Greg McKaskle]

The attached image shows the palette that exposes the VI Server. The VI Server is a hierarchy of class oriented services to the LabVIEW editor itself and to the objects on panels.

To the left of the palette are the VI methods for getting and setting a control value by name.

To their right are property nodes that get or set the value via an object refnum. You get the refnum using other VI server icons, or you can use linked property nodes that are bound to a specific control.

The VI Server is super powerful, but not the simplest thing to figure out. You may find the examples helpful, and you may also decide that the locals are good enough for what you are doing and you don't need a more extensible solution like VI Server.

Greg McKaskle