When moving to IVI drivers, it's vital to understand the important differences between
these two technologies. Your choice of development tool or developer company can
box you into supporting only one flavor of IVI. For instance, LabWindows/CVI supports
the development of IVI-C drivers only. Nimbus Driver Studio is the only product
available that supports the development of IVI-COM and IVI-C drivers.
While the table below provides a good summary of the differences between IVI-COM and IVI-C,
a complete discussion explaining each point is given in the following whitepaper:
Comparing IVI-COM and IVI-C.pdf
Feature
|
IVI-COM
|
IVI-C
|
|
.NET Support
|
No manual coding is required to support .NET applications.
Interchangeable .NET applications can easily be developed.
|
Special .NET attributes and method declarations are required in client applications.
Interchangeable .NET applications are not possible.
|
|
LabVIEW Support
|
IVI-defined functionality is accessed via native LabVIEW VIs, exactly as with IVI-C drivers.
Readability of code using Invoke Nodes and Property Nodes is superior to that of wrapped driver VIs.
All driver functionality, methods and properties, is accessible from the Class Browser.
Navigation of driver functionality is clearer and more convenient in the Class Browser than in the Function palette.
Property access is identical to IVI-C.
|
Palette icons for accessing driver functions are often ambiguous.
Development of unique icons is burdensome. Without unique icons, application code is difficult to understand at a glance.
Users must toggle between the Class Browser for accessing attributes and the Functions palette for accessing functions.
Users must download and run a separate tool to generate wrapper VIs.
Application code contains a mixture of wrapper VIs and Property Nodes.
|
|
LabWindows/CVI Support
|
IVI-defined functionality is accessed via native IVI-C class drivers, exactly as with IVI-C drivers.
Instrument-specific functionality is difficult to access.
|
IVI-defined functionality is accessed via native IVI-C class drivers.
Instrument-specific functionality access is simple and natively supported.
|
|
Interchangeability
|
Interchangeable applications require no 3rd party components.
A single driver can easily support more than one IVI instrument class.
Applications can easily access different IVI-defined class interfaces.
Applications can mix calls to IVI-defined functions and instrument-specific functions easily and clearly. Errors are reported at compile time.
|
Interchangeability requires proprietary class drivers, currently only available from a single supplier.
A single driver can only support a single IVI instrument class.
Mixing calls to IVI-defined functions and instrument-specific functions is error prone, and many common errors cannot be detected until runtime.
|
|
Deployment
|
Drivers are fully self-describing – only a single file needs to be imported by client applications.
Client applications do not require knowledge of where the driver is installed.
|
Drivers require a header file, a driver DLL, a library file, an .fp file, and a .sub file.
Application code must explicitly specify the location of DLL, header, and library files.
|
|
Function Hierarchy
|
Functions are located next to their associated attributes.
Function and attribute names are inherently scoped by their parent interface, allowing designers complete freedom in choosing meaningful names.
|
Functions and attributes are located in two completely different hierarchies.
All function and attribute names must be globally unique, often leading to confusing name collisions between instrument-specific and class-compliant names.
|
|
Attribute Access
|
Drivers provide simple and familiar “dot” syntax for accessing attributes.
The compiler reports many types of common programming errors.
Users enjoy a rich IntelliSense experience.
Very little typing is required for clients to access an attribute.
|
Attribute access rely upon special attribute accessor functions.
Many common errors cannot be detected until runtime.
IntelliSense is only marginally useful.
Even simple attribute access operations require a significant amount of typing.
|
|
Repeated Capabilities
|
Familiar collection interfaces clearly indicate what functionality applies to repeated capabilities.
Nested repeated capability access is intuitive.
|
Users have no indication as to which attributes apply to a repeated capability and which apply to the driver as a whole.
Accessing nested repeated capabilities require a special IVI-defined string-based syntax.
User must take care to pass the same repeated capability name to each function and attribute call.
|
|
Error Handling
|
Driver error objects contain rich error information that is automatically reported in almost all popular ADEs.
Errors in the driver automatically generate exceptions which cannot be ignored by the client.
|
Errors are reported as function return codes, which can easily be ignored by the application.
Application code must make explicit error checks after each driver call and then make a separate call into the driver to retrieve the error string.
|
|
Data Types
|
Arrays and strings are fully self-describing and require no additional parameters to carry size information.
Memory is always allocated by the driver, so the client need not know ahead of time how much data will be returned.
Related items can be returned as a single object.
|
Input arrays require an extra size parameter to be passed to the driver.
Output arrays require an extra buffer size parameter to be passed to the driver and an actual size parameter to be returned from the driver.
Output strings require an extra string length parameter to be returned from the driver.
Memory is always allocated by the client, so the application must know ahead of time how much data might be returned from the driver.
Struct parameters are not allowed or supported, so related items must always appear as separate parameters.
|
|
Remote Access
|
Accessing a driver across a process or network requires no additional development work for the driver developer or the application programmer.
|
No standard mechanism for cross-process or cross-machine access exists. Driver writers and application developers must resort to direct use of low-level Windows APIs.
|