3rd Party Repo List

docs/source/adding_devices.rst

@@ -12,15 +12,23 @@ Though not strictly required, you should also consider providing a `runviewer_pa
 General Strategy
 ~~~~~~~~~~~~~~~~
 
-As a general rule, it is best to model new hardware implementations off of a currently implemented device that has similar functionality. If the functionality is similar enough, it may even be possible to simply sub-class the currently implemented device, which is likely preferrable.
+As a general rule, it is best to model new hardware implementations off of a currently implemented device that has similar functionality.
+If the functionality is similar enough, it may even be possible to simply sub-class the currently implemented device, which is likely preferrable.
 
-Barring the above simple solution, one must work from scratch. It is best to begin by determining the **labscript** device class to inherit from: `Psuedoclock`, `Device`, `IntermediateDevice`. The first is for implementing Psuedoclock devices, the second is for generic devices that are not hardware timed by a pseudoclock, and the last is for hardware timed device that are connected to another device controlled via labscript.
+Barring the above simple solution, one must work from scratch.
+It is best to begin by determining the **labscript** device class to inherit from: `Psuedoclock`, `Device`, `IntermediateDevice`.
+The first is for implementing Psuedoclock devices, the second is for generic devices that are not hardware timed by a pseudoclock, and the last is for hardware timed device that are connected to another device controlled via labscript.
 
-The `labscript_device` implements general configuration parameters, many of which are passed to the `BLACS_worker`. It also implements the `generate_code` method which converts **labscript** high-level instructions and saves them to the h5 file.
+The `labscript_device` implements general configuration parameters, many of which are passed to the `BLACS_worker`.
+It also implements the `generate_code` method which converts **labscript** high-level instructions and saves them to the h5 file.
 
-The `BLACS_tab` defines the GUI widgets that control the device. This typically takes the form of using standard widgets provided by **labscript** for controlling **labscript** output primitives (ie `AnalogOut`, `DigitalOut`,`DDS`, etc). This configuration is done in the `initialiseGUI` method. This also links directly to the appropriate BLACS workers.
+The `BLACS_tab` defines the GUI widgets that control the device.
+This typically takes the form of using standard widgets provided by **labscript** for controlling **labscript** output primitives (ie `AnalogOut`, `DigitalOut`,`DDS`, etc).
+This configuration is done in the `initialiseGUI` method.
+This also links directly to the appropriate BLACS workers.
 
-The `BLACS_worker` handles communication with the hardware itself and often represents the bulk of the work required to implement a new labscript device. In general, it should provide five different methods:
+The `BLACS_worker` handles communication with the hardware itself and often represents the bulk of the work required to implement a new labscript device.
+In general, it should provide five different methods:
 
 * `init`: This method initialised communications with the device. Not to be confused with the standard python class `__init__` method.
 * `program_manual`: This method allows for user control of the device via the `BLACS_tab`, setting outputs to the values set in the `BLACS_tab` widgets.
@@ -37,7 +45,9 @@ There are currently two supported file organization styles for a labscript-devic
 
 The old style has the `labscript_device`, `BLACS_tab`, `BLACS_worker`, and `runviewer_parser` all in the same file, which typically has the same name as the `labscript_device` class name.
 
-The new style allows for arbitrary code organization, but typically has a folder named after the `labscript_device` with each device component in a different file (ie `labscript_devices.py`, `BLACS_workers.py`, etc). With this style, the folder requires an `__init__.py` file (which can be empty) as well as a `register_classes.py` file. This file imports :obj:`<labscript-utils:labscript_utils.device_registry>` via
+The new style allows for arbitrary code organization, but typically has a folder named after the `labscript_device` with each device component in a different file (ie `labscript_devices.py`, `BLACS_workers.py`, etc).
+With this style, the folder requires an `__init__.py` file (which can be empty) as well as a `register_classes.py` file.
+This file imports :obj:`<labscript-utils:labscript_utils.device_registry>` via
 
 .. code-block:: python
 
@@ -56,4 +66,5 @@ This function informs **labscript** where to find the necessary classes during i
 Contributions to **labscript-devices**
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-If you decide to implement a labscript-device for controlling new hardware, we highly encourage you to consider making a pull-request to the **labscript-devices** repository in order to add your work to the **labscript-suite**. Increasing the list of supported devices is an important way for the **labscript-suite** to continue to grow, allowing new users to more quickly get up and running with hardware they may already have.
+If you decide to implement a labscript-device for controlling new hardware, we highly encourage you to consider making a pull-request to the **labscript-devices** repository in order to add your work to the **labscript-suite**.
+Increasing the list of supported devices is an important way for the **labscript-suite** to continue to grow, allowing new users to more quickly get up and running with hardware they may already have.

docs/source/devices.rst

@@ -7,7 +7,9 @@ Here is a list of all the currently supported devices.
 Pseudoclocks
 ~~~~~~~~~~~~
 
-Pseudoclocks provide the timing backbone of the labscript_suite. These devices produce hardware-timed clocklines that trigger other device outputs and acquisitions. Many pseudoclock devices also include other types of outputs, including digital voltage and DDS frequency synthesizers.
+Pseudoclocks provide the timing backbone of the labscript_suite.
+These devices produce hardware-timed clocklines that trigger other device outputs and acquisitions.
+Many pseudoclock devices also include other types of outputs, including digital voltage and DDS frequency synthesizers.
 
 .. toctree::
    :maxdepth: 2
@@ -22,7 +24,8 @@ Pseudoclocks provide the timing backbone of the labscript_suite. These devices p
 NI DAQS
 ~~~~~~~~~~~~
 
-The NI_DAQmx device provides a generic interface for National Instruments data acquisition hardware. This includes digital and analog voltage I/O. These input/outputs can be either static or hardware-timed dynamically changing variables.
+The NI_DAQmx device provides a generic interface for National Instruments data acquisition hardware.
+This includes digital and analog voltage I/O. These input/outputs can be either static or hardware-timed dynamically changing variables.
 
 .. toctree::
    :maxdepth: 2
@@ -32,7 +35,9 @@ The NI_DAQmx device provides a generic interface for National Instruments data a
 Cameras
 ~~~~~~~~~~~~
 
-The camera devices provide interfaces for using various scientific cameras to acquire hardware-timed images during an experiment. They are organized by the programming API the underlies the communication to the device. The "master" camera class which provides the core functionality and from which the others derive is the IMAQdx class.
+The camera devices provide interfaces for using various scientific cameras to acquire hardware-timed images during an experiment.
+They are organized by the programming API the underlies the communication to the device.
+The "master" camera class which provides the core functionality and from which the others derive is the IMAQdx class.
 
 .. toctree::
    :maxdepth: 2

docs/source/devices/andorsolis.rst

@@ -3,7 +3,8 @@ Andor Solis Cameras
 
 A labscript device for controlling Andor scientific cameras via the Andor SDK3 interface.
 
-Presently, this device is hard-coded for use with the iXon camera. Minor modifications can allow use with other Andor cameras, so long as they are compatible with the Andor SDK3 library.
+Presently, this device is hard-coded for use with the iXon camera.
+Minor modifications can allow use with other Andor cameras, so long as they are compatible with the Andor SDK3 library.
 
 .. autosummary::
    labscript_devices.AndorSolis.labscript_devices
@@ -13,7 +14,8 @@ Presently, this device is hard-coded for use with the iXon camera. Minor modific
 Installation
 ~~~~~~~~~~~~
 
-The Andor SDK is available from Andor as a paid product (typically purchased with the camera). It must be installed with the SDK directory added to the system path.
+The Andor SDK is available from Andor as a paid product (typically purchased with the camera).
+It must be installed with the SDK directory added to the system path.
 
 Detailed Documentation
 ~~~~~~~~~~~~~~~~~~~~~~

docs/source/devices/flycapture2.rst

@@ -1,7 +1,9 @@
 FlyCapture2 Cameras
 ===================
 
-This device allows control of FLIR (formerly Point Grey) scientific cameras via the `FlyCapture2 SDK <https://www.flir.com/products/flycapture-sdk/>`_ with the now deprecated PyCapture2 wrapper. In order to use this device, both the SDK and the python wrapper must be installed. Note that PyCapture2 only supports up to Python 3.6.
+This device allows control of FLIR (formerly Point Grey) scientific cameras via the `FlyCapture2 SDK <https://www.flir.com/products/flycapture-sdk/>`_ with the now deprecated PyCapture2 wrapper.
+In order to use this device, both the SDK and the python wrapper must be installed.
+Note that PyCapture2 only supports up to Python 3.6.
 
 The new FLIR SDK is supported using the :doc:`SpinnakerCamera labscript device <spinnaker>`.
 
@@ -15,21 +17,28 @@ Installation
 
 First ensure that the FlyCapture2 SDK is installed. 
 
-The python wrapper is available via FLIR and is only released for Python up to 3.6. It must be installed separately, pointed to the correct conda environment during install.
+The python wrapper is available via FLIR and is only released for Python up to 3.6.
+It must be installed separately, pointed to the correct conda environment during install.
 
 
-For GigE cameras, ensure that the network interface card (NIC) on the computer with the BLACS controlling the camera has enabled Jumbo Frames. That maximum allowed value (typically 9000) is preferable to avoid dropped frames.
+For GigE cameras, ensure that the network interface card (NIC) on the computer with the BLACS controlling the camera has enabled Jumbo Frames.
+That maximum allowed value (typically 9000) is preferable to avoid dropped frames.
 
 Usage
 ~~~~~
 
-Like the :doc:`IMAQdxCamera <IMAQdx>` device, the bulk of camera configuration is performed using a dictionary of kwargs, where the key names and values mirror those provided by the FlyCapture2 SDK interface. Which parameters can/need to be set depend on the communication interface. Discovery of what parameters are available can be done in three ways:
+Like the :doc:`IMAQdxCamera <IMAQdx>` device, the bulk of camera configuration is performed using a dictionary of kwargs, where the key names and values mirror those provided by the FlyCapture2 SDK interface.
+Which parameters can/need to be set depend on the communication interface.
+Discovery of what parameters are available can be done in three ways:
 
 1. Careful reading of the FlyCapture2 SDK docs.
 2. Mirroring the FlyCap Viewer parameter names and values.
 3. Connecting to the camera with a minimal configuration, viewing the current parameters dictionary, and copying the relevant values to the connection table (preferred).
 
