Add jungfrau internal acquisition plan

[olliesilvester]

Part of #1200

Requires DiamondLightSource/dodal#1548

Instructions to reviewer on how to test:

1. Do thing x
2. Confirm thing y happens

Checks for reviewer

• Would the PR title make sense to a user on a set of release notes

[olliesilvester]

CI is failing because pilatus was disconnected from zebra in this PR, but there are still plans which require pilatus. Will revert the zebra changes in this PR and do that refactor elsewhere

[codecov]

Codecov Report

❌ Patch coverage is 96.00000% with 2 lines in your changes missing coverage. Please review.
✅ Project coverage is 90.16%. Comparing base (aee067c) to head (35da083).
⚠️ Report is 1 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #1216   +/-   ##
=======================================
  Coverage   90.15%   90.16%           
=======================================
  Files         130      132    +2     
  Lines        7844     7872   +28     
=======================================
+ Hits         7072     7098   +26     
- Misses        772      774    +2     

Components	Coverage Δ
i24 SSX	75.27% <ø> (ø)
hyperion	97.79% <ø> (ø)
other	97.94% <96.00%> (-0.06%)	⬇️

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[DominicOram]

Thanks, a few comments in the code.

[DominicOram]

Should: As I said in https://github.com/DiamondLightSource/dodal/pull/1548/files#r2369303859, I think that a call to a PathProvider will just give a new path. Also, I think that jungfrau._writer.file_name will get overriden by what is in the path provider when open is called anyway. So I think the only line in this function that actually does anything is the first one. Can we have some unit tests on this to confirm what we're actually doing and remove lines that aren't necessary?

[olliesilvester]

Thank you, yeah, I must have been rushing this part

[DominicOram]

Should: The name and docs of path_of_output_file implies that it's a full path but override_file_name actually juts wants a file name. Either update override_file_name to take a full path or change do_internal_acquisition to only take a new path filename

[DominicOram]

I think, from doing the tests on the beamline they wanted everything in folders e.g. /dls/i24/data/2025/cm40647-4/jungfrau/2025-09-15/zeo62 contains one set of data and /dls/i24/data/2025/cm40647-4/jungfrau/2025-09-15/zeo63 contains another. So we should let the folder change. Ideally we should also do this increment for them

[olliesilvester]

OK, if I change override_file_name to allow you to change filename and folder, and by default use the AutoIncrementingPathProvider, then this will increment automatically if a new path hasn't been specified. Does that sound good?

[olliesilvester]

Also the commissioning JF device now checks against the specified file already existing

[DominicOram]

OK, if I change override_file_name to allow you to change filename and folder, and by default use the AutoIncrementingPathProvider, then this will increment automatically if a new path hasn't been specified. Does that sound good?

Yes, that's fine. As long as we confirm that's what the AutoIncrementingPathProvider does. I know when we tested other path providers on the beamline we ended up with weird nested date directories

[DominicOram]

So the AutoIncrementingPathProvider gives us a slightly different format of /dls/i24/data/2025/cm40647-4/jungfrau/2025-09-15/zeo/00000/data_file then /dls/i24/data/2025/cm40647-4/jungfrau/2025-09-15/zeo/00001/data_file. I think this is fine but we should make the beamline aware

[DominicOram]

Also, the test looks real, can you take a look?

[olliesilvester]

Tests are passing locally, but will wait for CI to get fixed before re-review

[DominicOram]

Great, thank you. I think just #1216 (comment) then I think the test failure still looks somewhat real (it's on a JF one anyway)

Changes addressed