Using IVI Drivers in LabVIEW

5 ratings | 3.60 out of 5

Read in | Print

Overview

This document is intended for LabVIEW test developers who are familiar with traditional VXIplug&play instrument drivers but want to migrate to the IVI drivers.

Table of Contents

1. Introduction2. IVI Benefits and Features3. Using IVI Features4. Using Measurement & Automation Explorer to Configure IVI5. Differences with Traditional Drivers6. Conclusion7. Related Links8. BibliographyIntroduction

Instrument driverssoftware modules that control programmable instrumentshave advanced technologically in many ways. Standardization of hardware interfaces, including the standardization of GPIB through the IEEE 488.1 and 488.2 standards, has led to continual improvement of instrument driver technologies. The VXIplug&play Systems Alliance introduced VXIplug&play instrument drivers, which standardized naming conventions, file formats, and distribution of drivers. IVI (Interchangeable Virtual Instruments) drivers are the result of the efforts of the IVI Foundation, a consortium of instrument vendors, systems integrators, and end users who have a common interest in further improving the quality and performance of instrument drivers. For more information on the IVI Foundation, visit the IVI Foundation Web site at http://www.ivifoundation.org.This document briefly covers the IVI features, explains how to access the features in LabVIEW, and lists the visible differences between IVI and traditional drivers. You should know basic GPIB, serial and/or VXI concepts, and how to operate LabVIEW to develop test applications with traditional drivers based on the VISA VIs. This document focuses on IVI instrument specific drivers, not on IVI class drivers.

For additional information on IVI class drivers, which enable you to develop hardware-independent applications, refer to Application Note 121, Using IVI Drivers to Build Hardware-Independent Test Systems with LabVIEW and LabWindows/CVI.IVI Benefits and Features

VI drivers give you features that do not exist in traditional instrument drivers. This section describes the following IVI benefits and features:

Standardized configuration utility

Standardization

State caching

Range checking

Simulation

Status checking

Coercion recording

The Using IVI Drivers section describes two methods that you can use to access the IVI driver features.

Standardized Configuration UtilityYou can configure IVI drivers settings independently of a test application. With the IVI component of Measurement & Automation Explorer (MAX), you can set up driver session for instrument driver settings that an application can use. Instead of using a standard VISA resource name string, such as GPIB::2::INSTR, you can pass a previously configured driver session or logical name such as SCOPE1. The IVI Engine uses the predefined settings associated with the resource name string SCOPE1 for the test application. This virtual approach allows you to set up a number of different instrument driver configurations that test applications can easily access using the resource name string. To learn more about IVI configuration in MAX, refer to the DevZone document, Using Measurement & Automation Explorer to Configure IVI. You can access this document at http://ni.com/zone.

StandardizationThe IVI specifications are supersets of the VXIplug&play standards for driver development. IVI addresses areas that the VXIplug&play standard does not include. The VXIplug&play Systems Alliance standardizes design requirements with the VXIplug&play driver standard, including some naming convention, data format, and driver distribution standards. These traditional VXIplug&play drivers emphasize ease of use, and they do not set guidelines for the internal structure of drivers or for the interface provided for similar instruments.

The IVI class specification:

Sets internal structure

Sets programmatic interface of similar instruments

Divides instruments into functional classes such as oscilloscopes and digital multimeters

Establishes the characteristics of each class of instruments

The IVI Foundation also specifies the programmatic interface for these different classes of instruments. For example, with IVI all function generator drivers have the same programmatic interface for basic instrument functionality.

With IVI, two drivers for function generators share the same:

VI names (with the exception of the prefix)

Number of inputs/outputs

Terminal pattern

Control definitions

The IVI Engine always defines measurement parameters consistently, and the instrument driver adjusts parameters to account for differences between individual instruments. For example, the output amplitude for the two function generators is always defined to be volts peak-to-peak, not volts peak or volts rms. Although the interface to each driver VI is the same, IVI customizes the underlying operation of each function in the driver for the specific instrument. By defining standards for each of these functions, IVI makes it possible for you to develop test programs that can work with any function generator. When you have a standard interface to instrument drivers, you can work more quickly because you do not need to learn a new interface for each new instrument.

Standardization does not restrict your ability to access individual or unique capabilities of a specific instrument. Instrument specific VIs supplement the standard VIs and provide access to functions that are unique to the instrument. Standardization in IVI also enables instrument interchangeability in your test system.

