Customizing the LabVIEW Development Environment

2002 Jim Kring jim@jimkring.com All Rights Reserved

LabVIEW Tools
After using LabVIEW for a good period of time, a developer or organization will accumulate many tools to help them do their work. These tools will include LabVIEW primitive-like VIs; toolkit-like packages of VIs; instrument drivers; VI, control, and software component templates; application architectures; and edit-time development tools. Fortunately LabVIEW provides several mechanisms to tailor the LabVIEW development environment to suit the working needs of the developer. In this article I will examine those mechanisms and explore ways that the developer can use them to customize their work environment. In the conclusion, I will describe a way to propagate those changes onto LabVIEW installations on other machines. Again, the types of tools that a developer or organization will create can typically be divided into the following categories: LabVIEW Primitive-like Functions - These are small reusable VIs that look and feel like the functions in the default palette, which come stock with LabVIEW. Developers who use LabVIEW daily will often find gaps in the functions found in LabVIEWs palettes and need to augment them. LabVIEW Primitive-like Custom Controls - These are custom control, which are similar to those in the default controls palette. They may be buttons with fancy graphics, or things like the clever codeless radio button that appeared in LTR a long while ago. LabVIEW Toolkit-like Packages - These are groups of VIs that collectively achieve some task. An example would be GOOP classes or any of the GOOP-like synchronization tools such as the queue, semaphore, notifier, and rendezvous as well as LabVIEW add-ons like the PID, Fuzzy Logic, or Internet toolkits. VI and Control Templates - In an effort to save time, when design patterns are common to an organization or repeatedly used by individuals, VI and control templates may be used as a starting ground for development. Software Component Templates These are a collection of VIs that work together to achieve some compartmentalized functionality, like a configuration dialog with configuration data file storage and retrieval. It may have one or more VIs, custom control type definitions, and data files that need to be copied to a new location and possibly renamed while preserving the relative linking of the files Application Architectures - These are project templates or recycled projects. To save time one can reuse entire collections of several tools that have been implemented to solve specific large-scale tasks. Examples might be a data logger, test executive, device controller, etc. Instrument Drivers Companies that work with a specific set of instruments and use them in a specialized manor may develop a custom library of instrument drivers that suit their classes of experiments. They may wish to share one collective set of drivers company-wide. Edit-time Development Tools - These are LabVIEW programs that are designed to run while you are developing in LabVIEW. Some of the best examples of these are tools that 1

ship with LabVIEW, for example the VI Library Manager, Web Publishing Tool, and Application Builder. These are all applications written in LabVIEW that are designed to help you when you are building your own LabVIEW application. Most of the edit time tools that an individual or organization might write would be designed to reduce the time spent doing mundane repetitive tasks like renaming groups of VIs with a common prefix, or changing VI properties of groups of VIs at a time. However, they may also be designed to provide information and insight into the development environment itself. For example, an application might list all VIs in memory or all top-level VIs. It might allow you to select a VI in memory and open the VI by selecting it from the list or edit the VIs properties, such as its VI Info Description or Execution options. With the advent of VI server and hence LabVIEWs introspection capabilities, the possibilities are limitless for new developer tools written purely in LabVIEW.

Customization Options
I have defined the types of tools that one may wish to integrate into the LabVIEW development environment, so now an exploration, is necessary, of the options available for bringing them into the work area. LabVIEW provides some out-of-the-box tools for customizing the LabVIEW development environment, but also has some undocumented and under-documented features that the developer can employ as well.

Custom Palettes
Chapter 3, Section 1 of the LabVIEW User Manual (<LV>\manuals\lvuser.pdf) is entitled Customizing the Controls and Functions Palettes. It describes several mechanisms for modifying the LabVIEW Controls and Functions palettes. The simplest way, and the one that most people are familiar with, is to place their reusable VIs and Controls in the <LV>\user.lib or the <LV>\instr.lib directories. When LabVIEW starts up, it looks in these locations and builds subpalettes and icons reflecting the contents of those locations. The <LV>\user.lib contents are reflected in the Functions User Libraries palette and the <LV>\instr.lib contents are reflected in the Functions Instrument I/O palette. Another option that you have is to add a toolset, (LLB or directory of VIs) to the <LV>/vi.lib/addons folder. These toolsets will appear as subpalettes at the top-level of the Controls and Functions palettes. Lastly, you can create an entire palette view. A palette view allows you exact control of VI and Control icon locations and subpalette icons, names and locations within your custom palette. This is by far the most powerful of the palette customization options, so I will further describe its features. LabVIEW stores all the palette views in the <LV>\menus folder. The menus folder contains subfolders, each of which corresponds to a palette view. Inside the palette view folders are one or more files. Lets take a good look the contents of a palette view folder. root.mnu - This file defines the top-level Functions and Controls palette contents of the palette view. However, LabVIEW will continue to add the contents of <LV>\vi.lib\addons to every palette views root menu readonly.txt - this file, if present, disables some of the palette editing features. It effectively makes the palette view read-only. This file consists only of a carriage return \r character. *.mnu All the other .mnu files in the palette view folder define the palette views subpalettes. It is worth noting that a .mnu files palette can embed any other .mnu files 2

