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

Kickoff/Complete/Collect crashes with an attribute error when using internal trigger on standard det #603

Open
jwlodek opened this issue Oct 7, 2024 · 2 comments
Assignees
Labels
bug Something isn't working

Comments

@jwlodek
Copy link
Member

jwlodek commented Oct 7, 2024

When using a standard detector in internal trigger mode, trying to use kickoff/complete/collect, will crash with an attribute error because self._fly_start is never set because of this conditional:

if value.trigger != DetectorTrigger.internal:

Is there a reason we need this conditional? Everything works fine if I just remove it. Using kickoff/complete/collect with internal trigger is something I want to do because we want to be able to re-use the same plan for both the everything is hardware triggered experiment, and the everything is timestamped experiment.

Steps To Reproduce

Steps to reproduce the behavior:

  1. Create standard detector.
  2. Prepare in internal trigger mode.
  3. Run kickoff/complete/collect
  4. See traceback.

Acceptance Criteria

  • Allow for using kickoff/complete collect with internal trigger
@jwlodek jwlodek added the bug Something isn't working label Oct 7, 2024
@jwlodek jwlodek changed the title Kickoff/Complete/Collect crashes with an attribute error when using Internal trigger Kickoff/Complete/Collect crashes with an attribute error when using internal trigger on standard det Oct 7, 2024
@ZohebShaikh
Copy link
Contributor

This change was made in response to the comment here: #568 (comment). @coretl may have more context on the necessity of this requirement.

@coretl
Copy link
Collaborator

coretl commented Oct 7, 2024

We want to be able to parallelize the slow operations of our flyscan:

  • Move a motor to the start position (2s)
  • Arm the detector (10s)

But actually we might want to do the same flyscan 10 times at different energies, so we decided that we should be able to arm for multiple runs at the start:

  • Move motor to start and arm the detector for 10x flyscans (10s)
  • Do 1 flyscan
  • Move motor to start (2s)
  • Do 1 flyscan
  • ...

We decided that we should put the arm in prepare for this, but actually I'm beginning to think we should put the arm back in kickoff after all. Then the first detector kickoff of the 10 will arm for 10x flyscans, and subsequent ones will not have to do anything.

@ZohebShaikh I'm not sure if we explored that as an option?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

3 participants