DiamondLightSource / DiamondLightSource/dodal

Document decision on Base DCM

Open
#1,617 5 comments 0 reactions 0 assignees View on GitHub
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

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.