remove things that go into the cookbook (#302)

* remove things that go into the cookbook * revert mistaken newline * Update flyscanning.rst * fix design goalsrst
bluesky · May 22, 2024 · 9f332e3 · 9f332e3
1 parent 8950a2f
commit 9f332e3
Show file tree

Hide file tree

Showing 5 changed files with 2 additions and 36 deletions.
diff --git a/docs/explanations/design-goals.rst b/docs/explanations/design-goals.rst
@@ -32,7 +32,7 @@ Parity with Malcolm
 
 Ophyd-async should provide the same building blocks for defining flyscans scans as malcolm_. It should support PandA and Zebra as timing masters by default, but also provide easy helpers for developers to write support for their own devices.
 
-It should enable `motor trajectory scanning <motortraj_>` and `multiple triggering rates<detectorsync_>` based around a base rate, and pausing/resuming scans. Scans should be modelled using scanspec_, which serves as a universal language for defining trajectory and time-resolved scans, and converted to the underlying format of the given motion controller. It should also be possible to define an `outer scan <outerscan_>`.
+It should enable motor trajectory scanning and multiple triggering rates based around a base rate, and pausing/resuming scans. Scans should be modelled using scanspec_, which serves as a universal language for defining trajectory and time-resolved scans, and converted to the underlying format of the given motion controller. It should also be possible to define an outer scan .
 
 
 Improved Trajectory Calculation

diff --git a/docs/explanations/flyscanning.rst b/docs/explanations/flyscanning.rst
@@ -1,41 +1,7 @@
 Flyscanning
 ===========
 
-Flyscanning (also known as hardware triggered scanning, asynchronous acquisition, and hardware synchronized scanning) is the practice of accelerating the rate of data collection by handing control over to an external hardware system that can control and synchronize the triggering of detectors with other signals and/or commands. Flyscans take many forms.
-
-.. _detectorsync_:
-
-Detector Synchronization
-------------------------
-
-.. figure:: ../images/simple-hardware-scan.png
-    :alt: hardware-triggered setup
-    :width: 300
-
-A triggering system can send pulses to two or more detectors to make them expose simultaneously, or at different multiples of the same base rate (e.g. 200Hz and 400Hz).
-
-.. _motortraj_:
-
-Motor Trajectory Scanning
--------------------------
-
-.. figure:: ../images/hardware-triggered-scan.png
-    :alt: trajectory scanning setup
-
-The triggering system can be configured to trigger the detectors at the same time as the motion controller commands the motors to go to certain points, or even exactly when they reach those points, using the readback values. This can be achieved on the scale of microseconds/nanoseconds, in comparison to traditional soft scans controlled via a network, which normally synchronize on the scale of seconds.
-
-.. _outerscan_:
-
-Outer Scanning
---------------
-
-Outer scans are flyscans nested inside soft scans. 
-
-.. figure:: ../images/outer-scan.png
-    :alt: hardware-triggered setup
-
-In the example above a 2D grid scan in ``x`` and ``y`` is repeated in a third dimension: ``z``. Given that ``z`` only needs to move for every 1 in every 25 points, it could be synchronized via software rather than hardware without significantly affecting scan time (and saving the effort/expense of wiring it into a triggering system). It then becomes the responsibility of the software to move ``z``, hand control to the external hardware, wait for one grid's worth of points, take control back, and repeat. 
-
+See the documents in the [bluesky cookbook](http://blueskyproject.io/bluesky-cookbook/glossary/flyscanning.html)
 
 Hardware
 --------

diff --git a/docs/images/hardware-triggered-scan.png b/docs/images/hardware-triggered-scan.png
diff --git a/docs/images/outer-scan.png b/docs/images/outer-scan.png
diff --git a/docs/images/simple-hardware-scan.png b/docs/images/simple-hardware-scan.png