Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

XIA PFCU4 filters and shutters #974

Open
canismarko opened this issue May 10, 2024 · 3 comments
Open

XIA PFCU4 filters and shutters #974

canismarko opened this issue May 10, 2024 · 3 comments
Labels
hoist add code from a different project question
Milestone

Comments

@canismarko
Copy link
Collaborator

canismarko commented May 10, 2024

I recently added support for the XIA PFCU4 filter bank to the haven library.

https://github.com/spc-group/haven/blob/main/src/haven/instrument/xia_pfcu.py

In our configuration, 2 of the 4 filters are actually shutters where one is the top half and the other the bottom half.

To start with I tried to make the shutter with the same interface as the ShutterBase found in apstools. This didn't work with pydm, though, as pydm needs a signal to set for open and close, and to read for its current state, etc., and it needs to device to be subscribable.

I started adding this capabilities to the PSS shutter class, and realized I was re-inventing the PVPositioner class, so I just made my shutter be a PVPositioner instead of an apstools ShutterBase, and used an enum instead of strings for the possible states so it would work with the PyDMByteIndicator widget.

My next step is to re-implement our pss shutter support using this positioner approach.

My question then is what, if anything, is of interest to apstools? I imagine the filter support minus the shutter would be useful. Would the shutter work be useful as well, with the caveat that it might not be backwards compatible?

@canismarko canismarko added question hoist add code from a different project labels May 10, 2024
@prjemian
Copy link
Contributor

I'm starting to like the approach of a shutter as an enumerated positioner. Some shutters have separate open and close PVs and some of those have separate readback and target PVs. So it gets complicated but an enumerated positioner object might be an improvement over the present implementation. As long as we don't break existing installations.

Others also implement the shutter blade option as an X-ray opaque filter (product of $\mu_m(\lambda) \ \rho_m \ t$). Is there anything truly different, other than the exceptionally high absorption?

@canismarko
Copy link
Collaborator Author

When I have permission to control a shutter, I planned to work on the pss shutters. I'm hoping the DerivedSignal and MultiDerivedSignal will be useful there, or maybe subscriptions to a non epics setpoint signal.

Yeah, the existing installations question I'm not sure about. I think it depends on how they use it. If the "open" and "close" values are written into a library somewhere it could be a problem. Otherwise it's on the operator to type a 1 instead of "open".

Im not sure why we have two pieces instead of one. The xia filters i implemented are also positioners, so a single high attenuation filter would be basically the same.

Do you want a PR for what I have so far, and I can unify the shutters once I can test on a real one?

@prjemian
Copy link
Contributor

I think this can wait for beam testing first.

@prjemian prjemian added this to the 1.7.1 milestone Sep 21, 2024
@prjemian prjemian modified the milestones: 1.7.1, 1.7.2 Oct 24, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
hoist add code from a different project question
Projects
None yet
Development

No branches or pull requests

2 participants