Problem with rapidly stopping, setting AcquireTime, and starting detector

[MarkRivers]

Ji Li at NSLS-II has found a problem

We experienced a problem when changing exposure time for our Perkin Elmer detector in software. 
The procedure of the software is:

1.	Set Acquire=0
2.	Set AcquireTime=new_value
3.	Set Acquire=1

The program hung up at step 3 and acquisition was not enabled. 
It turned out that setting AcquireTime doesn’t finish immediately. 
After letting the program sleep for 3 seconds (the value we’re currently using, 
haven’t tried other values yet) after step 2, 
it can continue and enable the detector for acquisition. 
Is it possible for the program to be notified, 
or we can read some status to decide whether such parameter writing is completed? 

I studied the driver and found that the problem cannot be that setting AcquireTime takes a long time to complete, as Ji Li guessed above. When changing the AcquireTime in step 2 it calls the writeFloat64 method in the driver. When AcquireTime is changed writeFloat does not actually do anything except store the value in the parameter library and set a flag called acquireSettingsChanged. It does not actually change the acquire time in the camera until acquisition is started, at which point the acquireSetup() function is called which actually makes the calls to the SDK to set the AcquireTime and other parameters.

I was able to reproduce the problem with this little IDL test program to test with our PE 1621.

pro test_perkin_elmer_1621, acquire_time
  prefix = '13PEL1:cam1:'
  t = caput(prefix + 'Acquire', 0)
  wait, .1
  t = caput(prefix + 'AcquireTime', acquire_time)
  t = caput(prefix + 'Acquire', 1)
end

This does what Ji Li was doing:

• Set ADcquire=0
• Set AcquireTime to the value passed to this function
• Set Acquire=1

I found that if I ran this program without the wait, .1 line (which sleeps for 0.1 second) then it behaved as Ji Li said hanging the driver. By adding the wait, .1 it seems to work reliably. Note that I am waiting after step 1, not step 2.

I also tested putting the 0.1 second wait after setting the AcquireTime (step 2) rather than after setting Acquire=0 (step 1). That also works for me.

This appears to be a bug in the driver.