Lima issueshttps://gitlab.esrf.fr/limagroup/lima/-/issues2020-06-10T12:01:44+02:00https://gitlab.esrf.fr/limagroup/lima/-/issues/116Data saving with HDF5 shows low performance2020-06-10T12:01:44+02:00Alejandro Homs PuronData saving with HDF5 shows low performanceWhen performing acquisitions with the Dectris/Eiger2 under X-ray generator photons at ID22, the effective data saving performance is very low:
> The current illumination scheme generate compressed images of ~450 kByte. Under this regim...When performing acquisitions with the Dectris/Eiger2 under X-ray generator photons at ID22, the effective data saving performance is very low:
> The current illumination scheme generate compressed images of ~450 kByte. Under this regime, at 2 kHz frame rate, we found a limiting saving speed on BeeGFS with HDF5-BSLZ4 of ~450 MByte/s (when 900 MByte/s is needed). The interesting news is that we found more or less the same limit saving on one NVME drive, contrary to what we expected
https://gitlab.esrf.fr/limagroup/lima/-/issues/108Usage of [[maybe_unused]] and other C++17 attributes2020-05-20T14:48:53+02:00Samuel DebionneUsage of [[maybe_unused]] and other C++17 attributesThe following discussion from !158 should be addressed:
- [ ] @debionne started a [discussion](https://gitlab.esrf.fr/limagroup/lima/-/merge_requests/158#note_70720): (+8 comments)
> `[[maybe_unused]]` is C++17 but should be harml...The following discussion from !158 should be addressed:
- [ ] @debionne started a [discussion](https://gitlab.esrf.fr/limagroup/lima/-/merge_requests/158#note_70720): (+8 comments)
> `[[maybe_unused]]` is C++17 but should be harmless (even for MSVC) but might generate a warning... which is what you are trying to avoid.https://gitlab.esrf.fr/limagroup/lima/-/issues/106CtControl::m_img_status_thread_list management is not completely thread-safe2021-06-21T17:34:18+02:00Alejandro Homs PuronCtControl::m_img_status_thread_list management is not completely thread-safe`[un]registerImageStatusCallback` hold the lock before modifying the list. Before doing so, the acquisition state must be `AcqReady` (unregister) or different that `AcqRunning` (register).
During `AcqRunning` many methods iterate the li...`[un]registerImageStatusCallback` hold the lock before modifying the list. Before doing so, the acquisition state must be `AcqReady` (unregister) or different that `AcqRunning` (register).
During `AcqRunning` many methods iterate the list after releasing the lock. This is done for performance reasons. In a first approach there should be no big risk here, because taking/releasing the lock forces memory barriers that avoid race conditions.
There are two places with a risk of code iterating the list in parallel to a call to `[un]registerImageStatusCallback`:
1. In the beginning of `prepareAcq`, where no lock is taken
1. At the end of the last call to `_calcAcqStatus`, after setting the state to `AcqReady`.
A possible solution: add a `m_img_status_thread_list_busy` flag.https://gitlab.esrf.fr/limagroup/lima/-/issues/105Missing explicit way to know when prepareAcq can be called after an error2020-04-06T14:54:41+02:00Alejandro Homs PuronMissing explicit way to know when prepareAcq can be called after an errorAfter an error event the `AcqStatus` passes to `AcqFault`, and the clients cannot know then the processing has finish in order to call a new `prepareAcq`.
Possible solutions:
* Add AcqFaultStopping stateAfter an error event the `AcqStatus` passes to `AcqFault`, and the clients cannot know then the processing has finish in order to call a new `prepareAcq`.
Possible solutions:
* Add AcqFaultStopping statev1.10.0https://gitlab.esrf.fr/limagroup/lima/-/issues/104new CtAcquisition FramePerTrigger parameter2020-03-06T11:07:51+01:00Laurent Claustrenew CtAcquisition FramePerTrigger parameterThis will replace the TrigSequences trigger mode in Eiger experimental branch used on ID30a3.
This must work for both hw and soft triggers
Todo:
* Eiger
* Frelon
* Maxipix
* Simulator (useful to have test with mesh in bliss CI)This will replace the TrigSequences trigger mode in Eiger experimental branch used on ID30a3.
This must work for both hw and soft triggers
Todo:
* Eiger
* Frelon
* Maxipix
* Simulator (useful to have test with mesh in bliss CI)v1.10.0https://gitlab.esrf.fr/limagroup/lima/-/issues/103Int/ExtTriggerMulti: Distiguish between detector status Idle and WaitForTrigger2020-03-10T08:29:35+01:00Laurent ClaustreInt/ExtTriggerMulti: Distiguish between detector status Idle and WaitForTriggerThe detector status is a bit mask:
* DetIdle means the acquisition is finished (readout of last frame done): ready for a new prepareAcq
* DetWaitForTrigger means detector head is ready to receive a new software/hardware trigger
Todo: ...The detector status is a bit mask:
* DetIdle means the acquisition is finished (readout of last frame done): ready for a new prepareAcq
* DetWaitForTrigger means detector head is ready to receive a new software/hardware trigger
Todo:
* Remove HwInterface::Status::Basic
* Simulator, Frelon and Eiger, among others
* LimaCCDs attr ready_for_next_image
* This must been included in CtControl::startAcq()v1.10.0https://gitlab.esrf.fr/limagroup/lima/-/issues/84delation of external operation during acquisition not manage2019-03-13T15:07:18+01:00Laurent Claustredelation of external operation during acquisition not manageThat crashes something and the acquisition is endless till an abortAcq.
Solution, forbid the extOp.delete() during acquisitionThat crashes something and the acquisition is endless till an abortAcq.
Solution, forbid the extOp.delete() during acquisitionLaurent ClaustreLaurent Claustrehttps://gitlab.esrf.fr/limagroup/lima/-/issues/82[CMake] Rename CAMERA_ENABLE_PYTHON for every migrated cameras2019-01-09T19:40:10+01:00Samuel Debionne[CMake] Rename CAMERA_ENABLE_PYTHON for every migrated camerasShould be LIMA_ENABLE_PYTHON. Was my mistake in the first place to use a different variable name.Should be LIMA_ENABLE_PYTHON. Was my mistake in the first place to use a different variable name.v1.8Samuel DebionneSamuel Debionnehttps://gitlab.esrf.fr/limagroup/lima/-/issues/69Remove LiveViewer plugin2019-09-16T11:23:31+02:00Samuel DebionneRemove LiveViewer pluginKnown to be a source of issues according to @sebastien.petitdemangeKnown to be a source of issues according to @sebastien.petitdemangev1.8Laurent ClaustreLaurent Claustrehttps://gitlab.esrf.fr/limagroup/lima/-/issues/66Bootstrap script accepts options that are not defined and silently ignored them2021-11-08T13:35:26+01:00Samuel DebionneBootstrap script accepts options that are not defined and silently ignored them`install.sh tango` should fail with `ERROR: unknown option tango, did you mean pytango?`.`install.sh tango` should fail with `ERROR: unknown option tango, did you mean pytango?`.Alejandro Homs PuronAlejandro Homs Puronhttps://gitlab.esrf.fr/limagroup/lima/-/issues/52AttributeError reading image_events_max_rate on Simulator2019-09-11T14:51:16+02:00Matias GuijarroAttributeError reading image_events_max_rate on Simulator```
DevError[
desc = Failed to read_attribute on device id00/limaccds/simulator1, attribute image_events_max_rate
origin = DeviceProxy::read_attribute()
reason = API_AttributeFailed
severity = ERR]
]
DevFailed[
DevError[
desc...```
DevError[
desc = Failed to read_attribute on device id00/limaccds/simulator1, attribute image_events_max_rate
origin = DeviceProxy::read_attribute()
reason = API_AttributeFailed
severity = ERR]
]
DevFailed[
DevError[
desc = AttributeError: LimaCCDs has no attribute _LimaCCDs__image_status_cbk
origin = File "/home/matias/miniconda2/envs/bliss/lib/python2.7/site-packages/Lima/Core/Debug.py", line 52, in real_fn
return new_fn(*arg, **kw)
File "/home/matias/miniconda2/envs/bliss/lib/python2.7/site-packages/Lima/Server/LimaCCDs.py", line 1191, in read_image_events_max_rate
event_rate = self.__image_status_cbk.getImageEventsMaxRate()
File "/home/matias/miniconda2/envs/bliss/lib/python2.7/site-packages/Lima/Server/LimaCCDs.py", line 640, in __getattr__
raise AttributeError('LimaCCDs has no attribute %s' % name)
reason = PyDs_PythonError
severity = ERR]
```Samuel DebionneSamuel Debionnehttps://gitlab.esrf.fr/limagroup/lima/-/issues/51Move the camera specific part of Tango (python code and doc) in the camera su...2019-07-23T08:20:53+02:00Samuel DebionneMove the camera specific part of Tango (python code and doc) in the camera submoduleSamuel DebionneSamuel Debionnehttps://gitlab.esrf.fr/limagroup/lima/-/issues/49ROI (cropping) and ROI (counters) may conflict and error is reported at acqui...2021-11-08T13:32:54+01:00Samuel DebionneROI (cropping) and ROI (counters) may conflict and error is reported at acquisition stageReported by @meyer on JIRA
https://jira.esrf.fr/browse/BLHDK-5603
Improve error reporting on spec. Add a check at prepare stage for this kind of misconfigurations.Reported by @meyer on JIRA
https://jira.esrf.fr/browse/BLHDK-5603
Improve error reporting on spec. Add a check at prepare stage for this kind of misconfigurations.https://gitlab.esrf.fr/limagroup/lima/-/issues/48Add troubleshooting section2021-11-08T13:29:54+01:00Samuel DebionneAdd troubleshooting sectionThe first entry could be about `export HDF5_USE_FILE_LOCKING='FALSE'` when writing HDF5 file on NFS.The first entry could be about `export HDF5_USE_FILE_LOCKING='FALSE'` when writing HDF5 file on NFS.Samuel DebionneSamuel Debionnehttps://gitlab.esrf.fr/limagroup/lima/-/issues/38[CMake] Sip generated files misses a dependency on their sip sources2021-11-08T13:29:21+01:00Samuel Debionne[CMake] Sip generated files misses a dependency on their sip sourcesModification of `.sip` files do not trigger a regeneration of their `.cpp` counterparts.Modification of `.sip` files do not trigger a regeneration of their `.cpp` counterparts.Samuel DebionneSamuel Debionnehttps://gitlab.esrf.fr/limagroup/lima/-/issues/24Add a submodule commit checker server-side git hook2021-11-08T13:31:41+01:00Samuel DebionneAdd a submodule commit checker server-side git hookMaybe we should setup a submodule commit checker pre-receive server-side git hook, like the one describe here:
https://gist.github.com/bagage/bdca3d4b66d43db7a5e3Maybe we should setup a submodule commit checker pre-receive server-side git hook, like the one describe here:
https://gist.github.com/bagage/bdca3d4b66d43db7a5e3Samuel DebionneSamuel Debionnehttps://gitlab.esrf.fr/limagroup/lima/-/issues/23Create a landing page for the project2021-11-08T13:32:25+01:00Samuel DebionneCreate a landing page for the projectFind a webserver to serve these static pages.Find a webserver to serve these static pages.https://gitlab.esrf.fr/limagroup/lima/-/issues/19Move Tango server camera plugins to their respective submodules2019-03-13T15:20:56+01:00Samuel DebionneMove Tango server camera plugins to their respective submodulesIt would be easier to guaranty the compatibility of the Tango plugins with the Lima plugin if they were in the same repo.It would be easier to guaranty the compatibility of the Tango plugins with the Lima plugin if they were in the same repo.https://gitlab.esrf.fr/limagroup/lima/-/issues/1Wrong video_exposure2021-11-08T13:27:28+01:00Matias GuijarroWrong video_exposure(problem seen with Prosilica camera, latest version on sybil / ID23-2, with Lima Tango server)
Initially, video_exposure == 0.08 and acq_expo_time = 0.001 ; video_live = True.
video_exposure gets wrong when doing the following sequence...(problem seen with Prosilica camera, latest version on sybil / ID23-2, with Lima Tango server)
Initially, video_exposure == 0.08 and acq_expo_time = 0.001 ; video_live = True.
video_exposure gets wrong when doing the following sequence:
- video_live = False
- acq_nb_frames = 1
- prepareAcq
- startAcq
- video_exposure => 0.001 !!!
So, calling 'video_live = True' after that does not produce the 'right' frames.