You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Move beamline specific devies from dodal.devices.iXX to dodal.devices.beamlines.iXX (#1866)
* Move beamline specific devies from dodal.devices.iXX to dodal.devices.beamlines.iXX
* merge into main
* Fix tests from merge conflicts
* Fix test from merge conflict
* Update docs
Copy file name to clipboardExpand all lines: docs/how-to/create-device.md
+8-2Lines changed: 8 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -27,7 +27,13 @@ For example, only use `XYStage` for two perpendicular motors (e.g. X and Y axes
27
27
- Only a device that represents a group of motors with a physical relationship, should be defined in `motor`.
28
28
- If your class define an `XYStage` but you need extra signals or behaviour, extend the `XYStage` class outside the `motor` module.
29
29
30
-
**Only if no suitable class exists**, create a new device that connects to the required signals. During review, refactor to align with existing devices if needed, using inheritance or composition to deduplicate code.
30
+
**Only if no suitable class exists**, create a new device that connects to the required signals. During review, refactor to align with existing devices if needed, using inheritance or composition to deduplicate code.
31
+
32
+
Devices that are generic and reusable across multiple beamlines should be defined under `dodal.devices`. For example, `dodal.devices.motors.XYStage` is generic enough that most beamlines can use it directly or inherit from it.
33
+
34
+
Devices that are specific to a single beamline should be placed under `dodal.devices.beamlines.iXX`. For instance, a detector that is only used on that beamline and is too specialized to be reused elsewhere belongs here.
35
+
36
+
If a beamline has multiple endstations and a device is shared between them, it should be defined under `dodal.devices.beamlines.iXX_shared`.
31
37
32
38
Writing a device class
33
39
======================
@@ -36,7 +42,7 @@ To develop a new device, get an initial, working version of your code into the m
36
42
37
43
-**Follow the [ophyd-async device implementation guide](https://blueskyproject.io/ophyd-async/main/tutorials/implementing-devices.html)** to structure your device code.
38
44
-**Choose the right base class** by consulting the [base class guide](https://blueskyproject.io/ophyd-async/main/how-to/choose-right-baseclass.html), If your device needs to move, you'll need to extend the Movable protocol. For detailed guidance on when and how to do this, refer to the [movable device guide](https://blueskyproject.io/ophyd-async/main/explanations/when-to-extend-movable.html).
39
-
-**Add static metadata (if any) to the device class** using a [soft signal](https://blueskyproject.io/ophyd-async/main/_api/ophyd_async/ophyd_async.core.html#ophyd_async.core.soft_signal_rw) or existing device epics record. For example this could be a manufacturer or brand name of the device. Another example is crystal metadata in [i22 DCM](https://diamondlightsource.github.io/dodal/main/reference/generated/dodal.devices.i22.dcm.DCM.html#dodal.devices.i22.dcm.DCM) In some cases it might be beneficial to ask controls team to create an additional epics field containing metadata for such device.
45
+
-**Add static metadata (if any) to the device class** using a [soft signal](https://blueskyproject.io/ophyd-async/main/_api/ophyd_async/ophyd_async.core.html#ophyd_async.core.soft_signal_rw) or existing device epics record. For example this could be a manufacturer or brand name of the device. Another example is crystal metadata in [i22 DCM](https://diamondlightsource.github.io/dodal/main/reference/generated/dodal.devices.beamlines.i22.dcm.DCM.html#dodal.devices.beamlines.i22.dcm.DCM) In some cases it might be beneficial to ask controls team to create an additional epics field containing metadata for such device.
40
46
-**Write thorough unit tests** for all expected use cases. Reference the [ophyd-async device test guide](https://blueskyproject.io/ophyd-async/main/tutorials/implementing-devices.html) for best practices.
41
47
-**Validate your device on the beamline** and keep notes of any issues for later fixes.
42
48
-**Make use of type annotations** so that pyright will validate that you are passing around values that ophyd-async will accept.
0 commit comments