Setups subpackage¶
Each experiment uses a setup. Each setup in turn consists of different components that each have their connection. The base class for setups is eprcontrol.setups.Setup
. Every setup should inherit from this class.
There are currently a number of derived classes designed to control a particular setup, for the time being dedicated to time-resolved EPR. However, in a long run, these classes are no longer needed, as the setups can be defined using description files. For details, carry on reading.
Defining setups using textual descriptions¶
One can think of a setup as a simple list of components with each their individual connection. Hence, it is rather straight-forward to formalise the description of setups in simple config files and create the necessary classes a setup consists of on the fly.
An example of such a setup description using the YAML file format may look like the following:
connections:
xenon:
type: BrukerXenonXmlrpcConnection
configuration:
ip: 192.168.1.1
port: 4711
spcm:
type: SpcmConnection
components:
microwavebridge:
type: BrukerXenonMicrowaveBridge
connection: xenon
fieldcontroller:
type: BrukerXenonFieldController
connection: xenon
digitizer:
type: SpcmM4i4421x8
connection: spcm
Here, you can see how to create a setup for time-resolved EPR spectroscopy, consisting of three components: a microwave bridge, a magnetic field controller, and a digitizer. Note that two of the components share the same connection. Therefore, there is only two connections defined, but three components. Besides that, the setup description should be self-explaining. The connections defined can be referred to by their names, thus reusing one connection object for several components. Note that currently, the descriptions are not parsed for errors, hence every typo in a class name will inevitably lead to immediate error messages on the MATLAB® command line.
A note on the configuration for the connections: You can set any parameter that is understood by the respective connection class, i.e. where the configuration
struct of the class has a corresponding field. That means that misspelling field names will prevent the settings to take effect. Furthermore, you need not to specify all configuration values here, but can rely on the defaults set in the respective connection class.
Todo
For this functionality to reveal its full potential, one would need to create an infrastructure and define a strategy where to store setup descriptions (and possible other configuration files). The setup definition should be stored in the user space, whereas the eprcontrol toolbox will usually be located elsewhere.
Classes¶
-
class
eprcontrol.setups.
Setup
¶ Bases:
dynamicprops
Base class for setups
Setups consist of components represented by objects of class
eprcontrol.components.Component
.-
components
¶ list of objects of class
eprcontrol.components.Component
- Type
cell array
-
connected
¶ connection state of the setup
- Type
boolean
-
from_file
(filename)¶ Create a setup based on a configuration file.
- Parameters
filename (string) –
name of the file describing the setup
Usually, YAML files will be used, but you can use any format the
eprcontrol.configurations.Configuration
class understands.
Usually, setups are simply lists of components with each an individual connection. Hence, one can completely formalise the description of setups in simple config files and create the necessary classes a setup consists of on the fly.
An example of a setup description in a YAML file may look like the following:
connections: xenon: type: BrukerXenonXmlrpcConnection configuration: ip: 192.168.1.1 spcm: type: SpcmConnection components: microwavebridge: type: BrukerXenonMicrowaveBridge connection: xenon fieldcontroller: type: BrukerXenonFieldController connection: xenon digitizer: type: SpcmM4i4421x8 connection: spcm
Here, you can see how to create a setup consisting of three components, a microwave bridge, a field controller, and a digitizer. Furthermore, you can see that two of the components share the same connection. Therefore, there is only two connections defined, but three components. Besides that, the setup description should be self-explaining.
-
connect
()¶ Connect the setup
If the setup is already connected, i.e., its
connected
property is true, nothing will be done. Otherwise, for each component, theconnect()
method will be called.
-
disconnect
()¶ Disconnect the setup
If the setup is not connected, i.e., its
connected
property is false, nothing will be done. Otherwise, for each component, thedisconnect()
method will be called.
-
set_properties
(parameters)¶ Assign values to properties
If the “parameters” structure contains a field that corresponds to a property of the class, set this property to the corresponding value of the struct.
- Parameters
parameters (struct) – Structure with fields (keys) corresponding to the properties of the class. Only those properties will be set.
Note
This functionality will eventually perhaps allow to create setups by simply defining their components and connections in a configuration file.
-
apply_settings
(parameters)¶ Set parameters for each component
If the “parameters” structure contains a field that corresponds to the lowercase type of a component of the setup, apply the parameters stored in the corresponding value of the struct to the component. Afterwards, the parameters are applied to the hardware.
- Parameters
parameters (struct) – Structure with fields (keys) corresponding to the components’ type (in lowercase) of the setup. Only for those components the parameters will be set and the settings applied.
-