2018-03-30 16:58

1 files 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.  %