Lima-camera-eiger issueshttps://gitlab.esrf.fr/limagroup/Lima-camera-eiger/-/issues2020-04-22T17:54:19+02:00https://gitlab.esrf.fr/limagroup/Lima-camera-eiger/-/issues/1ReadImage() fails on first acquired image ?2020-04-22T17:54:19+02:00Matias GuijarroReadImage() fails on first acquired image ?It seems like '.ReadImage()' call fails for Eiger detector, if it is called just after last_image_acquired >= 0
(for the first image, for example). Subsequent calls work fine, though.It seems like '.ReadImage()' call fails for Eiger detector, if it is called just after last_image_acquired >= 0
(for the first image, for example). Subsequent calls work fine, though.https://gitlab.esrf.fr/limagroup/Lima-camera-eiger/-/issues/2Eiger1 triggers not working2020-04-20T09:02:53+02:00Stuart FisherEiger1 triggers not workingThere seems to be an issue with Eiger1 and trigger mode.
In the default INTERNAL_TRIGGER it is possible to take images with limatake in bliss, however the other modes
INTERAL_TRIGGER_MULTI
EXTERNAL_TRIGGER_MULTI
EXTERNAL_GATE
all resul...There seems to be an issue with Eiger1 and trigger mode.
In the default INTERNAL_TRIGGER it is possible to take images with limatake in bliss, however the other modes
INTERAL_TRIGGER_MULTI
EXTERNAL_TRIGGER_MULTI
EXTERNAL_GATE
all result in the first image being taken then the Lima device being stuck at last_image_ready = 0
This happens on both id13, and id30, not sure what has changed as it seem this used to work?https://gitlab.esrf.fr/limagroup/Lima-camera-eiger/-/issues/3Allow to define specific HTTP and ZMQ ports #22020-05-07T15:38:49+02:00Laurent ClaustreAllow to define specific HTTP and ZMQ ports #2This is a pull-request on github from @tiago.coutinho at Alba:
https://github.com/esrf-bliss/Lima-camera-eiger/pull/2
If ok on your side @alejandro.homs we should merge it, please.This is a pull-request on github from @tiago.coutinho at Alba:
https://github.com/esrf-bliss/Lima-camera-eiger/pull/2
If ok on your side @alejandro.homs we should merge it, please.Alejandro Homs PuronAlejandro Homs Puronhttps://gitlab.esrf.fr/limagroup/Lima-camera-eiger/-/issues/4add command resetBias()2020-11-20T13:11:03+01:00Laurent Claustreadd command resetBias()Only useful for CdTe detector to reset the high-voltage in case of sensor polarisation which can introduce some background on few pixels.Only useful for CdTe detector to reset the high-voltage in case of sensor polarisation which can introduce some background on few pixels.Laurent ClaustreLaurent Claustrehttps://gitlab.esrf.fr/limagroup/Lima-camera-eiger/-/issues/5file_writer can be broken with timeout in Curl request2021-06-25T15:19:23+02:00Laurent Claustrefile_writer can be broken with timeout in Curl requestthe filewriter is no more working the acquisition starts but the Thread never seen the new files available.
Could it be due to the change in version 2020.2?
According to the releas notes:
filewriter_status:
parameter files: value type ch...the filewriter is no more working the acquisition starts but the Thread never seen the new files available.
Could it be due to the change in version 2020.2?
According to the releas notes:
filewriter_status:
parameter files: value type changed from list to stringLaurent ClaustreLaurent Claustrehttps://gitlab.esrf.fr/limagroup/Lima-camera-eiger/-/issues/6camera.initialize() makes the camera not working afterward2021-01-15T17:45:23+01:00Laurent Claustrecamera.initialize() makes the camera not working afterwardcomplained about missing header after ARM command:
```
EXP [28]: ct(eiger)
Wed Jan 13 17:12:57 2021: Scan(name=ct, path='not saved')
ERROR 2021-01-13 17:13:04,031 bliss.scans: Exception caught in eiger.prepare (DevFailed[=========>] ...complained about missing header after ARM command:
```
EXP [28]: ct(eiger)
Wed Jan 13 17:12:57 2021: Scan(name=ct, path='not saved')
ERROR 2021-01-13 17:13:04,031 bliss.scans: Exception caught in eiger.prepare (DevFailed[=========>] 9/ 9 eta [00:00]
DevError[
desc = limacore.Exception: Hardware: waitArmed(/opt/conda/conda-bld/lima-camera-eiger_1603357441445/work/src/EigerStream.cpp, 746): Error: Global header not received
```v1.9.6https://gitlab.esrf.fr/limagroup/Lima-camera-eiger/-/issues/7add energy threshold diff mode2021-02-16T15:21:54+01:00Laurent Claustreadd energy threshold diff modeby setting enabled the second threshold and the difference mode one get get an image = threshold2 - threshold1.
So add a new attribute energy_threshold2 and a new command set_energy_threshold_diff_mode True or False
To set a specific ...by setting enabled the second threshold and the difference mode one get get an image = threshold2 - threshold1.
So add a new attribute energy_threshold2 and a new command set_energy_threshold_diff_mode True or False
To set a specific energy as second threshold (in the example 52000 eV):
lid17medg> curl -X PUT http://lid17eiger2dcu.esrf.fr/detector/api/1.8.0/config/threshold/2/energy -H "Content-Type: application/json" -d '{"value": 52000}'
lid17medg> curl -X PUT http://lid17eiger2dcu.esrf.fr/detector/api/1.8.0/config/threshold/2/mode -H "Content-Type: application/json" -d '{"value": "enabled"}'
lid17medg> curl -X PUT http://lid17eiger2dcu.esrf.fr/detector/api/1.8.0/config/threshold/difference/mode -H "Content-Type: application/json" -d '{"value": "enabled"}'v1.9.6Laurent ClaustreLaurent Claustrehttps://gitlab.esrf.fr/limagroup/Lima-camera-eiger/-/issues/8hv_reset: add SPEC macro2021-03-18T08:25:58+01:00Laurent Claustrehv_reset: add SPEC macroin limaeiger.mac add the hv_reset command like in BLISS to wait for the hv ramping.in limaeiger.mac add the hv_reset command like in BLISS to wait for the hv ramping.v1.9.6Laurent ClaustreLaurent Claustrehttps://gitlab.esrf.fr/limagroup/Lima-camera-eiger/-/issues/9hardware saving: setCommonHearder failed2021-03-18T08:12:09+01:00Laurent Claustrehardware saving: setCommonHearder failedwith eiger2 json API header parameters must be passed has float not stringwith eiger2 json API header parameters must be passed has float not stringLaurent ClaustreLaurent Claustrehttps://gitlab.esrf.fr/limagroup/Lima-camera-eiger/-/issues/10Dectris Filewriter bug when no files in http://lidxxxeiger2dcu/data2021-06-30T11:24:39+02:00Antonia BetevaDectris Filewriter bug when no files in http://lidxxxeiger2dcu/dataLima throws exception when http://lidxxxeiger2dcu/data is empty. Any consecutive data acquisition does not transfer the files to the /data/visitior ot /data/inhouse, unless the device server is restarted. The exception comes from the fac...Lima throws exception when http://lidxxxeiger2dcu/data is empty. Any consecutive data acquisition does not transfer the files to the /data/visitior ot /data/inhouse, unless the device server is restarted. The exception comes from the fact that files returns null instead of string.
```
Not OK:
blissadm@lidxxxeiger2lima$ curl -X GET http://lidxxxeiger2dcu/filewriter/api/1.8.0/status/files
{"access_mode":"r","value":null,"value_type":"string"}
OK:
blissadm@lidxxxeiger2lima:$ curl -X GET http://lidxxxeiger2dcu/filewriter/api/1.8.0/status/files
{"access_mode":"r","value":["test_master.h5"],"value_type":"string"}
And the Lima error:
Et le Lima error qui va avec
[2021/02/18 16:59:08.844356] 7f976effd700 *Camera*Eiger::SavingCtrlObj::_PollingThread::threadFunction (/opt/conda/conda-bld/lima-camera-eiger_1610729398733/work/src/EigerCameraRequests.h:93)-Error: Exception(Error): http://lid231eiger2dcu100ge1:80/filewriter/api/1.8.0/status/files:
--------------------------------------------------------------------------------------------
EigerException
Description: wait_status:Rx value is not a string array(http://lid231eiger2dcu100ge1:80/filewriter/api/1.8.0/status/files)
Origin : void eigerapi::CurlLoop::FutureRequest::wait(double, bool) const
Location : /opt/conda/conda-bld/lima-camera-eiger_1610729398733/work/sdk/linux/EigerAPI/src/CurlLoop.cpp line 151
--------------------------------------------------------------------------------------------
[thrown]
***** Thread 7f976effd700 function exited due to an exception without clean-up! *****
```https://gitlab.esrf.fr/limagroup/Lima-camera-eiger/-/issues/11autosummation off wrong image2021-06-23T09:11:33+02:00Laurent Claustreautosummation off wrong imagewhen switching off the auto-summation mode Lima image is corrupted. When saving with file_writer the image is ok.
Tests have been performed on ID17, with a beam pattern (rectangle), and we see the beam with file_writer and a destructed i...when switching off the auto-summation mode Lima image is corrupted. When saving with file_writer the image is ok.
Tests have been performed on ID17, with a beam pattern (rectangle), and we see the beam with file_writer and a destructed image when getting the image with Lima and the streamer.Laurent ClaustreLaurent Claustrehttps://gitlab.esrf.fr/limagroup/Lima-camera-eiger/-/issues/12Out of memory crashes during prepareAcq2021-11-15T17:29:20+01:00Jonathan WrightOut of memory crashes during prepareAcqI understood this is a known bug. Here are the steps to get it to reproduce at ID11, I just verified it still crashes since upgrading to bliss 1.8. Here is a plot of the percent memory + cpu versus time from `top`:
![wrght](/uploads/aa2...I understood this is a known bug. Here are the steps to get it to reproduce at ID11, I just verified it still crashes since upgrading to bliss 1.8. Here is a plot of the percent memory + cpu versus time from `top`:
![wrght](/uploads/aa205386bd040ad63cfc268917d41adc/wrght.png)
This needs to be run a few times from when the bliss nscope session is restarted to kill the Lima server:
```
# /users/opid11/bliss_scripts/eigertimeout.py
def eigertimeout1():
# go between 32/16 bit and a couple vs many frames
time.sleep(5)
eiger.camera.auto_summation = 'OFF'
limatake(0.1,2)
t = 0.002 # go to 16 bit to 32 bit
limatake(t, 120*1024*1024*1024//(2162*2068*2),save=False)
time.sleep(5)
eiger.camera.auto_summation = 'ON'
limatake(0.1,2)
print("!"*80)
print("####### control-c the next scan please, when collecting frames")
print("!"*80)
limatake(t, 120*1024*1024*1024//(2162*2068*4),save=False)
```
1. on lid11eh3 start nscope session, run the test script and control-c when it is collecting frames in the scan that is tagged:
```
NSCOPE [1]: user_script_load('eigertimeout.py')
Loading [/users/opid11/bliss_scripts/eigertimeout.py]
Merged [user] namespace in session.
NSCOPE [2]: user.eigertimeout1()
acquisition chain
\u2514\u2500\u2500 eiger
Scan 18 Thu Aug 12 11:11:29 2021 nscope user = opid11
limatake 0.1000 2
Preparing eiger ...
Running ...
eiger acq #2
Finished (took 0:00:05.300922)
acquisition chain
\u2514\u2500\u2500 eiger
Scan 19 Thu Aug 12 11:11:35 2021 nscope user = opid11
limatake 0.0020 14409
Preparing eiger ...
Running ...
eiger acq #14409
Finished (took 0:01:15.016661)
acquisition chain
\u2514\u2500\u2500 eiger
Scan 20 Thu Aug 12 11:12:56 2021 nscope user = opid11
limatake 0.1000 2
Preparing eiger ...
Running ...
eiger acq #2
Finished (took 0:00:02.628463)
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
####### control-c the next scan please, when collecting frames
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
acquisition chain
\u2514\u2500\u2500 eiger
Scan 21 Thu Aug 12 11:12:58 2021 nscope user = opid11
limatake 0.0020 7204
Preparing eiger ...
Running ...
^Ceiger acq #4436
Finished (took 0:00:47.220614)
!!! === ScanAbort: === !!! ( for more details type cmd 'last_error' )
```
2. exit bliss and repeat step 1, it should crash on the second or third run.
Over on lid11eiger2lima you can watch the memory grow with: `top -d 1 -b | grep -e 1430951 -e ^top`
tagging @papillon. This bug was previously being chased on the bliss side https://gitlab.esrf.fr/bliss/bliss/-/merge_requests/3888, I am moving it here as it seems to be the lima eiger server that is crashing.https://gitlab.esrf.fr/limagroup/Lima-camera-eiger/-/issues/13Possibility to not wait for file sync in hardware managed writing?2023-02-10T10:37:02+01:00Stuart FisherPossibility to not wait for file sync in hardware managed writing?Michael Sztucki @ id13 asked me if it would be possible to have an eiger mode so that when saving is hardware managed it would be possible for the lima server to not wait for the h5 file download before the scan was completed. Could this...Michael Sztucki @ id13 asked me if it would be possible to have an eiger mode so that when saving is hardware managed it would be possible for the lima server to not wait for the h5 file download before the scan was completed. Could this be processed in the background and thus allow another scan to start while a previous scan was completing file download? For large scans downloading the data can block the scan for a number of minutes.Alejandro Homs PuronAlejandro Homs Puronhttps://gitlab.esrf.fr/limagroup/Lima-camera-eiger/-/issues/14in tango device set cache for few attributes2022-03-14T16:35:11+01:00Laurent Claustrein tango device set cache for few attributessome control system like BLISS needs to regularly read camera specific attributes to save then as meta-data.
Reading for instance energy_threshold takes ~100ms, so reading few attributes can add a non-negligible delay.
concerned attribut...some control system like BLISS needs to regularly read camera specific attributes to save then as meta-data.
Reading for instance energy_threshold takes ~100ms, so reading few attributes can add a non-negligible delay.
concerned attributes are:
- auto_summation
- countrate_correction
- flatfield_correction
- retrigger
- energy_threshold
- energy_threshold2
- threshold_diff_mode
- virtual_pixel_correctionLaurent ClaustreLaurent Claustrehttps://gitlab.esrf.fr/limagroup/Lima-camera-eiger/-/issues/15cache system in Eiger.py device not working2022-03-18T17:01:00+01:00Laurent Claustrecache system in Eiger.py device not workingcache is not used and attributes continue to make hw reading for attribute values.cache is not used and attributes continue to make hw reading for attribute values.Laurent ClaustreLaurent Claustrehttps://gitlab.esrf.fr/limagroup/Lima-camera-eiger/-/issues/16Eiger update cache after modification of binded attributes2022-07-18T09:50:15+02:00Perceval GuillouEiger update cache after modification of binded attributesWhen modifying some attribute like `photon_energy` other attribute like 'threshold_energy' is modified automatically by the camera.
This is currently incompatible with the caching of the attributes (cache value should be updated when th...When modifying some attribute like `photon_energy` other attribute like 'threshold_energy' is modified automatically by the camera.
This is currently incompatible with the caching of the attributes (cache value should be updated when the linked attrib is modified)Laurent ClaustreLaurent Claustrehttps://gitlab.esrf.fr/limagroup/Lima-camera-eiger/-/issues/17HW ROI for 9M/16M models2022-07-26T16:55:08+02:00Laurent ClaustreHW ROI for 9M/16M models9M and 16M models accept an HW Roi of as 4M, centered for the 16M and on left centered for the 9M.9M and 16M models accept an HW Roi of as 4M, centered for the 16M and on left centered for the 9M.Laurent ClaustreLaurent Claustrehttps://gitlab.esrf.fr/limagroup/Lima-camera-eiger/-/issues/18Bad frame number when 'atop' process runs2023-02-10T10:37:20+01:00Jonathan WrightBad frame number when 'atop' process runsI open a new issue here on the Lima-camera-eiger plugin to track the problem from ID11. This was previously tracked in https://requests.esrf.fr/plugins/servlet/desk/portal/1/SCHLP-15329
The off-by-one frame number shows up when the atop...I open a new issue here on the Lima-camera-eiger plugin to track the problem from ID11. This was previously tracked in https://requests.esrf.fr/plugins/servlet/desk/portal/1/SCHLP-15329
The off-by-one frame number shows up when the atop logging process runs (at higher priority) and this causes the scan to block. We saw many examples in lid11eiger2lima:/var/log/EigerMem.log, usually the errors shows up at multiples of 10 minutes.
This problem should be suppressed by stopping the atop process for now. In the longer term, I am afraid there is an underlying problem that will surface again when the machine sees an increased load.
```
[2022/05/26 12:40:04.516360] 7f92cd2d1700 *Camera*Eiger::Stream::_ZmqThread::_read_zmq_messages (/bliss/users/blissadm/local/lima.git/camera/eiger/src/EigerStream.cpp:400)-Error: Exception(Error): Bad frame number: 760, expected 759 [thrown]
[2022/05/26 12:40:04.516719] 7f92cd2d1700 *Camera*Eiger::Stream::_ZmqThread::_run_sequence (/bliss/users/blissadm/local/lima.git/camera/eiger/src/EigerStream.cpp:337)-Error: *event=<Event: Severity=Error, Domain=Camera, Code=CamFault: Stream error: Hardware: _read_zmq_messages(/bliss/users/blissadm/local/lima.git/camera/eiger/src/EigerStream.cpp, 400): Error: Bad frame number: 760, expected 759>
[2022/05/26 12:40:04.516742] 7f92cd2d1700 *Control*Control::Event::reportEvent (/bliss/users/blissadm/local/lima.git/control/src/CtEvent.cpp:133)-Error: *event=<Event [5.78013]: Severity=Error, Domain=Camera, Code=CamFault: Stream error: Hardware: _read_zmq_messages(/bliss/users/blissadm/local/lima.git/camera/eiger/src/EigerStream.cpp, 400): Error: Bad frame number: 760, expected 759>
```Alejandro Homs PuronAlejandro Homs Puronhttps://gitlab.esrf.fr/limagroup/Lima-camera-eiger/-/issues/19hwroi reset acq parameters2022-11-03T10:39:01+01:00Laurent Claustrehwroi reset acq parametershwroi change (even to disabled) reset count_time and frame_time and maybe the trigger modehwroi change (even to disabled) reset count_time and frame_time and maybe the trigger modeLaurent ClaustreLaurent Claustrehttps://gitlab.esrf.fr/limagroup/Lima-camera-eiger/-/issues/20update to latest sip 4.19 and mamba build2022-11-03T12:13:17+01:00Laurent Claustreupdate to latest sip 4.19 and mamba buildLaurent ClaustreLaurent Claustrehttps://gitlab.esrf.fr/limagroup/Lima-camera-eiger/-/issues/21stopping an acquisition in hw saving does not manage the last file2023-11-03T16:45:21+01:00Laurent Claustrestopping an acquisition in hw saving does not manage the last fileWhen stopping an ongoing acquisition, Lima stops the detector (ABORT command) which disarms it then it stops the hw saving.
Disarm of the detector will finalize the last file and save it on the DCU storage. This can takes some amount of ...When stopping an ongoing acquisition, Lima stops the detector (ABORT command) which disarms it then it stops the hw saving.
Disarm of the detector will finalize the last file and save it on the DCU storage. This can takes some amount of time and in the middle Lima has already stop the file transfer.
The last file stays in the DCU storage, and a new acquisition started with the same file prefix will get transferred the file of the previous acquisition.
A first and simple solution to fix this issue consists in clearing the DCU storage before starting a new acquisition (in the prepareAcq()).
That means all the remaining images saved in the last file of the previous acquisition will be lost.
A more elegant solution is to wait few seconds after the ABORT command to let the hw saving transferring the last file.Laurent ClaustreLaurent Claustrehttps://gitlab.esrf.fr/limagroup/Lima-camera-eiger/-/issues/22Retrigger param does not exist on old eiger12024-01-29T16:50:55+01:00Stuart FisherRetrigger param does not exist on old eiger1retrigger param does not exist on old eiger1 hardware (raises 404 in the eiger dcu logs). This causes device initialisation to fail due to:
https://gitlab.esrf.fr/limagroup/Lima-camera-eiger/-/blob/master/tango/Eiger.py#L122
I've commen...retrigger param does not exist on old eiger1 hardware (raises 404 in the eiger dcu logs). This causes device initialisation to fail due to:
https://gitlab.esrf.fr/limagroup/Lima-camera-eiger/-/blob/master/tango/Eiger.py#L122
I've commented this locally, but i guess there needs to be a switch depending on hardware versionhttps://gitlab.esrf.fr/limagroup/Lima-camera-eiger/-/issues/23doc: fix sphinx error2023-11-03T16:16:05+01:00Laurent Claustredoc: fix sphinx errorLaurent ClaustreLaurent Claustrehttps://gitlab.esrf.fr/limagroup/Lima-camera-eiger/-/issues/24Preparation fails randomly (and rarely)2023-11-17T15:17:01+01:00Samuel DebionnePreparation fails randomly (and rarely)Looks like the state machine sometimes misses the end of the acquisition that stays RUNNING:
```
[2023/11/17 14:47:10.916635] 7f79ef7fe700 *Control*Control::Control::prepareAcq (/opt/conda/conda-bld/lima-core_1648541428893/work/cont...Looks like the state machine sometimes misses the end of the acquisition that stays RUNNING:
```
[2023/11/17 14:47:10.916635] 7f79ef7fe700 *Control*Control::Control::prepareAcq (/opt/conda/conda-bld/lima-core_1648541428893/work/control/src/CtControl.cpp:479)-Error: Exception(Error): Acquisition not finished [thrown]
[2023/11/17 14:48:25.153778] 7f79ed7fa700 *Control*Control::Control::prepareAcq (/opt/conda/conda-bld/lima-core_1648541428893/work/control/src/CtControl.cpp:479)-Error: Exception(Error): Acquisition not finished [thrown]
[2023/11/17 14:48:45.421245] 7f79ef7fe700 *Control*Control::Control::prepareAcq (/opt/conda/conda-bld/lima-core_1648541428893/work/control/src/CtControl.cpp:479)-Error: Exception(Error): Acquisition not finished [thrown]
```
cc: @maciej.jankowski