For further information on building test systems that are independent of any particular brand or type of instrument, refer to Application Note 121, Using IVI Drivers to Build Hardware-Independent Test Systems with LabVIEW and LabWindows/CV.State CachingIVI drivers maintain the physical state of instruments in a software cache to increase the efficiency and speed of instrument drivers. Focusing on the ease of use, traditional instrument drivers did not always provide optimal performance. With those drivers, high-level VIs might combine a number of instrument settings into a single VI. Calls to these high-level VIs often result in transmission of redundant commands to the instrument. In contrast, IVI drivers use state caching to eliminate redundant commands.

In IVI drivers, an attribute represents each area that you can configure in an instrument. High-level driver VIs logically group a number of attributes together. Consider the Configure Standard Waveform VI illustrated in Figure 1. The VI configures the parameters for a function generator and sets the waveform shape, amplitude, offset, frequency, and start phase for a waveform. When the VI performs a frequency sweep, only the frequency parameter changes. It is redundant to send the other four settings each time you run the VI. With state caching, only the frequency parameter is sent to the instrument each time you run the VI.

Figure 1. Configure Standard Waveform VI

The key to state management in IVI drivers is the IVI Engine, which controls the reading and writing of attributes to and from instruments. Through state caching, the IVI Engine stores a copy of the current instrument setting of each attribute, performing I/O with an instrument only when an attribute's value changes.

For more information on how the IVI Engine manages state caching, refer to Application Note 122, Improving Test Performance through Instrument Driver State Management.

Range CheckingIVI drivers verify that the values you specify for an attribute are valid. Previous LabVIEW drivers indicated the valid ranges for settings indirectly through the online documentation for each control. IVI drivers provide this information and verify the entries you have made if you enable Range Checking. Range checking is enabled by default, but you can disable it after you debug your application in order to increase execution speed.

If you enter an incorrect value, IVI drivers return an error through the error out indicator. Error checking includes consideration of rounding performed by specific instruments. To reduce any discrepancies, the driver coerces or rounds values to the actual value that the instrument uses internally. When you specify an attribute value, IVI drivers also identify dependencies for the attribute ranges on other instrument settings. For example, the vertical range (in volts per division) for an oscilloscope channel is dependent on the attenuation of the probe that you are using. When calculating the valid vertical range, IVI oscilloscope drivers take into account the attenuation of the probe. The IVI Engine uses this dynamically-calculated range to verify the setting. This approach to range checking eliminates incorrect settings and points out conflicts in an application.

SimulationUnlike traditional drivers, IVI drivers have a simulation mode in which you can make calls to the driver without being connected to an instrument. Simulation mode provides the benefits shown in Table 1.

Table 1. Characteristics of Simulation Mode for IVI DriversSimulation Mode CharacteristicsPurpose

Provides an instrument handle that VIs in the driver can use.To eliminate run-time errors that invalid instrument handles cause.

Does not alter any other behavior in driver operation. For example, range checking occurs as it does when a physical instrument is present.To verify the values you are planning to send the instrument, while you develop the test application.

To test a new instrument feature before you purchase that instrument by installing its IVI driver and running a test program to ensure that the instrument provides the functionality that you want.

Lets you simulate the data that you normally acquire using built-in algorithms to simulate data generation.To test your application with realistic data.

For more information on simulation, refer to Application Note 120, Using IVI Drivers to Simulate Your Instrumentation Hardware in LabVIEW and LabWindows/CVI.

Status CheckingTraditional LabVIEW drivers provide error query VIs that a programmer uses to check the status of instruments. This technique burdens you with inserting error-query VIs throughout the application to verify operation at various stages. With IVI drivers, you can check the status of an instrument after every function that interacts with the instrument without adding extra VI calls. Status checking in IVI drivers is enabled by default so that you can verify your applications during development. After the application has been thoroughly tested and verified, you can disable status checking to improve performance.

The IVI Engine checks the status of an instrument only after a function writes an attribute to, or reads a value from, an instrument. If an instrument error occurs at that time, the IVI Engine returns an error through the error out control. The developer can conditionally call the error query VI to learn more details about the instrument-specific error. An error reported from status checking does not invalidate the cached state of the instrument.

