QCoDeS Documentation

The following features were added or improved in version 0.1.6:

• Parameter Incrementing: Added an increment function to Parameter objects.
• Data Validation: The validator now supports numpy boolean types.
• IVVI: Added a function to round floats to the specific DAC resolution.
• Plotting Configuration: Notebook detection has been removed; top-level plotting library imports are now handled via configuration.
• Slack Bot: General improvements to the Slack bot integration.

Version 0.1.7 introduced several new drivers and performance enhancements:

New Drivers:

• Oxford Kelvinox
• Oxford ILM 200 Helium Level Meter
• IPS120 Magnet
• AMI430
• Tektronix awg5200

Improvements:

• Fixes for the DecaDac driver.
• Faster qdac performance.
• Benchmark for Keysight DMM software trigger.
• Support for IVVI triggers.
• Improved PyQtGraph performance.

The QCoDeS configuration module has been moved to disambiguate it from the currently active configuration.

• Configuration Module: Use qcodes.configuration to access the module.
• Active Configuration: Use qcodes.config to access the current active configuration.

QCoDeS has introduced generic arguments to several core classes to improve IDE integration and static type checking:

• InstrumentModule and InstrumentChannel: Now accept an optional generic argument to specify the type of the parent instrument.
• Parameter classes: ParameterBase, Parameter, ParameterWithSetpoints, DelegateParameter, ArrayParameter, and MultiParameter now take two optional generic arguments. This allows the data type and the bound instrument type to be fixed statically, enabling type checkers to know the return type of parameter.get(), the input type of parameter.set(), and the type of parameter.instrument.

The 0.3.0 release introduced several improvements to how data is saved and stored:

• Heterogeneous Arrays: You can now store arrays of different lengths together in a single data saving operation.
• Complex Numbers: Support for storing complex numbers has been added.
• Automatic Type Inference: The system now automatically infers the appropriate SQLite storage type for parameters.

The doNd functions have been optimized:

1. Redundant Setpoints: The dond function now avoids setting parameters with values that are already set, which improves performance during multi-dimensional measurements.
2. Manual Delay Handling: doNd functions now manually wait the delay between setpoints instead of relying on the post_delay attribute of setpoint parameters. This prevents unintentional slowdowns when the step delay of a setpoint parameter is significantly lower than the delay between measurement step points passed into the doNd functions.

An Instrument is the primary abstraction for hardware. It handles underlying communication and lists all available Parameters and Functions.

Common subclasses include:

• IPInstrument: For instruments controlled via IP.
• VisaInstrument: For instruments using the VISA protocol.
• MockInstrument: Used for simulation. It connects to a Model that mimics a serialized communication channel, allowing you to test code without physical hardware.

A Parameter represents a single state variable. Most parameters belong to an Instrument and are tied to specific hardware commands.

Key characteristics:

• Getters/Setters: A parameter must define at least a getter (to read) or a setter (to write). It does not need both.
• Gettable Parameters: Can return a single value or a collection (e.g., multiple named values or arrays) to allow saving raw and calculated data simultaneously.
• Settable Parameters: Take a single value. They can be sliced to create a SweepFixedValues object for automated sweeps.
• Arbitrary Logic: Parameters can be used to execute arbitrary functions, such as combining multiple gate voltages for a diagonal sweep.