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

By Jochen Wolle, TSEP and Peter Plazotta, TSEP

Agenda

• 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:

Read more >>

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.

Question:

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

Answer:

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
www.lxistandard.org

Use the connection you already know!

New LXI Products

LXI Links