Saving and Loading Configurations

Saving and Loading Configurations

In most cases you will probably want to save configurations from your program. Ranging from instrument addresses to experiment parameters.

This is made easy by use of the ConfigStore class. This page serves as a guide on how to use ConfigStore objects.

Getting Started

The first thing to do is instantiate a ConfigStore object. You do this by specifying a name for the config.

ConfigStore config = new ConfigStore("ConfigName");

If a config with this name already exists, then its contents are loaded into the newly created config object, otherwise a new, blank config is created.

The actual data in the config is saved as a JSON file at:

Windows

C:\Users\<your username>\.config\ConfigName.json

Linux/Mac

~/.config/ConfigName.json

Saving and Retrieving Parameters

Information is stored in a config using a key-value pair system. Each piece of information is given key, which acts as a label or variable name. When retrieving that was saved before, the key is used to refer to it.

For example, let's say we wanted to store the last "Minimum Voltage" value used, then we could store it with a key "minV" and then later retrieve it like so:

double minVoltage = minVoltageField.get();
config.set("minV", minVoltage);

then later, when the program is run again...

double lastMinVoltage = config.getDouble("minV");

For retrieving information there are several methods, which one you use depends on what kind of variable you want out:

String  textData = config.getString("key");
int     intData  = config.getInt("key");
double  dblData  = config.getDouble("key");
boolean boolData = config.getBoolean("key");

You can check whether the config actually has the information you are looking for stored or not by use of has(...) like so:

double lastMinVoltage = 0;

// If minV is there, then use that value, otherwise leave it as 0
if (config.has("minV")) {
    lastMinVoltage = config.getDouble("minV");
}

Every time you set a parameter, it is automatically written to the config file. Using set(...) with a key that already have a value will over-write that value with your new one.

Instrument Connection Configurations GUI

There is a GUI element for configuring instrument connections. This is called the ConfigGrid. You create it much like you would any other GUI element:

ConfigGrid configGrid = new ConfigGrid("Instrument Connection");

If you have a ConfigStore you can give it that as well and it will store your connection configuration along with your other config data automatically:

ConfigStore config     = new ConfigStore("experiment");
ConfigGrid  congigGrid = new ConfigGrid("Instrument Connection", config);

Then you can add instrument configurations to it like so:

InstrumentConfig<SMU>         smu1Conf = configGrid.addInstrument("SMU 1", SMU.class);
InstrumentConfig<SMU>         smu2Conf = configGrid.addInstrument("SMU 2", SMU.class);
InstrumentConfig<TController> tcConf   = configGrid.addInstrument("Temperature Control", TController.class);
InstrumentConfig<LockIn>      lockConf = configGrid.addInstrument("Lock-In Amplifier", LockIn.class);

This results in the following:

As we can see, this allows the user to select:

• Which driver class to use to control the instrument
• Which protocol to connect using
• The address of the instrument on that protocol

Alternatively, users can click the "Browse" buttons to see a list of all detected instruments and select from there, much like with GUI.browseVISA().

Now, to better understand the code we have just written, let's look at the arguments we gave:

configGrid.addInstrument(
  "Instrument Name",      // This is the name of the instrument to show to the user
  DriverType.class        // This is the class of the type of instrument we want here
);

For our two SMUs, we only want instruments controlled by classes extending from SMU (ie we want an SMU!!!). This is why in the second argument we specify SMU.class. By writing SMU.class we're passing the class definition of SMU as our argument. This lets it know that it should only give the user a choice of driver classes that extend from SMU when configuring the instrument connection. As a result the options in the "Driver:" drop-down box will only be SMU drivers (eg K2450, K2600B, K236 etc).

As we can see addInstrument returns objects of class InstrumentConfig. This is a generic class where the generic type is the class of instrument object we expect to get out of the config. So, if we chose SMU.class in the method call, we will expect to get an SMU object upon successful connection, hence why we have:

InstrumentConfig<SMU>

as the type for smu1Conf and smu2Conf, and

InstrumentConfig<TController>

as the type for our temperature controller configuration etc.

These objects allow you to interact with the configuration. For example, if successfully connected you can call get() to retrieve the actual instrument object itself like so:

SMU         smu1 = smu1Conf.get();
SMU         smu2 = smu2Conf.get();
TController tc   = tcConf.get();
LockIn      lock = lockConf.get();

You can also get and set the address and driver selected:

InstrumentAddress address = smu1Conf.getAddress();
Class             driver  = smu1Conf.getDriver();

smu1Conf.setAddress(new GPIBAddress(0, 20));
smu1Conf.setDriver(K2450.class);

as well as checking if successfully connected yet:

if (!smu1Conf.isConnected()) {
    GUI.errorAlert("Error", "Not Connected", "SMU1 is not connected!");
}