PlestyLib#

Introduction#

The PLESTY project provides a standardized framework for developing and deploying automation in physical experiments. It consists of three components: PlestyLib, PlestySDK, and PlestyHub, as shown below.

plesty_components Figure 1 Plesty components

This documentation introduces PlestyLib, the core module of the PLESTY project. It offers standardized device, data, and experiment management, along with utility tools that help developers rapidly automate new devices and experimental workflows.

Standardized device#

In general, a device is separated into six Python layers above the hardware and firmware layers provided by the manufacturer (Figure 2):

  • Traffic Manager: Manages the connection and messaging between the Python API and devices through APIs or protocols provided by manufacturers.

  • Command Logic Solver: Translates standardized Plesty operation calls into the target format required by a manufacturer protocol or API. It also converts device responses back into the standardized Plesty format.

  • Synchronized Device: The abstract base layer that must be inherited to define a real, functioning device.

  • Asynchronous Device Wrapper: Turns a synchronized device into an asynchronous one.

  • TCP/IP Serving Wrapper: Exposes the synchronized device over a TCP/IP port. Device operations can be executed synchronously in a single thread or asynchronously in multiple short-lived threads.

  • TCP/IP Client: Connects to a remote TCP/IP server and operates devices using the same syntax as a local device.

alt text Figure 2 Plesty layers for standardized device

As shown in Figure 2, the Asynchronous Device Wrapper, TCP/IP Serving Wrapper, and TCP/IP Client layers are fully implemented and ready to use. API developers mainly need to complete the remaining lower layers. PlestyLib may also provide commonly used implementations of traffic managers (e.g., USB, VISA, Serial) and command logic solvers (e.g., SCPI) to further simplify development.

As a result, the core workload in developing a new device API is defining the synchronized device. To simplify this process, we define the synchronized device with the structure shown in Figure 3. Each device includes connection and disconnection functions, as well as query and write functions for configuration parameters.

In addition to these abstract functions, we introduce a Parameter and Function management system to further reduce development effort. This system uses JSON Schema to define device features. The schema can be generated by an LLM from device manuals. Once standardized parameters and functions are registered in this system, we can conveniently validate end-user operations (for example, checking whether a parameter value has a valid type or range). We can also provide utility functions, such as synchronizing all parameters to or from the device and generating standardized documentation in different styles.

alt text Figure 3 Structure of synchronized device