The JungfrauJoch broker reports packet loss during data collection as a plain error, which fails the scan. Since 2026-09-03 that error has been suppressed on the beamline by an uncommitted edit, through a hardcoded flag on the Eiger base class: it applied to every Eiger at once, it could be reached neither from the client nor from deviceConfig, and it left nothing in the log. The tolerance is now a real parameter, raise_on_missing_packets: - named in Eiger, Eiger9M and Eiger1_5M, so that a deviceConfig key actually reaches the device. bec_server intersects config keys with the named parameters of the class, so a flag reachable only through **kwargs is silently dropped -- the same trap as readout_time (f450f29) and prefix (10be2b5). A test pins the signatures. - exposed through USER_ACCESS as get_/set_raise_on_missing_packets, so a beamtime can change its mind without a redeployment. Like every runtime value it is shared between clients and does not survive a server restart; deviceConfig is what makes a choice stick. - counted, and logged at warning level whenever an error is let through, so that "which scans were affected?" has an answer. get_missing_packet_events() returns the count. What is tolerated is narrower than it looks: the frame-count check below still raises when statistics.images_collected falls short of the trigger count. Only "the broker flagged packet loss but delivered the expected number of images" gets through, and a test pins that a short acquisition still fails. The default stays False, i.e. tolerate, so the running beamtime is unaffected. It should become True once the 9M's packet loss is understood, with raise_on_missing_packets: false in that detector's deviceConfig if it still needs it. That is one constant to change, RAISE_ON_MISSING_PACKETS. The wording of the broker message is the only handle available, as there is no error code for it. If JungfrauJoch rephrases it the match stops working and the error raises again, which is the safe direction to fail in. test_eiger_on_complete_error_message was skipped as failing "because the error should be skipped for now due to HW issues". With the tolerance scoped to the missing-packet message it passes again, and is no longer skipped. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
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)