diff options
| -rw-r--r-- | acquisition/chapter.tex | 121 |
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. %
|