lewis.devices

This module contains base classes for devices. Inherit from Device for simple devices or from StateMachineDevice for devices that are more complex and can be described using a state machine.

Submodules

chopper
julabo
linkam_t95

Members

Device	This class exists mainly for consistency.
StateMachineDevice	This class is intended to be sub-classed to implement devices using a finite state machine internally.

class lewis.devices.Device

Bases: DeviceBase, CanProcess

This class exists mainly for consistency. It is meant to implement very simple devices that do not require a state machine for their simulation. For such devices, all that is required is subclassing from Device and possibly implementing doProcess, but this is optional.

StateMachineDevice offers more functionality and is more likely to be useful for implementing simulations of real devices.

class lewis.devices.StateMachineDevice(override_states: dict[str, State] | None = None, override_transitions: dict[tuple[State, State], Callable[[], bool]] | None = None, override_initial_state: State | None = None, override_initial_data: dict[str, float] | None = None)

Bases: DeviceBase, CanProcessComposite

This class is intended to be sub-classed to implement devices using a finite state machine internally.

Implementing such a device is straightforward, there are three methods that must be overridden:

• _get_state_handlers()

• _get_initial_state()

• _get_transition_handlers()

The first method is supposed to return a dictionary with state handlers for each state of the state machine, the second method must return the name of the initial state. The third method must return a dict-like object (often an OrderedDict from collections) that defines the conditions for transitions between the states of the state machine.

They are implemented as methods and not as plain class member variables, because often they use the self-variable, which does not exist at the class level.

From these three methods, a StateMachine-instance is constructed, it’s available as the device’s _csm-member. CSM is short for “cycle-based state machine”.

Most device implementation will also want to override this method:

• _initialize_data()

This method should initialise device state variables (such as temperature, speed, etc.). Having this in a separate method from __init__ has the advantage that it can be used to reset those variables at a later stage, without having to write the same code again.

Following this scheme, inheriting from StateMachineDevice also provides the possibility for users of the class to override the states, the transitions, the initial state and even the data. For states, transitions and data, dicts need to be passed to the constructor, for the initial state that should be a string.

All these overrides can be used to define device setups to describe certain scenarios more easily.

Parameters:

• override_states – Dict with one entry per state. Only states defined in the state machine are allowed.

• override_transitions – Dict with (state, state) tuples as keys and callables as values.

• override_initial_state – The initial state.

• override_initial_data – A dict that contains data members that should be overwritten on construction.