Two concepts are central to almost any object in the API: Attributes and Modules.
Attributes are essentially variables which are automatically synchronized between a number of devices, i.e. the value of an FPGA register, a config file to store the last setting on the harddisk, and possibly a graphical user interface.
Modules are essentially collections of attributes that provide additional functions to usefully govern the interaction of the available attributes.
It is recommended to read the definition of these two classes, but we summarize the way they are used in practice by listing the important methods:
A module is a component of pyrpl doing a specific task, such as e.g. Scope/Lockbox/NetworkAnalyzer. The module can have a widget to interact with it graphically.
It is composed of attributes (see attributes.py) whose values represent the current state of the module (more precisely, the state is defined by the value of all attributes in _setup_attributes)
The module can be slaved or freed by a user or another module. When the module is freed, it goes back to the state immediately before being slaved. To make sure the module is freed, use the syntax:
with pyrpl.mod_mag.pop(‘owner’) as mod: mod.do_something()
_init_module(): initializes the module at startup. During this initialization, attributes can be initialized without overwriting config file values. Practical to use instead of init to avoid calling super().init()
_setup(): sets the module ready for acquisition/output with the current attribute’s values. The metaclass of the module autogenerates a function like this: def setup(self, kwds): *** docstring of function _setup * *** for attribute in self.setup_attributes: print-attribute-docstring-here ****
self.set_setup_attributes(kwds)
return self._setup()
_ownership_changed(old, new): this function is called when the module owner changes it can be used to stop the acquisition for instance.
The parameters of the modules are controlled by descriptors deriving from BaseAttribute.
An attribute is a field that can be set or get by several means:
Attributes have a type (BoolAttribute, FloatAttribute...), and they are actually separated in two categories:
A common mistake is to use the Attribute class instead of the corresponding Register or Property class (FloatAttribute instead of FloatRegister or FloatProperty for instance): this class is abstract since it doesn’t define a set_value/get_value method to specify how the data is stored in practice.