IVI-COM Property General Editor

Name

Name of the property. Property names must start with a capital letter and can contain only alphanumeric characters.

Type

Data type of the property.

Note

As per the IVI specifications, array-type properties are not permitted. If you need to read or write an array, then use explicit “Get” and “Set” methods.

Tip

The following syntax can be used in the Type text box to create a new enum type and use that enum as the type all in one operation:

new enum TriggerSource; Internal = 2, External = 0x15, Software = 47

See the topic Defining New Data Types Inline for more information on this feature.

Access

Indicates if the property is read-write, read-only, or write-only.

Repeated capability

The repeated capability with which the property is associated.

Note

Not all repeated capabilities defined for the driver may appear in the Repeated capability combo box. This is because not all repeated capability transitions may be valid for the selected property. For instance, a property located on a collection-style repeated capability is inherently associated with that repeated capability based on its location within the driver hierarchy. Thus, it cannot be associated with a completely different repeated capability by using the Repeated capability combo box.

Implementation

Choosing the Instrument command option instructs Nimbus to automatically generate all of the implementation code needed to send the specified commands and to read a response for the property getter, if the Response text box is non-empty.

Choosing the Manual option requires the driver developer to provide the implementation for the property getter and setter. This choice is often used for properties that rely upon non-message-based device communications, such as register-based devices or drivers that rely upon a support DLL.

Choosing the Manual with instrument command option is the same as Manual except that the command and response textboxes are enabled and used to populate the Instrument Command section of the driver help page for the property. This is useful for properties that require manual implementation but that ultimately rely upon an instrument command in their manually added code.

Use standard method preamble

For manual property implementations, Nimbus can be instructed to still generate pre-processing code for features such as parameter validation, state-caching, and range-checking. If unchecked, Nimbus will not generate any pre-processing code and the driver developer must supply all getter and setter method logic.

Caution

It is recommended that this option remain checked. Many Nimbus features can be “short-circuited” if the standard Nimbus pre-processing code is not generated. This option is intended for advanced scenarios.

Setter command

Specifies the command to send to the device when the value of the property is set (i.e. the property setter executes). This control is not enabled for read-only properties. Nimbus supports a rich command and response formatting syntax, which can include the parameters, repeated capabilities, and more. Please see the topic Working With Instrument Commands for a detailed discussion of automatic command formatting.

Clicking the editor icon at the far right end of the text box launches the Instrument Command Editor, which is useful for building instrument commands.

Getter command

Specifies the query to send to the device when the value of the property value is read (i.e. the property getter executes). This control is not enabled for write-only properties. Nimbus supports a rich command and response formatting syntax, which can include the parameters, repeated capabilities, and more. Please see the topic Working With Instrument Commands for a detailed discussion of automatic command formatting.

Clicking the editor icon at the far right end of the text box launches the Instrument Command Editor, which is useful for building instrument commands.

Getter response

Specifies the format of the response to read back from the device when the property value is read. This control is not enabled for write-only properties.

Clicking the editor icon at the far right end of the text box launches the Instrument Command Editor, which is useful for building instrument responses.

Model-Specific Programming with the Models Window

The Property General Editor contains a collapsible Models Window in the right portion of the editor. This window is used for two purposes:

• Specifying that a model or group of models does not support the method.
• Customizing settings on a per-model or per-family basis.

Note

The Models Window cannot be used to define new models for the driver. The list of models supported by the driver is specified on the Models Page of the Driver Settings Editor.

The root node of the Models Window is labeled “All Models”. This node can be thought of as the “default behavior” for the property. By default, all instrument models are supported for the property and all share the same command and response. Thus, the editor controls are initially only enabled when “All Models” is selected in the Models Window. This changes when model-specific behavior is specified, as explained below.

When you use the Models Window to specify that a property is not supported for a model, Nimbus will generate the necessary code to return the IVI-defined COM error E_IVI_PROPERTY_NOT_SUPPORTED.

To specify that a particular model is not supported

1. From the Models Window, right-click on the desired model or family.

2. Choose Remove model support.

3. The selected model name appears with a strikethrough font.

   Note that if a family was selected, all models in the family appear with a strikethrough font, indicating that the E_IVI_PROPERTY_NOT_SUPPORTED error will be returned for those models as well.

4. To re-enable support for a model, right-click the model and choose Add model support.

When customizing behavior on a per-model or per-family basis, Nimbus generates code that will send different setter commands, getter commands, and/or read a differently formatted getter response, based upon the actual model detected at runtime. See the discussion of the InitializeIdentification function to understand how Nimbus determines the connected model at runtime.

Only the getter and setter commands and getter response can be customized on a per-model basis. The return data type, property access, repeated capability, and implementation style are all static characteristics of the property and cannot be changed dynamically based on the connected instrument model.

To customize the command or response for a model

1. From the Models Window, right-click on the desired model or family.

2. Choose Customize settings

3. The Setter command, Getter command, and Getter response text boxes are enabled for the selected model, allowing model-specific values to be set. The model appears in bold font for the customized model.

   Note that if a family was selected, all models in the family appear in bold font, indicating that they will all share a custom command and/or response.

4. To have a property return to using the default commands and response for a model, right-click the model and choose Remove custom settings. The model appears in normal font and the editor controls are once again disabled when the model is selected, indicating that the model is controlled via the default settings specified when the “All Models” node is selected.

See also

• Adding Functionality to an IVI-COM Driver
• Defining New Data Types Inline