[xpd] unhitching fast shutter (sh1) from areaDetector

[sbillinge]

This urgent.....we are running TODAY....so a quick workaround would really help us!

This is a bug that was kind of swatted some time ago, but after 24 hours of struggle, it seems stlil to be alive and flying around. issue: synchronization of Perkin-Elmer (pe1) acquire and shutter is flakey, so sometimes darks are not dark, and only gods know whether lights are fully light. solution: was to disable sh1 from areaDetector so that we could operate it explicitly from bluesky with sh1.open = 1 etc., so we could do something like: sh1.open = 1 gs.RE(my_scan_of_num=20) sh1.open = 0 and the shutter would remain open for the entire my_scan.....

This is not possible right now because the shutter is linked to areaDetector which triggers it during the scan. I think that Daron (or someone) had a way to disable it from areaDetector so that this UC above would work, but this is not a standard setting and we have no idea how to reconfigure XPD to do that again.

related topic: when this is done, we would like to remove any delay that is in the system to wait for the shutter.

[brunoseivam]

You can do that by changing the PV $(P)cam1:ShutterMode to None

[danielballan]

@dchabot, I think On Mon, Nov 9, 2015 at 9:42 AM Bruno Martins notifications@github.com wrote:

You can do that by changing the PV $(P)cam1:ShutterMode to None

— Reply to this email directly or view it on GitHub https://github.com/NSLS-II/Bug-Reports/issues/55#issuecomment-155081763.

[dchabot]

@brunoseivam's suggestion is the correct one - from the CSS panel for the pe1 detector, select "shutter controls", or similar, then change the shutter mode to "None".

Alternatively, try caput XF:28IDC-ES:1{Det:PE1}cam1:ShutterMode None, from a beamline workstation command line.

This will also disable any delays associated with opening/closing the shutter under AreaDetector's control.

[heroux]

Done that, matt is at the beamline. Somehow the ioc or detector are not stable. It works 1/3 of the time

Sent from my iPhone

On Nov 9, 2015, at 12:19, dchabot notifications@github.com<mailto:notifications@github.com> wrote:

@brunoseivamhttps://github.com/brunoseivam's suggestion is the correct one - from the CSS panel for the pe1 detector, select "shutter controls", or similar, then change the shutter mode to "None".

Alternatively, try caput XF:28IDC-ES:1{Det:PE1}cam1:ShutterMode None, from a beamline workstation command line.

This will also disable any delays associated with opening/closing the shutter under AreaDetector's control.

— Reply to this email directly or view it on GitHubhttps://github.com/NSLS-II/Bug-Reports/issues/55#issuecomment-155129974.

[sbillinge]

thanks everyone for pitching in. This worked.

[cowanml]

I wouldn't close this yet.

• need to set the shuttermode to none in the scripts and when set to none,
• closing the shutter works, but generates an exception. (suppressed for now)
• the shutter closed status pv isn't set (or doesn't stay set?)

As for detector stability, next time it flakes out we should determine if restarting just the ioc is sufficient. I suspect not.

[sbillinge]

OK, fine with me to reopen the issue.

I closed it because the issue of "how to unhitch the shutter from areaDetector" was resolved, but indeed there are a number of other issues that this threw up, some software, some hardware, that do need to be fixed urgently for stable operations at XPD, , as per the list that you made. These should definitely be captured here, or in a custom issue. I leave it up to you guys where/how to handle the issue tracking on that.

Thanks to everyone for the rapid responses on that btw. I think the gitHub issue tracking is working well for this purpose. We got a really wonderful response and it helped a lot.

S

On Tue, Nov 10, 2015 at 9:22 AM, cowanml notifications@github.com wrote:

I wouldn't close this yet.

• need to set the shuttermode to none in the scripts and when set to none,
• closing the shutter works, but generates an exception. (suppressed for now)
• the shutter closed status pv isn't set (or doesn't stay set?)

As for detector stability, next time it flakes out we should determine if restarting just the ioc is sufficient. I suspect not.

— Reply to this email directly or view it on GitHub https://github.com/NSLS-II/Bug-Reports/issues/55#issuecomment-155433337.

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/

[ghost]