palette, regardless of location. However, if you plan on distributing your custom palette view, you should ensure that any .mnu files that you created or used as subpalettes are located inside the palette views folder. It is bad practice to link to .mnu files that exist inside of other palette views. This could happen if you tried to insert a submenu from an existing .mnu file and you selected the file manually with the file dialog. You could potentially insert, and therefore edit, a palette that belonged to another palette view. The bottom line is: when you create new submenus, make sure that you save your .mnu files in the palette view directory of the one you are editing and dont insert subpalettes from existing .mnu files in other palette view directories.

.mnu file basics

.mnu files define the LabVIEW palettes, so the developer really needs to know what an .mnu file is and what it does. It is useful to understand exactly how they work so that the developer can use them effectively. Lets first take a look at the LabVIEW documentation on palettes and how they are stored on disk. LabVIEW User Manual Excerpt (3-5) How LabVIEW Stores Views The .mnu files and .llb files contain one Controls palette and one Functions palette each. In addition, each file contains an icon for the Controls and Functions palettes. You must store each subpalette you create in a separate .mnu file. When you select a view, LabVIEW checks the menus directory for a directory that corresponds to that view. It builds the toplevel Controls and Functions palettes and subpalettes from the root.mnu file in that directory that LabVIEW automatically creates every time you create a view. For each VI or control, LabVIEW creates an icon on the palette. For each subdirectory, .mnu file, or .llb file, LabVIEW creates a subpalette on the palette. As mentioned in the LabVIEW User Manual Excerpt (3-5) .mnu files and .llb files contain one Controls palette and one Functions palette each. But what exactly is a palette (what information does it contain)? Submenu Name This is the name that will be seen from the palettes parent palette, which embeds the palette as a submenu. You may edit this only from a parent palette by right-clicking on the submenu icon and selecting Rename Submenu, as shown to the right. Palette Icon A palette has an icon that is seen in a parent (another palette that embeds the palette as a submenu). Just like the Submenu Name you may only edit this from a parent palette by right clicking on the submenu Icon and selecting Edit Submenu Icon. VIs/Controls A palette contains information on VIs/Controls (by relative path if beneath the LabVIEW) and their locations on the palette, as well as whether the VIs in the Functions palette are to be Merged. Merge VI is an option that causes the contents of a VI to be added to the target VI instead of adding a subVI to the target. The contents of the selected VI are merged into the target. (this setting is shown to the right) 3

Submenus A palette contains links to other palettes within LLBs or .mnu files and their locations on the palette. Synchronize with Directory - This option, if enabled causes the palette to build itself dynamically on startup based on a specified directorys contents. This option may only be set from a parent palette by right clicking on the submenu icon and selecting Synchronize with Directory. When set to TRUE LabVIEW will ask you to define the directory with which to synchronize.

Lesser-Known Palette and .mnu File Facts

The text that appears as a VIs name in a palette is the VIs default Window Title (Font Panel Window:Title VI server attribute). If the VI or CTLs Window Title is set to Same as VI Name the name will also display the .vi or .ctl extension string when viewed from a palette. This may or may not be desirable to you. You will probably want to rename the Window Title by removing the .vi or .ctl suffix. A palette views name is the name of the palette view folder in the <LV>\menus menus directory. However, this name can be overridden by placing a text file with the same name as the palette views folder (but with a .txt extension, of course) in the menus directory. The text in the first line of this file is used as the name for the palette view. *Note: this name override method occurs frequently in the customization features and it specifically relates to how the Tools and Help menu item names are generated -- this feature will be described in the next section. When you create a palette view, LabVIEW will create a new folder inside the menus folder with the name that you chose for your palette view. The only file that it will initially contain is root.mnu. This file links to .mnu files (subpalettes) in the default palette view (<LV>\menus\default), however, if you edit any of the subpalettes in your new palette view, LabVIEW will create copies of the default .mnu files that you edited and place them in your palette view folder. If you delete your modifications to a .mnu file that LabVIEW copied over from the default palette view folder, such that it is identical to the original file, LabVIEW will delete the copied .mnu file in your palette view folder. *Note: the file may not be identical even if the palettes look the same. If you try to delete the .mnu file manually you may see a ? icon in the parent palette because the parent palette is still linking to the file you deleted. You would then have to relink the parent palette to the .mnu file in the default palette view folder. This is done by first deleting it and then inserting a submenu link to the original .mnu file located inside the default palette view folder. (This is the one exception to the no palettes from other palette views rule mentioned earlier) Sometimes when adding to a subpalette, whose .mnu file does not yet exist in your palette view, LabVIEW will cause that palettes parent to show a ? icon for the submenu you were editing. For example, I added some functions to the Additional String Functions palette. After I saved my changes, the String pallet showed a ? icon for the Additional Strings Functions submenu. This is easily remedied by copying the icon from the default palette. Find the desired submenu icon in the default palette view, right click on it, and chose Copy Icon. Now go back and edit your palette view, edit the missing submenu icon, and paste the icon that you copied from the default palette view. The only way to remove a palette view is to delete its folder inside the menus directory. When you insert a submenu, you can choose to Link to a directory (dialog shown to the right). This will create a 4

