Fixes/flomni #260
No Reviewers
Labels
Clear labels
issue::not confirmed
issue::not reproducible
issue::reproducible
priority::critical
priority::needed
priority::nice to have
scope::backend
scope::frontend
stage::in development
stage::on hold
stage::pre_release
stage::ready for review
stage::selected for development
stage::weekly backlog
type::bug
type::discussion
type::doc
type::feature
type::improvement
type::test
bug
duplicate
enhancement
help wanted
invalid
question
wontfix
Used if an issue has not yet been confirmed by a developer
Used if an issue is not reproducible
Used if a developer was able to reproduce the issue
Should be done as soon as possible
An important update to the code base
Not really needed but a good improvement
An issue regarding the backend services
An issue regarding the user-facing services
This issue is currently being worked on
Something is blocking the development
For issues that have been merged into a pre-release branch and are waiting for their release.
For issues that have been resolved and are ready for review
This issue has been selected for development but has not been scheduled yet
This issue has been selected for development for the next development cycle
It's a bug!
A discussion is wanted/needed
Improvements to the documentation
A new feature
Neither a feature nor a bug but an improvement to the code base
Missing tests or improvements to the test suite
Something is not working
This issue or pull request already exists
New feature
Need some help
Something is wrong
More information is needed
This won't be fixed
No labels
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
acerbo_a (acerbo_a)
appel_c (appel_c)
bec-gitea
celcer_t (celcer_t)
debenjak_l (debenjak_l)
diaz (diaz)
divall_e (divall_e)
guizar_m (guizar_m)
haghta_s (haghta_s)
holler (holler)
lombosi_c (lombosi_c)
menzel (menzel)
perl_d (perl_d)
usov_i (usov_i)
wakonig_k (wakonig_k)
wang_x1 (wang_x1)
wyzula_j (wyzula_j)
zamofing_t (zamofing_t)
Clear assignees
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: bec/csaxs_bec#260
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Three independent fixes: - sub_tomo_scan(): in 360-degree tomo_type-1 mode, every sub-tomogram used to sweep the full 0-360 range, so each one's own fine grid contained angle pairs exactly 180deg apart -- redundant tomographic information. Sub-tomograms now each cover a 180deg span, split into low/high halves by subtomo_number % 4 with a bit-reversal-of-4 phase table, so adjacent pairs (1,2)/(3,4)/(5,6)/(7,8), either quartet, and all 8 combined each independently form a complete, evenly-spaced 360deg tomogram at successively finer spacing. Total projection count for a given tomo_angle_stepsize is now identical between 180 and 360 mode (same N, no longer doubled). Updated the 4 other consumers of the old N/step formula (zero-deg reference gating, _tomo_type1_actual_grid, the parameter wizard, the PDF report) to match. 180-degree mode is unchanged. Live-verified against the running flomni sim: real motor motion traces the expected boustrophedon path with no duplicate or 180deg-apart angles. - Sample storage: added an owner field, packed into the same EPICS DESC field as the sample name ("name | owner", via new sample_desc_codec.py) since there's no separate PV for it. Wired through FlomniSampleStorage, the CLI (flomni_modify_storage_non_interactive, ftransfer_modify_storage), the two transfer routines that forward a raw DESC value across a gripper move (now unpacked/repacked so owner survives the move instead of being dropped or double-packed), and SampleStorageWidget. Scoped to flomni only this session; OMNY's storage/transfer mixin is unchanged. - ConsoleButtonsWidget's ABORT button used to send SIGINT then, 500ms later, a stop_devices() broadcast to ALL devices with no stop_id -- an un-suppressed error from that broadcast landing on a queue-tracked instruction could kill the scan worker thread outright, requiring a full BEC restart. Replaced with: queue.request_scan_abortion() (safe no-op if idle, but registers a stop_id so expected errors are suppressed), then SIGINT, then a direct, immediate Galil hard stop via new GalilController.hard_abort_and_restore_positioning_mode() -- the same method ftransfer_abort() now delegates to, so the CLI and GUI paths can't drift apart again. SIGINT is sent before the hard stop: live testing showed that if the hard stop's mntprgs-clearing side effect lands first, a same-session polling loop can mistake it for normal completion and fall through into ensure_gripper_up(), which must not happen mid-transfer -- sending SIGINT first (near-instant) gives that loop's own KeyboardInterrupt handler a head start before the hard stop's own multi-step sequence completes. The button is labeled per beamline (e.g. "Flomni Motion Stop") and disabled rather than silently inert when no hard-stop device is configured/enabled. Scoped to flomni only this session (OMNY/LamNI wiring deferred). Live-verified against the running sim, including the exact stop-lands-mid-queued-instruction scenario that previously crashed the scan worker. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>Two independent fixes: - GUI "beamline busy" indicators (TomoParamsWidget's banner, FlomniWebpageGenerator's status page) purely wait for progress["heartbeat"] to go stale (120s / 90s respectively) - there was no explicit "scan finished" signal to react to instead, since tomo_scan() wrote a heartbeat at the start of every projection but never cleared it on exit. Wrapped the scan loop in try/finally so heartbeat is cleared on every exit path (normal completion, exception, or interrupt/abort), not just at the next scan's start - both busy-detectors now see this on their very next poll instead of waiting out the timeout. Live-verified: heartbeat is None immediately after tomo_scan() returns. - Found while investigating a related report ("angular step of the final combined tomogram shown different between 180 and 360 mode, although it has to be identical" + "GUI shows projection count doubling when switching 180->360"): TomoParamsWidget's _compute_type1()/ _requested_to_stepsize() (tomo_params.py) and the generated status webpage's calcProjections() JS (flomni_webpage_generator.py) are both independent, un-synced duplicates of the exact old N=int(angle_range/ stepsize) formula fixed in flomni.py's own _tomo_type1_actual_grid() two commits ago - they were never updated when that fix landed, so the GUI and webpage kept reporting double the projection count for 360 mode. Fixed both to match flomni.py: N/step/total are always computed against a fixed 180 degrees, independent of angle_range. Also fixed the "angular step of the final (combined) tomogram" CLI/wizard lines in flomni.py itself, which used tomo_angle_range/total_projections (correct for 180 mode by coincidence, wrong for 360 mode - the true combined resolution is always 180/total_projections, identical between modes). Added a regression test asserting the widget's formulas match flomni.py's for both modes, to catch this exact kind of drift if it recurs. Live-verified against the running sim: both modes now report identical total_projections and combined-tomogram step for the same stepsize. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>