Automatic Code Round-tripping

Arguably one of the most powerful features of the Nimbus product is its ability to round-trip driver implementation code. This means that decisions made about the layout of methods, interfaces, and other driver characteristics can be completely changed after the driver has been generated and after the developer has begun implementation. Nimbus Code Wizards automatically manipulate the C++ code to effect the desired changes. All implementation code is preserved in the process! No other driver development tool on the market today has this capability. Driver developers today facing significant design changes must make painstaking modifications to the code by hand. This is so tedious and error-prone as to be prohibitive. Developers working with other tools have reported completely regenerating their driver from scratch three or more times per day simply to accommodate design changes.back to chart >

VS.NET Integration

Visual Studio .NET is a boon for third-party developer tools as it provides an unprecedented level of customization possibilities. Nimbus fully capitalizes on Visual Studio .NET by integrating our own custom tool windows, menus, commands, and toolbars directly into the Visual Studio IDE. Driver developers working within Visual Studio have direct access to the same Nimbus design and development tools as in the stand-alone Nimbus Driver Designer. In fact, all phases of driver design, development, and test can be conducted without ever leaving the Visual Studio IDE.back to chart >

Forwards compatibility with IVI.NET

Nimbus was designed with a forward-looking eye towards .NET drivers. The driver designs you create with the Nimbus Driver Designer are already independent of the underlying implementation technology. That means you can take the same design and generate an IVI-COM driver today and a .NET driver tomorrow, without changing your design.back to chart >

Extensible and open architecture

Every feature and tool in Nimbus is built on top of the Nimbus Object Model, which encapsulates all of the design information associated with a driver project. Recognizing the need for users to develop and integrate their own tools, the team at Pacific has decided to publish the Nimbus Object Model and document it thoroughly. The result is an extraordinarily empowering range of possibilities for Nimbus users.

Working with the Nimbus Object Model, you can develop your own custom tools for accomplishing everything from custom design validation, to database integration, to custom reporting and printing. In short, anything you see that we've done with Nimbus, you can build for yourself with the Nimbus Object Model.back to chart >

VXI Plug-n-Play wrapper

While both Nimbus and VIVID allow importing of VXI Plug-n-Play (VXI PnP) Function Panel files, VIVID only imports the function signatures into the design. The existing VXI PnP driver implementation code is not automatically incorporated into the generated IVI-COM driver. All implementation of the generated IVI-COM methods is left up to the user. Indeed, this is the most critical, time-consuming, and error-prone portion of the task of producing an IVI-COM wrapper around a VXI PnP driver. Moreover, VXI PnP drivers often expose a lot (if not most) of their functionality through attributes, and VIVID does not import any of these attributes.

By contrast, Nimbus provides true one-click generation of IVI-COM wrappers for existing VXI PnP drivers. Users simply direct the Plug-n-Play Wrapper Wizard to the Function Panel (.fp) file and Nimbus imports all methods, all attributes, and even enum definitions. The generated driver is completely functional with no code modifications whatsoever.back to chart >

Multi-model driver support

Instrument vendors commonly develop products in families of related instrument models. Often, instrument models within a family support very similar functionality. Rather than developing, testing, and maintaining separate IVI drivers for each instrument model, it is far simpler to develop a single driver than can support multiple instrument models and families.

Multi-model drivers necessarily place a much greater implementation burden on the driver developer. Nimbus supplies a powerful array of features to facilitate multi-model driver development with no additional coding. At runtime, the Nimbus-generated driver detects the instrument to which it is connected and dynamically adapts to issue the proper device commands for that specific instrument model. The driver developer uses simple dialog boxes to configure this behavior. All of these dialogs are accessible from the Nimbus Driver Designer and from within Visual Studio.back to chart >

Performance monitoring

Nimbus automatically instruments your driver code by installing a variety of Windows performance counters to track the performance characteristics of your implementation. No coding is required on the part of the developer to take advantage of these valuable analysis tools, and there is virtually zero overhead incurred in collecting the driver's performance data.

Nimbus installs performance counters for tracking such driver performance characteristics as method call execution speed, instrument I/O execution speed, state caching efficiency, and I/O errors.back to chart >

Downloadable instrument personality support

Many types of instruments today ship with lots of configurable options. Customers purchase a base instrument and then purchase additional options in the form of measurement personalities that can be downloaded into the instrument. As a result, the capability of the instrument, and hence, the driver that communicates with it, needs to be configurable and expandable. As new measurement options are developed and released, the existing driver needs to be able to accommodate these options even though they did not exist when the driver was developed.

Nimbus provides direct support for these types of compound instruments. Supporting instruments with downloadable personalities is as easy as selecting an option in the New Driver Project Wizard. The Nimbus-generated driver dynamically adapts to expose only the options installed on the end-user instrument.back to chart >

Unified design environment

Constructing a complete, customer-ready IVI driver involves developing a number of different types of projects. These include the main driver project, a help project, an installer project, a regression test project, and potentially others. VIVID uses separate, disconnected tools for driver design, test code production, help file development, and installer implementation. As a result, the driver product itself is spread out amongst numerous different, incompatible project types. Nimbus provides a single environment for designing and implementing all of these driver development tasks. The single Nimbus project consolidates design, implementation, help, and even test information into a single open XML-format file.back to chart >

.NET-style attributed code

Nimbus introduces an extraordinarily powerful and easy-to-use mechanism for adding, removing, and modifying the functionality of your IVI-COM driver. Attributed programming allows you to replace reams of code that developers typically must write directly in their method implementations with simple declarative driver attributes. These attributes use the convenient .NET-style syntax and bring to COM programming the same power, flexibility, and ease-of-use as the .NET attributes that are becoming so popular in C# and VB.NET programming.back to chart >