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 pla! instrument drivers but want to migrate to the IVI drivers"

Table of Contents
#" Introduction $" IVI %enefits and &eatures '" (sing IVI &eatures )" (sing *easurement +utomation E,plorer to -onfigure IVI

5" .ifferences with Traditional .rivers /" -onclusion 0" 1elated Lin2s 3" %ibliograph!

Introd !tion
Instrument drivers4software modules that control programmable instruments4have advanced technologicall! in man! wa!s" 5tandardi6ation of hardware interfaces7 including the standardi6ation of 8PI% through the IEEE )33"# and )33"$ standards7 has led to continual improvement of instrument driver technologies" The VXIplug&play 5!stems +lliance introduced VXIplug&play instrument drivers7 which standardi6ed naming conventions7 file formats7 and distribution of drivers" IVI 9Interchangeable Virtual Instruments: drivers are the result of the efforts of the IVI &oundation7 a consortium of instrument vendors7 s!stems integrators7 and end users who have a common interest in further improving the ;ualit! and performance of instrument drivers" &or more information on the IVI &oundation7 visit the IVI &oundation Web site at http<==www"ivifoundation"org" This document briefl! covers the IVI features7 e,plains how to access the features in LabVIEW7 and lists the visible differences between IVI and traditional drivers" >ou should 2now basic 8PI%7 serial and=or VXI concepts7 and how to operate LabVIEW to develop test applications with traditional drivers based on the VI5+ VIs" This document focuses on IVI instrument specific drivers7 not on IVI class drivers" &or additional information on IVI class drivers7 which enable !ou to develop hardware? independent applications7 refer to +pplication @ote #$#7 Using IVI Drivers to Build HardwareIndependent Test Systems with LabVI ! and Lab!indows"#VI$

IVI "enefits and #eat res

VI drivers give !ou features that do not e,ist in traditional instrument drivers" This section describes the following IVI benefits and features<

5tandardi6ed configuration utilit! 5tandardi6ation 5tate caching 1ange chec2ing 5imulation 5tatus chec2ing -oercion recording

The Using IVI Drivers section describes two methods that !ou can use to access the IVI driver features" $tandardi%ed Config ration Utilit& >ou can configure IVI drivers settings independentl! of a test application" With the IVI component of *easurement +utomation E,plorer 9*+X:7 !ou can set up driver session for instrument driver settings that an application can use" Instead of using a standard VI5+ resource name string7 such as GPIB::2::INSTR7 !ou can pass a previousl! 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 !ou to set up a number of different instrument driver configurations that test applications can easil! access using the resource name string" To learn more about IVI configuration in *+X7 refer to the .evAone document7 Using %easurement & &utomation 'plorer to #on(igure IVI$ >ou can access this document at http://ni.com/zone" $tandardi%ation The 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 5!stems +lliance standardi6es design re;uirements with the VXIplug&play driver standard7 including some naming convention7 data format7 and driver distribution standards" These traditional VXIplug&play drivers emphasi6e ease of use7 and the! do not set guidelines for the internal structure of drivers or for the interface provided for similar instruments" The IVI class specification<

5ets internal structure 5ets programmatic interface of similar instruments

.ivides instruments into functional classes such as oscilloscopes and digital multimeters Establishes the characteristics of each class of instruments

The IVI &oundation also specifies the programmatic interface for these different classes of instruments" &or e,ample7 with IVI all function generator drivers have the same programmatic interface for basic instrument functionalit!" With IVI7 two drivers for function generators share the same<

VI names 9with the e,ception of the prefi,: @umber of inputs=outputs Terminal pattern -ontrol definitions

