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

Add generalized acquisition device and associated "hardware source" class #119

Open
cmeyer opened this issue May 21, 2022 · 3 comments
Open

Comments

@cmeyer
Copy link
Collaborator

cmeyer commented May 21, 2022

Notes from my generalized acquisition device plans.

A generalized acquisition device would be a device that could produce one or more streams of data in various arrangements. The idea is to eliminate the need for device implementers to subclass or implement their own HardwareSource (considered to be an internal class).

Examples would be:

  • Frames of 1D or 2D data (e.g. camera)
  • Streams of 2D data (e.g. scan)
  • Sequences of frames (e.g. camera with fixed number of frames)
  • Synchronized frames (e.g. camera synchronized with a scan)
  • Bursts of frames (e.g. sequences of frames at regular intervals)
  • Multiple channels of output.

The device would include control panels with components specific to the device to control the behavior.

A rough idea (see my local file AcquisitionDevice.py):

class ModeController(typing.Protocol):
    # is_continuous
    # is_interruptable?

    def begin_mode(self) -> None: ...

    def continue_mode(self) -> None: ...

    def end_mode(self) -> None: ...

    def cancel_mode(self) -> None: ...


class AcquisitionDevice(typing.Protocol):
    # device properties

    def close(self) -> None: ...

    def enter_mode(self, mode_name: str, mode_parameters: ModeParameters) -> ModeController: ...

Loose instructions to test a potential implementation

  • Define a device interface that supports your physical device, your simulator, and a Python-only simulator as concrete implementations. This will also define the types of data that the devices can produce. We can combine multiple devices together if that makes sense (i.e. scan + camera).
  • Implement a HardwareSource (see the protocol in the existing code) for use in live/view-mode image or spectra updates.
  • Implement a data stream for use in extended acquisitions such as SI that support partial data updates and may involve multiple devices.
  • Implement control panels to launch view modes and extended acquisitions. We may be able to define components to make this easier - Nion can maintain the general acquisition panel; you will implement specific components.
  • Implement configuration settings dialog where necessary.
  • Implement specific components to fit into the new Swift acquisition panel where possible. This is a work in progress and eventually may eliminate some of the control panels that you have.

Note: original discussion personal notes on 2022-02-15

@cmeyer
Copy link
Collaborator Author

cmeyer commented May 21, 2022

@cmeyer
Copy link
Collaborator Author

cmeyer commented Aug 17, 2022

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

No branches or pull requests

1 participant