Nimbus 2 represents a massive step forward in IVI driver development technology. The period over which Nimbus 2 was developed saw numerous changes in core technologies on which IVI drivers depend.
Microsoft introduced the Windows Vista® platform and 64-bit systems became widely used. Visual Studio 2005 and Visual Studio 2008 brought new integration opportunities as well as new challenges
for the Pacific MindWorks team. In addition, various IVI and LXI specifications have been added and extensively modified.
Nimbus 2 leverages the most successful features of our widely popular Nimbus 1 product and re-introduces them in a completely new platform that accurately tracks the latest Microsoft, IVI, and LXI requirements.
All of this has been done in a way that preserves the existing Nimbus 1 driver code base.
Major Features
Complete Visual Studio Integration
Driver development in Nimbus 2 is done completely within the Visual Studio IDE. No longer do developers use a standalone application, such as the Nimbus 1 Driver Designer,
to create their driver and then export to Visual Studio. Rather, the driver project is created, designed, implemented, tested, and documented all within the Visual Studio IDE.
In fact, the standalone Driver Designer application no longer even exists in Nimbus 2.
Visual Studio 2005 and 2008 Support
Nimbus 2 offers a custom unit testing engine that is built on top of the industry-standard NUnit framework. The user interface for creating and executing tests is now completely
integrated into the Visual Studio IDE, as opposed to the Nimbus 1 approach of linking to the external NUnit GUI. This integration greatly accelerates the edit-test-debug cycle.
New Help Editor
Nimbus 1 offered very limited help content formatting and editing options. Nimbus 2 completely reverses that deficiency by bringing full fidelity help editing to the driver developer.
The Nimbus 2 help designer harnesses the native Visual Studio HTML editor to allow developers to incorporate arbitrarily complex HTML content, including advanced formatting, tables,
and hyperlinks. A live preview pane allows the developer to immediately view the rendered help page without explicitly generating or compiling the help project.
Native 64-bit Driver Support
Nimbus now supports the development and deployment of 64-bit IVI drivers. The IVI specifications now prescribe specific requirements for installing IVI drivers on 64-bit system.
The new IVI installer generator and Setup Designer include special features for building installers that properly deploy 32-bit and 64-bit drivers on 64-bit machines.
MATLAB Driver Generation
Pacific MindWorks has teamed with The MathWorks® to provide completely automated generation of MATLAB® drivers from within your Nimbus 2 driver project. A single project setting
controls whether or not Nimbus generates the MATLAB driver and incorporates it into the driver installer. These MATLAB drivers leverage the latest IVI and COM features of MATLAB
itself to ensure seamless integration for application developers working within the MATLAB IDE.
Greatly Improved Compilation Speed
The C++ driver code generated by Nimbus as well as the underlying Nimbus Template
Library (NTL) have both been re-engineered to give a dramatic reduction in the time
it takes to compile a Nimbus driver. Driver development naturally involves a great
number of edit-compile-test cycles and the compile stage was almost always the bottleneck
in the overall process. With the shorter compile times of Nimbus 2 drivers, developers
enjoy a marked increase in overall driver development productivity.
Mixed-Mode Debugging
Most Nimbus users rely primarily on the C# unit tests for exercising their driver. Yet, these tests suffered from a grave flaw in Visual Studio 2003 -- they could not be used
to debug into the driver itself. Indeed, the mixed-mode debugging feature of Visual Studio 2003 (the ability to single-step from .NET code into the native C++ driver code) was
simply too slow to be usable at all. With Visual Studio 2005 and the .NET 2.0 framework, this has changed dramatically. Nimbus 2 users working with Visual Studio 2005 or later
will find that they can set a breakpoint in their C# unit test and step into their driver code as quickly and seamlessly as if all of the code were in C#. This improvement,
arguably as much as any other in all of Nimbus 2, represents an enormous step forward in driver developer productivity.
Improved Multi-Personality Support
In Nimbus 1, multi-personality drivers had to be managed as separate Nimbus projects and separate Visual Studio projects. In Nimbus 2, a driver and its personalities
are managed as a single Nimbus project and a single Visual Studio solution. This greatly simplifies the development and management of multi-personality drivers. In
addition, since the driver is directly associated with its personalities, more advanced code-roundtripping and validation can be performed across the driver as a whole.
Help Templates
Nimbus 2 help templates allow developers to customize the look and feel of their driver help files and then save those customizations as templates for other driver projects.
Standardized branding, colors, fonts, graphics, boilerplate content and much more can be incorporated into a help template and associated with a specific driver project.
This facilitates uniformity in driver help files produced across organizations. Nimbus 2 ships with two pre-built help templates -- one that uses the standard Visual Studio 2003
styling (as in Nimbus 1) and another that uses the new help format seen in Visual Studio 2005 and Visual Studio 2008.
New Hierarchical Designers
Driver developers working in Nimbus 2 can now design their drivers primarily using an intuitive hierarchical view of the driver methods and properties.
This view presents the driver API just as end-users will see it with IntelliSense. Drag-and-drop is fully supported, making driver design and refactoring much simpler and faster.
New IVI-C Designer
In Nimbus 1, there was no mechanism for viewing the IVI-C wrapper hierarchy in its entirety. A single textbox with a path-like syntax for the IVI-C function tree
location was all that the developer had to infer the hierarchy. In Nimbus 2, a first class hierarchical editor is available that presents a single view of the entire
IVI-C API. This makes it much simpler to edit and review the driver's IVI-C hierarchy. As with the new IVI-COM designer, the Nimbus 2 IVI-C designer fully supports
drag-and-drop and other convenient editing features.
IVI-C Driver Unit Testing
Nimbus 1 provided a very powerful mechanism for generating and managing C# unit tests for IVI-COM drivers. However, no direct support for testing the IVI-C wrapper was provided.
With Nimbus 2, native C language unit tests are automatically generated by Nimbus. These tests exercise the IVI-C wrapper functions and attributes and use the popular WinUnit
testing engine for running the tests.
New Driver Installer Designer
The Nimbus 2 driver installer features continue to build upon Microsoft's WiX (Windows Installer XML) . In order to allow users to customize their driver installer, Nimbus 2 now
provides a graphical editor that displays all of the standard IVI folders on an end user system and allows the driver developer to add files and folders to the installer by
simply dragging and dropping items from Windows Explorer. Driver developers can customize the Start Menu as well as specify assemblies in the Global Assembly Cache (GAC).
Nimbus uses automatic code roundtripping directly on the WiX source code files so that driver developers are freed from having to confront WiX when customizing their installer.
IVI-C Class Driver Generation
Nimbus 2 offers the ability to generate a fully functional IVI-C class driver for an instrument class. IVI-C drivers cannot be used interchangeably without a class driver, and these had to be authored by hand prior to Nimbus 2.
New I/O Object
All of the instrument I/O functions in Nimbus 2 have been consolidated under a single I/O object that can be accessed anywhere in a driver implementation using a
very simple syntax. This arrangement takes much better advantage of IntelliSense so that the suite of available I/O functions is much more accessible. In addition,
the new I/O object includes numerous new functions for performing powerful sprintf-style formatting of instrument commands. These new functions provide direct support
for COM data types, such as SAFEARRAYs and BSTRs, so that driver implementation code need not bother with tedious conversions.
Other Improvements
Simplified Install
Previous versions of Nimbus required a separate installation of specialized components, such as NUnit, WiX, and H2Reg. Nimbus now installs almost all required components
as part of the Nimbus installation itself.
Instrument Command Editor
Nimbus supports a very flexible syntax for specifying instrument commands that are associated with driver methods and properties. An interactive editor is now provided that helps in composing instrument commands.
New Error Reporting Object
Nimbus 2 introduces a new error reporting object that consolidates all of the standard IVI error codes and the custom driver-specific error codes in a single location.
This arrangement leverages IntelliSense so that driver developers can easily select the specific error they wish to return from a function. The error reporting object
is automatically roundtripped by Nimbus as new driver-specific errors are added to the driver project.
Multi-Driver Visual Studio Solutions
Nimbus 1 had a fundamental limitation of one Nimbus driver project per Visual Studio solution. With Nimbus 2, any number of drivers can be managed within a single Visual
Studio solution. Drivers can be edited together within the solution and Nimbus will properly roundtrip the associated driver source files, help files, setup files,
unit test files, etc.
Streamlined Non-Modal Editing
All of the Nimbus 1 design dialogs integrated into Visual Studio were modal -- which
meant that the user had to bring up a dialog box, change some settings, close the
dialog box and then move on to another method or property. Nimbus 2 has very few
modal dialog boxes, so that the design and editing process is much more streamlined.
Improved Navigation
Nimbus includes additional commands for navigating from designers to and from source
code as well as between IVI-COM items and their associated IVI-C counterparts. Additional
commands assist in locating where certain items, such as enums and repeated capabilities,
are used within a driver hierarchy. A new Info Panel
window provides for quick navigation between methods and the data types they use.
Updated Help Format
The Nimbus help file itself has been largely rewritten updated in style to match
that of Visual Studio's latest help format. Help topics are clearer and better organized
and code snippets are much easier to read having been updated to render with proper
language-based syntax coloring.
Register-Based Instrument Support
The Nimbus Library now includes a series of functions for communicating with a register-based
device.
Simplified Nimbus Template Library (NTL)
Nimbus 1 used a set of classes that heavily relied upon C++ templates. Driver developers
venturing very far into the NTL code were quickly confronted with a complex arrangement
of template classes. The new NTL base classes rely much less on C++ templates. This
not only makes the driver code more approachable, but it results in a noticeable
improvement in driver build time.
Improved Source Control Support
The Nimbus designers communicate with the user's source control provider to automatically
check files out when necessary.
Direct Support for IVI-C-Only Functions and Attributes
The new IVI-COM Designer and IVI-C Designer have an explicit notion of IVI-COM-only functions and IVI-C-only functions. Managing
them is now much simpler than the pure text-based approach in Nimbus 1.
Repeated Capability Lists and Ranges
IVI-C repeated capability selector strings can now include comma-separated lists
of names and name ranges (e.g. "Channel1-Channel10"). Nimbus automatically parses
these lists and ranges and invokes the function or attribute on each repeated capability
specified.
Removal of IDispatch
Nimbus 1 multi-personality drivers were implemented using a private IDispatch implementation.
Some 3rd party tools and IDEs would sometimes discover this IDispatch implementation
and mistakenly believe the entire driver could be accessed using scripting and other
late-binding techniques. The Nimbus 2 multi-personality architecture has been completely
re-written without any IDispatch code so that this problem can no longer occur.
New Code Signing Options
Nimbus 1 included only two options for signing a driver's interop assembly -- using
the temporary Nimbus key or using delay signing with only a public key. A third
option has been added to allow the driver developer to reference a custom full public-private
key pair, so that the interop assembly can be fully signed with each build. This
eliminates the need to perform a separate delay-signing step.
Consolidated Implementation Files
Nimbus 1 factored driver implementation code into separate files for each interface.
This made the code more difficult to navigate and produced an inordinate number
of files. In Nimbus 2, one .cpp file is used for all methods and properties on the
main driver class and one .cpp file is used for each repeated capability. In practice,
this means the driver developer will need to deal with only one or two implementation
files, instead of dozens.