VIs: Names and Properties

Contents

Name the LabVIEW Library with a Descriptive Name, Which Will Be Used to Namespace the Instrument Driver VIs Contained within that Library (.lvlib)

The driver identifier uniquely identifies your instrument driver and the instruments supported by the driver. The driver identifier is used for naming of the project libraries, project library files, and other driver files. The driver identifier should be the manufacturer name followed by the instrument model or the manufacturer name followed by a name that represents a family of instruments as branded by the vendor. It should not contain the instrument revision such as A, B, E punctuation or special characters.

The following list includes examples of driver identifiers for instrument drivers.

  • Agilent ESG Series—The Agilent instrument driver for the ESG series signal generators.
  • Agilent 33XXX Series—The Agilent instrument driver for the 33120A, 33220A, and 33250A family of function generators.
  • Tektronix TDS 3000 Series—The Tektronix instrument driver for the TDS 3000 series oscilloscopes.
  • Yokogawa 2533—The Yokogawa instrument driver for the 2533 power meter.

Use a Consistent Naming Convention for all Instrument Driver VIs

  • Use meaningful names that describe what operation the VI performs.
  • Use complete English words unless an abbreviation is known by users worldwide.
  • Name each VI with the base functionality first. Use a verb for the base name.(e.g., Configure, Query, and Read).
  • (Recommended) Use book title form (example: Fluke 45 Read Measurement).

Most users access VIs through the LabVIEW Functions palette. However, often users access the VI through a file dialog or explorer, so use a consistent naming methodology to help users identify VIs.

For example, in the Fluke 45 driver Configure Display and Configure Math would be correct, but Display Configure or Math Configure would not be correct.

Be sure to use consistent capitalization because that helps users organize the VIs in a file dialog, especially in file dialogs on operating systems that are case sensitive.

Use Polymorphic VIs to Enhance and Condense the Driver API

Recommended

If you create polymorphic VIs, name each instance subVI the same as the top-level VI name and indicate the differences such as data types, trigger types, and so on in parenthesis. Do not use the word "Polymorphic" in the VI name. An example would be to have a polymorphic VI named Read.vi with the instance VIs named Read (Multiple) and Read (Single). Also use polymorphic VIs to implement similar functionality on data for a variety of data types.

Do Not use the Word "Example" in the Name of API VIs

Name VIs with Characters All Operating Systems Accept in File Names. For Example, Do Not Use Special Characters, Such as /, \\, :, ', ", ~, +, |, <, >, and &

Name VIs with alpha-numeric characters only. A special character, such as /, \\, or ~, might be an operator on other file systems, which can cause problems if the VI is saved outside of a VI library and opened on a different operating system.

Use LabVIEW Default Settings in the VI Properties Dialog Box

Do not select options to make the panel automatically show or run.

You use the VI Properties dialog box to customize the settings for a VI. In most cases, use the default settings for the options in this dialog box. Enter documentation for the VI in the Documentation page of the dialog box. The following list includes some key property options and their recommended settings.

  • Protection: Unlocked—Give users must access to the source code so they can add functionality or customize the instrument driver.
  • Window Appearance: Default—The default settings ensure that instrument driver VIs appear the same as all other VIs used in the LabVIEW development environment.
  • Execution: Check Allow Debugging—Allows users to access debugging capabilities so they can easily detect and resolve cable issues, instrument address complications, and configuration problems.
  • Execution: Disable Reentrant execution—Setting a VI to reentrant execution increases memory usage because each call to a re-entrant VI is a copy of that VI, including memory buffers. Also it is difficult to debug reentrant VIs. Setting a VI to reentrant benefits only those customers interested in making simultaneous access calls to identical instruments. Customers who require increased performance should change this property when they need to.
  • Execution: Same as Caller—Set the Preferred Execution System to Same as Caller. The task priority varies based on application needs. Therefore, the end user should adjust the priority based on his or her application needs.
  • Execution: Uncheck Enable automatic error handling—This should be the default setting for each VI you create if you set your environment to disable automatic error handling for new VIs. LabVIEW, by default, enables automatic error handling to help new users debug their VIs. Handling errors in your API VIs using the error in and error out cluster parameters ensures errors are properly reported to users.
  • Execution: Uncheck Run when Opened—When used interactively, users should control when the VI runs.
  • Execution: Uncheck Suspend when Called—Instrument Driver VIs never should be suspended when called.

If you Use LabVIEW Revision History, Reset the History When Releasing Version 1.0 of the Driver

Recommended

Before releasing version 1.0 of an instrument driver, clear the revision history of each VI. This facilitates version tracking each time someone updates the driver. To clear the revision history, choose VI Revision History from the Tools menu and click on the Reset button. Choose Yes to reset the revision number. Then close the revision history window and save the VI. Consider using the Invoke Node and the Clear History method to reset the revision history for a collection of VIs. Refer to Programmatically Controlling VIs in the LabVIEW Help for more information about configuring VIs programmatically.

Was this information helpful?

Yes

No