An Introduction to LabOne Modules

All of the LabOne APIs are based on a central API called ziCore. This allows them to share a common structure which provides a uniform interface for programming Zurich Instruments devices. The aim of this section is to familiarize the user with the key ziCore programming concepts which can then be used in any of the LabOne APIs (LabVIEW, MATLAB, Python, .Net, and C).

Software Architecture

Each of the ziCore-based APIs is designed to have a minimal code footprint: They are simply small interface layers that use the functionality derived from ziCore, a central C++ API. The derived API interfaces (LabVIEW, MATLAB, Python, .NET and C) provide a familiar interface to the user and allow the them to receive and manipulate data from their instrument using the API language’s native data types and formats. See LabOne Software Architecture for an overview of the LabOne software architecture.

ziCore Modules

In addition to the usual API commands available for instrument configuration and data retrieval, e.g., setInt, poll), ziCore-based APIs also provide a number of so-called Modules: high-level interfaces that perform common tasks such as sweeping data or performing FFTs.

The Module’s functionality is implemented in ziCore and each derived high-level API simply provides an interface to that module from the API’s native environment. This design ensures that the user can expect the same behavior from each module irrespective of which API is being used; if the user is familiar with a module available in one high-level programming API, it is quick and easy to start using the module in a different API. In particular, the LabOne User Interface is also based on ziCore and as such, the user can expect the same behavior using a ziCore-based API that is experienced in the LabOne User Interface, see Figure 1.

Figure 1. The same results and behavior can be obtained from Modules in any ziCore-based interface; Sweeper Module results from the LabOne MATLAB API (left) and the LabOne User Interface (right) using the same Sweeper and instrument settings.

The modules currently available in ziCore are:

The Sweeper Module for obtaining data whilst performing a sweep of one of the instrument’s setting, e.g., measuring a frequency response.
The Data Acquisition Module for recording instrument data asynchronously based upon user-defined triggers.
The Device Settings Module for saving and loading instrument settings to and from (XML) files.
The PID Advisor Module for modeling and simulating the PID incorporated in the instrument.
The Scope Module for obtaining scope data from the instrument.
The Impedance Module for performing impedance measurements.
The Multi-Device Synchronisation Module for synchronizing the timestamps of multiple instruments.
The AWG Module for working with the AWG.
The Precompensation Advisor Module also for working with the AWG.

In addition to providing a unified-interface between APIs, modules also provide a uniform work-flow regardless of the functionality the module performs (e.g., sweeping, recording data).

An important difference to low-level ziCore API commands is that Modules execute their commands asynchronously, see Synchronous versus Asynchronous Commands .

Synchronous versus Asynchronous Commands

The low-level API commands such as setInt and poll are synchronous commands, that is the interface will be blocked until that command has finished executing; the user cannot run any commands in the meantime. Another feature of `ziCore’s Modules is that each instantiation of a Module creates a new Thread and, as such, the commands executed by a Module are performed asynchronously. Asynchronous means that the task is performed in the background and the interface’s process is available to perform other tasks in the meantime, i.e., Module commands are non-blocking for the user.

Converting LabOne’s "systemtime" to Local Time

Data returned by Core Modules, for example the data of a single sweep, contain a header with a systemtime; field whose value is the POSIX time in microseconds at the point in time when the data was acquired. It may correspond to the start of data acquisition or the end, depending on the module, but will be consistent for all objects returned from one module. In order to help convert this timestamp to an API environment’s native time format there are utility functions in the LabOne APIs, where appropriate the example code in the function’s docstring demonstrates their use. Please check the utility function of the respective API for more details.