DAE: user-facing classes

[Tom-Willemsen]

As a user I'd like to use a DAE in scans.

This ticket aims to deliver user-facing DAE device(s) which cover the "simple" scientific use-cases - but not necessarily all possible use-cases.

The basic signals (but no real functionality) will have been added in #9 - that needs to be completed first.

Acceptance criteria

• Can create a DAE object which can be used as a detector in any scan plan in a way that "makes sense" for end-users.
  • Note: this implies it needs to implement at least Readable and Triggerable)
• Can choose the run behaviour between the two typical "simple" cases:
  • One period per point
  • One run per point
  • Implementation note: this likely implies two classes - The period-per-point DAE needs to start/stop DAE runs in stage/unstage and therefore additionally needs to be an AsyncStageable.
• Can configure DAE parameters (tables, periods, tcbs, etc)
  • The signals for all of these things will already have been added - just need to make sure those signals remain accessible and with a sensible interface for plans to use them.
• Can configure basic "local" parameters such as:
  • How long to count for at each point (uamps/frames/events/seconds/etc). For this issue, don't consider "custom" counting conditions.
  • Whether to end runs or abort them
  • Which detectors to integrate counts from (for this issue - assume a small, explicit list of detectors)
  • Which monitors to integrate counts from (for this issue - assume a small, explicit list of monitors)
  • We may choose to accept some or all of the above via the Preparable protocol or similar.
• Summed detector and monitor counts are available
  • For this issue, do not consider time-of-flight bounds or any processing beyond a simple summation on detector or monitor spectra. That will be the subject of a future issue.
• Normalized detector counts are available
  • For this issue, do not worry about implementing uncertainties or uncertainty propagation on counts. That will be the subject of a future issue.
  • For this issue do not consider "custom" normalization. That will be the subject of a future issue. Only implement the simple case of dividing detector counts by monitor counts.

Discussed in planning 05/09/24

43:45

[iangillingham-stfc]

Functionally the build from this PR works as intended. Documentation has been augmented to cover the new features. I did however, need to do some detective work as to how to implement a period per point run. It wasn't entirely clear, for example, to use the PeriodGoodFramesNormalizer() reducer instead of the GoodFramesNormalizer() reducer. I'm sure that more exposure and familiarity with the bluesky dae classes would overcome this, but for someone starting to use this, it would be useful to perhaps have example snippets for each use case.

[iangillingham-stfc]

Re-tested this morning with Freddie's recent changes to ISISICP and it appeared to work well. So I'll merge the PR...