Skip to content

Conversation

@jacob720
Copy link
Contributor

@jacob720 jacob720 commented Dec 9, 2025

Fixes DiamondLightSource/mx-bluesky#1504

Required by DiamondLightSource/mx-bluesky#1511

Instructions to reviewer on how to test:

  1. Test beamline parameters files are not read from the file system in dodal

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
Copy link

codecov bot commented Jan 12, 2026

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 99.07%. Comparing base (af74ac0) to head (9517b6a).

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #1773      +/-   ##
==========================================
- Coverage   99.07%   99.07%   -0.01%     
==========================================
  Files         294      295       +1     
  Lines       11207    11183      -24     
==========================================
- Hits        11103    11079      -24     
  Misses        104      104              

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

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@jacob720 jacob720 marked this pull request as ready for review January 12, 2026 16:45
Copy link
Contributor

@DominicOram DominicOram left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, this looks good, some comments in code. This also means that we are now reliant on the config server so I think we need to do DiamondLightSource/mx-bluesky#478 before we put this on the beamline. Would you be able to pick that up and put in a meeting with Neil, Mark, Rob and Myself?

from dodal.log import LOGGER
from dodal.utils import get_beamline_name

BEAMLINE_PARAMETER_KEYWORDS = ["FB", "FULL", "deadtime"]
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should: This list is no longer used, can we remove it?

)


def get_beamline_parameters(beamline_param_path: str | None = None):
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could: This is a bit of scope creep but the way we're doing this is a bit messy. I think we can do it like we do

def daq_configuration_path() -> str:
and load it in as part of the beamline file. If that makes sense? Can you either do here or make a new issue?

Copy link
Contributor Author

@jacob720 jacob720 Jan 20, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This makes sense. So when devices need beamline parameters and before would have called get_beamline_parameters(), I'm guessing now they'd be passed in when the device is constructed.

How would this work when we need to get beamline parameters inside common plans? Or should these params always be attached to devices by that point?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So when devices need beamline parameters and before would have called get_beamline_parameters(), I'm guessing now they'd be passed in when the device is constructed.

Yes

How would this work when we need to get beamline parameters inside common plans? Or should these params always be attached to devices by that point?

Yh, that is a bit harder. I think we would need to have a look at it, which maybe means it should be in another issue

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe a similar thing can be done for the config server itself? So have a get_config_server() in every ixx.py that returns a config client set up for that beamline

return cls(params=dict(config_pairs))

@classmethod
def from_file(cls, path: str):
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: It's a little misleading that this is still called from_file when it's not reading directly from the file

@classmethod
def parse_value(cls, value: str):
return ast.literal_eval(value.replace("Yes", "True").replace("No", "False"))
config_server = ConfigServer(url="https://daq-config.diamond.ac.uk")
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should: Can you pull the URL into a constant? From DiamondLightSource/mx-bluesky#478 (comment) it may be that we will need it to be beamline specific too

Comment on lines 175 to 179
print(contents)
if desired_return_type is str:
return contents
elif desired_return_type is dict:
print("return type is dict")
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should: Remove print statements

elif desired_return_type is dict:
print("return type is dict")
return json.loads(contents)
elif issubclass(desired_return_type, ConfigModel): # type: ignore
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should: As far as I can see we're never trying to return a ConfigModel so why do we need this bit? Or is it for later PRs?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah this is for later PRs. We either get a dict or a ConfigModel depending on what we request from the server, other config like LUTs or display config will be returned as a subclass of ConfigModel, this fixture emulates that

@jacob720 jacob720 force-pushed the mx_bluesky_1504_migrate_beamline_parameters_to_config_server branch from c87a30e to 3dbb881 Compare January 23, 2026 17:33
@jacob720 jacob720 requested a review from DominicOram January 26, 2026 09:59
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Migrate beamline paramaters to use the daq-config-server

3 participants