Rework scan_info acquisition_chain
This is proposal to discuss about reworking the acquisition_chain
field from the scan_info
.
State
Now the acquisition_chain
looks like that:
"acquisition_chain": {
"timer": {
"master": {
"images": [],
"scalars": ["timer:elapsed_time", "timer:epoch"],
"spectra": [],
},
"scalars": ["diode1"],
"images": ["lima1:image"]
},
"axis":
"master": {
"images": [],
"scalars": ["sx"],
"spectra": [],
},
"scalars": ["diode2"],
"img": {
"master": {
"images": ["lima2:image"],
},
"spectra": ["opium:mca1"],
"scalars": ["timer:elapsed_time", "timer:epoch"]
},
},
It contains:
- Relationship between top master and channels
- Channel generated by device used as master
- Kind of channel data
- Ordered top masters
- Ordered channels
What i don't like
-
- structurally
is_master
and data kind are orthogonal information
- but here is handled by combination (6*2 = 6 lists, for now)
- structurally
-
- data kind have nothing to do with the
acquisition_chain
- This information is probably not at the proper place
- data kind have nothing to do with the
-
-
spectra
is not a proper name for any kind of list of values (in fact it's the same forimage
)
- It feels like an accurate kind, but it's just about data dimension
-
-
- A channel is never a master -> a device is the master and this device produce a channel
- What does
lima:image
as master means?- That's in fact just a counter
- Maybe there is a better way to handle that
-
- We have to expose metadata per devices (right now we have to cheat using channels)
Proposal 1
- This address 1) 2) 3)
- Now we have a
scan_info/channels
fields which can be used for data kind - We can use
data dim
instead ofdata kind
scan_info = {
'acquisition_chain': {
'timer': {
# WAS ADDED
'devices': ['timer', 'simulation_diode_sampling_controller'],
# STILL THERE FOR COMPATIBILITY
'images': [],
'master': {'images': [], 'scalars': ['timer:elapsed_time', 'timer:epoch'], 'spectra': []},
'scalars': ['simulation_diode_sampling_controller:diode1'],
'spectra': []}
},
# WAS ADDED
'devices': {
'simulation_diode_sampling_controller': {
'channels': ['simulation_diode_sampling_controller:diode1']},
'timer': {
'channels': ['timer:elapsed_time', 'timer:epoch'],
'triggers': ['simulation_diode_sampling_controller']}
},
'channels': {
'simulation_diode_sampling_controller:diode1': {
'dim': 0, # <-- DIM WAS ADDED
'display_name': 'diode1'},
'timer:elapsed_time': {
'dim': 0,
'display_name': 'elapsed_time',
'unit': 's'},
'timer:epoch': {
'dim': 0,
'display_name': 'epoch',
'unit': 's'}
},
}
It contains the same information as before then I think there is no problem to implement this change.
Proposal 1+1
- This address 4) 5)
- We can expose the devices and the relationshit between devices and channels
- A device can be a
master
if it triggers other devices (no magic, exact same model as bliss)
'acquisition_chain': {
'timer': {
# WAS ADDED
'devices': ['timer', 'simulation_diode_sampling_controller'],
# STILL THERE FOR COMPATIBILITY
'images': [],
'master': {'images': [], 'scalars': ['timer:elapsed_time', 'timer:epoch'], 'spectra': []},
'scalars': ['simulation_diode_sampling_controller:diode1'],
'spectra': []}
},
# WAS ADDED
'devices': {
'simulation_diode_sampling_controller': {
'channels': ['simulation_diode_sampling_controller:diode1']},
'timer': {
'channels': ['timer:elapsed_time', 'timer:epoch'],
'triggers': ['simulation_diode_sampling_controller']}
},