Coercion RecordingOften you choose an instrument setting from a range of values (for example from 1.0 to 1000.0) and the instrument coerces the value to one of several selected values. A digital multimeter (DMM) instrument might accept a value from 1.0 to 1000.0, and the DMM would coerce that value to one of three maximum reading ranges: 10.0, 100.0, or 1000.0. In this DMM example, if you set the range to 50.0, the instrument would coerce the value to 100.0.

To make state caching work properly, the IVI Engine must store the coerced value in the cache. Therefore, instead of letting the instrument coerce the value, the IVI driver coerces the value before it sets the instrument.

If you want to track the coercions that the IVI Engine performs, you can enable Record Value Coercions. Record Value Coercions maintains a list of all coercions for Integer and Real values passed to the instrument driver VIs. You can call the Get Next Coercion Record VI, which accesses the coercions by retrieving and clearing the oldest recorded instance.

CAUTION: If you enable Record Value Coercions and never use Get Next Coercion Record VI to retrieve and clear those coercion records, the records build up and could eventually overflow your computer memory.

Using IVI Features

In most cases, you develop a test application with the IVI driver VIs in the same way that you develop a test application with traditional LabVIEW drivers. Like traditional LabVIEW driver VIs, IVI driver VIs are grouped together in functional areas that you combine into an application. Unlike traditional LabVIEW driver VIs, IVI driver VIs operate differently internally since they rely on the IVI Engine to coordinate and control the features as described in the IVI Features section. For this reason, IVI drivers communicate with instruments and the IVI Engine through DLLs (dynamic link libraries).

The internal differences between traditional drivers and IVI drivers should not affect your use of driver VIs to develop an application. After you configure the IVI driver with the IVI features you want (state caching, range checking, simulation, status checking, or recording coercions) you continue developing an application as you do with a traditional LabVIEW instrument driver.

You can configure the IVI features using one of the following options:

Initialize With Options VI

Driver Session that you set up with MAX

The Initialize with Options VIIVI drivers include two distinct initialization VIs. The first performs similar to the Initialization VI found in traditional drivers and the second is the Initialize With Options VI. Figure 2 shows a sample front panel for the Initialize with Options VI. The only difference between the Initialize with Options VI and the Initialize VI of a traditional driver is the option string. The option string configures the IVI driver features that you choose: state caching, range checking, simulation, status checking, and record value coercions. For instrument drivers that support a family of instruments, you can also use the option string to set the particular model of instrument that you want the driver to emulate.

Figure 2. Sample Front Panel for IVI Initialize with Options VI

To enable one of the IVI features, you set its value to 1 in the option string. To disable a feature, you set its value to 0. The IVI Engine uses these settings when it runs your test application. The following table lists IVI driver features, their corresponding strings for the option string, and the default value setting for each feature. The IVI Engine uses the default value listed below whenever you do not name a feature in the option string.

Table 2. Option Strings for IVI Features

FeatureOption StringDefault ValueDefault State

State CachingCache1Enabled

Range CheckingRangeCheck1Enabled

SimulationSimulate0Disabled

Status CheckingQueryInstrStatus1Enabled

Record Value CoercionsRecordCoercions0Disabled

The option string in Figure 2, Simulate=0,RangeCheck=1,QueryInstrStatus=1,Cache=1, results in the following configuration:

Instrument simulation is disabled.

Range checking is enabled.

Status checking is enabled.

State caching is enabled.

Recording of coercions of values is disabled.

Using Measurement & Automation Explorer to Configure IVI

NOTE: This section discusses MAX. The IVI component for MAX comes with the IVI Compliance Package.

Instead of using the Initialize with Options VI, you can easily and conveniently enable and disable IVI features in MAX. The IVI configuration utility in MAX configures a driver session to store the settings you want to use. This method uses the standard Initialize VI that you use with traditional LabVIEW drivers. To make your program use the configured settings, you pass the name of the configured driver session to the resource name control of the Initialize VI. For example, if an oscilloscope is connected to your PC through the GPIB bus with an address of 2, you can use either of the following approaches:

As with any traditional driver, you can enterGPIB::2::INSTR for the resource name. When you use this approach, MAX settings do not take effect.

Alternatively, you can enter a driver session that you associate with your oscilloscope as the resource name string.

NOTE: The settings you make through MAX could conflict with settings you make with the Initialize With Options VI. Therefore, you will generate errors if you attempt to use both approaches. Make sure the option string is empty when you use the MAX approach.

