menzelandClaude Opus 5
5d6f2374ff
Verified against the camera on 2026-08-18: `control.cgi?stop=<axis>` does nothing. The suspicion recorded yesterday was right -- no bare `stop` field exists on this camera, it expresses actions as `<namespace>.action`, and because the server answers HTTP 200 for unimplemented commands the failure was completely silent. stop_all(), the device's on_stop() abort hook and the motion tool's own cleanup were all quietly doing nothing. stop() no longer sends a stop command. It halts each axis by **commanding a move to where that axis currently is**, which is built on the one motion primitive proven to work on this hardware. Properties worth knowing: * protocol-independent -- any camera accepting absolute moves stops this way, whatever it calls its stop command, so this survives firmware differences; * positions are sampled **once** for all axes rather than once per axis, because this is the panic path and must not be slow; * the axis decelerates on its normal ramp rather than dead-stopping, and may drift slightly past the sampled position before settling. It is a halt, not a freeze, and the docstring says so. _PARAM["stop"] is gone rather than left as a misleading dead entry. Also adds `motion_check.py --find-stop`, which hunts for a *native* one-request stop by interrupting a series of moves with each candidate (`c.1.pan.action=stop`, `c.1.action=stop`, `p.action=stop`, ...). Worth having because the re-target must read ~32 kB of info.cgi before it can act, and at 100 deg/s that round-trip is real extra travel on the path taken when something is already wrong. If a candidate halts the axis it becomes the fast path -- with the re-target kept as the fallback, since a silent no-op is precisely what the fallback protects against. Tests: 104. Coverage for re-targeting the sampled position, sampling info.cgi once for stop_all rather than four times, requiring control privilege, raising rather than silently skipping an axis it cannot read (the original bug's failure mode), and the candidate hunt's mechanics. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
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.