The IVI Engine alwa!s defines measurement parameters consistentl!7 and the instrument driver adBusts parameters to account for differences between individual instruments" &or e,ample7 the output amplitude for the two function generators is alwa!s defined to be volts pea2?to?pea27 not volts pea2 or volts rms" +lthough the interface to each driver VI is the same7 IVI customi6es the underl!ing operation of each function in the driver for the specific instrument" %! defining standards for each of these functions7 IVI ma2es it possible for !ou to develop test programs that can wor2 with an! function generator" When !ou have a standard interface to instrument drivers7 !ou can wor2 more ;uic2l! because !ou do not need to learn a new interface for each new instrument" 5tandardi6ation does not restrict !our abilit! to access individual or uni;ue capabilities of a specific instrument" Instrument specific VIs supplement the standard VIs and provide access to functions that are uni;ue to the instrument" 5tandardi6ation in IVI also enables instrument interchangeabilit! in !our test s!stem" &or further information on building test s!stems that are independent of an! particular brand or t!pe of instrument7 refer to +pplication @ote #$#7 Using IVI Drivers to Build HardwareIndependent Test Systems with LabVI ! and Lab!indows"#V$ $tate Ca!'ing IVI drivers maintain the ph!sical state of instruments in a software cache to increase the efficienc! and speed of instrument drivers" &ocusing on the ease of use7 traditional instrument drivers did not alwa!s provide optimal performance" With those drivers7 high?level VIs might combine a number of instrument settings into a single VI" -alls to these high?level VIs often result in transmission of redundant commands to the instrument" In contrast7 IVI drivers use state caching to eliminate redundant commands" In IVI drivers7 an attribute represents each area that !ou can configure in an instrument" Cigh? level driver VIs logicall! group a number of attributes together" -onsider the -onfigure 5tandard Waveform VI illustrated in &igure #" The VI configures the parameters for a function generator

and sets the waveform shape7 amplitude7 offset7 fre;uenc!7 and start phase for a waveform" When the VI performs a fre;uenc! sweep7 onl! the fre;uenc! parameter changes" It is redundant to send the other four settings each time !ou run the VI" With state caching7 onl! the fre;uenc! parameter is sent to the instrument each time !ou run the VI"

#ig re (. Config re $tandard Wavefor) VI

The 2e! to state management in IVI drivers is the IVI Engine7 which controls the reading and writing of attributes to and from instruments" Through state caching7 the IVI Engine stores a cop! of the current instrument setting of each attribute7 performing I=D with an instrument onl! when an attributeEs value changes" &or more information on how the IVI Engine manages state caching7 refer to +pplication @ote #$$7 Improving Test )er(orman*e through Instrument Driver State %anagement" Range C'e!*ing IVI drivers verif! that the values !ou specif! for an attribute are valid" Previous LabVIEW drivers indicated the valid ranges for settings indirectl! through the online documentation for each control" IVI drivers provide this information and verif! the entries !ou have made if !ou