Consider the following example. If you previously configured the fl45 driver session for a Fluke 45 Digital Multimeter, you can set and use the Initialize VI of the specific driver. Simply replace the resource name string with fl45. Figure 3 illustrates this configuration. The IVI Engine then uses the configuration parameters associated with the fl45 driver session when it executes your application.

Figure 3. Using a Virtual Instrument Name to Initialize Driver Settings

In the IVI Drivers subfolder of MAX, you find the driver sessions that you can configure. Along with driver sessions, you also see the subfolder for Logical Names. You can use Logical Names at class-driver level and can also be used at the specific-driver level. They point to driver sessions and allow for interchangeability. Driver Sessions consist of an instrument driver software module, general property settings, and, when you are not in simulation mode, a hardware asset. Instrument drivers specify the instrument driver DLL while the hardware asset properties specify the resource name to access a physical device. To learn more about IVI configuration in MAX, refer to DevZone document, Using Measurement & Automation Explorer to Configure IVI. You can access this document at http://ni.com/zone.

Differences with Traditional Drivers

This section addresses some of the changes that you will notice with IVI drivers if you are familiar with traditional LabVIEW drivers.

NOTE: VIs in LabVIEW and function panels in LabWindows/CVI can be run interactively. Therefore, if you are unfamiliar with instrument drivers, a particular function, or just want to test various values, you can run the function by clicking on the run button (white arrow).

VISA Sessions versus Instrument HandlesIn most traditional LabVIEW drivers, a VISA session serves as an identifier for communication with GPIB, serial, and VXI instruments; you create a VISA session when you initiate communication with an instrument, and you close the session when you end communication. Your application passes a VISA session between VIs.

In IVI drivers, an instrument handle serves as the identifier. You create this instrument handle in one of your initialize functions. Instead of passing VISA sessions between VIs, your application passes the instrument handle from VI to VI.

Text Menus versus IconsPalettes for IVI drivers use text menus by default, instead of icons. When you work with drivers, you can often recognize texts names more easily than icons. Menu structures and naming conventions for IVI drivers are similar throughout a class of instruments, so the menu view provides familiarity and consistency to users. If you prefer the traditional icon view, LabVIEW permits you to change to icon view. Figure 4 compares the two different menu views. The Fluke 45 DMM and illustrates the text view, and the HP 34401A Multimeter illustrates the icon view.

Figure 4. Menu and Icon Palettes for IVI Drivers

New VIsA few new VIs exist for IVI drivers that do not exist for traditional instrument drivers.

Initialize with Options VI- Discussed previously in this document, this VI is identical to the Initialize VI except for the addition of the option string control. You use the option string to configure the inherent settings of the driver, such as simulation and range checking.

Get Next Coercion Record VI- Tracks input values that the IVI driver coerces to new values. Get Next Coercion Record VI returns and clears coercions, if any, when you enable Record Coercions.

CAUTION: If you enable Record Value Coercions and never use Get Next Coercion Record VI to retrieve and clear those coercion records, the records build up and could eventually overflow your computer memory.

Virtual Channel NamesWhen using traditional instrument drivers, you have to supply some functions with the name of the channel that you would like to configure or measure. It is the same way with IVI drivers, unless you want to take advantage of the interchangeability that IVI offers. To enable interchangeability, you must configure IVI in MAX and use virtual channel names. Virtual channel names are simply aliases for specific driver channel names. This configuration enables the class drivers to use virtual channel names to make calls to a specific driver regardless of the specific driver's channel name style. You set up virtual channel names in the properties of a driver session. For more information on setting up virtual channel names, refer to the DevZone document, Using Measurement & Automation Explorer to Configure IVI. You can access this document at http://ni.com/zone. You may also refer to channels when using specific drivers by using virtual channel names.

NOTE: When using class drivers and switching between a multichannel instrument and a single-channel instrument, for issues of interchangeability, always pass a virtual channel name even if the instrument has only one channel.

IVI Class DriversClass drivers are what enable IVI drivers to be interchangeable. When you make calls to a class driver, the class driver then calls the specific driver to perform its function. The class driver knows which specific instrument driver to call and what attributes to call when you configure a logical name in MAX and pass it to the class driver's Initialize VI. For more information on setting up logical names, refer to the DevZone document, Using Measurement & Automation Explorer to Configure IVI. You can access this document at http://ni.com/zone.

You can get IVI class drivers for free when you download the NI IVI Compliance Package from http://www.ni.com/ivi. For additional information on IVI class drivers, which enable you to develop hardware-independent applications, please refer to Application Note 121, Using IVI Drivers to Build Hardware-Independent Test Systems with LabVIEW and LabWindows/CVI.Conclusion

