(DiamondLightSource/hyperion#1464) Change topup gating to prevent gating with long exposures

[rtuck99]

Fixes DiamondLightSource/hyperion#1464

After conversation with beamline staff, rather than implement the same solution as exists currently in GDA, the following behaviour is implemented:

• Topup gating in hyperion is now controlled by the following parameters in beamlineParameters:
  • dodal_topup_threshold_exposure_s (default 120) controls the exposure time at which hyperion gates topups
  • dodal_topup_end_delay_s (default 1) controls an additional adjustable delay after topup end to ensure no accidental overlap with topup due to timing inaccurancies and can be adjusted to allow further time for settling if necessary.

To determine whether a topup is performed:

• If the COUNTDOWN PV != -1 and Synchrotron mode is User or Special then the gating steps are followed as below, otherwise we proceed with the scan as normal.
• The exposure duration, plus an operation-specific setup time (currently default 10s for rotation scans and 30s for grid scans) is compared with the time remaining to topup (ENDCOUNTDN PV), if it is more than this then the scan may be delayed, otherwise the scan is not delayed.
• The exposure duration is compared with dodal_topup_threshold_exposure_s and if it is less than this the scan is delayed, otherwise it is considered a long duration scan which can be performed during topup and is not delayed.
• If after the above checks have determined a delay is required, we then wait for ENDCOUNTDN - COUNTDOWN + dodal_topup_end_delay_s seconds rounded up to the nearest second.

Note:

It is expected that the location of these parameters is temporary until at some later stage they are moved into the config server.

Instructions to reviewer on how to test:

1. Attempt normal and long-duration scans during topup and check the above happens.
2. Tests pass

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}

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 94.52%. Comparing base (851a002) to head (3ccfbd7).
Report is 1 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #674      +/-   ##
==========================================
+ Coverage   94.46%   94.52%   +0.06%     
==========================================
  Files         115      115              
  Lines        4604     4621      +17     
==========================================
+ Hits         4349     4368      +19     
+ Misses        255      253       -2     

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

[DominicOram]

Great, thanks. Some optional comments to help with working out why this the behaviour in the future. Otherwise looks good.

[DominicOram]

Could: We could have a docstring on this function explaining why we need the threshold and why sometimes wait and sometimes don't (basically just summarising this issue).

[DominicOram]

Should: A little bit more detail on why we need the safety margin would be good.