Architecture

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 left-to-right whether a bench has one instrument or nine. A device module wraps exactly one instrument and serves it over TCP, so nothing above it knows a vendor SDK exists. An analyzer turns what a device returns into a quantity that means something. An experiment decides the order — a plan, run step by step, recording as it goes. What it records is a directory of files, and monitors draw from that file while it is still being written, which is why watching a measurement cannot disturb it.

The bench underneath is plesty-server: the program on the lab PC that installs modules, starts their servers and supervises them. It is how a bench 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

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, each taking one cross-cutting decision and saying why it was made that way — not how to use it, which is what the guides are for.

• Modules — why one instrument is one repository, what a module declares about itself, and how the platform knows which rules apply.
• TCP Communication — the protocol every device speaks, and what a client can assume without knowing the instrument.
• The Bench — what runs on the lab PC: installing modules, starting servers, and why nothing the bench starts is a child process.
• Runs & Data — what a measurement leaves behind, and the rule that keeps images off the network.
• Live Views — how a run is watched while it happens, and why watching cannot disturb it.

Then, when the why is enough and you want the how:

• Quickstart — the whole path above, built on your own PC in six lessons, with no instruments attached.
• Build a Device and Build an Experiment — the two contracts from the inside.
• Quality Gates — what plesty check enforces, tier by tier.