enable 1ange -hec2ing" 1ange chec2ing is enabled b! default7 but !ou can disable it after !ou debug !our application in order to increase e,ecution speed" If !ou enter an incorrect value7 IVI drivers return an error through the error out indicator" Error chec2ing includes consideration of rounding performed b! specific instruments" To reduce an! discrepancies7 the driver coerces or rounds values to the actual value that the instrument uses internall!" When !ou specif! an attribute value7 IVI drivers also identif! dependencies for the attribute ranges on other instrument settings" &or e,ample7 the vertical range 9in volts per division: for an oscilloscope channel is dependent on the attenuation of the probe that !ou are using" When calculating the valid vertical range7 IVI oscilloscope drivers ta2e into account the attenuation of the probe" The IVI Engine uses this d!namicall!?calculated range to verif! the setting" This approach to range chec2ing eliminates incorrect settings and points out conflicts in an application" $i) lation (nli2e traditional drivers7 IVI drivers have a simulation mode in which !ou can ma2e calls to the driver without being connected to an instrument" 5imulation mode provides the benefits shown in Table #" Table (. C'ara!teristi!s of $i) lation +ode for IVI Drivers $i) lation +ode C'ara!teristi!s , r-ose Provides an instrument handle that VIs in the driver can use" To eliminate run?time errors that invalid instrument handles cause"

.oes not alter an! other behavior in driver To verif! the values !ou are planning to send the operation" &or e,ample7 range chec2ing occurs instrument7 while !ou develop the test as it does when a ph!sical instrument is present" application" To test a new instrument feature before !ou purchase that instrument b! installing its IVI driver and running a test program to ensure that the instrument provides the functionalit! that !ou want" Lets !ou simulate the data that !ou normall! ac;uire using built?in algorithms to simulate data generation" To test !our application with realistic data"

&or more information on simulation7 refer to +pplication @ote #$F7 Using IVI Drivers to Simulate +our Instrumentation Hardware in LabVI ! and Lab!indows"#VI" $tat s C'e!*ing Traditional LabVIEW drivers provide error ;uer! VIs that a programmer uses to chec2 the status of instruments" This techni;ue burdens !ou with inserting error?;uer! VIs throughout the application to verif! operation at various stages" With IVI drivers7 !ou can chec2 the status of an instrument after ever! function that interacts with the instrument without adding e,tra VI calls" 5tatus chec2ing in IVI drivers is enabled b! default so that !ou can verif! !our applications

during development" +fter the application has been thoroughl! tested and verified7 !ou can disable status chec2ing to improve performance" The IVI Engine chec2s the status of an instrument onl! after a function writes an attribute to7 or reads a value from7 an instrument" If an instrument error occurs at that time7 the IVI Engine returns an error through the error out control" The developer can conditionall! call the error ;uer! VI to learn more details about the instrument?specific error" +n error reported from status chec2ing does not invalidate the cached state of the instrument" Coer!ion Re!ording Dften !ou choose an instrument setting from a range of values 9for e,ample from #"F to #FFF"F: and the instrument coerces the value to one of several selected values" + digital multimeter 9.**: instrument might accept a value from #"F to #FFF"F7 and the .** would coerce that value to one of three ma,imum reading ranges< 10.07 100.07 or 1000.0" In this .** e,ample7 if !ou set the range to 50.07 the instrument would coerce the value to 100.0" To ma2e state caching wor2 properl!7 the IVI Engine must store the *oer*ed value in the cache" Therefore7 instead of letting the instrument coerce the value7 the IVI driver coerces the value before it sets the instrument" If !ou want to trac2 the coercions that the IVI Engine performs7 !ou can enable 1ecord Value -oercions" 1ecord Value -oercions maintains a list of all coercions for Integer and 1eal values passed to the instrument driver VIs" >ou can call the 8et @e,t -oercion 1ecord VI7 which accesses the coercions b! retrieving and clearing the oldest recorded instance" C.UTIO/0 If !ou enable 1ecord Value -oercions and never use 8et @e,t -oercion 1ecord VI to retrieve and clear those coercion records7 the records build up and could eventuall! overflow !our computer memor!"

Using IVI #eat res

In most cases7 !ou develop a test application with the IVI driver VIs in the same wa! that !ou develop a test application with traditional LabVIEW drivers" Li2e traditional LabVIEW driver VIs7 IVI driver VIs are grouped together in functional areas that !ou combine into an application" (nli2e traditional LabVIEW driver VIs7 IVI driver VIs operate differentl! internall! since the! rel! on the IVI Engine to coordinate and control the features as described in the IVI ,eatures section" &or this reason7 IVI drivers communicate with instruments and the IVI Engine through .LLs 9d!namic lin2 libraries:" The internal differences between traditional drivers and IVI drivers should not affect !our use of driver VIs to develop an application" +fter !ou configure the IVI driver with the IVI features !ou want 9state caching7 range chec2ing7 simulation7 status chec2ing7 or recording coercions: !ou continue developing an application as !ou do with a traditional LabVIEW instrument driver" >ou can configure the IVI features using one of the following options<

Initiali6e With Dptions VI .river 5ession that !ou set up with *+X

T'e Initiali%e wit' O-tions VI IVI drivers include two distinct initiali6ation VIs" The first performs similar to the Initiali6ation VI found in traditional drivers and the second is the Initiali6e With Dptions VI" &igure $ shows a sample front panel for the Initiali6e with Dptions VI" The onl! difference between the Initiali6e with Dptions VI and the Initiali6e VI of a traditional driver is the option string" The option string configures the IVI driver features that !ou choose< state caching7 range chec2ing7 simulation7 status chec2ing7 and record value coercions" &or instrument drivers that support a famil! of instruments7 !ou can also use the option string to set the particular model of instrument that !ou want the driver to emulate"

#ig re 1. $a)-le #ront ,anel for IVI Initiali%e wit' O-tions VI To enable one of the IVI features7 !ou set its value to # in the option string" To disable a feature7 !ou set its value to F. 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 1. O-tion $trings for IVI #eat res

#eat re 5tate -aching 1ange -hec2ing 5imulation 5tatus -hec2ing 1ecord Value -oercions

O-tion $tring -ache 1ange-hec2 5imulate Guer!Instr5tatus 1ecord-oercions

Defa lt Val e # # F # F

Defa lt $tate Enabled Enabled .isabled Enabled .isabled

The option string in &igure $7 Simulate 0!Ran"eChec# 1!$ue%&In't%Statu' 1!Cache 17 results in the following configuration<

Instrument simulation is disabled" 1ange chec2ing is enabled" 5tatus chec2ing is enabled" 5tate caching is enabled" 1ecording of coercions of values is disabled"

Using +eas re)ent 2 . to)ation E3-lorer to Config re IVI

/OTE0 This section discusses *+X" The IVI component for *+X comes with the IVI -ompliance Pac2age" Instead of using the Initiali6e with Dptions VI7 !ou can easil! and convenientl! enable and disable IVI features in *+X" The IVI configuration utilit! in *+X configures a driver session to store the settings !ou want to use" This method uses the standard Initiali6e VI that !ou use with traditional LabVIEW drivers" To ma2e !our program use the configured settings7 !ou pass the name of the configured driver session to the resource name control of the Initiali6e VI" &or e,ample7 if an oscilloscope is connected to !our P- through the 8PI% bus with an address of 27 !ou can use either of the following approaches<

+s with an! traditional driver7 !ou can enter(GPIB::2::INSTR for the resource name" When !ou use this approach7 *+X settings do not ta2e effect" +lternativel!7 !ou can enter a driver session that !ou associate with !our oscilloscope as the resource name string"

/OTE0 The settings !ou ma2e through *+X could conflict with settings !ou ma2e with the Initiali6e With Dptions VI" Therefore7 !ou will generate errors if !ou attempt to use both approaches" *a2e sure the option string is empt! when !ou use the *+X approach"

-onsider the following e,ample" If !ou previousl! configured the fl)5 driver session for a &lu2e )5 .igital *ultimeter7 !ou can set and use the Initiali6e VI of the specific driver" 5impl! replace the resource name string with fl)5" &igure ' illustrates this configuration" The IVI Engine then uses the configuration parameters associated with the fl)5 driver session when it e,ecutes !our application"

