Mirko, once Phase 1 (tomo-queue backend) was live-confirmed working: "is
the way to move to the widget phase" -- this adds OMNY as a third setup to
the tomo params GUI widget, alongside flomni/lamni.
Key design decision: replaced the module-level TOMO_TYPES dict (shared
across setups, couldn't express "type 1 means 2 sub-tomograms here but 8
there") with a per-profile "tomo_types" dict:
{tomo_type_int: {"label": str, "n_subtomos": int | None}}. n_subtomos is
not None became the single, uniform test for "is this an equally-spaced
type" everywhere (combo box, section visibility, validation, queue-table
projections display), since OMNY has three such flavors (types 1/4/5 --
2/4/8 sub-tomograms) instead of flomni's/lamni's one (always 8).
Critical bug caught by verifying the design against the live file, not by
the initial design itself: _validate() hardcoded
`tomo_type not in (1, 2, 3)` -- would have made the rest of Phase 2 look
like it worked (types 4/5 selectable, sections visible, math correct)
while silently rejecting every actual submit/queue attempt for an OMNY
type-4/5 job. Fixed to check profile membership instead. Also fixed three
UI strings that hardcoded "8 equal sub-tomograms" to read the active
type's real count.
New _compute_type1_omny/_requested_to_stepsize_omny (parameterized by
tomo_type via {1:2,4:4,5:8}, matching
OMNY._equally_spaced_subtomo_angles()'s own mapping exactly) and
_compute_fermat_positions_omny (calls OmnyFermatScan's real static
method, same pattern as flomni's). _format_projections() gained a 3-way
setup duck-type (OMNY's param set is a strict subset of flomni's -- no
positively-unique OMNY-only key exists, so a negative-then-positive check
is necessary) that resolves into SETUP_PROFILES rather than duplicating
the type-count mapping a third time.
Confirmed needing zero changes (verified, not assumed): _job_tooltip(),
_build_type23_section(), compute_fermat_positions call sites,
_detect_setup() (osamroy as OMNY's discriminator), the busy-banner
detection methods (already generic via the shared tomo_progress global
var from Phase 1), and the Qt Designer plugin registration files.
New test_omny_tomo_params_widget_math.py (29 pure-function tests, no
QApplication/QWidget, same style as the existing flomni/lamni test
files). Full suite: 761 passed. Not live-tested (needs a real display,
same as every GUI change this branch) -- next step is Mirko trying it
against a real OMNY session.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QLrD7sVYGLAzsQjLVJpCgt
cSAXS BEC
cSAXS specific plugins and configs for BEC This document guides you through the procedure to spin up BEC at the beamline for a new experiment (e-account). You might want to run cSAXS copy scripts before in case you want to have the former data structure to be preserved.
Overview
- Clone cSAXS BEC repository into e-account (e.g. into ~/Data10/software/.)
- Start Epics iocs
- Start BEC, BEC server and load/modify the device config with relevant hardware
- BEC commands
Clone cSAXS BEC repository
Clone the current cSAXS BEC repository from GIT into the new e-account. Create directory
mkdir ~/Data10/software
cd ~/Data10/software
Clone repository
git clone https://gitlab.psi.ch/bec/csaxs_bec.git
Start epics iocs
You can start up the iocs while the ./setup_bec.sh script is running. Be aware though that the scripts requires you to interact with it.
DelayGenerator
Open a new tab in a terminal in comp1/comp2 or cons1 and follow the commands below:
ssh gac-x12sa@localhost
cd ~/delaygen
iocsh -7.0.6 startup.script
Be aware -7.0.6 is referring to the current epics version and might change in future (SLS 2.0). To start the epics panel (only if needed), run in a new shell
caqtdm -noMsg -macro P=delaygen:,R=DG1: srsDG645.ui
More notes on usages and cabelling of DDGs. Currently 3 generators are used:
- DDG1 for detectors (EXT Enable from SGalil stages, T0 to DDG2, AB for eiger, CD for Falcon, EF for Pilatus_2)
- DDG2 for mcs card (ext. enable from DDG1, AB to mcs card)
- DDG3 for fast shutter and mcs enable (AB short pulse to enable MCS (needed!!), CD to keep FSH open )
Eiger
Open a new tab in a terminal in comp1/comp2 or cons1 and follow the commands below:
ssh gac-x12sa@localhost
cd ~/Software/Eiger/
./launch_ioc
A live view of status and images for std_daq can be found here xbl-daq-29:5000.
Pilatus_2
First, start the cam server. Connect to the computer and follow the instructions printed after connecting:
ssh det@x12sa-pd-2 (Pilatus2)
The cam server will open, wait until you see **. Nex step, open a new tab in a terminal in comp1/comp2 or cons1 and follow the commands below:
ssh gac-x12sa@localhost
cd ~/Software/Pilatus300K/
./launch_epics
FalconX1
Open a new tab in a terminal in comp1/comp2 or cons1 (logged in as the current e-account) and follow the commands:
ssh x12sa-cons-01
cd /ioc/X12SA-PC-FALCONX1/
iocsh -7.0.6 startup.script
Be aware -7.0.6 is referring to the current epics version and might change in future (SLS 2.0)
Start BEC, BEC server and load device config
Step 1 needs to have finished for continuing with these steps. What remains now is to start the bec server. Connect to pc15543 and open a new terminal to run:
cd ~/Data10/software
source bec_venv/bin/activate
bec-server start
tmux attach -t bec
Open another teminal on pc15543 and start BEC:
cd ~/Data10/software
source bec_venv/bin/activate
bec
Note: In case there is a warning after starting BEC that it was not able to import scilog, you will have to pip install scilog in the bec_venv to be able to send printouts to scilog from the command line. Within a new terminal:
cd ~/Data10/software
source bec_venv/bin/activate
pip install scilog
Device config from csaxs-bec plugins
bec.config.update_session_with_file('/sls/X12SA/data/e20639/Data10/software/csaxs-bec/bec_plugins/configs/bec_device_config_sastt.yaml')
bec.config.save_current_session('~/Data10/software/current_config.yaml')
The second command is helpful if you adjust limits of motors, which will then be stored in the config and loaded if a reload of the configuration is needed.
BEC commands
A number of commands that are useful:
To move devices that are added in the config:
umv(dev.samx, 0) #absolute
umvr(dev.samx, 0) #relative
dev.samx.wm #print motor position and limits
dev.samx.limits = [low_limit, high_limit] # To set limits, note, same lower and higher limit, e.g. [0, 0] means no limits!!
Scans:
scans.acquire(exp_time = 0.5, frames_per_trigger=10, readout_time=3e-3) # equivalent to a loopscan 30 0.5
scans.line_scan(dev.samx, -1, 1, steps=20, exp_time=0.5, readout_time=3e-3, relative=True) # optional, add frames_per_trigger =10 for burst acquisition at each step
#Scan 2 motors in a step scan at the same time
scans.line_scan(dev.samx, -1, 1, dev.samy, -1, 1, steps=20, exp_time=0.5, readout_time =3e-3, relative=True) # step scan with 20 steps, again frames_per_trigger can be added for burst at each point
scans.sgalil_grid(start_y = , end_y = , interval_y = , start_x=, end_x=, interval_x =, exp_time=0.5, readout_time=3e-3, relative=True)