Online documentationThis manual is also available in PDF format for offline viewing. Warning: Both this page and the offline manual are quite . . . incomplete. Table of ContentsIntroductionSpecial formattingFont type and color is used in this documentation to clarify and highlight some elements:
* These are a bit generic as jargon goes, so the highlighting is used to indicate the specific definition.
Neal Stephenson's writing notwithstanding, this approach seems preferable to making up words like wafflesnorker or spweeble mode to describe various aspects of the software.
ModesMezurit 2 starts in setup mode, which allows the user to configure DAQ and GPIB hardware and define virtual channels to be acquired and recorded. The terminal is works in setup mode, but is limited to certain functions. When switching to panel mode Mezurit 2 completes the parsing phase, during which it parses the channel definitions and generates a list of physical channels and gpib slots to be measured. The parsing phase occurs each time Mezurit 2 switches from setup mode to panel mode or between panels. The terminal is implemented as an instance of the Python interpreter running in a separate process from Mezurit 2 proper. Therefore, functions and variables defined in the terminal cannot be accessed by compute functions and vice versa. One advantage of this approach is that the terminal can hang, crash, or restart without affecting the time-sensitive data acquisition process. ThreadsMezurit 2 runs three threads in panel mode, not counting the terminal process:
Keyword definitions
|
| If: | ch(4) > 2.5 |
| Then: | fire_scope() wait(0.1) arm_trigger(0) |
| Result: | The scope will begin a scan when a sync signal represented by X4 rises above 2.5 V. The trigger will then rearm itself so that the data is refreshed every 0.1 seconds (assuming the scope is configured to scan for <0.1 seconds). |
Triggers can be also be started manually ("forced") by clicking the 
button or calling the force_trigger() terminal function or the force_trigger() trigger function.
Coming soon . . .
Coming soon . . .
The terminal provides a Python-based interface to Mezurit 2. Almost all aspects of the GUI can be controlled from the terminal, plus several "hidden" features only accessible from the terminal. In addition, all settings can be queried and modified using the get_var() and set_var() commands. The "key=value" syntax for these two functions matches that used in Mezurit 2's configuration files.
Example: Increase sweep rate by 10%
| Commands: | val = get_var('panel0_sweep1_rate_up') set_var('panel0_sweep1_rate_up={0:f}'.format(float(val) * 1.1)) |
| Result: | The first command returns the value of rsweep for the second sweep section on Panel 0, e.g. '0.500000' given rsweep = 0.5 V/s. The second line converts the queried string to a floating-point value, increases it by 10%, combines the result with the variable name, and sends the new string (e.g. 'panel0_sweep1_rate_up=0.550000'). |
In the previous example, the user must know the variable name to be modified a priori, specifically the appropriate panel id and the sweep id. These values can also be queried using get_panel() and get_sweep_id(), and then formatted into a variable name as in the following example.
Example: Easy variable name generation
| Channels: | ⋮ X2 = DAC(0, 0) / 100 X3 = DAC(0, 1) * 10 ⋮ |
| Commands: | pid = get_panel() sid = get_sweep_id(3) set_var('panel{0:d}_sweep{1:d}_scaled_up={2:f}'.format(pid, sid, 24.0)) |
| Result: | Assuming panel 0 is the active page, pid = 0 and sid = 1 because X3 is the second invertible channel overall. The full string passed to set_var() is 'panel0_sweep1_scaled_up=24.000000' which will set the upper limit for sweeping X3 to 24.0. |
The standard terminal commands are documented here. Additional features can be added to the terminal in two ways: user-defined terminal functions and "one-off" scripts:
New functions definitions can be placed in ~/.config/mezurit2/terminal.py (or equivalent, see Installed files) building on the existing set of commands. Once the changes are made, simply restart the terminal process using either the quit() command or the "Terminal | Restart" menu option. This option works best when there is some degree of generality in the functions to be added so that it can be used for multiple measurements.
Example: Function to repeat a megasweep at multiple temperatures (ver. 0.81+)
| Code: | def gigasweep_temperature (sweep_ch, step_ch, V0, V1, N, basefile, temps) : for T in temps : gpib(0, 24, 'T{0:f}'.format(T), eos=0x400|0xd) xleep(60) megasweep_up(sweep_ch, step_ch, V0, V1, N, basefile + '_{0:f}K.dat'.format(T)) clear_buffer(False, False) |
| Command: | gigasweep(1, 2, -10.0, 10.0, 40, 'dev01_run01', (1.4, 2.5, 5.0, 10.0, 20.0)) |
| Result: | The megasweep is run five times at the specified temperatures, which are sent to an Oxford Temperature Controller using a GPIB command. Mezurit 2 waits 60 seconds for the temperature to settle before beginning each measurement. The data is saved in five separate files with names like dev01_run01_1.40000K.dat. |
Another option is to place the desired commands in a custom script file, then run it via execfile(). The script will run in the current terminal as if a user had typed in each line directly. Note that, on its own, execfile() does not expand shortcuts such as ~ (relative paths are OK).
Example: Parametric megasweep
| Code: | fancysweep.py (save to a known location such as /home/yourusername) |
| Command: | execfile('/home/yourusername/fancysweep.py') |
| Result: | The sweep parameters are adjusted between voltage steps to produce a non-rectangular megasweep. See the script for details. |
One advantage of this approach is that a copy of the script can be saved along with each datfile as documentation. For example, the script used to record dev02_run03.dat could be saved alongside as dev02_run03_script.py. Another advantage is that the user does not have to remember what arguments to pass a custom function because every parameter must be mentioned explicitly in the script.
While some scripts may perform a measurement by simply sending a continuous stream of commands, it is often necessary to wait for certain conditions before continuing to the next step. This can be accomplished using the catch_* commands: catch_sweep() for sweeps, catch_scan_start() and catch_scan_finish() for scope scans, and catch_signal() for triggers.
Tip: Explicit synchronization is more reliable and precise than using xleep(). For example, while Mezurit 2 makes every effort to sweep at exactly the specified rate, jitter may creep in when starting and stopping due to synchronization between threads. Thus, waiting 1.0 seconds for a 1.0 second sweep could result in the script continuing on slightly "ahead of schedule."
Warning/Tip: These functions do not return until the specified event has occurred. If that event is never going to happen, i.e. due to user error, simply use the "Terminal | Abort" feature to regain control of the terminal.
Online manual
DAQ Hardware
Virtual Channels
Acquisition
DAC Controls
Scope
Triggers