meas layer#

The meas layer is implementated as mahos.meas package. The nodes in the meas layer provides the core functionalities of the measurement automation. To keep flexibility, there is almost no restriction on node implementation.

However, meas nodes are advised to have explicit state, i.e., to publish topic status (Status type) having state attribute (State type). If the node has state, we can use StateManager for the state management.

BasicMeasNode#

BasicMeasNode can be utilized as a base class to implement basic measurment nodes. This class assumes state of type BinaryState and status of type BinaryStatus.

Tweaker#

Tweaker is a generic node for manual-tuning of instrument parameters. This is useful for rather “floating” instruments which is not directly tied to specific measurement protocol, but its state affects the sample / DUT and measurement result. Examples: programmable (variable gain) amplifiers for the sensors, thermostats, or power supply for electromagnet. The instrument should have ParamDict-based interface to be managed by the Tweaker.

Recorder#

Recorder is a generic node for recording of time-series data from instruments. The instrument should provide several interfaces to be used by the Recorder.

StateManager#

StateManager is used as a manager of meas node states. It subscribes to topic states of all the managed nodes. We can register the command for the manager, which is a map from nodes to required states. Example configuration looks like below.

[localhost.manager1.node]
"localhost::node1" = ["mahos.msgs.common_msgs", "BinaryState"]
"localhost::node2" = ["mahos.msgs.common_msgs", "BinaryState"]

[localhost.manager1.command]
all_idle = { "localhost::node1" = "IDLE" , "localhost::node2" = "IDLE" }

This manager manages node1 and node2, both of which has BinaryState. A command named all_idle is a request to set both nodes to the IDLE state. Before a command is executed, the nodes state (last_state) is stored. After a command, we can use restore request to recover the last_state.

The figure below explans the command and restore operations.

Command and Restore operations of StateManager

Command and Restore operations of StateManager#

The manager1 is configured as the config snippets above.

  • (a): In initial state, node1 is ACTIVE and node2 is IDLE.

  • (b): node3 requests the manager1 to restore from all_idle command (Restore(all_idle)), which fails as the last_state is empty (all_idle has never been executed).

  • (c): node3 requests all_idle command execution (Command(all_idle), which turns both node1 and node2 to IDLE states. Here, the last_state is stored.

  • (d): node3 requests (Restore(all_idle) again. It succeeds this time and last_state is restored (node1 becomes ACTIVE).