From 8d24954c1bc110d8b88d135786e03265bb678c23 Mon Sep 17 00:00:00 2001 From: Blaise Thompson Date: Fri, 30 Mar 2018 16:58:46 -0500 Subject: 2018-03-30 16:58 --- acquisition/chapter.tex | 121 +++++++++++++++++++++++++++++++++++++++++++----- 1 file changed, 110 insertions(+), 11 deletions(-) diff --git a/acquisition/chapter.tex b/acquisition/chapter.tex index bd08edd..6805150 100644 --- a/acquisition/chapter.tex +++ b/acquisition/chapter.tex @@ -351,19 +351,39 @@ Conceptually, can imagine a 4 quadrant system. % Thus PyCMDS can be proud to try and generalize the hardware-complex part of acquisition software because indeed that is all that can be generalized. % -% TODO: 4 quadrants of complexity figure - +\begin{figure} + \caption{ + CAPTION TODO: 4 QUADRANTS OF COMPLEXITY + } + \label{aqn:fig:complexity_quandrants} +\end{figure} + \section{Hardware} \label{aqn:sec:hardware} % ==================================================== Hardware are things that 1) have a position, 2) can be set to a destination. % Typically they also have associated units and limits. % +They sometimes have an offset, as specified by the autonomic system +(\autoref{aqn:sec:autonomic}). % Each hardware can be thought of as a dimension of the MR-CMDS experiment, and scans include a specific traversal through this multidimensional space. % \subsection{Hardware inheritance} % -------------------------------------------------------------- -All hardware classes are children of the parent \python{Hardware} class, which is itself subclassed -from the global \python{Hardware} class shown in \autoref{aqn:lst:parent_hardware}. % +All hardware classes are children of the parent \python{Hardware} class +(\autoref{aqn:fig:hardware_class}), which is itself a child of the the global \python{Hardware} +class shown in \autoref{aqn:fig:parent_hardware_class}. % +By inspecting \autoref{aqn:fig:hardware_class}, we can see that all hardware require the following +methods: +\begin{ditemize} + \item \python{close} + \item \python{get_destination} + \item \python{get_position} + \item \python{on_address_initialized} + \item \python{poll} + \item \python{set_offset} + \item \python{set_position} + \item \python{@property units} +\end{ditemize} \begin{figure} \includepython{"acquisition/hardware.py"} @@ -379,12 +399,11 @@ from the global \python{Hardware} class shown in \autoref{aqn:lst:parent_hardwar \begin{figure} \includebash{"acquisition/hardware_inheritance"} \caption[Hardware inheritance.]{ + CAPTION TODO } \label{aqn:fig:hardware_inheritance} \end{figure} -So every hardware object must have the following... - \subsection{Delays} % ---------------------------------------------------------------------------- Delays are the kind of thing that have a position in absolute units, a zero position, and a @@ -408,7 +427,14 @@ The delay GUI, by default, offers \item \python{on_set_motor} \item \python{on_set_zero} \end{ditemize} - + +\begin{figure} + \caption[Representative delay stage advanced menu.]{ + CAPTION TODO + } + \label{aqn:fig:delay_advanced} +\end{figure} + \subsection{Spectrometers} % --------------------------------------------------------------------- Spectrometers are the kind of thing that can be set to a single color (typically native units are @@ -423,6 +449,13 @@ Driver: GUI: +\begin{figure} + \caption[Representative delay stage advanced menu.]{ + CAPTION TODO + } + \label{aqn:fig:spectrometer_advanced} +\end{figure} + \subsection{OPAs} % ------------------------------------------------------------------------------ Hardware: @@ -439,6 +472,13 @@ United Interpolation +\begin{figure} + \caption[Representative delay stage advanced menu.]{ + CAPTION TODO + } + \label{aqn:fig:opa_advanced} +\end{figure} + \subsection{Filters} % --------------------------------------------------------------------------- Hardware: @@ -447,6 +487,7 @@ Driver: GUI: +\clearpage \section{Sensors (devices)} \label{aqn:sec:sensors} % ============================================ Sensors are... @@ -465,6 +506,13 @@ Old boxcar: 300 ns window, ~10 micosecond delay. Onset of saturation ~2 V. % TODO: poweramp tune test (see darien slack) +\begin{figure} + \caption[Array detector serving as an axis.]{ + CAPTION TODO + } + \label{aqn:fig:array_as_axis} +\end{figure} + \section{Autonomic} \label{aqn:sec:autonomic} % ================================================== \begin{dquote} @@ -487,6 +535,13 @@ Old boxcar: 300 ns window, ~10 micosecond delay. Onset of saturation ~2 V. % TODO: concept of additive offsets +\begin{figure} + \caption[Representative spectral delay correction]{ + CAPTION TODO + } + \label{aqn:fig:sdc} +\end{figure} + \section{Somatic} \label{aqn:sec:somatic} % ======================================================= In contrast with the autonomic system (\autoref{aqn:sec:autonomic}), the somatic system is all @@ -535,8 +590,26 @@ For scan module, just \subsection{Spectral delay correction module} % -------------------------------------------------- +Currently spectral delay correction is done ``manually''. % +Relevant Wigner scans are taken using the SCAN module, processed using WrightTools, and generated +coset files are manually applied in the autonomic menu. % +Ideally, ``check'' Wigners are then taken to verify the veracity of the corrections. % +In the future, it would be preferable to have a dedicated SDC module that did all of these things +automatically. % + +It would start from existing corrections (for that table geometry) and iterate until the applied +Wigners are all correct. % + \subsection{``Headless'' hardware, sensors} % ---------------------------------------------------- +The abstraction of hardware complexity that PyCMDS offers is really convienient, but currently +these convinient classes can only be used within PyCMDS itself. % +Since code in PyCMDS is inseperable from the GUI, it is not possible to \python{import PyCMDS} and +use the abstract tools in other programs or scripts. % +This design is not necessary, and doing the work to free hardware and sensor code from the GUI code +would allow for all kinds of creative experiments that are not currently possible within the +central conceit of PyCMDS. % + \subsection{Ideal Axis Positions} \label{acq:sec:ideal_axis_positions} % ------------------------- Frequency domain multidimensional spectroscopy is a time-intensive process. % @@ -651,10 +724,36 @@ S_n &=& (1-c)\left(\frac{n}{N}\right)^{\frac{\tau_{\mathrm{step}}}{\tau_{\mathrm \subsection{Simultanious acquisitions} % --------------------------------------------------------- -\subsection{Enhanced modularity} % --------------------------------------------------------------- - -\subsection{wt5 savefile} % ---------------------------------------------------------------------- +Sometimes PyCMDS needs to do multiple scans that are completely orthogonal. % +For example, certain OPA tuning operations only require signals from pyroelectric detectors that +are each permanently installed to monitor a single OPA. % +In such cases, theoretically multiple OPAs could be tuned simultaneously. % +The coordination of such operations would be more difficult than what currently exists, but could +be possible within PyCMDS' multithreaded design. % \subsection{Hotswappable hardware} % ------------------------------------------------------------- -\subsection{Better logging and error handling} % ------------------------------------------------- \ No newline at end of file +One of the most important basic capabilities of PyCMDS is the ability to reconfigure itself +depending on what hardware is loaded. % +However controlling the hardware configuration is currently more difficult than it should be. % +Currently users need to shut down PyCMDS, manually edit INI files to configure which hardware are +included, and restart PyCMDS. % +A better solution would allow users to ``hotswap''---load, or drop hardware and sensors +without shutting down PyCMDS. % +The work of allowing this would also allow users to reload hardware, a great fallback option when +there are communication issues. % + +\subsection{wt5 savefile} % ---------------------------------------------------------------------- + +The wt5 save format, introduced in WrightTools 3, is a huge improvement over the simple, plaintext +data format currently used by PyCMDS. % TODO: link to discussion of wt5 format +wt5 files are smaller on disk, have richer metadata and self-descriptive properties, and multiple +scans can be stored in the same file using \python{Collections}. % TODO: again, link +Because wt5 files are stored on disk but fully accessible through slicing, PyCMDS could have full +access to the scan arrays without risk of memory overflow, which promises to allow for new +potential visualizations during acquisition. % TODO: presumably we talk about buffered file + % writing above? + +Even more exciting, wt5 files can be instantiated as empty and \textit{then} filled. % +This means that the wt5 file can be a self-describing set of destinations that actually defines +which pixels PyCMDS should visit. % -- cgit v1.2.3