Skip to content

Document all devices on i03 #1834

@DominicOram

Description

@DominicOram

If I run dodal describe i03 (using #1833) I get the following:

dodal describe

aperture_scatterguard:
Move the aperture and scatterguard assembly in a safe way. There are two ways to
    interact with the device depending on if you want simplicity or move flexibility.

    Examples:
        The simple interface is using::

            await aperture_scatterguard.selected_aperture.set(ApertureValue.LARGE)

        This will move the assembly so that the large aperture is in the beam, regardless
        of where the assembly currently is.

        We may also want to move the assembly out of the beam with::

            await aperture_scatterguard.selected_aperture.set(ApertureValue.OUT_OF_BEAM)

        Note, to make sure we do this as quickly as possible, the scatterguard will stay
        in the same position relative to the aperture.

        We may then want to keep the assembly out of the beam whilst asynchronously preparing
        the other axes for the aperture that's to follow::

            await aperture_scatterguard.prepare(ApertureValue.LARGE)

        Then, at a later time, move back into the beam::

            await  aperture_scatterguard.selected_aperture.set(ApertureValue.LARGE)

        Given the prepare has been done this move will now be faster as only the y is
        left to move.
    


attenuator:
The attenuator will insert filters into the beam to reduce its transmission.
    In this attenuator, each filter can be in one of two states: IN or OUT

    This device should be set with:
        yield from bps.set(attenuator, desired_transmission)

    Where desired_transmission is fraction e.g. 0-1. When the actual_transmission is
    read from the device it is also fractional


backlight:
Simple device to trigger the pneumatic in/out.


baton:
None


beamsize:
None


beamstop:

    Beamstop for I03 and I04.

    Attributes:
        x: beamstop x position in mm
        y: beamstop y position in mm
        z: beamstop z position in mm
        selected_pos: Get or set the current position of the beamstop as an enum.
    


collimation_table:
Basic collimation table device for motion plus the motion disable signal
    when laser curtain triggered and hutch not locked.

    The table has 3 physical vertical motors, the jacks. 1 upstream and 2 downstream.
    The two downstream jacks are labelled as outboard (away from the ring) and
    inboard (towards the ring).
    Together these 3 jacks provide compound motion for vertical motion and pitch/roll.
    There are 2 physical horizontal motors 1 upstream, 1 downstream. These provide yaw.

    Table motion is disabled by an object being within the laser curtain area and can be
    overridden by use of the dead man's handle device or locking the hutch. The effect of
    these disabling systems is to cut power to the motors - signal for this is crate_power
    


cryojet:
None


cryostream:
None


cryostream_gantry:
None


dcm:

    A double crystal monochromator (DCM), used to select the energy of the beam.

    perp describes the gap between the 2 DCM crystals which has to change as you alter
    the angle to select the requested energy.

    offset ensures that the beam exits the DCM at the same point, regardless of energy.
    


detector_motion:
None


diamond_filter:

    A filter set that is used to reduce the heat load on the monochromator.

    It has 4 slots that can contain filters of different thickness. Changing the thickness
    signal will move the filter set to select this filter.
    


eiger:
None


fastcs_eiger:
Ophyd-async implementation of an Eiger Detector.


fluorescence_det_motion:
None


flux:
Simple device to get the flux reading


hutch_shutter:
Device to operate the hutch shutter.

    When a demand is sent, the device should first check the hutch status     and raise an error if it's not interlocked (searched and locked), meaning it's not     safe to operate the shutter.

    If the requested shutter position is "Open", the shutter control PV should first     go to "Reset" and then move to "Open". This is because before opening the hutch     shutter, the interlock status PV (`-PS-SHTR-01:ILKSTA`) will show as `failed` until     the hutch shutter is reset. This will set the interlock status to `OK`, allowing     for shutter operations. Until this step is done, the hutch shutter can't be opened.
    The reset is not needed for closing the shutter.
    


ipin:
Simple device to get the ipin reading


lower_gonio:

    A standard three-axis stage with an x, a y, and a z motor.
    


mirror_voltages:
None


oav:

    OAV device that reads its beam centre values from a file. The config parameter
    must be a OAVConfigBeamCentre object, as this contains a filepath to where the beam
    centre values are stored.

    x_direction(int): Should only be 1 or -1, with 1 indicating the oav x direction is the same with motor x
    y_direction(int): Same with x_direction but for motor y
    z_direction(int): Same with x_direction but for motor z
    mjpg_x_size_pv(str): PV infix for x_size in mjpg
    mjpg_y_size_pv(str): PV infix for y_size in mjpg
    


panda:
PandA with common blocks for standard HDF writing.


panda_fast_grid_scan:
Device for panda constant-motion scan.

    In this scan, the goniometer's velocity
    is constant through each row. It doesn't slow down when going through trigger points.
    


pin_tip_detection:

    A device which will read from an on-axis view and calculate the location of the
    pin-tip (in pixels) of that frame.

    Used for pin tip centring workflow.

    Note that if the tip of the sample is off-screen, this class will return the tip as
    the "edge" of the image.

    If no tip is found it will return {INVALID_POSITION}. However, it will also
    occasionally give incorrect data. Therefore, it is recommended that you trigger
    this device, which will attempt to find a pin within {validity_timeout} seconds if
    no tip is found after this time it will not error but instead return {INVALID_POSITION}.
    


qbpm:

    A beam position monitor that gives a position and intensity of the beam.
    


robot:
The sample changing robot.


s4_slit_gaps:
Note that the S4 slits have a different PV fromat to other beamline slits


sample_shutter:
The shutter on most MX beamlines is controlled by the zebra.

    Internally in the zebra there are two AND gates, one for manual control and one for
    automatic control. A soft input (aliased to control_mode) will switch between
    which of these AND gates to use. For the manual gate the shutter is then controlled
    by a different soft input (aliased to manual_position_setpoint). Both these AND
    gates then feed into an OR gate, which then feeds to the shutter.


scintillator:
Moves a scintillator into and out of the beam.

    The scintillator will light up when hit with xrays, this allows scientists to use it
    in conjunction with the optical OAV camera to commission the beamline.

    When moved out of the beam it is parked under the table. This parking has a potential
    to collide with the aperture/scatterguard if that is not correctly parked already.
    


smargon:

    Real motors added to allow stops following pin load (e.g. real_x1.stop() )
    X1 and X2 real motors provide compound chi motion as well as the compound X travel,
    increasing the gap between x1 and x2 changes chi, moving together changes virtual x.
    Robot loading can nudge these and lead to errors.
    


synchrotron:
None


thawer:
None


undulator:

    An Undulator-type insertion device, used to control photon emission at a given beam energy.
    This class expects energy [keV] passed in set method and does conversion to gap
    internally, for which it requires path to lookup table file in constructor.
    


undulator_dcm:

    Composite device to handle changing beamline energies, wraps the Undulator and the
    DCM. The DCM has a motor which controls the beam energy, when it moves, the
    Undulator gap may also have to change to enable emission at the new energy.
    The relationship between the two motor motor positions is provided via a lookup
    table.

    Calling unulator_dcm.set(energy) will move the DCM motor, perform a table lookup
    and move the Undulator gap motor if needed. So the set method can be thought of as
    a comprehensive way to set beam energy.

    This class will be removed in the future. Use the separate Undulator and DCM devices
    instead. See https://github.com/DiamondLightSource/dodal/issues/1092
    


vfm:
A focusing mirror where the stripe material can be changed. This is usually done
    based on the energy of the beamline.


webcam:
None


xbpm_feedback:
The XBPM feedback device is an IOC that moves the DCM, HFM and VFM to automatically
    hold the beam into place, as measured by the XBPM sensor.


xspress3mini:
Xpress/XpressMini is a region of interest (ROI) picker that sums the detector
    output into a scaler with user-defined regions. It is often used as a signal
    discriminator to provide better energy resolution and signal to noise in X-ray detection experiments.
    This currently only provide staging functionality.

    Parameters
    ----------
    prefix:
        Beamline part of PV
    name:
        Name of the device
    num_channels:
        Number of channel xspress3 has, default is 1 for mini.
    timeout:
        How long to wait for before timing out for staging/arming of detector default is 1 sec
    


zebra:
The Zebra device.


zebra_fast_grid_scan:
Device for standard Zebra 3D FGS.

    In this scan, the goniometer's velocity profile follows a parabolic shape between X steps,
    with the slowest points occuring at each X step.
    


zocalo:
An ophyd device which can wait for results from a Zocalo job. These jobs should
    be triggered from a plan-subscribed callback using the run_start() and run_end()
    methods on dodal.devices.zocalo.ZocaloTrigger.

    See https://diamondlightsource.github.io/dodal/main/how-to/zocalo.html

    Args:
        name (str): Name of the device

        zocalo_environment (str): How zocalo is configured. Defaults to i03's development configuration

        channel (str): Name for the results Queue

        sort_key (str): How results are ranked. Defaults to sorting by highest counts

        timeout_s (float): Maximum time to wait for the Queue to be filled by an object, starting
        from when the ZocaloResults device is triggered

        prefix (str): EPICS PV prefix for the device

        results_source (ZocaloSource): Where to get results from, GPU or CPU analysis

Many of these have no description or a poor description, they also seem to vary about whether they have a trailing tab (which they should I feel as it looks neater)

Part of #1360

Acceptance Criteria

  • All devices printed in dodal describe i03 give sensible docs

Sub-issues

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions