Recent changes to ExampleSetup

ExampleSetup modified by Markus Ansmann

Markus Ansmann — Fri, 12 Oct 2018 05:49:52 -0000

--- v4
+++ v5
@@ -86,7 +86,7 @@

 **Performance**

-Since the *ExptScrpt Client* does not need to worry about displaying or storing the data, it's performance will not be impacted by potentially complex plotting functions or slow data storage access. Since the "Store Data" Requests can be sent to the *DataStrg Server* in a fire-and-forget manner, the overall system's data taking speed will not be impacted by the rate at which the data can be stored or displayed by the (potentially numerous) *Graphing Client*.
+Since the *ExptScrpt Client* does not need to worry about displaying or storing the data, its performance will not be impacted by potentially complex plotting functions or slow data storage access. Since the "Store Data" Requests can be sent to the *DataStrg Server* in a fire-and-forget manner, the overall system's data taking speed will not be impacted by the rate at which the data can be stored or displayed by the (potentially numerous) *Graphing Client*.

 Since Modules can have multiple LabRAD Requests "in flight" at the same time, execution can be parallelized and even pipelined to a large degree in a very straight forward manner. Many of the common headaches associated with these practices like race conditions, etc., are handled gracefully behind the scenes, since Requests are always executed atomically and serialized correctly within a Context.

ExampleSetup modified by Markus Ansmann

Markus Ansmann — Fri, 30 Jan 2015 23:40:25 -0000

--- v3
+++ v4
@@ -14,53 +14,88 @@
 || **Name** || **Module Type** || **Provides** ||
 ||----------||-----------------||--------------||
 || EXPT || N/A || Readings from and control mechanisms for the experiment ||
-|| RS232 Server || //Base Server// || Byte-level read and write access to COM ports ||
-|| GPIB Server || //Base Server// || Byte-level read and write access to a GPIB bus ||
-|| DataStrg Server || //Base Server// || Storage and retrieval of experimental datasets ||
-|| FnGen Server || //Abstraction Server// || Access to features of a function generator ||
-|| DAQ Server || //Abstraction Server// || Access to features of the data acquisition hardware ||
-|| Graphing Client || //Client// || Graphs of new data incoming to the DataStrg Server ||
-|| ExptScrpt Client || //Client// || Scripts to run the experiment ||
+|| RS232 Server || *Base Server* || Byte-level read and write access to COM ports ||
+|| GPIB Server || *Base Server* || Byte-level read and write access to a GPIB bus ||
+|| DataStrg Server || *Base Server* || Storage and retrieval of experimental datasets ||
+|| FnGen Server || *Abstraction Server* || Access to features of a function generator ||
+|| DAQ Server || *Abstraction Server* || Access to features of the data acquisition hardware ||
+|| Graphing Client || *Client* || Graphs of new data incoming to the DataStrg Server ||
+|| ExptScrpt Client || *Client* || Scripts to run the experiment ||

 Details
 -------
-===RS232 Server===
+
+**RS232 Server**
+
 Discovers the list of available COM ports on the computer it is running on and provides methods to open a port, choose the baud-rate and data format, send bytes, and read bytes. It does not know anything about the type of hardware connected.
-//This Module is written in Python, which makes access to COM ports easy through the pySerial package. Since COM ports are very low bandwidth interfaces, Python's execution performance is not a limiting factor for this task.//
-===GPIB Server===
+
+*This Module is written in Python, which makes access to COM ports easy through the pySerial package. Since COM ports are very low bandwidth interfaces, Python's execution performance is not a limiting factor for this task.*
+
+**GPIB Server**
+
 Gives access to a GPIB controller card, allowing the selection of a target address and the sending and receiving of raw data. Might do some basic device discovery by sending '*IDN?' commands to all addresses, but is otherwise unaware of the actual hardware connected and how it operates.
-//This Module is written in LabVIEW, since GPIB access is very convenient in this language using the VISA libraries.//
-===DataStrg Server===
+
+*This Module is written in LabVIEW, since GPIB access is very convenient in this language using the VISA libraries.*
+
+**DataStrg Server**
+
 Manages data storage by providing functions to create new datasets, list datasets, add and retrieve data points, store experimental parameters as meta-data, etc.