file called dir.mnu inside of the folder you select. This .mnu file will have the setting Synchronize with Directory set to true and the target directory set to the .mnu files parent directory. This effectively allows you to create a folder similar to <LV>\user.lib and <LV>\instr.lib. It will automatically generate icons and submenus based on the folders contents. Inside this folder, you can place LLBs, VIs and other folders containing dir.mnu files.

LabVIEW Tools and Help Menus

LabVIEW provides a mechanism, which allows the user to open VIs and help files by selecting them from the Tools and Help pull-down menus. This is a very powerful feature for development tools creation, so I will describe how this works. When LabVIEW starts up it does several things, which include initializing the menus. This is a process where LabVIEW looks for files within specific directories for inclusion in the menus. The <LV>\project and <LV>\help folders are intrinsically related to the Tools and Help menus, respectively. When you install a LabVIEW add-on, you will notice that new menu items are usually added to these two menus. This was achieved by adding files to the <LV>\project and <LV>\help folders. Through a little experimentation the nature of this process has been determined to be the following: First, LabVIEW looks in the <LV>\project and <LV>\help folders for standalone VIs and top-level VIs within LLBs. In the <LV>\help folder, it also looks for .hlp and .chm compiled help files. These files are then opened when selected from the menu. LabVIEW will look recursively Advanced Developer Tip through all subfolders and LLBs There is a private VI server method called looking for these files of interest. Application:Menu Launch VI may be found exposed on However, the search will ignore any the diagram of the "Web Publishing Tool" VIs, folders, or LLBs whose name <LV>\project\webdoc.llb\_Web Document Tool.vi this begins with an underscore _ property returns the last VI to call a Tools menu VI (it character. When the search finds a file doesnt work for Help menu), but returns it only once of interest it will create a menu item at then returns a null string until another Tools menu VI is a location, which reflects where it selected from the menu. Use this feature to create a tool found it in the directory structure that operates on the VI that the user launched it from, like inside the project or help folder. For Check into Source Code Control, or something similar. Example, if it finds the file <LV>\project \Goop Tools\ Rename Goop Class.vi, it will create the menu item Tools GOOP Tools Rename GOOP Class. Here is where a twist is thrown into the naming rules. You can override the names of the VIs, .chm and .hlp files, folders and LLBs so that they are named differently in the menu structure from their names on disk. For VIs, LabVIEW will use the Window Title as the menu name (this is also the VI Server VI:Front Panel Window:Title property). But, by placing a text file with the identical root name ( RootName.vi RootName.txt ) in the same location as the folder or file, you can specify the name LabVIEW should use in the menus. The name you wish to use in the menu should be placed in the text file. For example, if you have a VI called MyBuggyCode.vi, you can make the menu item show up as Elegant Solution by creating a 5

text file called MyBuggyCode.txt that contains the contents Elegant Solution and placing it in the same directory as MyBuggyCode.vi. Note that this override method works for LLBs, folders, .hlp, and .chm files, but for .hlp and .chm files you must also add the characters .hlp or .chm after the menu item name in the overriding text file. The file MyCHM.chm should have an override text file called MyCHM.txt that contains the contents All The Help You Need.chm This will cause its menu name to be All The Help You Need. How does the developer use this feature, whereby they can open VIs and help files from the menu? VIs placed in the Tools menu (<LV>\project folder) should always be set to Run When Opened. This will cause them to look and feel like a functional dialog or tool once they are opened after being selected from the menu. In the Help menu, .chm and .hlp files are opened just as if they had been double-clicked from a file explorer window. However, the developer may want something fancier. There is a function in the Application Control Help palette called Control Online Help. This function may be used to open a help file and have it automatically jump to whichever topic you are interested in by wiring the topic name to the String to search for input. If you have one help file with several topics but want a menu item for each topic, you would want to put a VI inside the <LV>\help folder for each topic and have the VIs call Control Online Help with the appropriate topic argument. Just like the VIs placed in the <LV>\project folder, these VIs should be set to Run when Opened. Another thing you may wish to do is open an online help document located on the Internet or perhaps a PDF file located on local computer. NI does this by calling the VIs <LV>\help\_browser.llb\Open URL In Browser.vi and <LV>\help\_browser.llb\Open Acrobat Manual.vi. If you wish to do the same, you would want to put a VI inside the <LV>\help folder that calls these VIs with the appropriate path or URL arguments.

