PLESTY is not one program. It is a set of small pieces that agree on a few things — how an instrument is addressed, what a measurement records, what counts as a finished module — so that work done on one bench is usable on another, and a module written for one experiment outlives it.
This page is the map: what exists, how a measurement moves through it, and where each piece is published.
The ecosystem at a glance
Three bands, and the middle one is the point.
The measurement path is the same whether a setup has one instrument or nine. A device module wraps exactly one instrument and serves it over TCP, so nothing that uses it knows a vendor SDK exists. An experiment decides the order — a plan, run step by step, driving the device servers and recording what they return. What it records is the run: a directory of files, with the large files the instruments wrote themselves beside the records. When the measurement is in, the experiment hands its records to an analyzer, which turns them into a quantity that means something and saves that result — with a report of what it found — into the run as well. Live views draw from the run's files while they are still being written, which is why watching a measurement cannot disturb it.
PLESTY Bench is the application on each lab PC: it installs device and experiment modules from the hub, starts the device servers and supervises them, and runs experiments — starting each instrument on the bench it is plugged into, and writing the run's report when it ends. It is how a lab becomes a thing you set up once rather than a terminal per instrument.
The foundations are three packages every module depends on, and the reason a module written by someone else behaves the way yours does.
Publishing is the top band, and it is what makes the ecosystem an ecosystem rather than a folder of scripts: a finished module goes to PyPI, its documentation is generated from its own code, and the registry lists it so the next person can find it without asking anyone.
What each piece is
| What it is | Who touches it | |
|---|---|---|
plesty-lib |
The runtime: device base classes, the TCP service layer, composite devices, the experiment framework, monitors | Every module depends on it; you import it |
plesty-sdk |
The plesty command — init scaffolds a module, check runs the quality gates |
Contributors, on their own machine |
plesty-ci |
The GitLab CI component that runs the same gates, builds the docs and publishes releases | Included by every module's .gitlab-ci.yml |
plesty-bench |
PLESTY Bench — the lab-PC application that installs modules, runs device servers and runs experiments (its command is plesty-server) — and the client that drives a bench from another machine (plesty-bench) |
Whoever runs a bench; developers driving one remotely |
| Hub modules | The devices, analyzers and experiments themselves | Anyone adding an instrument or a measurement |
| Data tools | Shared views and data helpers — plesty-common-monitors, labdata |
Reused rather than rewritten per experiment |
| Governance | The written rules: standards, membership, decisions | Everyone, when something needs deciding |
Where it lives
Everything public is one GitLab group, arranged by what a thing is:
plesty/
├── governance the rules, and the issue tracker for them
├── core/ plesty-lib · plesty-sdk · plesty-ci · plesty-bench
├── hub/
│ ├── devices/<vendor>/ one project per instrument, grouped by maker
│ ├── analyzers/
│ └── experiments/
├── datatools/ labdata, monitors/plesty-common-monitors
├── utilities/ general-purpose helpers
├── website/ this site's content, the contributor guide, reports
└── sandbox/ the legacy monolith, kept readable, not built on
The shape carries a rule worth naming: a module is a repository. One instrument, one project, its own version, its own documentation, its own release. That is what lets a bench install exactly the modules it needs at exactly the versions it was tested against, and what lets a device written three years ago still be installable today.
The rest of this section
The map above is deliberately shallow. Five pages go under it, in the order a measurement meets them, each saying how a part works and why it was built that way — not how to use it, which is what the guides are for.
- Modules — the three kinds of module, why one instrument is one repository, and what each module declares about itself.
- Networking — how the modules of one measurement find and talk to each other: device servers, clients, the bench agents, and the wiring of a run across lab PCs.
- Data Flow — where a measurement's data goes: a plan of atomic steps, one folder per run, large files that never cross the network, and one shared disk.
- Analysis and Reports — how records become a result, and how the result and the whole run are written up.
- Interfaces — the ways people and programs drive it all: PLESTY Bench, control panels, runs, command lines and live views.
Then, when the why is enough and you want the how:
- Quickstart — the whole path above, on one real measurement: on one PC, then across two.
- Build & Run a Device and Build & Run an Experiment — the two kinds of module from the inside, and running them on a bench.
- Quality Gates — what
plesty checkenforces, tier by tier.