#ig re 3. Using a Virt al Instr )ent /a)e to Initiali%e Driver $ettings

In the IVI .rivers subfolder of *+X7 !ou find the driver sessions that !ou can configure" +long with driver sessions7 !ou also see the subfolder for Logical @ames" >ou can use Logical @ames at class?driver level and can also be used at the specific?driver level" The! point to driver sessions and allow for interchangeabilit!" .river 5essions consist of an instrument driver software module7 general propert! settings7 and7 when !ou are not in simulation mode7 a hardware asset" Instrument drivers specif! the instrument driver .LL while the hardware asset properties specif! the resource name to access a ph!sical device" To learn more about IVI configuration in *+X7 refer to .evAone document7 Using %easurement & &utomation 'plorer to #on(igure IVI$ >ou can access this document at http://ni.com/zone"

Differen!es wit' Traditional Drivers

This section addresses some of the changes that !ou will notice with IVI drivers if !ou are familiar with traditional LabVIEW drivers" /OTE0 VIs in LabVIEW and function panels in LabWindows=-VI can be run interactivel!" Therefore7 if !ou are unfamiliar with instrument drivers7 a particular function7 or Bust want to test

various values7 !ou can run the function b! clic2ing on the run button 9white arrow:" VI$. $essions vers s Instr )ent 4andles In most traditional LabVIEW drivers7 a VI5+ session serves as an identifier for communication with 8PI%7 serial7 and VXI instrumentsH !ou create a VI5+ session when !ou initiate communication with an instrument7 and !ou close the session when !ou end communication" >our application passes a VI5+ session between VIs" In IVI drivers7 an instrument handle serves as the identifier" >ou create this instrument handle in one of !our initiali6e functions" Instead of passing VI5+ sessions between VIs7 !our application passes the instrument handle from VI to VI" Te3t +en s vers s I!ons Palettes for IVI drivers use te,t menus b! default7 instead of icons" When !ou wor2 with drivers7 !ou can often recogni6e te,ts names more easil! than icons" *enu structures and naming conventions for IVI drivers are similar throughout a class of instruments7 so the menu view provides familiarit! and consistenc! to users" If !ou prefer the traditional icon view7 LabVIEW permits !ou to change to icon view" &igure ) compares the two different menu views" The &lu2e )5 .** and illustrates the te,t view7 and the CP '))F#+ *ultimeter illustrates the icon view"

#ig re 5. +en and I!on ,alettes for IVI Drivers