-//This Module is written in Python, where dynamic typing makes it straight forward to handle the different meta-data formats.//
-===FnGen Server===
-Maintains a list of all function generators hooked up to the LabRAD system through possibly multiple GPIB Servers running on many different computers. It creates a central location for access to the higher level functionality of these devices by name, i.e. "Output a 5kHz 0.5Vpp square wave on 'Input A'". These requests are turned into the required command strings and passed on to the correct //GPIB Servers//.
-//This Module is written in Python, because of its string assembly and parsing abilities.//
-===DAQ Server===
-Allows other LabRAD Modules to ask for the different readings provided by the experiment. It retrieves these by sending the correct command strings to the //RS232 Server// to tell the custom DAQ board to record voltages. It then parses the returned strings to extract the readings.
-//This Module is written in Python, because of its string assembly and parsing abilities.//
-===Graphing Client===
-Monitors the //DataStrg Server// for new datasets being created or existing ones being updated. It automatically shows plots of incoming data as it arrives in the DataStrg Server. It might provide the user with an interface to perform some quick on-the-fly data analysis, like fitting parabolas to extract maxima, or exponentials to gauge decay times. The //Graphing Client// can also be used to browse all existing datasets ever stored using the //DataStrg Server//.
-Since multiple copies of the //Graphing Client// can be run simultaneously on any computer connected to the Internet, collaborators can be watching the incoming data live and suggest changes to the runs in a teleconference.
-//This Module is written in Delphi for performance reasons and because Delphi programs compile into a stand-alone executable that can be shared easily with collaborators without requiring them to purchase or install other software. Alternatively, for small datasets, LabVIEW could be a natural choice for its plotting capabilities (for larger datasets, LabVIEW's plotting functions become extremely sluggish).//
-===ExptScrpt Client===
-Can either be a single script or a collection of scripts that send commands to the //FnGen Server// to set up the experimental parameters and request readings from the //DAQ Server//. The so collected data is then passed to the //DataStrg Server//.
-//This Module is written in Python, because of the simplicity and speed with which Python scripts can be developed.//
+
+*This Module is written in Python, where dynamic typing makes it straight forward to handle the different meta-data formats.*
+
+**FnGen Server**
+
+Maintains a list of all function generators hooked up to the LabRAD system through possibly multiple GPIB Servers running on many different computers. It creates a central location for access to the higher level functionality of these devices by name, i.e. "Output a 5kHz 0.5Vpp square wave on 'Input A'". These requests are turned into the required command strings and passed on to the correct *GPIB Servers*.
+
+*This Module is written in Python, because of its string assembly and parsing abilities.*
+
+**DAQ Server**
+
+Allows other LabRAD Modules to ask for the different readings provided by the experiment. It retrieves these by sending the correct command strings to the *RS232 Server* to tell the custom DAQ board to record voltages. It then parses the returned strings to extract the readings.
+
+*This Module is written in Python, because of its string assembly and parsing abilities.*
+
+**Graphing Client**
+
+Monitors the *DataStrg Server* for new datasets being created or existing ones being updated. It automatically shows plots of incoming data as it arrives in the DataStrg Server. It might provide the user with an interface to perform some quick on-the-fly data analysis, like fitting parabolas to extract maxima, or exponentials to gauge decay times. The *Graphing Client* can also be used to browse all existing datasets ever stored using the *DataStrg Server*.
+
+Since multiple copies of the *Graphing Client* can be run simultaneously on any computer connected to the Internet, collaborators can be watching the incoming data live and suggest changes to the runs in a teleconference.
+
+*This Module is written in Delphi for performance reasons and because Delphi programs compile into a stand-alone executable that can be shared easily with collaborators without requiring them to purchase or install other software. Alternatively, for small datasets, LabVIEW could be a natural choice for its plotting capabilities (for larger datasets, LabVIEW's plotting functions become extremely sluggish).*
+
+**ExptScrpt Client**
+
+Can either be a single script or a collection of scripts that send commands to the *FnGen Server* to set up the experimental parameters and request readings from the *DAQ Server*. The so collected data is then passed to the *DataStrg Server*.
+
+*This Module is written in Python, because of the simplicity and speed with which Python scripts can be developed.*

 Benefits
 --------
-===High Turn-Around===
-The //ExptScrpt Clients// do not need to worry about how the //FnGen Server// and the //DAQ Server// perform the requested actions or what happens to the data after it is passed on to the //DataStrg Server//. This makes the development of these clients extremely fast and clean allowing for a very high turn-around of new experiments.
-===Reduced Duplication of Effort===
+
+**High Turn-Around**
+
+The *ExptScrpt Clients* do not need to worry about how the *FnGen Server* and the *DAQ Server* perform the requested actions or what happens to the data after it is passed on to the *DataStrg Server*. This makes the development of these clients extremely fast and clean allowing for a very high turn-around of new experiments.
+
+**Reduced Duplication of Effort**
+
 Common functionality, like storing or plotting data, can be easily packaged into a separate LabRAD Module. This reduces the code necessary to implement these features separately in all locations where it is used.
-===Flexibility===
-Should the hardware layout of the experiment change, a new DAQ card, for example, can be swapped in and supported by the //DAQ Server// without a change in the interface that this Server provides to the System. Thus, all other parts of the system will remain functional (without even a recompile).
-===Performance===
-Since the //ExptScrpt Client// does not need to worry about displaying or storing the data, it's performance will not be impacted by potentially complex plotting functions or slow data storage access. Since the "Store Data" Requests can be sent to the //DataStrg Server// in a fire-and-forget manner, the overall system's data taking speed will not be impacted by the rate at which the data can be stored or displayed by the (potentially numerous) //Graphing Client//.
+
+**Flexibility**
+
+Should the hardware layout of the experiment change, a new DAQ card, for example, can be swapped in and supported by the *DAQ Server* without a change in the interface that this Server provides to the System. Thus, all other parts of the system will remain functional (without even a recompile).
+
+**Performance**
+
+Since the *ExptScrpt Client* does not need to worry about displaying or storing the data, it's performance will not be impacted by potentially complex plotting functions or slow data storage access. Since the "Store Data" Requests can be sent to the *DataStrg Server* in a fire-and-forget manner, the overall system's data taking speed will not be impacted by the rate at which the data can be stored or displayed by the (potentially numerous) *Graphing Client*.
+
 Since Modules can have multiple LabRAD Requests "in flight" at the same time, execution can be parallelized and even pipelined to a large degree in a very straight forward manner. Many of the common headaches associated with these practices like race conditions, etc., are handled gracefully behind the scenes, since Requests are always executed atomically and serialized correctly within a Context.
-===Maintainability===
+
+**Maintainability**
+
 Different programmers can service the different modules of the system independently. This reduces the burden on everyone to understand the entire system down to the last detail.

-==Next: [[QuickStart|Quick Start]] (for now)==
+**Next: [Quick Start](QuickStart) (for now)**
+
+ 

 ~ Markus Ansmann, Dec 12th, 2007

ExampleSetup modified by Markus Ansmann

Markus Ansmann — Fri, 30 Jan 2015 23:37:53 -0000

--- v2
+++ v3
@@ -3,11 +3,11 @@

 Connection Diagram
 ------------------
-[[img src=ExampleSetupNetwork.png alt=screenshot]]
+[[img src=ExampleSetupNetwork.jpg alt=screenshot]]

 Logical Diagram
 ---------------
-[[img src=ExampleSetupLogical.png alt=screenshot]]
+[[img src=ExampleSetupLogical.jpg alt=screenshot]]

 Overview
 --------

ExampleSetup modified by Markus Ansmann

Markus Ansmann — Fri, 30 Jan 2015 23:37:20 -0000

--- v1
+++ v2
@@ -3,11 +3,11 @@

 Connection Diagram
 ------------------
-> [[image:ExampleSetupNetwork.jpg]]
+[[img src=ExampleSetupNetwork.png alt=screenshot]]

 Logical Diagram
 ---------------
-> [[image:ExampleSetupLogical.jpg]]
+[[img src=ExampleSetupLogical.png alt=screenshot]]

 Overview
 --------
@@ -47,7 +47,8 @@
 Can either be a single script or a collection of scripts that send commands to the //FnGen Server// to set up the experimental parameters and request readings from the //DAQ Server//. The so collected data is then passed to the //DataStrg Server//.
 //This Module is written in Python, because of the simplicity and speed with which Python scripts can be developed.//

-==Benefits==
+Benefits
+--------
 ===High Turn-Around===
 The //ExptScrpt Clients// do not need to worry about how the //FnGen Server// and the //DAQ Server// perform the requested actions or what happens to the data after it is passed on to the //DataStrg Server//. This makes the development of these clients extremely fast and clean allowing for a very high turn-around of new experiments.
 ===Reduced Duplication of Effort===

ExampleSetup modified by Markus Ansmann

Markus Ansmann — Fri, 30 Jan 2015 23:36:10 -0000

LabRAD Example Setup

Connection Diagram

[[image:ExampleSetupNetwork.jpg]]

Logical Diagram

[[image:ExampleSetupLogical.jpg]]

Overview

Name	Module Type	Provides
EXPT	N/A	Readings from and control mechanisms for the experiment
RS232 Server	//Base Server//	Byte-level read and write access to COM ports
GPIB Server	//Base Server//	Byte-level read and write access to a GPIB bus
DataStrg Server	//Base Server//	Storage and retrieval of experimental datasets
FnGen Server	//Abstraction Server//	Access to features of a function generator
DAQ Server	//Abstraction Server//	Access to features of the data acquisition hardware
Graphing Client	//Client//	Graphs of new data incoming to the DataStrg Server
ExptScrpt Client	//Client//	Scripts to run the experiment

Details

===RS232 Server===
Discovers the list of available COM ports on the computer it is running on and provides methods to open a port, choose the baud-rate and data format, send bytes, and read bytes. It does not know anything about the type of hardware connected.
//This Module is written in Python, which makes access to COM ports easy through the pySerial package. Since COM ports are very low bandwidth interfaces, Python's execution performance is not a limiting factor for this task.//
===GPIB Server===
Gives access to a GPIB controller card, allowing the selection of a target address and the sending and receiving of raw data. Might do some basic device discovery by sending '*IDN?' commands to all addresses, but is otherwise unaware of the actual hardware connected and how it operates.
//This Module is written in LabVIEW, since GPIB access is very convenient in this language using the VISA libraries.//
===DataStrg Server===
Manages data storage by providing functions to create new datasets, list datasets, add and retrieve data points, store experimental parameters as meta-data, etc.
//This Module is written in Python, where dynamic typing makes it straight forward to handle the different meta-data formats.//
===FnGen Server===
Maintains a list of all function generators hooked up to the LabRAD system through possibly multiple GPIB Servers running on many different computers. It creates a central location for access to the higher level functionality of these devices by name, i.e. "Output a 5kHz 0.5Vpp square wave on 'Input A'". These requests are turned into the required command strings and passed on to the correct //GPIB Servers//.
//This Module is written in Python, because of its string assembly and parsing abilities.//
===DAQ Server===
Allows other LabRAD Modules to ask for the different readings provided by the experiment. It retrieves these by sending the correct command strings to the //RS232 Server// to tell the custom DAQ board to record voltages. It then parses the returned strings to extract the readings.
//This Module is written in Python, because of its string assembly and parsing abilities.//
===Graphing Client===
Monitors the //DataStrg Server// for new datasets being created or existing ones being updated. It automatically shows plots of incoming data as it arrives in the DataStrg Server. It might provide the user with an interface to perform some quick on-the-fly data analysis, like fitting parabolas to extract maxima, or exponentials to gauge decay times. The //Graphing Client// can also be used to browse all existing datasets ever stored using the //DataStrg Server//.
Since multiple copies of the //Graphing Client// can be run simultaneously on any computer connected to the Internet, collaborators can be watching the incoming data live and suggest changes to the runs in a teleconference.
//This Module is written in Delphi for performance reasons and because Delphi programs compile into a stand-alone executable that can be shared easily with collaborators without requiring them to purchase or install other software. Alternatively, for small datasets, LabVIEW could be a natural choice for its plotting capabilities (for larger datasets, LabVIEW's plotting functions become extremely sluggish).//
===ExptScrpt Client===
Can either be a single script or a collection of scripts that send commands to the //FnGen Server// to set up the experimental parameters and request readings from the //DAQ Server//. The so collected data is then passed to the //DataStrg Server//.
//This Module is written in Python, because of the simplicity and speed with which Python scripts can be developed.//

==Benefits==
===High Turn-Around===
The //ExptScrpt Clients// do not need to worry about how the //FnGen Server// and the //DAQ Server// perform the requested actions or what happens to the data after it is passed on to the //DataStrg Server//. This makes the development of these clients extremely fast and clean allowing for a very high turn-around of new experiments.
===Reduced Duplication of Effort===
Common functionality, like storing or plotting data, can be easily packaged into a separate LabRAD Module. This reduces the code necessary to implement these features separately in all locations where it is used.
===Flexibility===
Should the hardware layout of the experiment change, a new DAQ card, for example, can be swapped in and supported by the //DAQ Server// without a change in the interface that this Server provides to the System. Thus, all other parts of the system will remain functional (without even a recompile).
===Performance===
Since the //ExptScrpt Client// does not need to worry about displaying or storing the data, it's performance will not be impacted by potentially complex plotting functions or slow data storage access. Since the "Store Data" Requests can be sent to the //DataStrg Server// in a fire-and-forget manner, the overall system's data taking speed will not be impacted by the rate at which the data can be stored or displayed by the (potentially numerous) //Graphing Client//.
Since Modules can have multiple LabRAD Requests "in flight" at the same time, execution can be parallelized and even pipelined to a large degree in a very straight forward manner. Many of the common headaches associated with these practices like race conditions, etc., are handled gracefully behind the scenes, since Requests are always executed atomically and serialized correctly within a Context.
===Maintainability===
Different programmers can service the different modules of the system independently. This reduces the burden on everyone to understand the entire system down to the last detail.

==Next: [[QuickStart|Quick Start]] (for now)==

~ Markus Ansmann, Dec 12th, 2007