 | Understanding the Initialization Sequence |
The instantiation and initialization of an IVI-COM driver follows a series of well-defined steps. At each stage in the process, Nimbus provides customization functions for taking control of some aspect of the driver initialization. The first step in understanding how to customize this process is to understand the sequence in which code executes during the lifetime of an IVI-COM driver instance. Consider the simple C# client code used to instantiate and initialize the Acme4321 IVI-COM driver.
// Create an instance of the driver IAcme4321 driver = new Acme4321(); // Initialize the driver driver.Initialize("GPIB::15", true, true, "");
When the code above executes, the following sequence occurs within the IVI-COM driver:
Step | Function Called | Description |
|---|---|---|
1 | new Acme4321() runs | In another language, this would correspond to another function call, such as CoCreateInstance if a C++ client were in use. |
2 | This method executes on the main driver class only. The repeated capability instances have not been created at this point in the initialization process. This method is called only once over the lifetime of the driver instance, irrespective of the number of times the client application invokes the driver's Initialize method. | |
3 | driver.Initialize(...) | |
4 | IIviDriver::Initialize execution begins | This method executes on the main driver class after each client call to the Initialize method. The NTL implementation of this method (which must ALWAYS be called by the driver implementation) calls several customizable functions on the main driver class and on any repeated capability classes before it finishes. |
5 | By default, Nimbus initializes the selected I/O provider (typically the VISA-COM or VISA-C I/O provider). Drivers using a custom I/O library would override this method to perform custom I/O initialization. | |
6 | This method is used to set the instrument model, as well as other identification information. By default, Nimbus issues a "*IDN?" query and expects a standard 488.2 response. Drivers that need to use an alternate mechanism for identifying the connected instrument must override this method. | |
7 | This method checks if the connected instrument is supported by the driver. By default, this function checks that the model detected by the InitializeIdentification method in the previous step is in the list of supported models. This function can be overridden to implement more advanced logic, such as cases where the number of instrument models supported is prohibitively large and/or not precisely enumerable by the driver. | |
8 | This method first executes on the main driver class and then on any repeated capability instances. | |
9 | This method first executes on the main driver class and then on any repeated capability instances. | |
10 | IIviDriver::Initialize execution completes |