Instrument drivers are an indispensable tool to help you rapidly develop test and measurement applications. By providing high-level VIs for programming, they eliminate the need for application developers to learn complex programming protocols. The new technologies introduced with IVI drivers maintain the benefits of traditional drivers while adding features that improve the application development process and application performance. Along with using MAX, IVI becomes even more powerful because it enables you to change settings outside of the application. You should develop an application with IVI instrument drivers in the same way that you develop applications with traditional LabVIEW drivers, except that you can also take advantage of the new IVI features described in this.

The LabWindows/CVI remote debugger extends debugging beyond your local desktop to remote target machines. LabWindows/CVI performs debugging on two types of targets DLLs running on LabVIEW Real-Time and executables/DLLs running on another desktop. This document addresses the general setup and use of the remote debugging features in LabWindows/CVI

Table of Contents

1. Terms and Definitions2. Introduction3. Configure the Debugger4. Configure the Debuggee5. The Debugging Process6. TroubleshootingTerms and Definitions

Debugger The LabWindows/CVI environment that has the source code in memory along with its debugging features. Usually, this is the development computer.Debuggee The application or DLL, meant to be debugged, running on a target PC or LabVIEW Real-Time environment.

Introduction

In LabWindows/CVI, users can easily create and debug applications and DLLs. The Remote Debugger extends this functionality so that a development machine can now debug applications or DLLs running on a remote computer. This feature is extremely useful if the target computer does not have LabWindows/CVI installed, or have the application source code present. Remote debugging is also helpful when it is difficult to re-create in the development machine the runtime conditions required to run the application or to reproduce a particular error. When creating DLLs for a real-time target, the Remote Debugger is the only way to debug the DLLs using the LabWindows/CVI environment.

Configure the Debugger

1. Click on Run >> Switch Execution Target >> Select Target with Options2. Select an execution target based on whether you are debugging the DLL/executable on another PC on the network or a DLL on an RT target.

a. If you are debugging an executable/DLL on another PC on the network, select New Target on the Network from the drop-down menu. In the Machine Name/IP field, enter the network address of the computer on which the debug executable or DLL is running. You can enter either a machine name or an IP address for this option. LabWindows/CVI rejects debug connections that do not originate from this network address. You can either leave the Port of the debug session as the default port number, 3291, or change it.

b. If you are debugging a Real-Time DLL running on an RT target without using LabVIEW RT, select New RT Target on the Network from the drop-down menu. In the Machine Name/IP field, enter the network address of the RT Target. This will allow LabWindows/CVI to automatically download the DLL to the RT target and run it.

c. If you are debugging a Real-Time DLL that is running on an RT target via LabVIEW RT, select New RT Target on the Network via LabVIEW. In the Machine Name/IP field, enter the network address of the computer on which the debug executable or DLL is running. You can enter either a machine name or an IP address for this option. LabWindows/CVI rejects debug connections that do not originate from this network address. You can either leave the Port of the debug session as the default port number, 3291, or change it.

3. Click OK

4. Make sure there is a check mark next to Build>>Configuration>>Debug5. To Debug an Application (EXE):

a. Make sure there is a check mark next to Build>>Target Type>>Executable.

b. Click on Build>>Create Debuggable Executable. This creates an executable in your project folder

6. To Debug a Dynamic Linked Library (DLL):

a. Make sure there is a check mark next to Build>>Target Type>>Dynamic Linked Library. If you are creating a DLL that will run on an RT target, make sure to set Real-Time only runtime support by going to Build >> Target Settings and setting Run-time support to Real-time only. For more information about creating DLL for RT target, refer to the LabWindows/CVI Shipping Help topic Creating and Downloading Real-Time DLLs from LabWindows/CVINote: Skip steps b, c and d if you are creating a DLL for a Real-Time system.

b. Click on Run>>Specify External Processc. This opens a new window called Specify External Processd. For the field Program Name, enter the path of the executable that is going to call your DLL. If your DLL is being called by a LabVIEW VI, the program name should be LabVIEW.exe. If your DLL is being called by a TestStand sequence, the program name should be SeqEdit.exe.

1.

[+] Enlarge Image

a. Click on Build>>Create Debuggable Dynamic Link LibraryConfigure the Debuggee

