Refactoring of data handling in scans
Both AcquisitionDevice
and AcquisitionMaster
objects have a type
property, which is currently set to:
- zerod
- lima
- axis ...
However, the type of data produced should be defined in AcquisitionChannel
objects. We can imagine a device
that produces different kinds of data.
The analysis of current implementation of data handling also showed some flaws that we want to fix.
TODO
-
AcquisitionChannel
will have the following members:name
-
dtype
(numpy type) -
shape
(data item value shape, ie.()
for scalar,(n, )
for 1D,(n, -1)
for 2D -
reference
(bool,True
means data item value is in fact a reference) -
value
(ordata
? ; data item value, eg. numpy array or reference) -
metadata
(orparameters
? ; dict, meta data associated with the data item like exposure time for Lima 2D acq channel)
- the published data in Redis has to be an exact match of the acquisition chain tree
- writer objects will take data from Redis or from a "fast path" (callback), but in anyways the events etc will match the acquisition chain tree as close as possible
See PR !512 (merged)
DONE CRITERIA
- tests (
pytest
) demonstrateAcquisitionChannel
features and how data is published and how HDF5 file is written
Edited by Matias Guijarro