Triggering the Perkin-Elmer takes ~10 seconds regardless of acquisition time

[danielballan]

An issue discovered with @sbillinge and @timoHMM today at XPD:

Even when pe1.acquire_time is small (0.2 seconds), the status object returned by pe1.trigger() takes ~10 seconds to flip to done. (The worst case we saw was 13, the best case about 10.)

I don't have a comprehensive understanding of all the different attributes and precisely what they means (num_images, num_exposure, acquire_time, acquire_period, ...) but all were on a low setting.

If we can't resolve this by Wednesday, Simon's group will effectively be losing 99% of their beam time to this issue. cc @stuwilkins @dchabot

[stuwilkins]

Things to check / thoughts.

1) Please check what plugins are enabled in the IOC and which ones are configured to do “blocking callbacks”. The status object returns when the $(Sys)$(Dev)cam1:Acquire signal finishes (put completes). This is when the camera says it is idle and all the blocking plugins (such as stats / file writing) have also completed. However be very careful disabling blocking callbacks. This relies on buffering and from memory the machine that runs the IOC for the PE detector is not exactly powerful. I also think that file writing blocks callbacks … are you writing to a directory that is fast? Samba problems?

2) See if the Acquire and Acquire_RBV PVs and how they toggle. If they don’t toggle correctly at the IOC then this is not a problem with python but with the detector. This can be done with a camonitor to the Acquire PV.

3) Check the IOC to make sure it is not out of memory etc. Is this a windoze machine?

S

On Oct 19, 2015, at 5:08 PM, Dan Allan notifications@github.com<mailto:notifications@github.com> wrote:

An issue discovered with @sbillingehttps://github.com/sbillinge and @timoHMMhttps://github.com/timoHMM today at XPD:

Even when pe1.acquire_time is small (0.2 seconds), the status object returned by pe1.trigger() takes ~10 seconds to flip to done. (The worst case we saw was 13, the best case about 10.)

I don't have a comprehensive understanding of all the different attributes and precisely what they means (num_images, num_exposure, acquire_time, acquire_period, ...) but all were on a low setting.

If we can't resolve this by Wednesday, Simon's group will effectively be losing 99% of their beam time to this issue. cc @stuwilkinshttps://github.com/stuwilkins @dchabothttps://github.com/dchabot

— Reply to this email directly or view it on GitHubhttps://github.com/NSLS-II/ophyd/issues/157.

[dchabot]

This is not a python problem - I observed this too when actuating the detector via the CSS interface.

IIRC, the PE camera was configured to take 50 frames and sum them in the Processing plugin to produce a single, integrated frame. That would produce 50*0.2 = 10 seconds.

Also check for deliberate delays introduced on shutter open/close. Contrary to what it is called, that shutter is anything but fast...

[ghost]

I tested a little bit last night, it seems this delay is independent of acquire time.

From my test, when pe1 acquire time is equal to 0.2 seconds, delay is ~11 secs when pe1 acquire time is equal to 5 seconds, delay is ~15 secs, when pe1 acquire time is equal to 10 seconds, delay is ~15 secs

[sbillinge]

yes, Tim got the same results from his tests. It is still an issue though since most of our (well scattering) samples have acquire times of around 1 second. We will try and work with Sanjit to check the CSS issues that Darron mentioned, but I don't think that is the issue based on the fact that the delay doesn't scale with acquire time. Your help on this is really appreciated!

I am cc'ing Sanjit because I don't think he is linked to the github issue (and I don't know how to add him)

Thanks,

S

On Tue, Oct 20, 2015 at 11:40 AM, Timothy.Liu notifications@github.com wrote:

I tested a little bit last night, it seems this delay is independent of acquire time.

From my test, when count time is equal to 0.2 seconds, delay is ~11 secs when count time is equal to 5 seconds, delay is ~15 secs, when count time is equal to 10 seconds, delay is ~15 secs

— Reply to this email directly or view it on GitHub https://github.com/NSLS-II/ophyd/issues/157#issuecomment-149608150.

Prof. Simon Billinge Applied Physics & Applied Mathematics Columbia University 500 West 120th Street Room 200 Mudd, MC 4701 New York, NY 10027 Tel: (212)-854-2918 (o) 851-7428 (lab)

Condensed Matter Physics and Materials Science Dept. Brookhaven National Laboratory P.O. Box 5000 Upton, NY 11973-5000 (631)-344-5661

email: sb2896 at columbia dot edu home: http:// http://nirt.pa.msu.edu/bgsite.apam.columbia.edu/

[sbillinge]

Just a quick comment: There are two issues if that might be linked to the issues discussed here.

1.  The fast shutter EPICS control is having a 5 sec delay ( that is setup ) We can change that.

2.  The fast shutter currently broke (mechanical) as reported by John Trunk at the beamline.

3.  I am going to take off the EPICS PV control and we will be working without fast shutter having pe1.dark_interval = 0. I am not sure if that works.

From: Simon Billinge [mailto:simon.billinge@gmail.com] Sent: Tuesday, October 20, 2015 11:45 AM To: NSLS-II/ophyd Cc: NSLS-II/ophyd; Ghose, Sanjit Subject: Re: [ophyd] Triggering the Perkin-Elmer takes ~10 seconds regardless of acquisition time (#157)

yes, Tim got the same results from his tests. It is still an issue though since most of our (well scattering) samples have acquire times of around 1 second. We will try and work with Sanjit to check the CSS issues that Darron mentioned, but I don't think that is the issue based on the fact that the delay doesn't scale with acquire time. Your help on this is really appreciated!

I am cc'ing Sanjit because I don't think he is linked to the github issue (and I don't know how to add him)

Thanks,

S

On Tue, Oct 20, 2015 at 11:40 AM, Timothy.Liu notifications@github.com<mailto:notifications@github.com> wrote:

I tested a little bit last night, it seems this delay is independent of acquire time.

From my test, when count time is equal to 0.2 seconds, delay is ~11 secs when count time is equal to 5 seconds, delay is ~15 secs, when count time is equal to 10 seconds, delay is ~15 secs

— Reply to this email directly or view it on GitHubhttps://github.com/NSLS-II/ophyd/issues/157#issuecomment-149608150.

Prof. Simon Billinge Applied Physics & Applied Mathematics Columbia University 500 West 120th Street Room 200 Mudd, MC 4701 New York, NY 10027 Tel: (212)-854-2918 (o) 851-7428 (lab)

Condensed Matter Physics and Materials Science Dept. Brookhaven National Laboratory P.O. Box 5000 Upton, NY 11973-5000 (631)-344-5661

email: sb2896 at columbia dot edu home: http://http://nirt.pa.msu.edu/bgsite.apam.columbia.edu/http://bgsite.apam.columbia.edu/

[danielballan]

Conversation continued and possibly resolved at https://github.com/NSLS-II/Bug-Reports/issues/49