The state of the GUI can always be saved to a file by means of the "Save as..." and restored from file via the "Load..." menu options. Saving the state of the gui produces a tcl script that can be executed for configuring the device exactly as the GUI would display it. Note that this is not necessarily the state of the device itself, because the GUI and device are not necessarily identical unless settings are either committed or the gui is updated. To execute the script produced by the the GUI in a tclsh, the user must ensure:
The driver scripts are included in the TCLLIBPATH environment variable. These scripts should be usable if the user adds $DAQROOT/TclLibs to their TCLLIBPATH environment variable.
The same settings for the communication protocol that were valid when the script was generated are still valid. In other words, if the GUI was launched with --protocol usb --serialfile /dev/ttyUSB0, then it must still be possible to write to the device through the /dev/ttyUSB0 file. The same idea must be true if the protocol was mxdcrcbus. If these have changed, the first few lines must be adjusted accordingly to instantiate the appropriate driver type. MCFD16USB types are used for usb communication and the MCFD16RC and MXDCRCProxy are used together for the mxdcrcbus.
# USB instantiation and use example package require mcfd16usb MCFD16USB ::dev /dev/ttyUSB0 ::dev SetThreshold 0 12
# MxDC RC-bus instantiation and usage package require mcfd16rc MXDCRCProxy ::proxy -server localhost -port 27000 -module myproxy -devno 3 MCFD16RC ::dev ::proxy ::dev SetThreshold 0 12
At this point you can simply feed the script to a tclsh program. For example, executing a file called mysettings.tcl, you can do the following:
tclsh < mysettings.tcl
Like saving, restoring implies that a setting is loaded to the GUI rather than immediately loading to the device. The user should select a tclscript that was either generated by the GUI through a save as operation or some other one that contains appropriate device driver calls. Loading the file causes the lines that are understood to be driver calls to be executed and loaded into the GUI. Furthermore, lines that set channel names (set ::MCFD16ChannelNames::chan0 name) are executed and read into the GUI. Other lines of code are not evaluated. it is important to note that this is not fully fool proof. It is important that the user refer to only one instance of a device driver in the script. For all of the parameters that are not set, the GUI will show "NA". It is possible to commit the state to the device when some parameters show "NA" because only valid parameters will actually affect the device. In other words, values that show "NA" are ignored during the commit.