Get pin tip from ophyd device

[DominicOram]

Issues with i19's OAV(s) have meant that it has had to be converted to K8s. This has broken the pin tip detection code in the IOC. We should be able to instead use the pin tip detection in the ophyd-async device.

To do this we will need to:

• Add two PinTipDetection (https://github.com/DiamondLightSource/dodal/blob/dc0d8edea5ff4150d18a6be8f9a092468e43eec5/src/dodal/devices/oav/pin_image_recognition/__init__.py#L32) and OAVBeamCentrePV (https://github.com/DiamondLightSource/dodal/blob/dc0d8edea5ff4150d18a6be8f9a092468e43eec5/src/dodal/devices/oav/oav_detector.py#L300) devices (one for each OAV) to i19_1.py and confirm they connect
• Create a plan that:
  1. Sets the oav params to the pin tip detection device (e.g. the i19_1 equivalent of /dls_sw/i03/software/daq_configuration/json/OAVCentring_hyperion.json) - e.g. using https://github.com/DiamondLightSource/mx-bluesky/blob/510fb97274592a7c5904cf7e28d56aa86c03cff0/src/mx_bluesky/common/device_setup_plans/setup_oav.py#L14, which we should also move into dodal as a device setup plan. Note that BlueAPI might not have access to the location of the .json file in the file system so we may need to copy them into the scratch area for now
  2. Trigger the pin tip detection device
  3. Write the location to oav.beam_centre_i and oav.beam_centre_j (note this is a hack because it's hard to send info back to GDA, long term we should look at changing this)
  4. In GDA change the pin tip detection code to trigger this plan then read results from BL19I-EA-OAV-01:OVER:1:CenterX and BL19I-EA-OAV-01:OVER:1:CenterY (or equivalent for other IOC). These are the PVs that beam_centre_i/beam_centre_j map too

Acceptance Criteria

• We can trigger a pin tip centre in GDA again

[DominicOram]

@tpoliaw and I had a discussion about whether there was a better way to get the values out of bluesky rather than writing to those PVs. It is currently possible to hook into the event stream from GDA so we could do it via that. Eventually, it would be good for simple values like this for BlueAPI to return the plan_result (DiamondLightSource/blueapi#1349). However, given the urgency on this I think using the PVs for now is the quickest path to getting something that works

[DominicOram]

As discussed, we actually cannot reuse OAVBeamCentrePV as we need the PVs to be writable. We will need a new simple device:

class PinTipCentreHolder(StandardReadable):
    """Some description about the workaround we're using"""
    def __init__(
        self,
        prefix: str,
        name: str = "",
        overlay_channel: int = 1,
    ):
        with self.add_children_as_readables():
            self.pin_tip_x = epics_signal_rw(
                int, prefix + f"OVER:{overlay_channel}:CenterX"
            )
            self.pin_tip_y = epics_signal_rw(
                int, prefix + f"OVER:{overlay_channel}:CenterY"
            )
        super().__init__(
            prefix=prefix,
            name=name,
        )

[noemifrisina]

Testing on i19 today:

• Pin tip direction is read from file as 2, we're assuming this means REVERSE but should be FORWARD
• the direction definitions - when GDA scanned - belonged in the EPICS ioc and came in two flavours
  -- ( see mx-config init.py file under scripts/mxsc in GDA )
• in the blue sky algorithm x back step direction and the enum for scan direction seem to have been conflated
  -- so a tweak is being tried where these are distinct
• target for Strawberry needed to be updated with crosshair values from display.configuration that had been changed in the meantime -> Need to set up config server