No longer explicitly support n=0 frames to go forever. Plan should pass this to the detectors. about ophyd-async HOT 7 CLOSED

The existing code assumed all detectors could arm forever, this is the part we need to change

from ophyd-async.

Just checking that this will still leave open the possibility to allow the detector to run forever? It is a requirement for MX.

from ophyd-async.

For the MX use case, do you know in advance how many triggers could be sent to the detector?

I think the reason we decided to do this, was because we found there's no universal way to do this with detectors. We initially thought n=0 would probably mean detectors take images forever, but on a Pilatus that's not the case and you just have to set a really high number, that doesn't even necessarily correspond with the highest number EPICs says the 'num_images' PV can take (which is really rather odd in the case of the Pilatus)

However if there's a use case for this we need to reconsider, if there is really no way we could compute ahead of time the number of images you'd need to take. Personally at that stage, I'd want to speak to people maintaining/writing the epics drivers for detectors, so we can enforce n=0 means take images forever (rather than have to guess for every detector you're using..)

from ophyd-async.

For the MX use case, do you know in advance how many triggers could be sent to the detector?

No, the use case is not knowing in advance. We need to arm the detector before having analysed the optical images to determine the grid size (i.e. number of images)

from ophyd-async.

And does Eiger have the concept of "forever", or do you send it a (detector specific) big number?

from ophyd-async.

Eiger takes 0 triggers to "run until stopped".

As long as we can still pass 0 images through to the detector somehow this shouldn't be a problem for us though, we can check/assert the detector type ourselves. It's fine if that's just required to be explicit.

It seems like even in a case where you always specify some positive number, you could end up in the situation where a Pilatus is given a fixed number of images and then runs forever? Unless you artificially limit this number to less than the Pilatus' magic number, which also seems bad.

I think if there's no universal way to do this for detectors that is telling us that plans which require this functionality can't be detector-agnostic. There might well also exist detectors which don't support running forever at all.

from ophyd-async.

Yes, I think we can raise this to the plan level to decide how many frames the detectors should arm for. Then if you pass n=0 down to a Pilatus it would fail, but if you pass to an Eiger it would pass. It would be the plan's responsibility to select a suitable n.

from ophyd-async.