#25: Configuration Development

ConfigurationManager

A new core device, the Karabo Configuration Manager is implemented in Karabo 2.10.0.

The configuration manager device is able to manage configurations of multiple devices. It can save online configurations (keys, value) and the schemas (keys, attributes) of the devices it manages. Hence, a so-called online snapshot with the full device information, e.g. injected properties next to the general static schema, can be stored.

The configuration manager is able to instantiate a device with a given configuration and attributes.

New Features - Karabo GUI

  • Device configurations can be tagged via the device topology and project panels

    • Configuration snapshots cannot be deleted or modified

    • Configuration snapshot names are unique for a device

Configurations by name dialog

Get a configuration by a name from the configuration dialog

  • Device configurations can be retrieved via the device topology and project panels

    • Compare configuration with existing in Configurator (as before)

  • Configuration dialogs are not anymore blocking operator input and can be multiple times open

Configurations by time dialog

Get a configuration by a time from the configuration dialog

In certain scenarios devices change over time. Even worse, they might change their schema, e.g. the description of their properties. A bool value might become a string, a table element gets one more column etc. pp. These errors will not be silent anymore but are notified.

Property violations in the configurations

Configuration violations in the Karabo Gui are now notified

Component Management (generic)

The configuration of components consisting of several devices can be managed by so called Component Manager devices and their scenes.

Component Manager Scene

Scene of a component manager handling a simplified component (six motors)

The component manager is still under active development:

  • Quick view if all devices are online

  • Configurations can be saved for all devices under same name (snapshot)

  • Devices can be instantiated from configuration set by unique name

  • Configuration set can be applied to all devices as bulk

  • … more in the future!

New functions: MDL / ikarabo

New synchronized (coroutines) functions are available to communicate with the configuration manager:

  • instantiateFromName(device, name=None, classId=None, serverId=None):

    • device: The mandatory parameter, either deviceId or proxy

    • name: Optional parameter. If no name is provided, the latest configuration is retrieved with priority 3 (INIT).

    • classId: Optional parameter for validation of classId

    • serverId: Optional parameter to overwrite the server where to instantiate

      (otherwise taken from stored configuration)

  • saveConfigurationFromName(devices, name, description=’‘, priority=1):

    • The parameter devices can be a Karabo proxy, a list of deviceIds, a list of proxies or a mixture of them. It can be as well a single deviceId string.

    • The description text is by default empty.

    • The priority default 1 is the lowest available (1-3: TEST - COMMISSIONED - INIT).

  • listConfigurationFromName(device, name_part=’‘):

    • Optional: A name part can be provided to filter the list of configurations

    • Returns a list where each configuration item is a Hash containing:

      • name: the configuration name

      • timepoint: the timepoint the device was taken

      • description: the description of the configuration

      • priority: the priority of the configuration

      • user: place holder, for future user information (planned)

  • getConfigurationFromName(device, name):

    • Get the configuration Hash of a deviceId or proxy with a given name

  • getLastConfiguration(device, priority=3):

    • Get the last configuration Hash of a deviceId with given priority

Quick tools - Configuration

Additional quick tools are provided for the command line interface (CLI) to walk through

  • timing functions to facilitate easy timestamping, where number can be floating point or integer

    • daysAgo(number)

    • hoursAgo(number)

    • minutesAgo(number)

  • compareDeviceConfiguration(device_a, device_b):

    • Compare device configurations (key, values) of two devices

    • The changes are provided in a list for comparison:

      -> h = compareDeviceConfiguration(device_a, device_b)
-> h
-> <disableEpsilonFeedback{}: [True, False]>
  • compareDeviceWithPast(device, timepoint):

    • timepoint: The timepoint to compare

    • Compare device configuration (key, values) between present and past

    • The changes are provided in a Hash of lists for comparison:

      changes = [PRESENT | PAST]

-> h = compareDeviceWithPast(device, minutesAgo(2))
-> h
-> <disableEpsilonFeedback{}: [True, False]>

Configuration Contract Changes (Developers)

  • A karabo configuration consists of keys and values. A schema consists of keys and attributes (mininum, maxmimum, units, etc.). The karaboGUI was doing a rather difficult work to merge both configuration and schema together as configuration. In the future, the karabo GUI configuration will contain only keys and values. This full change is aimed for end of 2021, hence, there is a 1 year notification period, together with the backward compatiblity period of 1 release (6 months), there is a total removal period of ~ 1 1/2 years. In the future, certain attributes must be exposed as device property if they are supposed to be changed. Since this feature is rarely used, no big effect is expected after a survey. In contrast, important attributes are visible in general and not changeable for devices were they are not supposed to be changed (validation). They are by default writable which is a safety concern. With Karabo 2.10 the attributes minInc, maxInc, minExc, maxExc, absoluteError and relativeError cannot be set anymore from the GUI client. With Karabo 2.11 the attributes unitSymbol and metricPrefixSymbol are not configurable.

  • A Table element must specify default values in their columns. In the future, if the table changes by adding a column and no default value is provided, the whole previous configuration is declared invalid, as the GUI is not able to reconstruct a proper table configuration!

  • An assignment internal declaration of a device property should only be used in combination with access mode init_only . It provides the information that this value cannot be set from outside, but maybe set from internal. These assignment internal properties will also NOT appear in any applied configuration. Examples of assignment internal properties are __deviceId__ and __serverId__. Those two properties are set by a device server as part of the device instantiation process.