4. Plugin development — ESIBD Explorer 0.6 documentation

# 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.