@sbillinge I just talked to John (Sanjit's technician) and he is trying to fix the shutter now. Seems like bad mechanical design. We will address the issues @cowanml listed.

[dchabot]

@cowanml: what is the exception generated on shutter.close()?

[cowanml]

Seems pretty clear the shutter was not designed or intended to shutter individual images and it should be used as it is now. (open, take multiple images, close)

There must be some way to get the scan to run in this mode so they don't have to bracket all their scans with opens and closes?

-matt

[dchabot]

There are at least three means to get at what you're proposing: 1) bracket each exposure with with software-actuated shutter open/close in a scan 2) hack areadetector (perkin elmer support) to support shutter open/close, per exposure, when in multiple-image mode 3) if the Perkin Elmer and shutter supports it, use physical signals to actuate each (e.g. TTL)

[sbillinge]

agreed. It could be nice to have that behavior handled robustly at the bluesky level. However, I also like to have some control over that at my script level. I can imagine a scenario where I want to take a scan and not have the shutter automatically open and close at the beginning/end of the scan. So having the capability to override that default behavior would be best for us. Some kind of remote_shutter_control = True but this can be set to False in the scan definition and the scan doesn't do anything with the shutter.

There is an argument to be made that areaDetector doesn't do anything with the shutter too. If that hadn't been buried down at that level our lives would have been much easier. The responsibility is then on us to make robust shutter handling at our script level, to avoid damaging the detector for example, but maybe that is preferable. It is our (instrument scientists and their helpers) responsibility to use the software tools of the software group, with help and advice from the software group, to make a robust setup at the beamline.

In this context, having some tools from the software group that could check things. For example, if there was a tool that told us when a certain theshold number of detector pixels were saturated and threw some kind of exception, we could build safeguards into our scripts that either aborts a run in that situation, or gives users a warning, whatever we choose. I think these kinds of functionality would actually be the most powerful and the most flexible for us, as we could use them in different ways depending on the situation, and particular solutions are not hard-wired deep in the data acquisition software, and hard to override.

S

On Tue, Nov 10, 2015 at 1:34 PM, cowanml notifications@github.com wrote:

Seems pretty clear the shutter was not designed or intended to shutter individual images and it should be used as it is now. (open, take multiple images, close)

There must be some way to get the scan to run in this mode so they don't have to bracket all their scans with opens and closes?

-matt

— Reply to this email directly or view it on GitHub https://github.com/NSLS-II/Bug-Reports/issues/55#issuecomment-155524555.

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/

[cowanml]

On Tue, 10 Nov 2015, dchabot wrote:

@cowanml: what is the exception generated on shutter.close()?

I'm guessing it'll promptly complain about 'ton_shutter' (looks like an editor goof) after getting past this.

######################################################################

In [4]: sh1.close = 1

AttributeError Traceback (most recent call last)

in () ----> 1 sh1.close = 1 /home/xf28id1/ipython_profiles/profile_collection/startup/79-shutter.py in close(self, val) 48 49 # this is the fast shutter ---> 50 ret = self.read_pv 51 ton_shutter 52 sh1 = Nsls2Shutter(open='XF:28IDC-ES:1{Sh:Exp}Cmd:Opn-Cmd', AttributeError: 'Nsls2Shutter' object has no attribute 'read_pv' ######################################################################

[klauer]

For reference, the Nsls2Shutter: https://github.com/NSLS-II-XPD/ipython_ophyd/blob/master/profile_collection/startup/79-shutter.py#L50 (and my own comment: um, what's going on there?)

[dchabot]

@klauer, no idea what that is... Looks like an errant paste (middle-click)?

OTOH, I don't see how Nsls2Shutter could ever successfully work - is it not reading/writing status pvs, not actuation (Cmd) pvs?

[klauer]

@dchabot Yeah, it looks like it was never fully implemented. Was this ever actually used at the beamline?

[sbillinge]

we were trying to use use it.....it was flaky, sometimes worked sometimes didn't, odd behavior like sh1.open = 1 working but sh1.close = 1 not working and so on.

So in short, we tried to use it but not successfully.

There were also mechanical issues with the shutter not completely closing. John is working on that at the beamline, but it is a very real possibility that the shutter may be blocking the beam in the "closed" position (and therefore "working" from the point of view of the experimenter) but not registering as fully closed because it has not reached a limit switch. The experimenter would be mad if the script threw and exception and stopped collecting in this scenario......though a warning that it needs to be fixed would be nice :)

S

On Tue, Nov 10, 2015 at 2:28 PM, K Lauer notifications@github.com wrote:

@dchabot https://github.com/dchabot Yeah, it looks like it was never fully implemented. Was this ever actually used at the beamline?

— Reply to this email directly or view it on GitHub https://github.com/NSLS-II/Bug-Reports/issues/55#issuecomment-155540023.

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/

[klauer]

@dchabot Oh, looking closer it's actually it's using the write_pv/read_pv for cmd/status, respectively. I think lines 49~51 should probably just be deleted, as 47 does the actual caput to close the shutter. It'd probably start working again.

[dchabot]

you're right, @klauer. not sure what I was thinking.