LXI Newsletter
News New LXI Products Join Newsletter Lead Article


The Change in Remote Control from the Central Test Computer to
Distributed Systems

By Jochen Wolle, TSEP and Peter Plazotta, TSEP


  • Overview development of remote control
  • Hardware Standards
  • Software Standards
  • LXI – LAN Extensions for Instrumentation
  • LXI – „Extended Functions“ for distributed Systems
  • Time Synchronous Measurements (1588)
  • Event Messages
  • Applications
  • Summary

Overview Development of Remote Control

• Hardware Standards:



IVI Web Forum Question and Answer

In general why IVI-C, IVI.COM or IVI.NET?

Answered by Kirk Fertitta, Pacific Mindworks
for the
IVI Web Forum

Note:  Offering an IVI driver is a requirement for all LXI-conformant instruments, something you will find in the LXI Device Specification 2016, Section 6.1. The IVI Web Forum is hosted by the IVI Foundation.
It was created to answer the more practical questions that arise when using the IVI Drivers to program test systems. To see a list of the IVI Drivers, click here. To view this question/answer in the Forum, click here.


In general why IVI-C, IVI.COM or IVI.NET?


This is a pretty involved topic – and a contentious one, but I’ll share what I tell folks when building an IVI strategy.The most important factor is considering the development environment (ADE) that your customers primarily work in.

Few would argue that IVI.NET provides the best end-user experience for those working in a .NET environment, such as C# or VB.NET.However, IVI-COM drivers include .NET interop assemblies (i.e. .NET “wrappers”) that have provided a very good .NET end-user experience for many years.IVI-C drivers don’t fare as well in .NET, as they require the use of somewhat tedious attributes to call into the native C DLL.There are some vendor-specific wrapper generation tools for IVI-C in .NET, but there is no IVI standard mechanism for doing this and interchangeability across vendors isn’t really supported with IVI-C.

For end-users working in native code (i.e. unmanaged code, such as C/C++), then IVI-COM or IVI-C would probably be the best fit.One can generate special wrappers to expose an IVI.NETdriver to native code, but the presence of the .NET runtime in an unmanaged application can sometimes cause problems.It often works, but it would not be my first choice if I was targeting native code.For a C/C++ programmer, they would typically feel quite comfortable with a well-designed IVI-C driver.The attribute access model in IVI-C is pretty tedious, so care must be taken by the driver developer to ensure that commonly used attributes are wrapped in convenient Configure or Query methods.But, with this done, then C/C++ programmers should have little difficulty with IVI-C. As for IVI-COM in C/C++ environments, there is a certain class of users that might prefer using COM, but I would expect this to be a minority of test and measurement programmers.Importantly, using IVI-COM in pure C environments, such as LabWindows/CVI, is so difficult as to be impractical for most users.

Source code is also an important consideration, as the readability and overall accessibility of IVI driver source code has historically been an issue with a large number of IVI users.IVI.NETdrivers typically have far simpler source code than either IVI-COM or IVI-C.This is largely due to the simplicity of C# relative to C/C++.Both IVI-COM and IVI-C drivers suffer from some degree of source code inscrutability – and somewhat for different reasons.IVI-C drivers typically “black-box” some functionality into a special runtime DLL that ships with the driver. By contrast, IVI-COM drivers often expose all of their source code, which necessarily surfaces all of the dizzying complexities required to support Microsoft COM itself.

All that said, if, for some reason, you can only do one driver, well that’s a shame -- because you’re probably going to leave some users less than satisfied.But, in that situation, you could do an IVI-COM driver and provide a first-class user experience in nearly all important ADEs – all the way from good old Visual Basic 6 to C/C++ to .NET to LabVIEW.The one notable exception where IVI-COM falls apart is LabWindows/CVI.If, however, you can do more, then I would consider doing either IVI-COM with IVI-C or IVI.NET with IVI-C – you’ll give a familiar API to the traditional C user, a reasonable experience for the C++ user, and a first-class experience for the .NET user.

Thanks to all our readers.
Bob Helsel, Editor

Use the connection you already know!

New LXI Products

The LXI Consortium has certified more than 3897 instruments in over 329 product families since the specifications were first released in September 2005. Some of the recent LXI product introductions are highlighted below:

Keysight 34970A data acquisition / data logger switch 
The 34970A consists of a three-slot mainframe with a built-in 6 1/2 digit digital multimeter. Each channel can be configured independently to measure one of 11 different functions without the added cost or hassles of signal-conditioning accessories. Choose from eight optional plug-in modules to create a compact data logger, full-featured data acquisition system or low-cost switching unit. 

Tektronix 5 Series MSO Mixed Signal Oscilloscope
With a remarkably innovative pinch-swipe-zoom touchscreen user interface, the industry's largest high-definition display, and 4, 6, or 8 FlexChannel™ inputs that let you measure one analog or eight digital signals, the 5 Series MSO is ready for today’s toughest challenges, and tomorrow’s too. 

AMETEK Programmable Power/VTI Instruments 
The EX1401 delivers accuracies of ±0.20°C, 1000 V channel-channel isolation, built-in self-test capabilities, and independent 24-bit ADC’s per channel. Its ability to acquire data at 20K samples/second/channel allows its usage in high-speed temperature transient applications.

Textron Systems RFS340
High-Performance RF/Microwave source & vector signal generator
Textron Systems’ RF Synthesizers provide an unmatched combination of frequency coverage, power range, signal fidelity and switching speed in either a 2-slot VXI or 1U LXI® (Ethernet) format.

Kikusui Electronics PWR Series DC Power Supplies
The PWR-01 is a series of high performance, multifunctional, compact, wide-range DC power supplies. It consists of 12 models in total with 4 maximum voltage outputs (L, ML, MH, and H) and 3 maximum power outputs (400 W, 800 W, and 1200 W).

Tektronix 5 Series MSO Mixed Signal Oscilloscope
With a remarkably innovative pinch-swipe-zoom touchscreen user interface, the industry's largest high-definition display, and 4, 6, or 8 FlexChannel™ inputs that let you measure one analog or eight digital signals, the 5 Series MSO is ready for today’s toughest challenges, and tomorrow’s too.

Pickering’s New 2-slot USB/LXI modular chassis - model 60-104
This 2–slot USB/LXI modular chassis offers a small lightweight form factor, making it ideal for portable, benchtop, and space restrictive applications. The chassis is designed for desk or rack mounting and features remote control via USB or LXI Ethernet. 

R&S®NGE100 Power Supply Series
The R&S®NGE100 power supply series consists of robust, high-performance, affordable instruments.
-R&S®NGE102 with two, or -R&S®NGE103 with three channels

Chroma High Power DC Electronic Load Model 63200A series

  • Rated power:3kW, 4kW, 5kW, 6kW, 12kW, 18kW, 24kW, Max. 240kW (Parallel)
  • Voltage range: 150V, 600V, 1200V
  • Current range: 2,000A max. per unit
  • CC, CR, CV & CP operation modes
  • CR+CC, CR+CV, CC+CV complex modes



LXI Links

LXI Reference Design V1.30

New Guides for Using LXI

LXI Discovery Tool

youtube LXI Channel on YouTube

linkedin Join our LXI LinkedIn group

©2018 LXI Consortium, Inc.
PO Box 1016; Niwot, CO 80544
Publiished by Bode Enterprises, LLC