/ew VIs + few new VIs e,ist for IVI drivers that do not e,ist for traditional instrument drivers"

Initiali%e wit' O-tions VI6 .iscussed previousl! in this document7 this VI is identical to the Initiali6e VI e,cept for the addition of the option string control" >ou use the option string to configure the inherent settings of the driver7 such as simulation and range chec2ing" 7et /e3t Coer!ion Re!ord VI6 Trac2s input values that the IVI driver coerces to new values" 8et @e,t -oercion 1ecord VI returns and clears coercions7 if an!7 when !ou enable 1ecord -oercions"

C.UTIO/0 If !ou enable 1ecord Value -oercions and never use 8et @e,t -oercion 1ecord VI to retrieve and clear those coercion records7 the records build up and could eventuall! overflow !our computer memor!" Virt al C'annel /a)es When using traditional instrument drivers7 !ou have to suppl! some functions with the name of the channel that !ou would li2e to configure or measure" It is the same wa! with IVI drivers7 unless !ou want to ta2e advantage of the interchangeabilit! that IVI offers" To enable interchangeabilit!7 !ou must configure IVI in *+X and use virtual channel names" Virtual channel names are simpl! aliases for specific driver channel names" This configuration enables the class drivers to use virtual channel names to ma2e calls to a specific driver regardless of the specific driverEs channel name st!le" >ou set up virtual channel names in the properties of a driver session" &or more information on setting up virtual channel names7 refer to the .evAone document7 Using %easurement & &utomation 'plorer to #on(igure IVI$ >ou can access this document at http://ni.com/zone" >ou ma! also refer to channels when using specific drivers b! using virtual channel names" /OTE0 When using class drivers and switching between a multichannel instrument and a single? channel instrument7 for issues of interchangeabilit!7 alwa!s pass a virtual channel name even if the instrument has onl! one channel" IVI Class Drivers -lass drivers are what enable IVI drivers to be interchangeable" When !ou ma2e calls to a class driver7 the class driver then calls the specific driver to perform its function" The class driver 2nows which specific instrument driver to call and what attributes to call when !ou configure a logical name in *+X and pass it to the class driverEs Initiali6e VI" &or more information on setting up logical names7 refer to the .evAone document7 Using %easurement & &utomation 'plorer to #on(igure IVI$ >ou can access this document at http://ni.com/zone" >ou can get IVI class drivers for free when !ou download the @I IVI -ompliance Pac2age from http://))).ni.com/i*i" &or additional information on IVI class drivers7 which enable !ou to

develop hardware?independent applications7 please refer to +pplication @ote #$#7 Using IVI Drivers to Build Hardware-Independent Test Systems with LabVI ! and Lab!indows"#VI$

Con!l sion
Instrument drivers are an indispensable tool to help !ou rapidl! develop test and measurement applications" %! providing high?level VIs for programming7 the! eliminate the need for application developers to learn comple, 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" +long with using *+X7 IVI becomes even more powerful because it enables !ou to change settings outside of the application" >ou should develop an application with IVI instrument drivers in the same wa! that !ou develop applications with traditional LabVIEW drivers7 e,cept that !ou can also ta2e advantage of the new IVI features described in this" The LabWindows=-VI remote debugger e,tends debugging be!ond !our local des2top to remote target machines" LabWindows=-VI performs debugging on two t!pes of targets I .LLs running on LabVIEW 1eal?Time and e,ecutables=.LLs running on another des2top" This document addresses the general setup and use of the remote debugging features in LabWindows=-VI

Table of Contents
#" Terms and .efinitions $" Introduction '" -onfigure the .ebugger )" -onfigure the .ebuggee 5" The .ebugging Process /" Troubleshooting

Ter)s and Definitions

Deb gger I The LabWindows=-VI environment that has the source code in memor! along with its debugging features" (suall!7 this is the development computer" Deb ggee 8 The application or .LL7 meant to be debugged7 running on a target P- or LabVIEW 1eal?Time environment"

Introd !tion
In LabWindows=-VI7 users can easil! create and debug applications and .LLs" The 1emote .ebugger e,tends this functionalit! so that a development machine can now debug applications or .LLs running on a remote computer" This feature is e,tremel! useful if the target computer does not have LabWindows=-VI installed7 or have the application source code present" 1emote debugging is also helpful when it is difficult to re?create in the development machine the runtime

conditions re;uired to run the application or to reproduce a particular error" When creating .LLs for a real?time target7 the 1emote .ebugger is the onl! wa! to debug the .LLs using the LabWindows=-VI environment"

Config re t'e Deb gger

#" -lic2 on R n 99 $wit!' E3e! tion Target 99 $ele!t Target wit' O-tions: $" 5elect an e,ecution target based on whether !ou are debugging the .LL=e,ecutable on another P- on the networ2 or a .LL on an 1T target" a" If !ou are debugging an e,ecutable=.LL on another P- on the networ27 select /ew Target on t'e /etwor* from the drop?down menu" In the +a!'ine /a)e;I, field7 enter the networ2 address of the computer on which the debug e,ecutable or .LL is running" >ou can enter either a machine name or an IP address for this option" LabWindows=-VI reBects debug connections that do not originate from this networ2 address" >ou can either leave the ,ort of the debug session as the default port number7 '$J#7 or change it" b" If !ou are debugging a 1eal?Time .LL running on an 1T target without using LabVIEW 1T7 select /ew RT Target on t'e /etwor* from the drop?down menu" In the +a!'ine /a)e;I, field7 enter the networ2 address of the 1T Target" This will allow LabWindows=-VI to automaticall! download the .LL to the 1T target and run it" c" If !ou are debugging a 1eal?Time .LL that is running on an 1T target via LabVIEW 1T7 select /ew RT Target on t'e /etwor* via LabVIEW" In the +a!'ine /a)e;I, field7 enter the networ2 address of the computer on which the debug e,ecutable or .LL is running" >ou can enter either a machine name or an IP address for this option" LabWindows=-VI reBects debug connections that do not originate from this networ2 address" >ou can either leave the ,ort of the debug session as the default port number7 '$J#7 or change it" '" -lic2 O<

)" *a2e sure there is a chec2 mar2 ne,t to " ild99Config ration99Deb g

5" To .ebug an +pplication 9EXE:< a" *a2e sure there is a chec2 mar2 ne,t to " ild99Target T&-e99E3e! table" b" -lic2 on " ild99Create Deb ggable E3e! table" This creates an e,ecutable in !our proBect folder /" To .ebug a .!namic Lin2ed Librar! 9.LL:< a" *a2e sure there is a chec2 mar2 ne,t to " ild99Target T&-e99D&na)i! Lin*ed Librar&. If !ou are creating a .LL that will run on an 1T target7 ma2e sure to set 1eal?Time onl! runtime support b! going to " ild 99 Target $ettings and setting R n6ti)e s --ort to Real6ti)e onl&" &or more information about creating .LL for 1T target7 refer to the LabWindows=-VI 5hipping Celp topic Creating and Downloading Real6Ti)e DLLs fro) LabWindows;CVI /ote0 52ip steps b7 c and d if !ou are creating a .LL for a 1eal?Time s!stem" b" -lic2 on R n99$-e!if& E3ternal ,ro!ess c" This opens a new window called $-e!if& E3ternal ,ro!ess d" &or the field ,rogra) /a)e7 enter the path of the e,ecutable that is going to call !our .LL" If !our .LL is being called b! a LabVIEW VI7 the program name should be LabVIEW"e,e" If !our .LL is being called b! a Test5tand se;uence7 the program name should be 5e;Edit"e,e"

#" KLM Enlarge Image a" -lic2 on " ild99Create Deb ggable D&na)i! Lin* Librar&

Config re t'e Deb ggee

#" &irst !ou need to transfer the application or .LL to the target computer" >ou can do this either b! creating a debuggable e,ecutable and then sharing the director! with the target machine or cop!ing it7 and ever! file that is needed to run !our application I the -VI run? time engine7 for e,ample I over to the target computer or b! creating an Installer 9" ild99Create Distrib tion <it:" The following steps describe how to create an installer with a debuggable e,ecutable< a" -lic2 on " ild99Create Distrib tion <it and go through the regular process of creating an Installer" b" Install the application on the target computer" c" 1epeat steps )7 57 and / under Config ring t'e Deb gger section

d" -op! the newl! created debuggable e,ecutable=.LL over to the target machine and replace the one created b! the Installer e" Ever! time !ou change the source code7 !ou can simpl! create another debuggable e,ecutable=.LL and cop! it over to the target machine" /ote0 When !ou have finished debugging !our e,ecutable=.LL7 !ou can create a regular .istribution Nit and install it over the debuggable installer or build a release version of the e,ecutable=.LL and cop! it over the debug version" /ote< If !ou specified !our target settings as /ew RT Target on /etwor*7 LabWindows=-VI will automaticall! download the .LL to the 1T target" If !our target settings specif! RT Target via LabVIEW7 !ou will need to use LabVIEW 1T to download the .LL for !ou" 1efer to the LabVIEW 1T Celp for instructions on how to download .LLs on an 1T target" If !ou are tr!ing to debug a .LL on a 1T target 9regardless of how it was downloaded:7 s2ip the rest of this section" $" 1un -onfigure1emote.ebugging"e,e located in ""OProgram &ilesO@ational InstrumentsO-VI3FObin director! on the target computer" If the e,ecutable is not on the target computer7 !ou can cop! it over from the development machine" >ou can run this e,ecutable onl! after the -VI run?time engine has alread! been copied to the target computer 9see step #: '" @etwor2 port of the debug session" This should match the port on the debugger" )" Enter the IP address or computer name of the debugger" 1emember that !ou must leave the utilit! running during the debugging session" -lic2 Done once !ou are finished debugging"

5ee +lso< -ustomi6ing -reate .istribution Nit Installers in LabWindows=-VI

T'e Deb gging ,ro!ess

The 1emote .ebugger accomplishes its tas2s b! communicating with the debuggee via T-P" With remote debugging enabled7 the debuggee loo2s for the LabWindows=-VI debugger at a

certain IP address" If it is unable to find the debugger7 it continues without debugging" Dnce !ou have setup the debugger and the debuggee7 run the debugger b! clic2ing on the P.ebug ProBectQ button or pressing 5hiftL&5" If !ou specif! !our target settings as /ew RT Target on /etwor*7 LabWindows=-VI will automaticall! download the .LL to the 1T Target and start running the code" >ou can debug the code as it is alread! running" &or the other target settings7 instead of running the code7 the debugger begins waiting for a connection from the debuggee" >ou will see a LabWindows;CVI Deb gger window popup similar to the one below"

@ow launch the debuggee e,ecutable or the application that calls the debuggee .LL" The debuggee connects to the debugger using the networ2 address and port information provided" >ou can now control the application as though it were a regular debugging process7 e"g" !ou can suspend e,ecution on brea2points7 step through code7 loo2 at variables and e,amine watch points" The LabWindows=-VI .ebugger waits for further connections after the debuggee e,its" /ote0 When !ou debug a .LL for LabVIEW 1eal?Time and !ou are waiting for a connection7 !ouQll see a dialog 9see below: when !ou load the corresponding VI in LabVIEW" This happens because when LabVIEW loads a VI7 it also loads all the .LLs called b! the VI" If !ou define .LLmain in !our .LL7 the .LL will connect to the -VI debugger and !ouQll see this dialog" If !ou want to debug the .LL on !our des2top machine7 select .!!e-t" If !ou want to debug the .LL on a real?time target instead7 select Wait" The .LL tries to reconnect after !ou download !our VI to the 1T target"

Tro bles'ooting

Wh! do I get a message sa!ing that m! .LL is out of dateR

The .LL or the application on the debuggee must match the version of that on the debugger" Dtherwise LabWindows=-VI will give !ou a version mismatch error"

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

The debugger must alwa!s be started before the debuggee application" The debuggee onl! chec2s for the debugger once" If it cannot find the debugger7 it continues li2e a normal application without loo2ing for it again"

Wh! doesnQt m! application connect to the -VI debuggerR

-hec2 the connection parameters" Verif! both machines are connected to the networ2" Include the domain name in the networ2 address< m!testF$"m!domain"com (se IP addresses 9e"g" #'F"$55"#F3"#5: instead of machine names in case name resolution doesnQt wor2" If !ou installed !our application through a distribution 2it verif! that the distribution 2it installed the debug version of !our application" %! default7 the release version is used"

Wh! do we wait for additional connectionsR

%ecause we donQt 2now when !ouQre done debugging" &or e,ample7 !ou might create an e,ecutable with V-LL that calls several -VI .LLs" These .LLs connect and disconnect to the -VI debugger in their entr! point functions" -VI doesnQt 2now when the e,ecutable has finished using the -VI .LLs"