1. First you need to transfer the application or DLL to the target computer. You can do this either by creating a debuggable executable and then sharing the directory with the target machine or copying it, and every file that is needed to run your application the CVI run-time engine, for example over to the target computer or by creating an Installer (Build>>Create Distribution Kit). The following steps describe how to create an installer with a debuggable executable:

a. Click on Build>>Create Distribution Kit and go through the regular process of creating an Installer.

b. Install the application on the target computer.

c. Repeat steps 4, 5, and 6 under Configuring the Debugger section

d. Copy the newly created debuggable executable/DLL over to the target machine and replace the one created by the Installer

e. Every time you change the source code, you can simply create another debuggable executable/DLL and copy it over to the target machine.

Note: When you have finished debugging your executable/DLL, you can create a regular Distribution Kit and install it over the debuggable installer or build a release version of the executable/DLL and copy it over the debug version.Note: If you specified your target settings as New RT Target on Network, LabWindows/CVI will automatically download the DLL to the RT target. If your target settings specify RT Target via LabVIEW, you will need to use LabVIEW RT to download the DLL for you. Refer to the LabVIEW RT Help for instructions on how to download DLLs on an RT target. If you are trying to debug a DLL on a RT target (regardless of how it was downloaded), skip the rest of this section.

2. Run ConfigureRemoteDebugging.exe located in ..\Program Files\National Instruments\CVI80\bin directory on the target computer. If the executable is not on the target computer, you can copy it over from the development machine. You can run this executable only after the CVI run-time engine has already been copied to the target computer (see step 1)

3. Network port of the debug session. This should match the port on the debugger.

4. Enter the IP address or computer name of the debugger. Remember that you must leave the utility running during the debugging session.

Click Done once you are finished debugging.

See Also:Customizing Create Distribution Kit Installers in LabWindows/CVIThe Debugging Process

The Remote Debugger accomplishes its tasks by communicating with the debuggee via TCP. With remote debugging enabled, the debuggee looks for the LabWindows/CVI debugger at a certain IP address. If it is unable to find the debugger, it continues without debugging.

Once you have setup the debugger and the debuggee, run the debugger by clicking on the Debug Project button or pressing Shift+F5. If you specify your target settings as New RT Target on Network, LabWindows/CVI will automatically download the DLL to the RT Target and start running the code. You can debug the code as it is already running.

For the other target settings, instead of running the code, the debugger begins waiting for a connection from the debuggee. You will see a LabWindows/CVI Debugger window popup similar to the one below.

Now launch the debuggee executable or the application that calls the debuggee DLL. The debuggee connects to the debugger using the network address and port information provided. You can now control the application as though it were a regular debugging process, e.g. you can suspend execution on breakpoints, step through code, look at variables and examine watch points.The LabWindows/CVI Debugger waits for further connections after the debuggee exits.

Note: When you debug a DLL for LabVIEW Real-Time and you are waiting for a connection, youll see a dialog (see below) when you load the corresponding VI in LabVIEW. This happens because when LabVIEW loads a VI, it also loads all the DLLs called by the VI. If you define DLLmain in your DLL, the DLL will connect to the CVI debugger and youll see this dialog. If you want to debug the DLL on your desktop machine, select Accept. If you want to debug the DLL on a real-time target instead, select Wait. The DLL tries to reconnect after you download your VI to the RT target.

Troubleshooting

Why do I get a message saying that my DLL is out of date?

The DLL or the application on the debuggee must match the version of that on the debugger. Otherwise LabWindows/CVI will give you a version mismatch error.

Is there an order in which the debugger and debuggee need to be started?

The debugger must always be started before the debuggee application. The debuggee only checks for the debugger once. If it cannot find the debugger, it continues like a normal application without looking for it again.

Why doesnt my application connect to the CVI debugger?

Check the connection parameters.

Verify both machines are connected to the network.

Include the domain name in the network address: mytest02.mydomain.com

Use IP addresses (e.g. 130.255.108.15) instead of machine names in case name resolution doesnt work.

If you installed your application through a distribution kit verify that the distribution kit installed the debug version of your application. By default, the release version is used.

Why do we wait for additional connections?

Because we dont know when youre done debugging. For example, you might create an executable with VC++ that calls several CVI DLLs. These DLLs connect and disconnect to the CVI debugger in their entry point functions. CVI doesnt know when the executable has finished using the CVI DLLs._1330980219.unknown