Eiger: Create a gantt chart of the arming process

[DominicOram]

To be able to optimise the arming of the Eiger, and to write the FastCS Eiger we need to understand the order of operations better. To do this we should make a diagram (something like a gantt chart) of what operations depend on others and how long they each take.

Acceptance Criteria

• There is a diagram of what operations rely on what others in the eiger and how long they take

[DominicOram]

Based on the code the current behaviour is:

gantt
    title Eiger arming with timing in seconds
    dateFormat ss
    axisFormat %S
    odin.stop                                                       : a1,  0, 0.00890186s
    change_dev_shm                                         : a2, after a1, 0.0067055175s
    set_detector_threshold                                 : a3, after a2, 0.0016777475s
    set_cam_pvs                                                : a4, after a3, 0.96287229125s
    set_odin_number_of_frame_chunks            : a5, after a4, 0.01019072125s
    set_odin_pvs                                                : a6, after a5, 0.05567243125s
    set_mx_settings_pvs                                   : a7, after a6, 1.9021649325s
    set_num_triggers_and_captures                 : a8, after a7, 1.320268595s
    wait_for_not_stale                                       : a9, after a8, 0.0006886675s
    _wait_for_odin_status                                 : a10, after a9, 0.96810295625s
    set_acquire                                                 : a11, after a10, 0.9095709875s
   _wait_fan_ready                                          : a12, after a11, 1.5318339725s
    expected_total                                           : a13,  0, 7.67865068000s
    measured_total                                           : a13,  0, 8.7477270925s

Loading

[shihab-dls]

I've just updated the Gantt chart; these are averaged over 4 scans (with rotation too, so 8 arming chains in total).

expected_time is just summation of the individual arming tasks, whereas measured_time is the logged time required to complete arming from start to finish. It seems that some time is lost, I'll look into whether something was not explicitly not logged.

[DominicOram]

set_mx_settings_pvs is odd here, it should just be setting a few PVs. Would be worth digging into it and working out which of those sets is slow

[DominicOram]

It looks like I missed enable_roi_mode in the list, that might be where the missing time is.

From my understanding of the detector I think the following might be possible:

gantt
    title Eiger arming with timing in seconds
    dateFormat ss
    axisFormat %S
    odin.stop                                                       : a1,  0, 0.00890186s
    change_dev_shm                                         : a2, 0, 0.0067055175s
    set_detector_threshold                                 : a3, 0, 0.0016777475s
    set_cam_pvs                                                : a4, 0, 0.96287229125s
    set_odin_number_of_frame_chunks            : a5, after a1, 0.01019072125s
    set_odin_pvs                                                : a6, after a5, 0.05567243125s
    set_mx_settings_pvs                                   : a7, 0, 1.9021649325s
    set_num_triggers_and_captures                 : a8, 0, 1.320268595s
    wait_for_not_stale                                       : a9, after a2 a3 a4 a7 a8, 0.0006886675s
    _wait_for_odin_status                                 : a10, after a6 a9, 0.96810295625s
    set_acquire                                                 : a11, after a10, 0.9095709875s
   _wait_fan_ready                                          : a12, after a11, 1.5318339725s

Loading

Which in theory cuts out 3 seconds. In practice it will likely be slower as setting so many things at once may make wait_for_not_stale slower.

[shihab-dls]

Ah my bad, I hadn't noticed enable_roi_mode due to its conditional execution, so I agree this is likely where the final 1.069s are. Will add logging there, and more granular logging on set_mx_settings_pvs

[DominicOram]

and more granular logging on set_mx_settings_pvs

You need to be careful with adding logging here:

status = self.cam.beam_center_x.set(
            beam_x_pixels, timeout=self.timeouts.general_status_timeout
        )
        status &= self.cam.beam_center_y.set(
            beam_y_pixels, timeout=self.timeouts.general_status_timeout
        )

Sets x and y simultaneously, similarly with the other PVs. So to find out if it's one of them being slow you need to change it to set them sequentially. You will then see one of:

• One of them takes the whole ~2s - this will tell us that maybe if we can avoid just that one it's helpful
• On they're own each is <<2s. You would think this means that if you set them all simultaneously it would be fast but the IOC may have logic internally that means they're always set sequentially internally.

[DominicOram]

For interest @GDYendell

[DominicOram]

The disarm is now on the critical path so would be good to profile that too.

[DominicOram]

For disarm in the case where we're not free running and already disabled ROI (i.e. a rotation scan):

Waiting on filewriter to finish - 1.76s
Disarming det - 0.073
Waiting on odin ok - 0.007
Disable ROI - 0.004

For disarm when we're free running and not ROI disabled (i.e. XRC):

Waiting on final frames - 0.444
Stopping odin - 1.12
Waiting on filewriter to finish - 0.001
Disarming det - 0.038
Waiting on odin ok - 0.005
Disable ROI - 2.887

[DominicOram]

See https://jira.diamond.ac.uk/browse/I03-637 for some analysis that has been done before