gotmc / ivi

Go-based implementation of the Interchangeable Virtual Instrument (IVI) standard

ivi

Go-based implementation of the Interchangeable Virtual Instrument (IVI) standard.

Overview

The IVI Specifications developed by the IVI Foundation provide standardized APIs for programming test instruments. This package is a partial, Go-based implementation of the IVI Specifications.

The main advantage of the ivi package is not having to learn the SCPI commands for each individual piece of test equipment. For instance, by using the ivi package both the Agilent 33220A and the Stanford Research Systems DS345 function generators can be programmed using one standard API. The only requirement for this is having an IVI driver for the desired test equipment.

If an ivi driver doesn't exist for a peice of test equipment that you want to use, please open an issue and/or submit a pull request. The IVI Specifications don't provide APIs for every type of test equipment (e.g., they don't specify an API for electronic loads) in which case a set of APIs will be developed as needed for new types of test equipment.

Development focus is currently on solidifying the APIs and creating a few IVI drivers for each instrument type.

IVI Driver Goal

Per Section 2.6 Capability Groups in IVI-3.1 Driver Architecture Specification:

The fundamental goal of IVI drivers is to allow test developers to change the instrumentation hardware on their test systems without changing test program source code, recompiling, or re-linking. To achieve this goal, instrument drivers must have a standard programming interface...Because instruments do not have identical functionality or capability, it is impossible to create a single programming interface that covers all features of all instruments in a class. For this reason, the IVI Foundation recognizes different types of capabilities – Inherent Capabilities, Base Class Capabilities, Class Extension Capabilities and Instrument Specific Capabilities.

IVI Specification Deviation

TL;DR: When developing the Go-based IVI drivers, follow the .NET methods and prototypes as much as possible.

As stated in Section 1.5 Conformance Requirements of the IVI-3.1: Driver Architecture Specification, Revision 3.8, "IVI drivers can be developed with a COM, ANSI-C, or .NET API." In general, the Go method signatures try to be as close to the .NET signatures as possible. However, given the desire to write idiomatic Go, where necessary and where it makes sense, the Go-based IVI drivers deviate from the detailed IVI Specifications at times.

For instance, since Go does not provide method overloading, the .NET method prototypes cannot be followed in all cases. For example, in the IVI-4.2 IviDmm Class Specification, the .NET method prototypes show two Configure methods with different function signatures based on whether auto-range is specified or a manual range value is provided.

void Configure(MeasurementFunction measurementFunction,
               Auto autoRange,
               Double resolution);

void Configure(MeasurementFunction measurementFunction,
               Double range,

               Double resolution);

However, Go isn't C, so the Go-based IVI drivers don't have to rely on defined values, such as specific negative numbers representing auto-range (e.g., -1.0 = auto range on) and positive numbers representing the user specified manual range. Using the same example, below is the C prototype for Configure, where Range is a ViReal64 and negative values provided defined values.

ViStatus IviDmm_ConfigureMeasurement (ViSession Vi,
                                      ViInt32 Function,
                                      ViReal64 Range,
                                      ViReal64 Resolution);

Because of these differences, the Go function signatures may deviate from the IVI Specifications, when required and where it makes sense to enable writing idiomatic Go. Using the same example, below is the function signature for ConfigureMeasurement in Go.

ConfigureMeasurement(
    msrFunc MeasurementFunction,
    autoRange AutoRange,
    rangeValue float64,
    resolution float64,
) error

MeasurementFunction and AutoRange are user-defined types with enumerated constant values. Note: the function parameter rangeValue is used instead of range, since range is a reserved keyword and cannot be used as an identifier in Go.

type MeaurementFunction int

const (
	DCVolts MeasurementFunction = iota
	ACVolts
    ...
	Period
	Temperature
)

type AutoRange int

const (
	AutoOn AutoRange = iota
	AutoOff
	AutoOnce
)

Installation

$ go get github.com/gotmc/ivi

Usage

The ivi package requires receiving an Instrument interface. The following gotmc packages meet the Instrument interface:

• visa — Calls lxi or usbtmc as needed, so that you can identify instruments using a VISA resource address string.
• lxi — Used to control LXI enabled instruments via Ethernet.
• usbtmc — Used to control USBTMC compliant instruments via USB.
• prologix — Used to communicate with instruments using a Prologix GPIB controller.
• asrl — Used to control intstruments via serial.

Examples

Examples can be found at https://github.com/gotmc/ivi-examples.

Documentation

Documentation can be found at either:

• https://godoc.org/github.com/gotmc/ivi
• http://localhost:6060/pkg/github.com/gotmc/ivi/ after running $ godoc -http=:6060

Contributing

Contributions are welcome! To contribute please:

1. Fork the repository
2. Create a feature branch
3. Code
4. Submit a pull request

Testing

Prior to submitting a pull request, please run:

$ make check
$ make lint

To update and view the test coverage report:

$ make cover

License

ivi is released under the MIT license. Please see the LICENSE.txt file for more information.

ivi's Issues

Add option to reset when creating new instrument

The signature for the New function should be changed from New(address string) to New(address string, reset bool) so that users can select whether or not to reset the device when creating a new IVI instrument.

Current and Voltage swapped?

I guess there should be "VOLT" in the voltage function and CURR for the current function?

ivi/dcpwr/keysight/e36xx/measurement.go

Line 25 in 6c31b48

cmd := fmt.Sprintf("MEAS:CURR? %s", ch.Name())

Add IVI driver for Keysight 35670 DSA

Even though the IVI Foundation hasn't defined a standard for DSAs, I need to create one based on the 35670.

Refactor New for E36xx to handle different types of DCPwr instruments

If a single driver is going to handle multiple models, I'll need to implement one or possibly multiple of the following new functions:

1. Have specific new functions for each supported model, such as NewE3631A(inst) instead of New(inst)
2. Have a NewQuery(inst) function that queries the instrument and confirms it is supported.
3. Have a New(inst, model) function that specifies the model of the instrument to create.

In all of these, how do I handle passing in an option to reset the device? Is that always a boolean that is provided? What if I want to specify NewE3631A(inst) and I also want to query the device to ensure it actually that? I could simply mandate that a query is always performed.

Eliminate duplicate *IDN? calls

The inherent methods that call *IDN? should only call *IDN? once and then cache all results—mfr, model, s/n, etc.

Add ability to query ID when creating a new instrument

Section 6.16 Initialize in IVI-3.2: Inherent Capabilities Specification states that the Initialize function has an IdQuery boolean parameter that queries the instrument for its ID (*IDN?) and verifies that the IVI specific driver supports the particular instrument model.

Refactor IVI driver for Fluke 45 DMM

Add IVI driver for Keysight 33500B Series function generator

Fix DS345 burst rate trigger

The DS345 driver leaves the internal trigger set to single when configuring a burst currently.

Refactor HP and Agilent to Keysight

I plan on standardizing all HP and Agilent equipment to be Keysight since that is the name now being used by the company.

Update driver for Keysight 3446x DMM

Refactor code and add functionality to the IVI driver.

Add IVI driver for Agilent MSO-X 3024A and DSO-X 3024A oscilloscopes

Replace Instrument interface with io.ReadWriter interface

Should we replace the Instrument interface with io.ReadWriter interface? Stated differently, do we really need the StringWriter and Querier interfaces?

type Instrument interface {
	Read(p []byte) (n int, err error)
	Write(p []byte) (n int, err error)
	StringWriter
	Querier
}

type StringWriter interface {
	WriteString(s string) (n int, err error)
}

type Querier interface {
	Query(s string) (value string, err error)
}

I think the only reason I'm using the StringWriter and Querier interfaces is to handle automatically adding the command termination. Is that true? What about using the Prologix GPIB controller? Would that work without the StringWriter and Querier interfaces?

Add IVI driver for E4411B spectrum analyzer

Make command line terminator a variable

Right now all SCPI command strings include \n as the command line terminator. What if an instrument doesn't expect a newline as the SCPI terminator? For the Prologix GPIB, the line terminations are stripped by the GPIB controller and then a terminator is added based on the ++eos command setting.

One option is to include a terminator that can be set for the instrument instead of just hardcoding \n. Ideally the IVI driver has the proper line terminator for that driver. Although, I don't know if the line termination could need to change for the same piece of test equipment based on the interface used to communicate (i.e., GPIB vs LXI vs ASRL vs USBTMC).

Would you accept a DC load class, even if not speced by IVI

As far as I can see DC loads are not covered by IVI.

Would you accept a PR anyways?

Add timeouts

Need to have timeouts for connecting to devices using VISA or directly using LXI or USBTMC. This might be something that needs to be added to the other packages.

Add IVI driver for Agilent E4980AL LCR meter