LabVIEW Templates Folder

VI and control templates (.vit and .ctt files) if placed within the <LV>\templates folder become accessible from the File New menu. LabVIEW gives you the option to create a new VI or control from one of these template files in an easy-to-use menu ring style selector that is filled with all files in the <LV>\templates folder. The use of VI templates in the form of .vit files is not recommended for large project templates. You can place templates as SubVITs inside of a top-level template. When a new VI is created from the top-level .vit, a new top-level and a new subVI are opened, but you now have the tedious chore of manually naming all of the VIs in memory and defining their locations on disk. However, if you simply have a VI shell that you use over and over, this may be a good option for you. The other option is to create your own development 6

tool that will copy a project folder to a new location, load all project files into memory and then rename and relink them according to your project name. The process of renaming and relinking is achieved by doing a Save As starting at the bottom of the hierarchy and working upward. That being said, advanced templates are best left for a development tool application or the next version of LabVIEW ;-)

Integrating Your Tools Into LabVIEW

I have covered many details concerning the minutia of LabVIEWs customization options, so now Ill tie everything together. If you are creating a distribution of tools for your organization you should do something like the following: 1. Create the following folders: <LV>vi.lib\ OrganizationName <LV>project\ OrganizationName <LV>help\OrganizationName <LV>addons\OrganizationName <LV>instr.lib\OrganizationName

2. Create a palette view called OrganizationName. Doing this will create a folder called <LV>menus\OrganizationName 3. Inside <LV>vi.lib\ OrganizationName create a folder tree structure that reflects LabVIEWs default palette structure, and populate the folders with your primitive-like VIs, custom controls, and Toolkit-like Packages. Make sure you place these in a logical folder location, based on where you plan on placing them in your custom palette view. Now add these VIs and custom controls to your custom palette view. Add new submenus where appropriate, and make all your icons look good! They should look similar to LabVIEW-primitive icons, which are simple yet easily interpreted. 4. Inside <LV>project\ OrganizationName depending on how many tools you have you may create a folder tree structure, or simply put all of your VIs and LLBs in the root folder. Make sure to set the VI execution options to Run When Opened for those that open via the menu selection. This will make them feel like a stand-alone application. 5. Inside <LV>help\OrganizationName put your toolsets compiled help file or VIs that will open a PDF or help page on the Internet via a web browser. 6. Inside <LV>addons\OrganizationName put all the Toolkit-like packages that dont naturally fit anywhere except at the root functions palette. These will be specific to your company, such as a widget testing toolkit, or something like that. 7. Inside <LV>instr.lib\ OrganizationName place all of your organizations instrument drivers. 8. Now all that is left are VI and Control Templates, Software Component Templates, and Application Architectures. For the very simple stuff you can just put them in the <LV>templates folder. For the big stuff, you will either have to manually copy a source project/component folder to a new location. You may or may not have to rename the VIs in the hierarchy, depending on if you will have more than one instance opened at a time. Another option is to create a tool, which automates this process. That tool should then be placed inside the <LV>project\ OrganizationName so that it is available from the Tools menu. Installing (uninstalling) your tools distribution is now just a matter of copying (deleting) the above-mentioned folders into another installation of LabVIEW. Automating this is step is easy. The user may have to manually change over to your OrganizationName 7

palette-view, but you can automate that, too, by having the installer change the LabVIEW preferences file menuSetup keys value to OrganizationName. Thats all there is to it! To see a working example of all of these principles in action, visit OpenG.org at http://www.openg.org/ and download the OpenG Toolkit, which contains man-years worth of Open Source LabVIEW tools. All this for the low price of free. Lastly, I would like to thank Albert Given and Jean-Pierre Drolet for their valuable feedback and input into this article. I would also like to thank the community at OpenG.org for the content, inspiration, and feedback needed to create the OpenG Toolkit, which was the underlying reason for accumulating the knowledge contained in this article -- special thanks, in particular to LabVIEW Development Tools project team.