Analyse how long changing Odin PVs takes

DiamondLightSource / mx-bluesky

Bluesky plans, plan stubs, and utilities for MX beamlines

https://diamondlightsource.github.io/mx-bluesky/

Apache License 2.0

0 stars 2 forks source link

Analyse how long changing Odin PVs takes #403

Open DominicOram opened 1 year ago

DominicOram commented 1 year ago

One current performance bottleneck in Artemis is arming the detector. This requires setting a number of properties through odin then waiting for the stale parameters to be complete. We should analyse where this time is spend and potentially guard against it in Artemis. e.g. for the threshold energy we do not set it if it's already within tolerance.

Acceptance Criteria

It is measured and documented how long changing parameters in odin/eiger takes e.g. if we set more PVs does this take longer? How much longer? Do different PVs add different timings?
We guard in Artemis against setting PVs if we think they will take longer (with appropriate comments in the code, including in the threshold energy)

DominicOram commented 1 year ago

@GDYendell would be good to look at together maybe?

GDYendell commented 1 year ago

I think PVs should take approximately the same time to set because they just send the request and fetching the updated parameters is done in a separate thread. However the time it takes for the detector to make the change will be variable.

npat113 commented 1 year ago

I'm fairly sure that GDA encountered many failed PV settings when we initially tried to operate like that. Was a long time ago though. A lot of what is in GDA is working around the 'how it should work'/'how it does work' quagmire.

DominicOram commented 1 year ago

Sorry, when I say "How long does the PV take to set" I really mean how long between setting a PV and everything being in a state where we can continue i.e. for the detector to be arm-able. We can probably reduce this time by:

Changing the ordering of things
Not setting some PVs if they don't need to be

Even if we can't reduce it, we should document it. So we don't end up in the GDA situation of it not being obvious why we're doing things in a specific order.