PLESTY runs scientific instruments. A microscope, a laser, a motorised stage — each one gets wrapped in a small Python package, and a measurement is written against those packages instead of against the hardware.
The fastest way to understand it is to watch it run. In six lessons you build a working setup on your own PC, with no instruments attached, and end up watching a measurement play out live.
The five ideas
Everything in this section is one of these. You meet them one at a time, and each lesson adds the next.
| Term | What it means |
|---|---|
| Device module | A Python package that knows how to talk to one instrument — a powermeter, say. Nothing else in the platform knows the instrument's protocol. |
| Device server | That module, running as a program that owns the instrument and listens on a network port. Everything else talks to it over the network, even on the same PC. |
| Fleet | The set of device servers a lab bench runs, written down in one file so they start together. |
| Composite device | Several device servers driven as though they were one instrument, so a measurement can say "take a reading" instead of coordinating three programs. |
| Experiment | The measurement itself: a list of steps, run in order, with every result written to disk as it happens. |
One more thing is not an idea so much as a window: the monitor draws a measurement while it is still running, reading the results off disk.
Working without instruments
A device module can run in mock mode — --mock on the command line — where it simulates the instrument instead of reaching for one. That is how the whole platform fits on a laptop.
Mocks normally invent their answers. These ones do not: they replay a measurement that was really taken, on real hardware, on 4 August 2026. The numbers you see are the numbers the instruments recorded.
The measurement you will reproduce
Polarization-resolved photoluminescence of a quantum dot: how the emission spectrum depends on polarization angle.
A half-wave plate steps through 0–180° in 2° increments. At each angle the spectrometer records one spectrum and the powermeter logs the excitation power alongside it, so a dim spectrum can be told from a dim excitation. That is 91 rows — the tutorial's word for one angle's spectrum plus the readings taken with it — and the series is a sweep.
Three instruments, which are the three device servers you will start:
| Instrument | Role |
|---|---|
| K10CR1 rotation stage | Carries the half-wave plate |
| Spectrometer | One spectrum per angle |
| PM100D powermeter | Excitation power reference per row |
Spectrum — the row just acquired.
Spectral map — every row so far, stacked: angle down, wavelength across, counts as colour. This is the product.
Power — excitation power against angle.
Prerequisites
Two installs, both in lesson 1: the bench itself, plesty-server, whose installer brings what it needs; and plesty-sdk, which scaffolds the project you write in.
| Comes from | Used for | |
|---|---|---|
| uv | the plesty-server installer, if you do not already have it |
running every command here |
| Python | uv |
never installed by you |
| git | you, on macOS and Linux — the bench installs its own on Windows | fetching the modules |
plesty-sdk |
uv tool install plesty-sdk |
scaffolding the project, in lesson 1 |
uv downloads and manages an interpreter for every environment in this section, including the one each device server runs in. So there is no Python to install, no pip, poetry or conda, and no virtual environment to activate.
git is the one thing you may have to supply. The modules here are installed from GitLab rather than PyPI, so the bench needs it. On Windows it takes care of itself — a lab PC rarely has git, so the bench downloads a portable copy into its own directory and uses that. On macOS and Linux it expects to find one already: xcode-select --install, or your package manager.
You build it, lesson by lesson
In a lab, the PC standing next to the instruments and running their device servers is called the bench. You are about to build one — except yours has no instruments next to it.
This is not a repository you clone and run, not yet. You build it up across six lessons, adding one layer at a time, and by the end you have made it yourself.
Each lesson is one commit of the demo-bench repository, and each branch holds the finished state of that lesson. Type it out yourself; check out the branch when you want the answer, or when you want to skip ahead.
| Lesson | Branch | What you add |
|---|---|---|
| One Device | step-1-device |
One instrument's server, and a script that talks to it |
| A Fleet | step-2-fleet |
The other two servers, and getting them to agree |
| Composite Device | step-3-composite |
The three of them driven as one instrument |
| The Experiment | step-4-experiment |
The measurement itself: a plan, records, resume |
| The Monitor | step-5-monitor |
A live view of the run, from the records it writes |
| The Viewer | step-6-viewer |
Three views docked in one window, and the run as a video |
Lessons 1–3 build the bench. Lessons 4–6 build a second project on top of it: the measurement is not part of the instruments, and one bench outlives many experiments. The wrap-up at the end is what the six add up to, and what it costs to point them at real instruments.
The diff between two branches is exactly the lesson between them:
git clone https://gitlab.com/plesty/demo-bench.git
cd demo-bench
git diff step-1-device..step-2-fleet
main is the finished bench — the same thing, with some of the by-hand setup automated away. That is where you end up.
Nothing here is a special demo mode except the mocks themselves. Point the same setup at real instruments instead and it runs a real measurement; the last lesson lists exactly what differs.