Before using LabVIEW, it is important to set up the environment for maximum productivity. There are a lot of settings in LabVIEW. We do not need to configure everything; the default setting would usually suffice. However, we should at least configure the layout of the Controls palette, the layout of the Functions palette, and the LabVIEW option, before we start coding.
We will start by configuring the Functions palette. Configuring the Controls palette is not shown, but it is similar to configuring the Functions palette. Here are the steps to configure the Functions palette:
To configure the Functions palette, right-click on the block diagram to get the palette and left-click on the thumb pin to pin it down. On the palette, navigate to Customize | View this Palette As, and select your preference on how the palette should be arranged. For this example, select Category (Icons and Text).
In Customize, select Change Visible Palettes..., and then select which categories should appear on the palette. Only the categories that are used frequently should be selected. The unselected categories are still accessible by clicking on the double arrow (pointed down) at the bottom of the palette. The following screenshot shows the Functions palette pinned downed, with the Customize menu activated:
Only the first category of the palette will stay open, so the category that is used the most (Programming) should be at the top. When the palette is pinned down, there is a pair of parallel lines (||) on the left of each category (left of right arrow). The parallel lines are used to move the categories. The following screenshot shows how the Functions palette looks like after the configuration:
In the LabVIEW option, we can configure the LabVIEW environment in detail. The readability and space utilization can be improved. In the block diagram, click on Tools and Options. Under the Block Diagram category, deselect the Place front panel terminals as icons to save space on the block diagram, and then select Use transparent name labels for a cleaner block diagram. The size of controls and indicators are reduced in the block diagram, and the name labels look cleaner in the block diagram compared to the name labels that are opaque. The following screenshot shows the LabVIEW option dialog:
The palette settings and LabVIEW options are not saved locally in the VI (Virtual Instrument) file that contains both the block diagram and front panel. They are saved globally, so every time a new VI is created, the saved settings and options would apply. Inside the LabVIEW installation folder, a file called
LabVIEW.ini resides. The file contains all the saved settings and options and is loaded when LabVIEW starts. If we wish to transfer the settings from one computer to another, we can save this file and transfer it to the same location in the other computer.
For both the Controls and Functions palette, only what are necessary should be on them, and the rest should be hidden. The Controls palette is for the front panel, and the Functions palette is for the block diagram. We will only demonstrate how to set up the Functions palette, but keep in mind that the same procedures apply for setting up the Controls palette.
The quick drop feature was introduced in LabVIEW 8.6. Previously, finding a function would require navigating and searching through the palette. With quick drop, finding a function can be done through a text-based search without going through the palette. To do a search, the name of the function is entered and, as it is entered, a list of possible functions would appear for the user to choose. To make searching easier, a function can be associated with a keyboard shortcut, and to make quick drop even more amazing, repetitive tasks can be associated with a keyboard shortcut.
We will start by associating the while loop function with a keyboard shortcut. Here are the steps to do that:
Press Ctrl + spacebar to invoke quick drop and click on Shortcut. As an example, we will associate shortcut W + L to the while loop. Under Diagram Shortcut, enter wl. Under Diagram Shortcut Object, enter While Loop. If we are unsure about the name of the function, we can always find the function inside the palette and look for its name. Finally, we click on Add and then on OK to add the customized shortcut into the quick drop configuration. The following screenshot shows how the shortcut is added:
Besides finding functions quickly, we can assign a shortcut to a plugin that accomplishes predefined tasks.
To execute a plugin via shortcut, we press Ctrl + Space and the shortcut of the plugin. Built-in shortcuts are available for routine tasks. The following are a few examples of built-in shortcuts:
Ctrl + Space and then Ctrl + D creates all controls and indicators for a subVI
Ctrl + Space and then Ctrl + R deletes a subVI, while also cleaning up all unnecessary wires and re-connecting broken ones
Ctrl + Space and then Ctrl + T moves the labels of all controls and indicators to their left and right
If built-in plugins are not adequate, we can customize our own plugin and assign a shortcut to it.
To make a plugin, use the template in
LabVIEW\resource\dialog\QuickDrop\QuickDrop Plugin Template.vias a starting point. After the plugin is completed, it needs to be placed within
LabVIEW Data\Quick Drop Plugins. If the plugin is placed within the
LabVIEWfolder, it will only be available to that version of LabVIEW. If the plugin is placed into the other path, versions of LabVIEW from 2010 and up can use the plugin. Follow the previous step to assign a shortcut to a plugin.
When a shortcut is associated with a function or a task, the shortcut is saved in the LabVIEW configuration so that it can be used again.
For useful plugins that are made by other LabVIEW users, please visit the link https://decibel.ni.com/content/groups/quick-drop-enthusiasts?view=documents.
Many features exist in LabVIEW for debugging a program. Text-based programmers should already be familiar with some of the features, such as step in, step out, and so on, but there are some features that may sound unfamiliar.
Before jumping into the code, let's check the obvious:
Examine the run button (a right arrow) on the block diagram to see if it is broken or not. If it is broken, click on it to see a list of problems that we must fix. If we double-click on an item of the list, LabVIEW will bring us to the location of the problem. We need to fix all the problems first before we can go further. To see what a broken arrow looks like, open a new VI and place an
addnode under the Numeric palette to it. Click on the broken arrow to see what the cause of the broken arrow is.
After the run arrow turns solid, we can start debugging the program. First, we turn on Retain Wire Values by clicking on its button on the block diagram toolbar. This will enable us to examine the values in all the wires. Then we navigate to the location of interest and set a breakpoint by right-clicking on the location, selecting Breakpoint, and Set Breakpoint.
After we set up the program for debugging, click on the run arrow to run the program. The program will pause at the breakpoint. If we placed our breakpoint on a SubVI, we can choose to step over it, so that we stay on our current VI without going deeper; or we can step into it, so that we go into the subVI for further investigation. If we are already in a subVI and we want to get out, we can step out of it. To step into, step over, or step out, we can click on the corresponding button on the block diagram toolbar. The following screenshot shows the portion of the block diagram toolbar discussed:
To examine the value of a wire, right-click on the wire and select Probe. A dialog will pop up and show the wire's value. When the program has not sent data through that wire, the value is not populated. Once the value is populated, it will show up in the dialog. With the probe, we can view the data within the wire, but we cannot modify it.
To activate Highlight Execution , we click on its button on the block diagram toolbar. This feature allows us to view how the data is actually flowing in the program, but our program will slow down. Many LabVIEW programmers find this useful because it allows them to grasp how the data flows in a VI.
Custom probe is an enhancement to the generic probe which only allows users to examine the value of a wire. A custom probe is able to pause the program using conditional statements inside the probe. By doing that, the custom probe acts like a conditional breakpoint. Also, it can process and extract information from the raw data to facilitate the debugging process.
We will create a custom probe with a VI that is built-in to LabVIEW installation. The following are the steps to do that:
We will use the code shown in the following screenshot to set up the custom probe. The code contains an outer while loop that executes the inner for loop continuously. The inner for loop would generate an array of 0 to 10 elements randomly, and each element would contain a random number between 0 to 30. In this example, we want the execution to pause when the array generation contains more than 9 elements.
To create a custom probe, right-click on the wire feeding the U32 array indicator and navigate to Custom Probe | New. When a dialog appears, select Create a probe from an existing probe and click on Next. A dialog with a list of probes would appear. From the list, in our example, we select the Conditional Unsigned32 Array Probe. When a probe is selected, a detailed description about the probe is shown below the list. This is how we determine whether an existing probe is suitable for our application or not. When we click on Next, the next page appears, and we enter
u32arrayas Filename and leave all other options at the default setting. We click on Save. See the following screenshot to initiate the setup:
We have created a custom probe for our application based on an existing one from the LabVIEW installation. To try out the custom probe, we right-click on the wire feeding the U32 array indicator and select Custom Probe |
u32array.vi. The Probe Watch Window appears; on the right side, it contains a tab control with two tabs. The first tab shows the data and the size of the array. The size of the array is a function for this custom probe. It is not present in a generic probe. The second tab contains all the conditions that we can set to stop the execution of the program. For our example, we will set the check box to make Number of element as the criterion, and set the criteria to greater than nine. After we finish the custom probe setup, we click on the run button to start the program. Since we put a
Wait Until Next ms Multiplenode and set it at equal to 1000ms, the outer while loop will iterate once every second. While the program is running, we can go to Probe Watch Window and look at the data. Once the criterion is met, the program would pause, and we can probe other wires on the block diagram if we want to.
When we created a custom probe based on an existing probe, we can use the probes located in the
vi.lib folder of the LabVIEW installation folder. To use a custom probe, we should save the probe in the
\default folder located at
<LabVIEW>\user.lib\_probes or the
Probes folder located at
<Documents>\LabVIEW Data\. If the probe is saved in the first path (the
default folder), LabVIEW will use that custom probe as the default probe for that particular data type.
The machine where we will deploy our code usually does not have LabVIEW development software. To deploy our code, we need to install LabVIEW run time engine with the correct version (free of charge), and deploy an executable instead of deploying a set of VI.
To create a project, the easiest way is to select Create Project and then Blank Project at the startup screen. Or, if we already have a VI, we can select Project | Create Project | Blank Project. Within the project, right-click on My Computer and select New | VI. Now the VI is within the project, we will create a VI called
EXEvi.vito calculate a 1 cycle sinusoidal waveform with given amplitude, phase, and frequency. It contains an event structure with an event case that will execute when the Read File Boolean control is clicked. See the following screenshot for the example:
The subVI, SinWave.vi, in the preceding example takes the input parameters to calculate the sampling rate and number of samples for one cycle of waveform before using the Sine Waveform.vi to generate the waveform. Refer to Chapter 3, Working with Common Architectures for creating a subVI. See the following screenshot:
To compile the executable, right-click on Build Specifications and select New | Application (EXE) within the project. The My Application Properties dialog will pop up and we will set up each category of the dialog. In the Information category, we enter
ExeExampleBuildunder the Build Specifications name. That name would appear under Build Specification within our project. We enter
ExeExample.exeunder the Target filename, and that is the actual name of the executable. For the Destination directory, enter a convenient location for development.
In the Source Files category, select EXEvi.vi, and click on the right arrow next to Startup VIs so that the VI will appear when the executable is invoked. As for Always Included, if the program calls VI dynamically or by reference, works with files, and so on, we can include these dependencies that the program uses. Since the subVI, SinWave.vi, is part of the program, the compiler knows that it needs to include the subVI in the compilation without specification.
Under Destinations, we will leave everything as default. If we have dependencies (subVIs, files, and so on), we can choose where to place them relative to the executable. The dependencies can either go into the executable or into a support directory. We can add additional destinations if we so desire. In this category, we are configuring all the destinations where the files can go.
Under Source File Settings, we can choose how the files are included with the executable. If we click on EXEvi.vi, we see that Inclusion Type is Startup VI, since we have already specified the same under the Source Files category. The destination of Startup VI is the executable itself, which means the Startup VI is not located at
...\ExeExample.exe\EXEvi.vi. For SinWave.vi, we will use the default setting. The default setting will put the subVI inside the executable as well. The following screenshot shows how the project looks like with executable:
Sometimes, our code will work perfectly in the development environment, but will fail miserably when we deploy and run its executable on another computer. When that happens, we can put more indicators into the VI to display data at relevant locations of the program. Then, we can re-compile the executable and use the extra data to find the bug. If that still does not work, we can step through the executable similar to what we do in the development environment.
If our code works perfectly in development, but fails miserably after deployment in the executable mode, how do we debug the executable?
We do not have the LabVIEW development software on the machine where we deploy the executable, so how do we step through the executable? We will connect to the machine where the EXE is deployed (EXE machine) from another computer that has the LabVIEW development software installed (DEV machine). The two computers must be on the same network; we verify their connection by issuing the
pingcommand in the command prompt with the EXE machine's IP address from the DEV computer. See following screenshot for an example:
After we verify that we can ping the EXE machine from the DEV machine, we need to recompile the executable with Enable debugging option selected, so that the block diagram is compiled into the executable for debugging purposes. The option is inside executable properties and under the Advanced category. Within Enable debugging option, there is another option that we can select; it is Wait for debugger on launch. If we select that option, when we double-click on the executable to run it, it will not run and will wait for the debugger to connect. For our example, we will only select Enable debugging option.
On the EXE machine, double-click on your executable to run it. While it is running, open the LabVIEW development system on the DEV machine. In the startup window, select Operate | Debug Application or Shared Library. The Debug Application or Shared Library dialog appears, and we enter the IP address of the EXE machine and click on Refresh. Under Application or shared library, the name of the executable that is running on the EXE machine will appear, click on Connect. See the following screenshot for an example:
After the connection is established, the front panel of the executable will appear on the DEV machine. On the front panel, we right-click and select Remote Debugging | Show Block Diagram. See the following screenshot for an example. When the block diagram is shown, we can use all the debugging tools in LabVIEW.
If we cannot make the connection, the EXE machine could have a firewall that is preventing the DEV machine from connecting. To resolve this problem, we can open port 3580 through the Windows Firewall for NI Service Locator. If this approach fails, we can install the LabVIEW development software in the EXE machine and connect to the local host (to itself) for debugging.
After we compile an executable and deploy it on a machine, we cannot run the executable immediately. We must set up the machine with the correct software before we can run the executable. It is troublesome if we have to install multiple software on the machine before we can run the executable. In this recipe, we will learn how to package the executable with the required software into one installer, so that we only need to double-click on the installer and everything will be installed automatically.
A standalone application is just an installer that comprises an executable and drivers required by the executable. We will use an executable that we created previously.
We will open the project ExeExample.lvproj from the recipe where we learned how to compile an executable. We right-click on Build Specification and select New | Installer; the My Installer Properties dialog, where we can set up the properties of the installer, appears.
In the Product Information category, we specify the Build specification name with
ExeExampleInstaller, Product name with
ExeExample, and Installer destination with a convenient place for the example.
In the Destination category, we can set up where the content of our program will go. We will use the default setting, and that will create a folder inside the Program Files folder in your local drive.
In the Source Files category, we select the executable and all relevant files on the left and transfer them to the right.
In a compiled standalone application, it can be sent as an installer to deploy onto another machine. In the installer, everything that is needed to execute a program is included. The user only needs to double-click on the received installer, and the program with all its dependencies will be installed automatically.
In the Additional Installers category, we select all the additional installers that our program needs during execution. At the very least, the NI LabVIEW Run-Time Engine is needed. If you used other features such as DAQmx, VISA, FPGA, and so on, more installers will be needed. If you are unsure about what is needed, click on each installer and read its description to see whether the installer describes a feature in our code or not.