658 create device for pressure jump cell

[barnettwilliam]

closes #658
Ophyd device for pressure jump cell #658, required for pressure jump experiment.

Initial control PVs, TODO fast adc capture.

Checks for reviewer

• Would the PR title make sense to a scientist on a set of release notes
• If a new device has been added does it follow the standards
• If changing the API for a pre-existing device, ensure that any beamlines using this device have updated their Bluesky plans accordingly
• Have the connection tests for the relevant beamline(s) been run via dodal connect ${BEAMLINE}

[stan-dot]

At the moment it's implemented as one large object hard to debug, should be split into components

[codecov]

Codecov Report

Attention: Patch coverage is 95.08197% with 6 lines in your changes missing coverage. Please review.

Project coverage is 94.47%. Comparing base (851a002) to head (26e46cd).

Files	Patch %	Lines
src/dodal/devices/pressure_jump_cell.py	94.95%	6 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #673      +/-   ##
==========================================
+ Coverage   94.46%   94.47%   +0.01%     
==========================================
  Files         115      116       +1     
  Lines        4604     4726     +122     
==========================================
+ Hits         4349     4465     +116     
- Misses        255      261       +6     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[DiamondJoseph]

Are the limits settable and required to be Read signals or are they read-once Config signals?

[stan-dot]

how to check that?

[DiamondJoseph]

They're epics_signal_r read only from the ophyd layer, which means they're read-only from the ophyd layer. They could be derived from other signals, and therefore changing on the rate of every point of a scan, but I would infer from the name that they are hardware limits that don't change over the lifetime of the device, let alone within a scan. I would make them config signals.

[barnettwilliam]

These signals are the state of limit switches for the pump so they will change during a scan if the pump is driven for a some length of time (approx 50s) in one direction. The name could be improved to pump_..._limit_state

[stan-dot]

some small bits

[DiamondJoseph]

They're epics_signal_r read only from the ophyd layer, which means they're read-only from the ophyd layer. They could be derived from other signals, and therefore changing on the rate of every point of a scan, but I would infer from the name that they are hardware limits that don't change over the lifetime of the device, let alone within a scan. I would make them config signals.