Skip to content

hardware support for micro photon devices picosecond delayer#1232

Merged
David-Baddeley merged 8 commits into
python-microscopy:masterfrom
barentine:mpd-pds
May 25, 2022
Merged

hardware support for micro photon devices picosecond delayer#1232
David-Baddeley merged 8 commits into
python-microscopy:masterfrom
barentine:mpd-pds

Conversation

@barentine
Copy link
Copy Markdown
Member

@barentine barentine commented May 6, 2022

Is this a bugfix or an enhancement?
enhancement
Proposed changes:

  • add a picosecond delayer distributed by picoquant useful for synchronizing pulsed diode lasers
  • add a GUI panel to control/visualize the delay set-point
  • fix trivial typo in a microscopy.py docstring
  • add the picosecond delayer to the list of supported hardware under miscellaneous.

Note: will likely follow up at some point with a class to support the Picoquant Taiko pulsed/cw driver.

Checklist:

  • Tested with numpy=1.14
  • Tested on python 2.7 and 3.6
  • Tested with wx=3.x and wx=4.x [if UI code]
  • Does the PR avoid variable renaming in existing code, whitespace changes, and other forms of tidying? [There is a place for code tidying, but it makes reviewing
    much simpler if this is kept separate from functional changes]

If an enhancement (or non-trivial bugfix):

  • Has this been discussed in advance (feature request, PR proposal, email, or direct conversation)?
  • Does this change how users interact with the software? How will these changes be communicated?
  • Does this maintain backwards compatibility with old data?
  • Does this change the required dependencies?
  • Are there any other side effects of the change?

@David-Baddeley
Copy link
Copy Markdown
Contributor

Will merge as is ... but probably need to think a bit more about the conventions for new hardware going forward. As much as there is a current convention it is to use functional setters/getters rather than attribute/property access for hardware parameters that you might change. A lot of this is historical, and in some respects property-based access is more "pythonic", but there is definitely a case for being consistent across different hardware types. The potential arguments for functional getters/setters are:

  • what we currently use (i.e. less work). Not sure this is a great argument
  • generally closer to the APIs/SDKs of the hardware itself (also not necessarily a clincher)
  • property access is generally assumed to be instantaneous and zero cost. A lot of hardware operations take some time (although we often hide this with threading). A programmer is more likely to expect some latency / to have to wait with a functional API.

@David-Baddeley David-Baddeley merged commit 212991c into python-microscopy:master May 25, 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

Successfully merging this pull request may close these issues.

2 participants