Lima issueshttps://gitlab.esrf.fr/limagroup/lima/-/issues2024-03-06T12:22:53+01:00https://gitlab.esrf.fr/limagroup/lima/-/issues/208Set default debug type (level) to Warning & Error2024-03-06T12:22:53+01:00Samuel DebionneSet default debug type (level) to Warning & Errorv1.10.0Laurent ClaustreLaurent Claustrehttps://gitlab.esrf.fr/limagroup/lima/-/issues/207regular doc and submodule update2024-01-22T17:34:03+01:00Laurent Claustreregular doc and submodule updateLaurent ClaustreLaurent Claustrehttps://gitlab.esrf.fr/limagroup/lima/-/issues/205Overall performance is degraded when saving at high frame rates2024-01-05T13:44:39+01:00Alejandro Homs PuronOverall performance is degraded when saving at high frame ratesThe `PSI/Eiger` detector can continuously work at 8 kHz in 4-bit mode, but the Lima performance is degraded when data is saved. Even after applying several optimizations:
* CPU idle Power Management disabled: `sudo bash -c 'for f in /s...The `PSI/Eiger` detector can continuously work at 8 kHz in 4-bit mode, but the Lima performance is degraded when data is saved. Even after applying several optimizations:
* CPU idle Power Management disabled: `sudo bash -c 'for f in /sys/devices/system/cpu/cpu*/cpuidle/state{1..3}/disable; do echo 1 > ${f}; done'`
* CPU frequency scaling performance governor: `sudo bash -c 'for f in /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor; do echo performance > ${f}; done`
* Ping CPU & memory affinity to single NUMA node
the `newFrameReady` call in control layer takes several tens of microseconds, degrading the performance of the plugin acquisition thread loop. In addition, the overall saving performance is degraded when the frame rate increases.
The following benchmarks are performed with a simulator reading images from a `PSI/Eiger-500k` detector on a Dectris Eiger2 Lima computer:
```
# opid17@lid17eiger2lima
$ (cd ~blissadm/local/Git/lima/camera/simulator &&
numactl --cpunodebind=1 --membind=1 \
build/test/test_simulator --debug-type-flags=$(printf "%d" 0x7) \
--cam-mode=LOADER_PREFETCH \
--cam-file-pattern=/nobackup/deg_du_data/test_eiger/psi_eiger_500k_00000.edf --cam-nb-prefetched-frames=500 \
--buffer-max-memory=20 \
--acq-expo-time=0.5e-6 --acq-latency-time=0 --acq-nb-frames=100000 \
--saving-directory=/data/id13/inhouse/test/psi_eiger_500k/test_eiger/simulator \
--saving-prefix=test_simulator_ --saving-frames-per-file=10000 --saving-format=HDF5BS \
--proc-nb-threads=10 --video-active=1 \
--test-rm-files-before-acq=1 --test-image-status-callback=1)
[2024/01/04 09:27:06.262477] 7f84fb9d6c80 *Test*Simulator::TestApp::getCtControl (A Exception::102)-Always: Camera: m_pars->cam_mode=LOADER_PREFETCH
[2024/01/04 09:27:06.262569] 7f84fb9d6c80 *Test*Simulator::TestApp::getCtControl (A Exception::119)-Always: m_pars->cam_file_pattern=/nobackup/deg_du_data/test_eiger/psi_eiger_500k_00000.edf
[2024/01/04 09:27:06.262651] 7f84fb9d6c80 *Test*Simulator::TestApp::getCtControl (A Exception::121)-Always: m_pars->cam_nb_prefetched_frames=500
[2024/01/04 09:27:06.264035] 7f84fb9d6c80 *Test*Control::CtTestApp::init (control/src/CtTestApp.cpp:267)-Always: m_pars->acq_mode=Single, m_pars->acq_expo_time=5e-07, m_pars->acq_lat_time=1e-08
[2024/01/04 09:27:06.264315] 7f84fb9d6c80 *Test*Control::CtTestApp::init (control/src/CtTestApp.cpp:290)-Always: nb_exec_threads=0
[2024/01/04 09:27:06.264344] 7f84fb9d6c80 *Test*Simulator::TestApp::configureAcq (A Exception::140)-Always: effective_dim=<1030x514x1-Bpp8>
[2024/01/04 09:27:06.264444] 7f84fb9d6c80 *Test*Control::CtTestApp::execCmd (control/src/CtTestApp.cpp:327)-Always: executing cmd=rm -f /data/id13/inhouse/test/psi_eiger_500k/test_eiger/simulator/test_simulator_*.h5
[2024/01/04 09:27:06.270128] 7f84fb9d6c80 *Test*Control::CtTestApp::runAcq (control/src/CtTestApp.cpp:349)-Always: acq_idx=0, nb_frames_idx=0, acq_nb_frames=100000
[2024/01/04 09:27:27.677832] 7f84fb9d6c80 *Test*Control::CtTestApp::runAcq (control/src/CtTestApp.cpp:363)-Always: acq prepared
[2024/01/04 09:27:27.677872] 7f84fb9d6c80 *Test*Control::CtTestApp::runAcq (control/src/CtTestApp.cpp:367)-Always: max_nb_buffers=76073
[2024/01/04 09:27:27.677894] 7f84fb9d6c80 *Test*Control::CtTestApp::runAcq (control/src/CtTestApp.cpp:370)-Always: acq started
[2024/01/04 09:27:27.777974] 7f84fb9d6c80 *Test*Control::CtTestApp::runAcq (control/src/CtTestApp.cpp:397)-Always: AcqRunning, acquired:838, saved: 799
[2024/01/04 09:27:27.878071] 7f84fb9d6c80 *Test*Control::CtTestApp::runAcq (control/src/CtTestApp.cpp:397)-Always: AcqRunning, acquired:1699, saved: 1665
[2024/01/04 09:27:27.978158] 7f84fb9d6c80 *Test*Control::CtTestApp::runAcq (control/src/CtTestApp.cpp:397)-Always: AcqRunning, acquired:2558, saved: 2528
[2024/01/04 09:27:28.078246] 7f84fb9d6c80 *Test*Control::CtTestApp::runAcq (control/src/CtTestApp.cpp:397)-Always: AcqRunning, acquired:3389, saved: 3364
[2024/01/04 09:27:28.178336] 7f84fb9d6c80 *Test*Control::CtTestApp::runAcq (control/src/CtTestApp.cpp:397)-Always: AcqRunning, acquired:4246, saved: 4225
[2024/01/04 09:27:28.278419] 7f84fb9d6c80 *Test*Control::CtTestApp::runAcq (control/src/CtTestApp.cpp:397)-Always: AcqRunning, acquired:5102, saved: 5084
[2024/01/04 09:27:28.378513] 7f84fb9d6c80 *Test*Control::CtTestApp::runAcq (control/src/CtTestApp.cpp:397)-Always: AcqRunning, acquired:5928, saved: 5913
[2024/01/04 09:27:28.478598] 7f84fb9d6c80 *Test*Control::CtTestApp::runAcq (control/src/CtTestApp.cpp:397)-Always: AcqRunning, acquired:6782, saved: 6768
[2024/01/04 09:27:28.578680] 7f84fb9d6c80 *Test*Control::CtTestApp::runAcq (control/src/CtTestApp.cpp:397)-Always: AcqRunning, acquired:7503, saved: 7491
[2024/01/04 09:27:28.678771] 7f84fb9d6c80 *Test*Control::CtTestApp::runAcq (control/src/CtTestApp.cpp:397)-Always: AcqRunning, acquired:8329, saved: 8314
[2024/01/04 09:27:28.778866] 7f84fb9d6c80 *Test*Control::CtTestApp::runAcq (control/src/CtTestApp.cpp:397)-Always: AcqRunning, acquired:9179, saved: 9165
...
[2024/01/04 09:27:43.392844] 7f84fb9d6c80 *Test*Control::CtTestApp::runAcq (control/src/CtTestApp.cpp:397)-Always: AcqRunning, acquired:98834, saved: 98815
[2024/01/04 09:27:43.492952] 7f84fb9d6c80 *Test*Control::CtTestApp::runAcq (control/src/CtTestApp.cpp:397)-Always: AcqRunning, acquired:99685, saved: 99669
[2024/01/04 09:27:43.593057] 7f84fb9d6c80 *Test*Control::CtTestApp::runAcq (control/src/CtTestApp.cpp:397)-Always: AcqReady, acquired:99999, saved: 99999
[2024/01/04 09:27:43.593095] 7f84fb9d6c80 *Test*Control::CtTestApp::runAcq (control/src/CtTestApp.cpp:406)-Always: all frames acquired: elapsed=15.9152, frame_rate=6283.3
[2024/01/04 09:27:43.593117] 7f84fb9d6c80 *Test*Control::CtTestApp::runAcq (control/src/CtTestApp.cpp:426)-Always: saving finished
[2024/01/04 09:27:43.593124] 7f84fb9d6c80 *Test*Control::CtTestApp::runAcq (control/src/CtTestApp.cpp:434)-Always: acq finished
[2024/01/04 09:27:43.593130] 7f84fb9d6c80 *Test*Control::CtTestApp::runAcq (control/src/CtTestApp.cpp:451)-Always: elapsed=15.9152
[2024/01/04 09:27:43.849468] 7f84fb9d6c80 *Test*Control::CtTestApp::runAcq (control/src/CtTestApp.cpp:464)-Always: Saving statistics (MByte/s): statistics_size=100000, incoming_speed=3512.57, compression_speed=3442.35, compression_ratio=5.44358, saving_speed=1515.68
```
The following `limatake` scan shows the same kind of degradation with a `PSI/Eiger-500k` detector:
```
TEST_EIGER [123]: limatake(10e-6, 100000, psi_eiger_500k, latency_time=(1 / 2e3 * int(psi_eiger_500k.camera.pixel_depth) / 16 - 10e-6), save=True)
Scan 178 Fri Jan 05 13:34:02 2024 /data/id13/inhouse/test/psi_eiger_500k/test_eiger/data.h5 test_eiger user = opid13
limatake 0.0000 100000
psi_eiger_500k acq #100000 save #100000
Finished (took 0:01:06.030725)
Out [123]: Scan(number=178, name=limatake, path=/data/id13/inhouse/test/psi_eiger_500k/test_eiger/data.h5)
TEST_EIGER [124]: limastat(psi_eiger_500k)
camera history incoming compression compression write
size speed ratio speed speed
-------------- --------- -------------- ------------- -------------- -------------
psi_eiger_500k 100000 1432.74 MB/sec 5.442 1193.75 MB/sec 816.79 MB/sec
```
The incoming frame rate should be 8 kHz (4 GB/sec); it is degraded to ~3 kHz.v1.10.0Alejandro Homs PuronAlejandro Homs Puronhttps://gitlab.esrf.fr/limagroup/lima/-/issues/204Accumulation processing leads to frame drop2023-12-18T10:14:02+01:00Samuel DebionneAccumulation processing leads to frame dropThe accumulation processing runs in the context of the acquisition thread. For very large detector, then accumulation execution time might lead to frame drop.The accumulation processing runs in the context of the acquisition thread. For very large detector, then accumulation execution time might lead to frame drop.Samuel DebionneSamuel Debionnehttps://gitlab.esrf.fr/limagroup/lima/-/issues/199Rename (or add) setIntrumentName to setUserIntrumentName2023-08-24T14:00:56+02:00Samuel DebionneRename (or add) setIntrumentName to setUserIntrumentNameFollowing up of https://gitlab.esrf.fr/limagroup/Lima-tango-python/-/merge_requests/100#note_272037Following up of https://gitlab.esrf.fr/limagroup/Lima-tango-python/-/merge_requests/100#note_272037https://gitlab.esrf.fr/limagroup/lima/-/issues/196Add scan concept2023-07-06T09:12:35+02:00Samuel DebionneAdd scan conceptMost of the time, Lima acquisitions are part of a broader concept (e.g. scan, sequence). It would be interesting to make Lima aware of this concept (let's use scan) and to provide:
- A way to set a `scan_uid`. If none/empty (default), k...Most of the time, Lima acquisitions are part of a broader concept (e.g. scan, sequence). It would be interesting to make Lima aware of this concept (let's use scan) and to provide:
- A way to set a `scan_uid`. If none/empty (default), keep the old behavior;
- If a `scan_uid` is set, `ImageStatus` counters (aka `last_image_xxx`) would be reset only when the `scan_uid` changes;
- Provide `scan_uid` in the frame `DevEncoded` header returned by `readImage()`;
- Overload `readImage([frame_idx, scan_uid])` to ensure that we get an image (eventually the latest image with `-1`) of a specific scan (would return `None` if a new scan has been prepared).
AFAIU, it would remove a lot of complexity in the clients code (e.g. blissdata, flint).
cc: @valentin.valls, @matias.guijarrohttps://gitlab.esrf.fr/limagroup/lima/-/issues/193Add a "Save every N frames" option2023-09-08T10:07:50+02:00Samuel DebionneAdd a "Save every N frames" optionRequested on ID10 to monitor the experiment at high frame rate (e.g. 10 fps) while saving the data at 0.5 fps. Used for instance with a Basler camera on LMCat.
Discussed with @papillon:
- Add a new saving mode `AUTO_SUBSAMPLE`
- Add a...Requested on ID10 to monitor the experiment at high frame rate (e.g. 10 fps) while saving the data at 0.5 fps. Used for instance with a Basler camera on LMCat.
Discussed with @papillon:
- Add a new saving mode `AUTO_SUBSAMPLE`
- Add a new property `saving_every_n_frames` that defaults to `1`Samuel DebionneSamuel Debionnehttps://gitlab.esrf.fr/limagroup/lima/-/issues/192Expose saturation level2023-01-25T09:09:03+01:00Valentin VallsExpose saturation levelFollowing https://gitlab.esrf.fr/bliss/bliss/-/issues/2880
It would be nice to allow camera connector to optionally expose the saturation level.
This way the information could be exposed to BLISS.
The exposed value also have to suppor...Following https://gitlab.esrf.fr/bliss/bliss/-/issues/2880
It would be nice to allow camera connector to optionally expose the saturation level.
This way the information could be exposed to BLISS.
The exposed value also have to support the actual Lima configuration such as accumulation mode.
This feature was also requested by scientist at ID31 during the EBS upgrade phase.https://gitlab.esrf.fr/limagroup/lima/-/issues/187CtAccumulation throws InvalidValue2022-11-18T11:21:04+01:00Samuel DebionneCtAccumulation throws InvalidValueOn BM18 with the Iris detector, looking at the logs:
```
[2022/11/17 08:38:27.315767] 197be0c2660 *Control*lima::CtAccumulation::getFrame (C:\blissadm\sources\lima\control\src\CtAccumulation.cpp:715)-Error: Exception...On BM18 with the Iris detector, looking at the logs:
```
[2022/11/17 08:38:27.315767] 197be0c2660 *Control*lima::CtAccumulation::getFrame (C:\blissadm\sources\lima\control\src\CtAccumulation.cpp:715)-Error: Exception(InvalidValue): [thrown]
********* Something weard append should be never in that case
```
This happens regularly over the last week, the log level is not high enough to investigate further. But "something weard append"! Weird.
cc @muzellehttps://gitlab.esrf.fr/limagroup/lima/-/issues/183Frames are not always flipped2022-09-15T15:16:33+02:00Samuel DebionneFrames are not always flippedOn BM18, acquisition with **accumulation** and **vertical flip** results in mixed flipped/non-flipped accumulated frames.
Acquired on IRIS (no hardware flip nor hardware accumulation).
In `/data/visitor/md1290/bm18/20220913/HA-2275_9.5...On BM18, acquisition with **accumulation** and **vertical flip** results in mixed flipped/non-flipped accumulated frames.
Acquired on IRIS (no hardware flip nor hardware accumulation).
In `/data/visitor/md1290/bm18/20220913/HA-2275_9.54um_C.niloticus_egg_R01-93D_acc3x10ms_15000proj_A__0002/md1290_HA-2275_9.54um_C.niloticus_egg_R01-93D_acc3x10ms_15000proj_A__0002.h5`, see projection `0001_4`, image `4012` for instance.https://gitlab.esrf.fr/limagroup/lima/-/issues/179HDF5: open file with access property list set with stdio driver to remove cac...2022-06-28T21:11:17+02:00Laurent ClaustreHDF5: open file with access property list set with stdio driver to remove cache effect on GPFSLaurent ClaustreLaurent Claustrehttps://gitlab.esrf.fr/limagroup/lima/-/issues/178Open HDF5 files as they are written (SWMR like)2022-06-08T13:25:14+02:00Samuel DebionneOpen HDF5 files as they are written (SWMR like)For [Tomovis](https://gitlab.esrf.fr/ui/tomovis), @tvincent and @valentin.valls would like to open HDF5 file as they are written. Tomovis is not aware of the Lima DS and cannot get frames directly from the cyclic buffer.
This is current...For [Tomovis](https://gitlab.esrf.fr/ui/tomovis), @tvincent and @valentin.valls would like to open HDF5 file as they are written. Tomovis is not aware of the Lima DS and cannot get frames directly from the cyclic buffer.
This is currently not possible `H5FOpen` reports a `Bad Header` error.
AFAIK, SWMR is not compatible with Direct Chunk.
A few things to try:
- [ ] `H5Fflush()` after preparing the file
- [ ] `H5Dflush()` periodically
- [ ] Add an "`H5FOpen` and `H5FClose`" option for each frame (since the scan is @1Hz)https://gitlab.esrf.fr/limagroup/lima/-/issues/176Update Camera List in the Documentation2022-04-07T10:56:11+02:00Samuel DebionneUpdate Camera List in the DocumentationMaybe it's worth noting the Iris camera in "Under development" and the Basler Pylon6 as "Supported"Maybe it's worth noting the Iris camera in "Under development" and the Basler Pylon6 as "Supported"v1.9.16https://gitlab.esrf.fr/limagroup/lima/-/issues/171Add `readLastImage()`2022-03-11T09:26:01+01:00Samuel DebionneAdd `readLastImage()`With the current API, `readImage()` returns the image for a given idx. With idx == -1, the last image is returned but the image does not have metadata attached to identify the frame (frame idx).
```
/// Optionally returns a frame if
//...With the current API, `readImage()` returns the image for a given idx. With idx == -1, the last image is returned but the image does not have metadata attached to identify the frame (frame idx).
```
/// Optionally returns a frame if
///
/// \param last_frame_idx The last frame that the client read (to avoid fetching the same data twice)
Data* readLastImage(int last_read_frame_idx);
```
There might also be an issue with `DATA_ARRAY` DevEncoded that does not pack enough information in the header (such as frame idx).
Feature request from @valentin.valls for Flinthttps://gitlab.esrf.fr/limagroup/lima/-/issues/169tutorials on Lima acq_trigger_mode2021-12-13T12:55:45+01:00Gaurontutorials on Lima acq_trigger_modeHello,
I wonder if there is a tutorial somewhere about different acq_trigger_mode (internal soft, external with trigger, etc.) and the awaited behaviour.
Some colleagues would like to test Lima and I imagine such a thing perhaps already...Hello,
I wonder if there is a tutorial somewhere about different acq_trigger_mode (internal soft, external with trigger, etc.) and the awaited behaviour.
Some colleagues would like to test Lima and I imagine such a thing perhaps already exists somewhere.
Regards.https://gitlab.esrf.fr/limagroup/lima/-/issues/168command to use with saving_mode doc ?2021-12-09T11:28:31+01:00Gauroncommand to use with saving_mode doc ?Hi,
I read in "Manual, no automatic saving, a command will be implemented in a next release to be able to save an acquired image."
I don't know when this was added to the [saving attributs doc section](https://lima1.readthedocs.io/en/l...Hi,
I read in "Manual, no automatic saving, a command will be implemented in a next release to be able to save an acquired image."
I don't know when this was added to the [saving attributs doc section](https://lima1.readthedocs.io/en/latest/applications/tango/python/doc/index.html#saving), but is this command `WriteImage`?
Regards,https://gitlab.esrf.fr/limagroup/lima/-/issues/164Latency time with video live is not working2021-11-10T13:13:32+01:00Valentin VallsLatency time with video live is not workingTrying to play with a RGB basler at ID24
It sounds like the latency time is not working.
```
BERRU [96]: bas_uscope_us.proxy.camera_model
Out [96]: 'acA3088-16gc'
```
```
BERRU [88]: bas_uscope_us.stop_live()
BERRU [89]: bas_uscope...Trying to play with a RGB basler at ID24
It sounds like the latency time is not working.
```
BERRU [96]: bas_uscope_us.proxy.camera_model
Out [96]: 'acA3088-16gc'
```
```
BERRU [88]: bas_uscope_us.stop_live()
BERRU [89]: bas_uscope_us.proxy.image_roi = [0, 0, 100,100]
BERRU [90]: bas_uscope_us.start_live(0.01)
BERRU [91]: bas_uscope_us.proxy.latency_time = 1
BERRU [92]: bas_uscope_us.stop_live()
BERRU [93]: bas_uscope_us.start_live(0.01)
BERRU [94]: bas_uscope_us.proxy.latency_time
Out [94]: 1.0
```
The camera was still taking about 20 frames/s
```
BERRU [97]: prdef(bas_uscope_us.start_live)
'start_live' is defined in:
/home/blissadm/local/bliss.git/bliss/controllers/lima/lima_base.py:1106
def start_live(self, acq_time: typing.Optional[float] = 0.1):
"""Start live video of a Lima detector.
This will also be displayed inside Flint.
"""
flint = plot_module.get_flint()
proxy = self.proxy
flint.start_image_monitoring(self.image.fullname, proxy.name())
if proxy.video_live:
proxy.video_live = False
proxy.acq_time = acq_time
proxy.video_source = "BASE_IMAGE"
proxy.video_exposure = acq_time
proxy.video_live = True
BERRU [98]: prdef(bas_uscope_us.stop_live)
'stop_live' is defined in:
/home/blissadm/local/bliss.git/bliss/controllers/lima/lima_base.py:1121
def stop_live(self):
"""Stop live video of a Lima detector
This will also be stopped inside Flint.
"""
proxy = self.proxy
proxy.video_live = False
flint = plot_module.get_flint(creation_allowed=False, mandatory=False)
if flint is not None:
flint.stop_image_monitoring(self.image.fullname)
```
Any idea why? @claustre @berruyerhttps://gitlab.esrf.fr/limagroup/lima/-/issues/163update install script and cmake and create a conda-requirements.txt for local...2021-11-22T15:45:07+01:00Laurent Claustreupdate install script and cmake and create a conda-requirements.txt for local compilation* missing last new cameras in config.txt
* tango server no longer uses cmake but pip to make installation
* provide a conda-requirements.txt to help creating a dev. conda environment for local compilation
* missing some saving formats (e...* missing last new cameras in config.txt
* tango server no longer uses cmake but pip to make installation
* provide a conda-requirements.txt to help creating a dev. conda environment for local compilation
* missing some saving formats (e.g hdf5bs) in install.sh script
* update documentation for local compilation using conda environmentLaurent ClaustreLaurent Claustrehttps://gitlab.esrf.fr/limagroup/lima/-/issues/162Pixel size unit2021-11-10T10:08:07+01:00Valentin VallsPixel size unitHi,
I found the following code in our bliss-tomo project (https://gitlab.esrf.fr/tomo/ebs-tomo)
```
ccd_ps = det.proxy.camera_pixelsize[0]
# Frelon return pixel size in meters, PCO and Andor in um!
if det.camera_type.lower() == "frelon...Hi,
I found the following code in our bliss-tomo project (https://gitlab.esrf.fr/tomo/ebs-tomo)
```
ccd_ps = det.proxy.camera_pixelsize[0]
# Frelon return pixel size in meters, PCO and Andor in um!
if det.camera_type.lower() == "frelon":
# conversion in microns
ccd_ps *= 1e6
```
I think it would be good to normalize that in order to reduce such tuning.
The best thing would be to normalize the Lima implementation and use the same unit everywhere, but i am afraid it could break stuffs in beamlines.
So one of the idea could be to provide a new function in the lima tango device.
```
def camera_pixelsize_um(...):
"""Returns the camera pixel size in micrometer"""
```
Such function could contain the fix according to each detector.
What do you think?https://gitlab.esrf.fr/limagroup/lima/-/issues/156prepareAcq fails with "ImageStatusCallback still active after 2 sec"2021-11-24T17:05:40+01:00Samuel DebionneprepareAcq fails with "ImageStatusCallback still active after 2 sec"I am afraid this is a follow-up of #106.
See bliss/bliss#2835 for the preliminary discussion.
It's basically a race condition that happens when running a basic acquisition in a loop", thanks to @denolf for the reduced repro:
```py
...I am afraid this is a follow-up of #106.
See bliss/bliss#2835 for the preliminary discussion.
It's basically a race condition that happens when running a basic acquisition in a loop", thanks to @denolf for the reduced repro:
```py
for i in range(32):
cam.proxy.prepareAcq()
cam.proxy.startAcq()
gevent.sleep(expo)
with gevent.Timeout(2.0):
while (
cam.proxy.acq_status.lower() != "ready"
or cam.proxy.last_image_ready == -1
):
gevent.sleep(0.001)
```
Reproduced on `bcu-ci` within Docker, but not locally nor on `lid00limace` within Docker. So tricky to reproduce.