Understanding IVI-C Driver Development Options

Standalone IVI-C drivers are created by running the New Project Wizard and selecting IVI-C Driver. Standalone IVI-C drivers are developed using native C++ code without any reliance on an underlying IVI-COM driver. These drivers have easy-to-read source code that uses the C++ Standard Library, instead of COM and the Active Template Library (ATL), as is used with IVI-C wrappers on IVI-COM drivers. This has a number of important advantages, including making it much easier for the end user to browse the source code and potentially understand more about how the instrument works. It also makes the debugging experience (for developers and end users) much more intuitive.

Standalone IVI-C drivers will often use the VISA library for instrument communication and Nimbus can be instructed to automatically implement message-based IVI-C drivers using standard VISA library functions such as viPrintf, viScanf, and viQueryf.

Important

When choosing to develop a standalone IVI-C driver, it is important to realize that the standalone IVI-C driver cannot be linked to an IVI-COM driver or IVI.NET driver in the future. Once created, standalone IVI-C drivers must always be developed, implemented, and maintained independently of any other driver (IVI-COM or IVI.NET), even all of the drivers are being developed for the same instrument. For this reason, it is advisable to consider the benefits of creating an IVI-C driver linked to IVI-COM or IVI.NET if one of those driver types may be desired for the same instrument.

IVI-C wrappers on IVI-COM drivers are created by running the New Project Wizard and selecting IVI-COM Driver and then enabling IVI-C wrapper support on the Features page of the New IVI-COM Driver Wizard.

IVI-C wrappers on IVI-COM drivers expose both the IVI-C and IVI-COM driver interfaces from a single DLL. All of the functionality of the driver is typically implemented in the IVI-COM methods and properties and Nimbus automatically generates IVI-C entry points that simply delegate to the underlying IVI-COM implementation.

IVI-C wrappers can be developed very rapidly as part of an IVI-COM driver because Nimbus automatically adds functionality to the IVI-C wrapper as the driver developer adds functionality to the IVI-COM driver. Moreover, Nimbus keeps the IVI-C wrapper functions synchronized with the IVI-COM methods. For instance, changing a method name or removing a parameter in the IVI-COM Driver Designer causes Nimbus to automatically effect the corresponding change to the IVI-C function or parameter.

The primary advantage that IVI-C wrappers on IVI-COM have is that in nearly all cases, only a single implementation is required. For non-messaged-based drivers that cannot leverage the auto-generated VISA-based features of Nimbus, manual implementation of methods and properties is required. This manual implementation code need only be implemented once -- in the IVI-COM driver, and the IVI-C wrapper code simply delegates to the single IVI-COM implementation.

Similarly, any customizations to the driver initialization and shutdown sequence need only be implemented once in the IVI-COM driver and the IVI-C wrapper can leveraged all of that implementation.

The primary disadvantage of IVI-C wrappers on IVI-COM is that the source code is dizzingly complex. Since all of the implementation code is implemented in the IVI-COM driver, both the driver developer and the end user must contend with all of the complexities of COM and ATL, both of which are very unfamiliar to most developers and end users.

In addition to the inherent complexities of COM itself are the mechanics of delegating from IVI-C functions to IVI-COM methods. This involves translating from COM data types to and from IVI-C data types. These translations also come with a performance penalty which is not always insignificant. For instance, the memory models of IVI-COM and IVI-C are "opposite" of one another in that memory for output parameters is allocated by the caller in IVI-C (the client program) and by the callee (the driver method) in IVI-COM. Bridging those two memory models often requires performing extra buffer copies, which can become considerable when passing large amounts of data into and out of drivers.

In spite of its shortcomings, building IVI-C wrappers on IVI-COM drivers has been a very popular and successful feature for many driver developers using Nimbus for many years. It remains a very viable option worthy of consideration.

IVI-C drivers can also be linked to an IVI.NET driver and developed simultaneously with the IVI.NET driver in an analagous fashion to IVI-C wrappers being developed simultaneously with an IVI-COM driver. IVI-C drivers linked to IVI.NET are structurally identical to standalone IVI-C drivers -- the internals of the driver project, the unit test project, the help project, and the setup project are exactly the same as if the IVI-C driver was being developed on its own.

IVI-C drivers are linked to IVI.NET in the sense that adding methods and properties to an IVI.NET driver automatically creates a corresponding function or attribute in the linked IVI-C driver, just as with IVI-C wrappers on IVI-COM. This gives IVI-C drivers linked to IVI.NET much of the same productivity gains as IVI-C wrappers on IVI-COM -- design data is entered in one place and rendered in both drivers.

The key difference between developing IVI-C drivers linked to IVI.NET and IVI-C wrappers on top of IVI-COM is that the implementation code is completely indepedent between IVI-C drivers linked to IVI.NET and their IVI.NET driver counterpart. Unlike IVI-C wrappers on IVI-COM where Nimbus would generate implementation code in the IVI-COM driver and have the IVI-C wrapper delegate, Nimbus generates two completely independent implementations for linked IVI-C and IVI.NET drivers. For message-based devices, the IVI.NET implementation is realized using VISA.NET functions and an independent implementation is realized using VISA-C functions in the linked IVI-C driver.

Since IVI-C drivers linked to IVI.NET are structurally identical to standalone IVI-C drivers, this option has the advantages of both approaches -- the source code simplicity of standalone IVI-C along with the design-time productivity of IVI-C wrappers on IVI-COM.

Also like their standalone counterparts, IVI-C drivers linked to IVI.NET inherit some of the same disadvantages. The key disadvantage is that manually implemented functionality must be manually implemented in both the IVI.NET driver and IVI-C driver -- no code is shared between the two implementations. This manual implementation code might simply be a few methods and properties, or, for non-message-based devices, it might be all of the methods and properties in the driver. Even for message-based devices which leverage the auto-implementation features of Nimbus, any customizations to the initialization and shutdown sequence must be duplicated in both the IVI.NET and IVI-C drivers.

The table below summarizes many of the important differences between the three options for build IVI-C drivers with Nimbus.