From b6d88e014f454e040a96d6f1342cefff0c99f061 Mon Sep 17 00:00:00 2001 From: Blaise Thompson Date: Thu, 26 Apr 2018 10:51:26 -0500 Subject: 2018-04-26 10:51 --- acquisition/chapter.tex | 34 ++++++++++++++++------------------ 1 file changed, 16 insertions(+), 18 deletions(-) (limited to 'acquisition') diff --git a/acquisition/chapter.tex b/acquisition/chapter.tex index 8ca947c..7fbd1e7 100644 --- a/acquisition/chapter.tex +++ b/acquisition/chapter.tex @@ -53,7 +53,7 @@ require custom software to address all of the simultaneous, repeated motor motio requires. % Because MR-CMDS is really a family of techniques which require different kinds of motor motion, this acqusition software should be flexable enough to meet the creativity of its users. % -Furthermore, because MR-CMDS is a bleeding edge, rapidly evolving technique the instrumental +Furthermore, because MR-CMDS is a, rapidly evolving technique the instrumental software must be built in an extendable way to accommodate the ever-changing hardware configurations. % In this chapter I describe how I built such an acquisition software, PyCMDS. % @@ -439,8 +439,8 @@ This is typical behavior for Mutexes, however. % \subsubsection{Hardware and driver} % ------------------------------------------------------------ Now that we have basic data types to work with, let's actually communicate with hardware. % -Every hardware and sensor have two classes: a driver class, which lives in the worker thread and -handles direct communication, and a hardware class which lives in the main thread and +Every hardware and sensor are made of two classes: a driver class, which lives in the worker thread +and handles direct communication, and a hardware class which lives in the main thread and ``represents'' that device to the rest of PyCMDS. % The idea is that all of PyCMDS communicates to that device \emph{only} via its hardware class, and that hardware class only talks to that driver class. % @@ -778,8 +778,8 @@ forward. % \begin{landscape} \begin{figure} \includegraphics[width=9in]{"acquisition/screenshots/003"} - \caption{ - PCI-6251 samples tab. + \caption[PCI-6251 samples tab.]{ + Screenshot of PCI-6251 samples tab. } \label{acq:fig:samples} \end{figure} @@ -937,7 +937,7 @@ from the file \bash{PyCMDS/somatic/acquisition.py}. % This method understands how to any scan that PyCMDS can do: any stepwise multidimensional scan with separate hardware and sensors. % -The central scan method requires acquisition modules to provide all of the axes (instances of +The central scan method requires acquisition modules to provide all of the axes (instances of \\ \python{PyCMDS.somatic.acquisition.Axis}) that need to be broadcast across each-other. % Then something very simple happens. % For each hardware that will move during the scan, a destinations object (instance of @@ -1020,14 +1020,14 @@ Arbitrary expressions (PyCMDS calls them ``constants'') are also possible, as ca The TUNE TEST module does a simple thing: it sets a chosen OPA to each of the points in its tuning curve and does a monochromator scan of set width about that setpoint. % In this way the tune (output color) agreement between the curve and the OPA can be determined. % -As a convinience, a new point curve with remapped colors is automatically created. % +A new point curve with remapped colors is automatically created. % % TODO: link to place in tuning chapter... \subsubsection{MOTORTUNE} MOTORTUNE is capable of arbitrary acquisitions in OPA motor space. % Users are free to choose any set of positions for any set of motors, and PyCMDS will broadcast all -of those positions against eachother to form a multidimensional acquisition. % +of those positions against each-other to form a multidimensional acquisition. % Optionally, a leading dimension of \emph{setpoint} may be added, with motor positions being scanned about the points in the old curve. % @@ -1044,11 +1044,11 @@ regular tuning. See \autoref{act:sec:poynting} for more information. % \section{Conditional validity} % ================================================================= -The central conceit of the PyCMDS modular hardware abstraction is that experiments can be boiled -down to a set of orthogonal axes that can be set separately from other hardware and sensor +The central requirement of the PyCMDS modular hardware abstraction is that experiments can be +boiled down to a set of orthogonal axes that can be set separately from other hardware and sensor status. % This requirement is loosened by the autonomic and expression systems, such that any experiment -could \emph{probably} be forced into PyCMDS, but still the conceit stands---PyCMDS is probably +could \emph{probably} be forced into PyCMDS, but still the requirement stands---PyCMDS is probably \emph{not} the correct framework if your experiment cannot be reduced in this way. % From this we can see that it is useful to talk about the conditional validity of the modular hardware abstraction. % @@ -1066,7 +1066,6 @@ For measurement-complex problems, the challenge is, well, the measurement. % These are experiments where every little piece of the instrument is tied together into a complex network of inseparable parts. % These are often time-domain or ``single shot'' measurements. % -Consider work of (GRAPES INVENTOR). % Such instruments are typically much faster at data acquisition and more reliable. % This comes at a price of flexibility: often such instruments cannot be modified or enhanced without touching everything. % @@ -1076,8 +1075,6 @@ purpose modular software design. % The instrument is so custom that it certainly requires entirely custom software. % Measurements can be neither hardware-complex nor software-complex (simple) or both (expensive). % -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. % @@ -1124,9 +1121,9 @@ 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 +The abstraction of hardware complexity that PyCMDS offers is really convenient, but currently +these convenient classes can only be used within PyCMDS itself. % +Since code in PyCMDS is inseparable 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 @@ -1166,7 +1163,7 @@ Of course, linearizing pixels in signal requires prior expectations about the sh multidimensional signal---linear stepping is still an appropriate choice for low-resolution ``survey'' scans. % -CMDS scans often posses correlated features in the multidimensional space. % +CMDS scans often contain correlated features in the multidimensional space. % In order to capture such features as cheaply as possible, one would want to define regions of increased pixel density along the correlated (diagonal) lineshape. % As a concession to reasonable simplicity, our acquisition software (PyCMDS) assumes that all scans @@ -1271,3 +1268,4 @@ See \autoref{cha:pro} for more information about WrightTools. % 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. % +% JCW: i don't think there is enough information provided to support these sentences \ No newline at end of file -- cgit v1.2.3