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

Ophyd-Async support for DXP detectors #322

Draft
wants to merge 14 commits into
base: main
Choose a base branch
from
Draft

Ophyd-Async support for DXP detectors #322

wants to merge 14 commits into from

Conversation

canismarko
Copy link
Contributor

Things to do before merging:

  • add tests
  • write docs
  • update iconfig_testing.toml
  • flake8, black, and isort

@Cathyhjj Cathyhjj marked this pull request as ready for review December 7, 2024 00:56
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we need to consider long-duration measurements such as XRF mappings, where visualizing data on the fly would be great. Not sure whether the HFD reading while writing you mentioned before can resolve this?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's something I'd like to have as well. Maybe we should test how SWMR works at the beam line sometime with an area detector?

The DXP IOCs (at least the 4-element vortex) don't seem to have HDF plugins installed though, only netCDF. Not sure how this would be possible with netCDF files. Hoping to figure that out later. It's possible we'll need to add those plugins.

def __init__(self, prefix: str, name: str = "") -> None:
# SNL status records
self.snl_connected = epics_signal_r(bool, f"{prefix}SNL_Connected")
# Acquisition control records
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I vaguely remebered there is also one more option erase_start in epics, but maybe it's not necessary to include this

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yep, there is.

For the xspress detectors I found that if you start the HDF writer, and then use "erase", you get an extra frame in the HDF file because "erase" sets the ndarray to all zeros and the writer treats that as new data to save.

So to avoid this extra frame, the Xspress device sets "erase", then starts the HDF plugins, then sets "start". I couldn't think of a situation where "start_erase" was necessary, I left it off of the xspress device so people don't accidentally save extra blank frames.

I'm not sure if that extra frame happens on the DXP detectors, though, so if there's a reason to include it we maybe could. Do you have a use case in mind?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's just leave if off

self._drv = driver

def get_deadtime(self, exposure: float) -> float:
# Xspress deadtime handling
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is this deadtime 0.001 correct, or it's like DXPController above?
maybe we should also add the same comment here

# No-op value. Fill this in when we know what to include

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good idea. I'll add that to the xspress PR: #316

@canismarko canismarko marked this pull request as draft December 7, 2024 14:01
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants