When it comes to cameras (and other potential 2D+ mappings) we are not doing the right thing.
The way has-mapping is written any mappings that apply to the same channel must have the same ndim as each other and the channel. They form a group of mapping that all work together and operate on the same channels. and the channels themselves must all broadcast together as well.
The way we have it implemented here each mapping provides sets of dimensions and the channel takes on all of their named dimensions (with the names being autogenerated).
This was not a problem for 1D detectors as they only had one mapping, so it actually did the right thing (aside from name of the dimension probably not being what we want, but nothing functionally wrong)
I propose adding a fake-has-mapping daemon to yaqd-fakes which operates like a camera and adding a test here which runs count in a run engine and reads the data back as an xarray using bluesky tools (and of course fixing the implementation).
ksunden
commented
2 years ago
When it comes to cameras (and other potential 2D+ mappings) we are not doing the right thing.
The way has-mapping is written any mappings that apply to the same channel must have the same ndim as each other and the channel. They form a group of mapping that all work together and operate on the same channels. and the channels themselves must all broadcast together as well.
The way we have it implemented here each mapping provides sets of dimensions and the channel takes on all of their named dimensions (with the names being autogenerated).
This was not a problem for 1D detectors as they only had one mapping, so it actually did the right thing (aside from name of the dimension probably not being what we want, but nothing functionally wrong)
I propose adding a fake-has-mapping daemon to yaqd-fakes which operates like a camera and adding a test here which runs
countin a run engine and reads the data back as an xarray using bluesky tools (and of course fixing the implementation).