DiamondLightSource / DiamondLightSource/dodal
Document decision on Base DCM
- Dominant language
- Python
- Stars
- 5
- Forks
- 13
- Avg merge
- 3d 2h
- Merged PRs (30d)
- 10
Description
From discussion with various members across DAQ, this is what was decided for the BaseDCM class:
- D spacing should be taken out of the base class
- If any extra logic or signals need to be added for a beamline implementation, they can subclass `BaseDCM`
- If the extra logic is _just_ metadata (i.e signals that are added as readables, but never referred to in the plan), then use the optional metadata parameter on `BaseDCM` (see https://github.com/DiamondLightSource/dodal/pull/1601#issuecomment-3376514153)
- We temporarily need to make another DCM class which doesn't have some signals in the `BaseDCM`. This class should be linked to an issue about moving their DCM IOC to the standard interface
- The standard interface for the BaseDCM should be documented, which defines what it needs from EPICS and in DAQ.
- Avoid making long chains of inheritance. Ideally it should only ever be BaseDCM -> BeamlineDCM
- Avoid creating devices dynamically, make short classes instead
- Rename `BaseDCM` to `DCMBase`, because it will be annoying to have loads of classes starting with the word "Base"
## Acceptance criteria
- Document the above decisision
- Document the general process for creating a base device
Contributor guide
Assessment
This issue has not been assessed yet.