-The python structure for setting these values differs somewhat from other camera devices in labscript, taking the form of nested dictionaries. This structure most closely matches the structure of the FlyCapture2 SDK in that each camera property has multiple sub-elements that control the feature. In this implementation, the standard camera properties are set using keys with ALL CAPS. The control of the Trigger Mode and Image Mode properties is handled separately, using a slightly different nesting structure than the other properties.
+The python structure for setting these values differs somewhat from other camera devices in labscript, taking the form of nested dictionaries.
+This structure most closely matches the structure of the FlyCapture2 SDK in that each camera property has multiple sub-elements that control the feature.
+In this implementation, the standard camera properties are set using keys with ALL CAPS.
+The control of the Trigger Mode and Image Mode properties is handled separately, using a slightly different nesting structure than the other properties.
 
 Below is a generic configuration for a Point Grey Blackfly PGE-23S6M-C device.
 

docs/source/devices/ni_daqs.rst

@@ -56,7 +56,8 @@ NI Multifunction DAQs generally provide hardware channels for
 :class:`StaticDigitalOut <labscript:labscript.labscript.StaticDigitalOut>`,
 :class:`AnalogOut <labscript:labscript.labscript.AnalogOut>`,
 :class:`DigitalOut <labscript:labscript.labscript.DigitalOut>`,
-and :class:`AnalogIn <labscript:labscript.labscript.AnalogIn>` labscript quantities for use in experiments. Exact numbers of channels, performance, and configuration depend on the model of DAQ used.
+and :class:`AnalogIn <labscript:labscript.labscript.AnalogIn>` labscript quantities for use in experiments.
+Exact numbers of channels, performance, and configuration depend on the model of DAQ used.
 
 .. code-block:: python
 
@@ -78,7 +79,9 @@ and :class:`AnalogIn <labscript:labscript.labscript.AnalogIn>` labscript quantit
 	AnalogOut('daq_ao0',daq,'ao0')
 	AnalogIn('daq_ai1',daq,'ai1')
 
-NI DAQs are also used within labscript to provide a :class:`WaitMonitor <labscript:labscript.labscript.waitmonitor>`. When configured, the `WaitMonitor` allows for arbitrary-length pauses in experiment execution, waiting for some trigger to restart. The monitor provides a measurement of the duration of the wait for use in interpreting the resulting data from the experiment.
+NI DAQs are also used within labscript to provide a :class:`WaitMonitor <labscript:labscript.labscript.waitmonitor>`.
+When configured, the `WaitMonitor` allows for arbitrary-length pauses in experiment execution, waiting for some trigger to restart.
+The monitor provides a measurement of the duration of the wait for use in interpreting the resulting data from the experiment.
 
 Configuration uses three digital I/O connections on the DAQ:
 
@@ -98,7 +101,9 @@ An example configuration of a `WaitMonitor` using a NI DAQ is shown here
 	# Necessary to ensure even number of digital out lines in shot
 	DigitalOut('daq_do1',daq,'port0/line1')
 
-Note that the counter connection is specified using the logical label `'ctr0'`. On many NI DAQs, the physical connection to this counter is PFI9. The physical wiring for this configuration would have port0/line0 wired directly to PFI9, with PFI1 being sent to the master pseudoclock retriggering system in case of timeout. If timeouts are not expected/represent experiment failure, this physical connection can be omitted.
+Note that the counter connection is specified using the logical label `'ctr0'`. On many NI DAQs, the physical connection to this counter is PFI9.
+The physical wiring for this configuration would have port0/line0 wired directly to PFI9, with PFI1 being sent to the master pseudoclock retriggering system in case of timeout.
+If timeouts are not expected/represent experiment failure, this physical connection can be omitted.
 
 
 Detailed Documentation

