Adding Support for Multiple Instrument Models
Instruments are often designed in related families. Consequently, these instruments share many characteristics from a driver design and implementation perspective. Often identical SCPI command sets are available in more than one instrument, with differences arising in only specific measurement parameters, such as sweep speed, resolution, frequency, or bandwidth. Designing, developing, and implementing separate IVI drivers for each model in an instrument family would result in an intractable development and version management burden.
Nimbus allows a single driver to support multiple models of an instrument. The following driver features can all be made model-specific:
Method or property supported
The first step in building a multi-model driver is defining the list of supported models. This is done via the Models Page of the Driver Settings Editor. Models are defined within instrument families. This allows related models to be grouped together and family-specific behavior to be assigned to a group of instrument models. The list of models defined in the Models Page is used by Nimbus for a variety of purposes:
It establishes the list of models returned by the SUPPORTED_MODELS attribute.
During driver initialization, if the IdQuery parameter was set to true, the actual model detected is checked against this list of models. If the model detected is not in the list set on the Models Page, then the initialization function fails.
The model list is used in generating the IVI compliance information in the driver help file.
The model marked as the default model is used in simulation mode if no Model value is supplied in the OptionString parameter passed to Initialize.
The model names defined in the Models Page of the Driver Settings Editor must match exactly the model string set by the InitializeIdentification (for IVI.NET), the InitializeIdentification function (for IVI-COM), or the GetIdentificationInfo (for IVI-C). If the detected model does not match, an error will be generated when initializing the driver. By default, during initialization, Nimbus will issue a *IDN? query and parse the result to determine the instrument model. In some cases, this may not be the desired behavior. For instance, some drivers might support a large number of specific instrument models that cannot practically be listed on the Models Page. Such drivers often choose to include "wildcard" characters in the model names. For instance, a model name such as Acme43XX could be used to respresent an entire series of instruments that start with "Acme43" and have a range of possible values for the last two characters in the model. Obviously, when querying the instrument for its model name, it will return a specific model and not Acme43XX. This requires one of two approaches for ensuring that the initialization of the driver succeeds.
Override the function used to identify the connected instrument and to set the model string to one of the values defined on the Models Page of the Driver Settings Editor.
For IVI.NET drivers, that function is the InitializeIdentification function.
For IVI-COM drivers, that function is the InitializeIdentification function.
For IVI-C drivers, that function is the GetIdentificationInfo function.
Override the implementation of the function used to determine if the connected instrument is one that is supported by the driver.
For IVI.NET drivers, that function is thefunction.
For IVI-COM drivers, that function is the InstrumentSupported method.
For IVI-C drivers, that function is the InstrumentSupported method.
When the driver is initialized using a live instrument session, the model is determined by the implementation of the InitializeIdentification (for IVI.NET), the InitializeIdentification function (for IVI-COM), or the GetIdentificationInfo (for IVI-C). Typically, this performs a simple *IDN? query and parses the response to determine the connected model. However, in simulation mode, the driver obviously cannot issue queries to an instrument, yet a simulated instrument model must be established since many driver features may be model-specific. Nimbus provides three ways for the simulated model to be determined. These are listed below in order of precedence:
A Model value can be supplied in the OptionsString parameter passed during initialization of the driver.
If no Model value is passed as part of the OptionsString during initialization, Nimbus checks for a Model value supplied as a Configurable Initial Setting in the IVI Configuration Store.
If no Model value is supplied during driver initialization and no Model value is found in the IVI Configuration Store, the driver falls back to use the default model specified by the driver developer on the Models Page of the Driver Settings Editor.
From Solution Explorer, double-click the Driver Settings Editor node to bring up the Driver Settings Editor.
Click on the Models tab.
From within the list of defined models, right-click on the desired default model for simulation and choose Make Default Model. The default model appears in bold text.
Nimbus allows specific aspects of method and property implementations to be customized on a per-model and per-family basis. The following Item Editors within the Driver Designer include a special Models Window for defining model-specific behavior:
Method General Editor
Property General Editor
Property Range Checking Editor
Property Simulation Editor
Function General Editor (for IVI-C)
Attribute General Editor (for IVI-C)
Attribute Range Checking Editor (for IVI-C)
Attribute Simulation Editor (for IVI-C)
Enum Member General Editor
For each of the editors that support model-specific settings, the behavior of the Models Window is the same. When a method or property is first created, all models will use the same settings. When clicking on a specific model in the Models Window, all of the controls in the editor become read-only. Only by selecting the All Models node in the Models Window may any of the settings in an editor be changed.
The settings on a specific editor may be customized for a particular model by right-clicking the desired model in the Models Window and choosing Customize Settings.
In some cases, the desired model-specific behavior cannot be specified using one of the Item Editors mentioned above. Nimbus provides three functions that can be used in a method or property implementation to perform custom model-specific or family-specific logic.
For IVI.NET drivers, See the documentation in the Nimbus Class Library for details and examples of the following methods and properties:
For IVI-COM drivers, See the documentation in the Nimbus Template Library for details and examples of these three functions:
For IVI-C drivers, See the documentation in the Nimbus Runtime Library for details and examples of these three functions:
Download a complete CHM version of this documentation here.