4. Plugin development
If you are a user of ESIBD Explorer you can skip this section. Please read on if you want to extend the functionality by adding plugins or adapt the software for a different type of experiment.
The main code does not need to be modified to add support for additional
devices and other features. Instead, you can add Plugin
that will be
automatically integrated into the user interface. In fact, everything
the user sees in ESIBD Explorer is a Plugin
. This section will discuss
the underlying framework that enables communication between different
devices, scan modes, and other plugins.
To add plugins, all you need to do is prepare a plugin file inside a
sub folder of the user defined Plugin path. A plugin file is a python
script that defines a providePlugins()
function, which returns one or
multiple plugins
.
Plugins
can be enabled in the plugin dialog
found in Settings after restarting the software. It is
recommended that your custom plugin classes inherit directly from
Plugin
, Device
, Scan
, or from one of the other built-in plugins. All built-in plugins
can be imported from plugins
and the corresponding modules in the plugins folder. Many other helpful classes and methods can be imported from core
.
If you want to do something completely different to the already implemented functionality, get in touch and see if we can implement a base class that can be reused for similar projects in the future and keeps your custom plugin code minimal.
4.1. Plugin
Abstracts basic GUI code for devices scans and other high level UI elements.
All plugins are ultimately derived from the Plugin
class.
The doc string of the plugin class will be shown in the corresponding help window.
4.2. PluginManager
The PluginManager
is responsible for loading all internal and external
Plugins. It catches errors or incompatibilities while loading,
initializing, and closing plugins. Users will only see the plugin selection
interface accessed from the Settings plugin.
The PluginManager
can be accessed from the Console as PluginManager.
It allows plugins to interact by using unique plugin names as attributes, e.g.
self.pluginManager.ISEG or self.pluginManager.DeviceManager.
4.3. Devices
A Device
manages access to parameters on a physical device, represented as a Channel
.
4.4. Channels
A Channel
represents a virtual or real parameter and manages all data and
metadata related to that parameter. Each Device
can only have one
type of Channel
, but channels have dynamic interfaces that allow to
account for differences in the physical backend.
4.5. Scan
Base class for scans
and other measurement plugins.
Acquires arbitrary output channel values vs. arbitrary input channel values.
The dimension of inputs and outputs is dynamic.
4.6. DeviceController
Each Device
or Channel
comes with a DeviceController
. The
DeviceController
is not itself a Plugin
. It only abstracts the direct
hardware communication from plugins
allowing them to use minimal and
consistent code that can be adjusted and reused independently of the
hardware. It should do all resource or time intensive communication work
in parallel threads to not slow down the main software. Following the
producer consumer logic, the DeviceController
reads values and assigns
them to the corresponding Channel
. The devices
will collect data from
the Channel
independently. In case you work with time sensitive
experiments this concept will need to be adapted. Feel free to use the
basic functionality provided by DeviceController
or implement
your own from scratch. As the DeviceController
only interacts with your
custom Channel
or Device
, there are no general requirements for
its implementation.