docs/source/devices/opalkellyXEM3001.rst

@@ -6,7 +6,9 @@ A pseudoclocking labscript device based on the OpalKelly XEM3001 integration mod
 Installation
 ~~~~~~~~~~~~
 
-Firmware (.bit) files for the FPGA are available `here <https://github.com/labscript-suite/opalkellyxem3001>`_ and should be placed in the labscript_devices folder along with the `CiceroOpalKellyXEM3001.py` file. The Opal Kelly SDK, which provides the python bindings, is also required. The python bindings will need to either be added to the PATH or manually copied to the site-packages of the virtual environment that BLACS is running in.
+Firmware (.bit) files for the FPGA are available `here <https://github.com/labscript-suite/opalkellyxem3001>`_ and should be placed in the labscript_devices folder along with the `CiceroOpalKellyXEM3001.py` file.
+The Opal Kelly SDK, which provides the python bindings, is also required.
+The python bindings will need to either be added to the PATH or manually copied to the site-packages of the virtual environment that BLACS is running in.
 
 Detailed Documentation
 ~~~~~~~~~~~~~~~~~~~~~~

docs/source/devices/prawnblaster.rst

@@ -30,9 +30,12 @@ The PrawnBlaster takes advantage of the specs of the Pico to provide the followi
 Installation
 ~~~~~~~~~~~~
 
-In order to turn the standard Pico into a PrawnBlaster, you need to load the custom firmware available in the `Github repo <https://github.com/labscript-suite/PrawnBlaster/tree/master/build/prawnblaster>`_ onto the board. The simplest way to do this is by holding the reset button on the board while plugging the USB into a computer. This will bring up a mounted folder that you copy-paste the firmware to. Once copied, the board will reset and be ready to go.
+In order to turn the standard Pico into a PrawnBlaster, you need to load the custom firmware available in the `Github repo <https://github.com/labscript-suite/PrawnBlaster/tree/master/build/prawnblaster>`_ onto the board.
+The simplest way to do this is by holding the reset button on the board while plugging the USB into a computer.
+This will bring up a mounted folder that you copy-paste the firmware to. Once copied, the board will reset and be ready to go.
 
-Note that this device communicates using a virtual COM port. The number is assigned by the controlling computer and will need to be determined in order for BLACS to connect to the PrawnBlaster.
+Note that this device communicates using a virtual COM port.
+The number is assigned by the controlling computer and will need to be determined in order for BLACS to connect to the PrawnBlaster.
 
 Usage
 ~~~~~

docs/source/devices/pulseblaster.rst

@@ -1,14 +1,19 @@
 Pulseblaster
 ============
 
-This labscript device controls the Spincore PulseblaserDDS-II-300-AWG. The Pulseblaster is a programmable pulse generator that is the typical timing backbone of an experiment (ie it generates the pseudoclock timing pulses that control execution of other devices in the experiment). This labscript device is the master implementation of the various Pulseblaster devices. Other Pulseblaster labscript devices subclass this device and make the relevant changes to hard-coded values. Most importantly, the `core_clock_freq` must be manually set to match that of the Pulseblaster being used in order for the timing of the programmed pulses to be correct (in the `labscript_device` and the `BLACS_worker`).
+This labscript device controls the Spincore PulseblaserDDS-II-300-AWG.
+The Pulseblaster is a programmable pulse generator that is the typical timing backbone of an experiment (ie it generates the pseudoclock timing pulses that control execution of other devices in the experiment).
+This labscript device is the master implementation of the various Pulseblaster devices.
+Other Pulseblaster labscript devices subclass this device and make the relevant changes to hard-coded values.
+Most importantly, the `core_clock_freq` must be manually set to match that of the Pulseblaster being used in order for the timing of the programmed pulses to be correct (in the `labscript_device` and the `BLACS_worker`).
 
 This particular version of Pulseblaster has a 75 MHz core clock frequency and also has DDS synthesizer outputs.
 
 Installation
 ~~~~~~~~~~~~
 
-Use of the Pulseblaster requires driver installation available from the manufacturer `here <https://www.spincore.com/support/>`_. The corresponding python wrapper, `spinapi <https://github.com/chrisjbillington/spinapi/>`_ is available via pip.
+Use of the Pulseblaster requires driver installation available from the manufacturer `here <https://www.spincore.com/support/>`_.
+The corresponding python wrapper, `spinapi <https://github.com/chrisjbillington/spinapi/>`_ is available via pip.
 
 .. code-block:: bash