- Widget: reject assigning a shuttle to a parking slot already held by a
different shuttle ("Slot in use", clear it first) instead of silently
overwriting.
- Widget: PDF report now shows only the 3 shuttles + their samples (title
"OMNY Shuttle Samples") -- stage/gripper/fixed-O positions can't
physically leave the vacuum chamber, so a printed report has nothing
useful to say about them. The on-screen widget still shows/manages all
of it.
- Widget: fixed the active-parking-slot badge never showing for a
loadlock-driven park. Root cause: otransfer_park_loadlock_slot() drives
oparkz to a different target-position table (base -6, "leica") than the
regular otransfer_park_slot() (base -0.9); the widget only recognized
the regular one. Now checks both.
- OMNYSampleStorage: measured status now packs status *and* the beamtime
account into one VAL -- 0 = not measured, negative 5-digit = started,
positive 5-digit = completed, falling back to FALLBACK_ACCOUNT (11111)
for anything that doesn't parse as exactly 5 digits. No IOC schema
change needed (same ai record). New get_sample_account()(+gripper/
samplestage variants); set_sample_status() now takes an account param;
show_all()/help() updated. otransfer_* CLI wrappers updated to match.
- Widget: new P-touch label-print offer, but only when clearing a
*shuttle* slot (not fixed-O/stage/gripper -- those are bookkeeping
corrections, not physical sample removal, since only shuttle samples
leave the vacuum chamber). Uses a separate PTouchLabelPrinter instance
at template 3 (not yet bench-tested against a real printer, unlike
FlOMNI's confirmed-working template 1), same field names as FlOMNI.
- AI_docs/OPEN_ISSUES.md: noted that the measured-status+account encoding
should be ported to FlOMNI at some point (separate task, not this
branch's scope -- FlOMNI's own status tracking is untouched, still the
redis-based _MeasuredSampleLog).
- New tests: encode/decode round-trips + fallback behavior for the
status+account VAL scheme, plus oparkz leica-target coverage.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018Mupip8x7Hean6E3FFvpbj
Getting Started with Testing using pytest
BEC is using the pytest framework. It can be installed via
pip install pytest
in your python environment.
We note that pytest is part of the optional-dependencies [dev] of the plugin package.
Introduction
Tests in this package should be stored in the tests directory.
We suggest to sort tests of different submodules, i.e. scans or devices in the respective folder structure, and to folow a naming convention of <test_module_name.py>.
It is mandatory for test files to begin with test_ for pytest to discover them.
To run all tests, navigate to the directory of the plugin from the command line, and run the command
pytest -v --random-order ./tests
Note, the python environment needs to be active.
The additional arg -v allows pytest to run in verbose mode which provides more detailed information about the tests being run.
The argument --random-order instructs pytest to run the tests in random order, which is the default in the CI pipelines.
Test examples
Writing tests can be quite specific for the given function. We recommend writing tests as isolated as possible, i.e. try to test single functions instead of full classes. A very useful class to enable isolated testing is MagicMock. In addition, we also recommend to take a look at the How-to guides from pytest.