Create plans to arm the fast-cs eiger

[olliesilvester]

The next step in completing ophyd-async's fast-cs Eiger is to benchmark the time taken to arm the Eiger in a two step process:

1. The "load" plan. For this issue, this plan can just set the relevant PV's using bps.abs_set, rather than using ophyd async load. This plan should set the mx settings (see currently dodal eiger arming), set the ROI mode, and set the energy threshold

• Wait for the above plan to be finished

2. The prepare plan. This should call the fast-cs eigers' prepare method, which we will also need to modify slightly for this issue: we need to add the datatype setting (see FastCS Eiger: Pass datatype from eiger to odin bluesky/ophyd-async#529); we also need to add wait_for_stale_params.

Acceptance Criteria

1. Ophyd-Async fast-cs eiger prepare modified to include datatype and wait_for_stale_params
2. Plan written to: load, wait for load, do the new prepare
3. Plan tested on a real Eiger and benchmark how long each bit takes

[shihab-dls]

Update on the testing me and @olliesilvester did:

gantt
    title Eiger arming with timing in seconds
    dateFormat ss
    axisFormat %S
    odin.stop                                                       : a1,  0, 0.015491247177124023s
    set_cam_pvs                                                : a2, after a1, 0.017783403396606445s
    set_odin_number_of_frame_chunks            : a3, after a2, 0.5823836326599121s
    set_odin_pvs                                                : a4, after a3, 0.08258485794067383s
    change_roi_mode                                         : a5, after a4, 0.5823836326599121s
    set_mx_settings_pvs                                   : a6, after a5, 0.5847890377044678s
    prepare                                                        : a7, after a6, 0.5850582122802734s

Loading

Above are the timings we got for the arming chain set up in #1054

set_cam_pvs is likely taken care of in prepare, so may be redundant here.
PVs were set, but prepare could not complete successfully. As fastcs-odin is not availible yet, we used ADOdin where we could in the arming sequence; however, fastcs-odin is required in some parts of StandardDetector prepare(), which we could not get working yet with ADOdin. This meant that we could not subsequently arm and trigger during testing.

We were also unable to test setting image_mode, as I have not yet found a fast-cs equivalent.

[olliesilvester]

FYI @DominicOram

[DominicOram]

Fixed by #1187