Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

VMXm: fast grid scans #323

Open
Tom-Willemsen opened this issue Oct 12, 2023 · 5 comments
Open

VMXm: fast grid scans #323

Tom-Willemsen opened this issue Oct 12, 2023 · 5 comments
Assignees
Labels

Comments

@Tom-Willemsen
Copy link
Contributor

Umbrella issue for fast grid scans on VMXm - subtickets to be created as work becomes clearer.

Simple fast grid scans, 2D scan at a single rotation angle, heatmaps not needed in GDA but would be liked in ispyb.

Queries/outstanding work:

  • Fast shutter control currently being done in geobrick motion program, may make more sense for GDA/bluesky to do this.
    • Two shutters - fast & slow - need coordinating correctly.
  • Still need to figure out exactly how VMXm's zebra is set up and demo a fast grid scan running & triggering the detector but setting everything up manually rather than through GDA/bluesky.
    • Scientist to add meeting next week about this.
  • Metadata:
    • aperture_scatterguard, flux, s4_slits, undulator, xbpm - not required or don't make sense for VMXm.
    • backlight just needs moving out, nothing else.
    • attenuator would be good to include on VMXm.

VMXm scientists have said they would like some basic functionality by 20th Nov as they have scheduled an experiment that would benefit from this...

@DominicOram
Copy link
Contributor

DominicOram commented Oct 12, 2023

Thoughts on how we do this:

@Tom-Willemsen
Copy link
Contributor Author

#!/bin/sh

# Fast Grid Scan Interface
caput BL02J-MO-SAMP-11:FGS:P1404:X_NUM_STEPS            10
caput BL02J-MO-SAMP-11:FGS:P1407:Y_NUM_STEPS            8
caput BL02J-MO-SAMP-11:FGS:P1406:X_STEP_SIZE            0.005
caput BL02J-MO-SAMP-11:FGS:P1409:Y_STEP_SIZE            0.005
caput BL02J-MO-SAMP-11:FGS:P1401:EXPOSURE_TIME          180   # Exposure or Acquisition Time in ms
caput BL02J-MO-SAMP-11:FGS:P1420:FAST_SHUTTER_OPEN_TIME 71    # Fast Shutter opening time in ms
caput BL02J-MO-SAMP-11:FGS:P1405:X_START                -0.2
caput BL02J-MO-SAMP-11:FGS:P1408:Y_START                 0.5
caput BL02J-MO-SAMP-11:FGS:P1410:Z_START                -0.2
caput BL02J-MO-SAMP-01:OMEGA.VAL                         100.0

sleep 2

# Eiger
caput BL02J-EA-EIGER-01:CAM:AcquireTime   0.18
caput BL02J-EA-EIGER-01:CAM:AcquirePeriod 0.18
caput BL02J-EA-EIGER-01:CAM:NumTriggers   80    # Number of grid points
caput BL02J-EA-EIGER-01:CAM:ManualTrigger Yes
caput BL02J-EA-EIGER-01:CAM:NumExposures  1
caput BL02J-EA-EIGER-01:CAM:NumImages     1
caput BL02J-EA-EIGER-01:CAM:ImageMode     Continuous
caput BL02J-EA-EIGER-01:CAM:TriggerMode   "External Enable"

sleep 2

# ODIN
caput BL02J-EA-EIGER-01:OD:NumCapture     80   # Number of grid points
caput -S BL02J-EA-EIGER-01:OD:FilePath    /dls/mx/data/cm33865/cm33865-4/ajf67
caput -S BL02J-EA-EIGER-01:OD:FileName    test5

# Zebra
caput BL02J-EA-ZEBRA-01:OUT4_TTL          1    # Set the detector trigger output = trigger input from motion program

sleep 2

# Start ODIN and Eiger
caput BL02J-EA-EIGER-01:OD:Capture        1
caput BL02J-EA-EIGER-01:CAM:Acquire       1

sleep 2

# Start the scan
caput BL02J-MO-SAMP-11:FGS:RUN.PROC 1

@Tom-Willemsen
Copy link
Contributor Author

Note: fast shutter will be controlled by motion controller directly (hence the FAST_SHUTTER_OPEN_TIME and related parameters above). Slow shutter control should be done by hyperion.

@Tom-Willemsen Tom-Willemsen self-assigned this Oct 17, 2023
@Tom-Willemsen
Copy link
Contributor Author

With DiamondLightSource/dodal#211 and DiamondLightSource/hyperion#942 I think we are close to the point where we should test this on the beamline manually as above (not integrating with GDA yet - but just prove we can set off a sensible-looking FGS from bluesky).

The new plan is messy and duplicates a lot from the i03 version, once we're happy with how it works on VMXm we should consider:

  • What is generic/instrument specific
    • Do the refactoring to reduce duplication
  • Where this plan should live - if hyperion is meant for UDC long-term, then maybe the VMXm one should be in mx_bluesky
    • If so, where do we store any common components etc

@olliesilvester
Copy link
Contributor

There are a number of issues which need compleition before this can be merged, see:
DiamondLightSource/hyperion#942 and
DiamondLightSource/dodal#211

@DominicOram DominicOram transferred this issue from DiamondLightSource/hyperion Sep 2, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
Status: Blocked
Development

No branches or pull requests

3 participants