Acquire parameter callback occurs before camera acquisition has started

[BenBradnick]

Currently when you set Acquire in EPICS the callback happens before the camera has finished setting up and starting the acquisition.
At Diamond we have software which monitors the acquire PV which then believes the detector is ready for an acquisition early (and then misses external triggers).

[MarkRivers]

Currently when you set Acquire in EPICS the callback happens before the camera has finished setting up and starting the acquisition.

Please explain what you mean by "the callback". If you mean ca_put_callback on ADAcquire is returning, that should not happen. That callback should only happen when acquisition is complete.

Do you mean that you are polling the value of Acquire_RBV and it is going to 1 before the camera has started the acquisition? If so then I suggest you just change the logic to poll DetectorState_RBV rather than Acquire_RBV. I don't think that would require any changes to the driver, because DetectorState_RBV should already be changing state only after the detector is actually started.

[BenBradnick]

Sorry I wasn't clear enough.

I do mean that our scanning application monitors the value of the Acquire_RBV PV and will wait for its value to say 1 before it assumes the detector is ready for an externally-triggered acquistion.

So is it wrong to say that the Acquire_RBV value should be 1 after the detector is ready? This application (Malcolm) at Diamond currently uses this PV for a number of other detectors.

[MarkRivers]

I think what you propose is OK. I think many detectors start the camera acquisition immediately when writeInt32 receives the ADAcquire command, rather than deferring it to the poller thread. Starting the camera from the poller thread is what introduces the complexity in the ADAndor driver. It might make sense to rewrite that to start the camera immediately from writeInt32.

[BenBradnick]

Great! I will look at starting the acquisition from writeInt32 when ADAcquire is set.

[BenBradnick]

Hi @MarkRivers, could you take another look at #34 and check if it looks okay?

[MarkRivers]

Has this been thoroughly tested? If so I will merge it.

[BenBradnick]

I have been testing the branch using an Andor iXon Ultra.

I can acquire images in each of the available image modes (tested multiple times), and changing other Int32 parameters (such as binning, ADC speed) works as expected.

[BenBradnick]

I am happy with my testing of these changes - so I think this is ready to be merged.

[MarkRivers]

Closed via #34