LabVIEW Basics II Course Manual
LabVIEW Basics II Course Manual
Course Manual
Copyright
Copyright © 1993, 2000 by National Instruments Corporation,11500 North Mopac Expressway, Austin, Texas 78759-3504.
Under the copyright laws, this publication may not be reproduced or transmitted in any form, electronic or mechanical, including
photocopying, recording, storing in an information retrieval system, or translating, in whole or in part, without the prior written consent
of National Instruments Corporation.
Trademarks
LabVIEW™, National Instruments™, and ni.com™ are trademarks of National Instruments Corporation.
Product and company names mentioned herein are trademarks or trade names of their respective companies.
Worldwide Technical Support and Product Information
ni.com
Worldwide Offices
Australia 03 9879 5166, Austria 0662 45 79 90 0, Belgium 02 757 00 20, Brazil 011 284 5011, Canada (Calgary) 403 274 9391,
Canada (Ontario) 905 785 0085, Canada (Québec) 514 694 8521, China 0755 3904939, Denmark 45 76 26 00,
Finland 09 725 725 11, France 01 48 14 24 24, Greece 30 1 42 96 427, Germany 089 741 31 30, Hong Kong 2645 3186,
India 91805275406, Israel 03 6120092, Italy 02 413091, Japan 03 5472 2970, Korea 02 596 7456, Mexico (D.F.) 5 280 7625,
Mexico (Monterrey) 8 357 7695, Netherlands 0348 433466, New Zealand 09 914 0488, Norway 32 27 73 00,
Poland 0 22 528 94 06, Portugal 351 1 726 9011, Singapore 2265886, Spain 91 640 0085, Sweden 08 587 895 00,
Switzerland 056 200 51 51, Taiwan 02 2528 7227, United Kingdom 01635 523545
Contents
Student Guide
A. About This Manual ............................................................................................... SG-1
B. What You Need to Get Started ............................................................................. SG-3
C. Installing the Course Software.............................................................................. SG-4
D. Course Goals and Non-Goals ............................................................................... SG-5
E. Course Map........................................................................................................... SG-6
F. Course Conventions.............................................................................................. SG-7
Lesson 1
Planning LabVIEW Applications
A. The Planning and Design Process......................................................................... 1-2
B. The Implementation Process................................................................................ 1-3
C. Error Handling Techniques................................................................................... 1-4
D. LabVIEW Programming Architectures ................................................................ 1-10
E. VI Templates ........................................................................................................ 1-21
Summary, Tips, and Tricks......................................................................................... 1-24
Lesson 2
Designing Front Panels
A. Basic User Interface Issues................................................................................... 2-2
B. Using Boolean Clusters as Menus ........................................................................ 2-14
C. Property Nodes ..................................................................................................... 2-24
Common Properties .................................................................................................... 2-27
D. Graph and Chart Properties .................................................................................. 2-37
E. Control References ............................................................................................... 2-46
F. LabVIEW Run-Time Menus (Optional)............................................................... 2-51
G. Intensity Plots ....................................................................................................... 2-60
Summary, Tips, and Tricks......................................................................................... 2-64
Additional Exercises................................................................................................... 2-65
Lesson 3
Data Management Techniques
A. Data Management Techniques in LabVIEW........................................................3-2
B. Local Variables .....................................................................................................3-4
C. Global Variables ...................................................................................................3-14
D. Important Advice about Local and Global Variables ...........................................3-23
E. DataSocket ............................................................................................................3-26
Summary, Tips, and Tricks.........................................................................................3-35
Additional Exercises ...................................................................................................3-36
Lesson 4
Advanced File I/O Techniques
A. Working with Byte Stream Files ..........................................................................4-2
B. LabVIEW Datalog Files .......................................................................................4-13
C. Streaming Data to Disk.........................................................................................4-20
Summary, Tips, and Tricks.........................................................................................4-21
Additional Exercises ...................................................................................................4-22
Lesson 5
Developing Larger Projects in LabVIEW
A. Assembling a LabVIEW Application ...................................................................5-2
B. LabVIEW Features for Project Development.......................................................5-13
C. LabVIEW Tools for Project Management............................................................5-21
Summary, Tips, and Tricks.........................................................................................5-35
Additional Exercises ...................................................................................................5-36
Lesson 6
Performance Issues
A. LabVIEW Multithreading and Multitasking Overview........................................6-2
B. The Profile Window..............................................................................................6-6
C. Speeding Up Your VIs..........................................................................................6-12
D. System Memory Issues .........................................................................................6-25
E. Optimizing VI Memory Use .................................................................................6-28
Summary, Tips, and Tricks.........................................................................................6-46
Appendix
A. Polymorphic SubVIs.............................................................................................A-2
B. Custom Graphics in LabVIEW.............................................................................A-7
C. The LabVIEW Web Server...................................................................................A-14
D. Additional Information .........................................................................................A-20
E. ASCII Character Code Equivalents Table ............................................................A-22
Thank you for purchasing the LabVIEW Basics II course kit. You can begin
developing an application soon after you complete the exercises in this
manual. This course manual and the accompanying software are used in the
two-day, hands-on LabVIEW Basics II course. You can apply the full
purchase of this course kit towards the corresponding course registration fee
if you register within 90 days of purchasing the kit. Visit the Customer
Education section of ni.com for online course schedules, syllabi, training
centers, and class registration.
The course manual is divided into lessons, each covering a topic or a set of
topics. Each lesson consists of the following:
• An introduction that describes the purpose of the lesson and what you
will learn
• A description of the topics in the lesson
• A set of exercises to reinforce those topics
• A set of additional exercises to complete if time permits
• A summary that outlines important concepts and skills taught in the
lesson
If you do not have this hardware, you still can complete most of the
exercises. Be sure to use the demo versions of the VIs when you are working
through exercises. Exercises that explicitly require hardware are indicated
with an icon, shown at left. You also can substitute other hardware for those
previously mentioned. For example, you can use another National
Instruments DAQ device connected to a signal source, such as a function
generator.
Each exercise shows a picture of a finished front panel and block diagram
after you run the VI, as shown in the following illustration. After each block
diagram picture is a description of each object in the block diagram.
1 2
Filename Description
LVB2SW.exe Self-extracting archive containing VIs used in the
course
LVB2Sol.exe Self-extracting archive containing completed course
exercises
LVB2Read.txt Text file describing how to install the course software
Windows
1. Run the program called LVB2SW.exe. The course files will be extracted
to the c:\exercises\LV Basics 2 directory:
Basics2.llb will be installed in the LabVIEW\user.lib directory.
When you launch LabVIEW, a palette called Basics 2 Course will be in
the User Libraries palette of the Functions palette.
2. (Optional) Double-click LVB2Sol.exe to install the solutions to all
exercises in the c:\solutions\LV Basics 2 directory.
Macintosh
1. As shown in steps 1 and 2 of the Windows installation, use a
Windows-based PC to extract the files and transfer them to your
Macintosh. If you do not have access to a PC, contact National
Instruments for uncompressed files.
2. Copy the files to your hard disk using the directory structure described
in the Windows section.
UNIX
1. As shown in steps 1 and 2 of the Windows installation, use a
Windows-based PC to extract the files and transfer them to your
workstation. If you do not have access to a PC, contact National
Instruments for uncompressed files.
2. Mount the PC disk you are using to transfer the files. The course
assumes the directory structure described in the Windows section.
Copy all files to the appropriate location.
The project you will build must meet the following criteria:
• Provides a menu-like user interface.
• Requires the user to log in with a correct name and password.
• If the user is not correctly logged in, other features are disabled.
• Acquires data with the specified user configuration.
• The user can analyze a subset of data and save the results to a file.
• The user can load and view analysis results previously saved to disk.
The following course map contains notes about the parts of the project you
will develop in various sections of the course. Exercises within the lessons
also remind you when you are working on a VI used in a later exercise.
E. Course Map
Planning
LabVIEW Develop flowchart for
Applications Application Exervise VI
Build Login VI
Data Management
Techniques
Performance
Issues
F. Course Conventions
The following conventions appear in this course manual:
» The » symbol leads you through nested menu items and dialog box options
to a final action. The sequence File»Page Setup»Options directs you to pull
down the File menu, select the Page Setup item, and select Options from
the last dialog box.
bold Bold text denotes items that you must select or click in the software, such as
menu items and dialog box options. Bold text also denotes parameter names,
controls and buttons on the front panel, dialog boxes, sections of dialog
boxes, menu names, and palette names.
monospace Text in this font denotes text or characters that you should enter from the
keyboard, sections of code, programming examples, and syntax examples.
This font is also used for the proper names of disk drives, paths, directories,
programs, subprograms, subroutines, device names, functions, operations,
variables, filenames and extensions, and code excerpts.
Platform Text in this font denotes a specific platform and indicates that the text
following it applies only to that platform.
Process
Test & Release
Define Project Customer
Final Product
Feedback
Implement
Test SubVIs
Nodes as VIs
Top-Down Bottom-Up
Designing a flow diagram can help you visualize how your application
should operate and set up the overall hierarchy of your project. Because
LabVIEW is a data flow programming language and its block diagrams are
similar to typical flowcharts, it is important to carefully plan this chart. You
can directly implement many nodes of the flowchart as LabVIEW subVIs.
By carefully planning the flowchart before implementing your LabVIEW
application, you can save development time later.
After you build and test the necessary subVIs, you will use them to complete
your LabVIEW application. This is the bottom-up portion of the
development.
The previous example illustrates a typical usage of the error in/error out
approach. That is, the File I/O VIs and functions use error clusters to pass
information from one operation to the next. You can then use the error
handling VIs from the bottom row of the Time & Dialog palette to notify
the user of any error conditions that occur.
The General Error Handler VI also accepts the error in cluster or the error
code value and a dialog box of the type specified appears when an error
occurs. However, in addition, you can set up error exception lists so that
specified errors are cleared or set when they occur. You also can use the
General Error Handler VI to add errors to the internal error description table.
The error description table describes all errors for LabVIEW and its
associated I/O operations. Therefore, you can add your own error codes and
descriptions to the error handler VIs. Refer to the LabVIEW Help for
information about how to modify your error handler VIs.
When an error occurs, the Simple Error Handler and General Error Handler
VIs open a dialog box that displays the information contained in the error
cluster and possible reasons for that error as listed in the internal error
description table.
The Merge Errors VI looks at the incoming error clusters or the array of
error clusters and outputs the first error found. If no errors occur, LabVIEW
returns the first warning message, error code is a positive value. Otherwise,
LabVIEW returns a no error condition.
As shown in the previous example, you place the code you wish to run in the
No Error case and then define the error out value for that case depending
upon what is occurring in that case.
In the next exercise you will build a VI that generates data, analyzes those
data, and presents the data to the front panel while using error clusters
appropriately.
You will build a VI that generates a noisy sine waveform, computes the
frequency response of those data, and plots the time and frequency
waveforms in waveform graphs. You will use the error clusters and the error
handling VIs to properly monitor error conditions.
Front Panel
Block Diagram
3. Open and build the block diagram using the following components.
a. Place a While Loop located on the Functions»Structures palette on
the block diagram. This structures the VI to continue to generate and
analyze data until the user clicks the Stop button. Right-click the
Conditional terminal and select Stop If True.
b. Place the Sine Waveform VI located on the Functions»
Analyze»Waveform Generation palette on the block diagram.
This VI generates a sine waveform with the specified frequency,
amplitude, and sampling information. To create the sampling info
cluster control, right-click that input terminal and select
Create»Control from the shortcut menu.
c. Place the Uniform White Noise Waveform VI located on the
Functions»Analyze»Waveform Generation palette on the block
diagram. This VI generates a waveform of uniform white noise
specified by the amplitude and sampling information.
d. Place the Merge Errors VI located on the Functions»Time &
Dialog palette on the block diagram. This VI combines the error
clusters coming from the Sine and Noise VIs into a single error
cluster.
e. Place the Add Waveforms VI located on the Functions»
Waveform»Waveform Operations palette on the block diagram.
This function adds the two waveforms to obtain a noisy sinewave.
f. Place the FFT Power Spectrum VI located on the Functions»
Analyze»Waveform Measurements palette on the block diagram.
This VI calculates the frequency response of the time waveform
input and averages the data according to the specified averaging
parameters. To create the averaging parameters cluster control,
You can structure VIs differently depending on what functionality you want
them to have. This section describes some of the common types of VI
architectures, along with their advantages/disadvantages—simple, general,
parallel loops, multiple cases, and state machines.
Simple VI Architecture
When doing calculations or making quick lab measurements, you do not
need a complicated architecture. Your program might consist of a single VI
that takes a measurement, performs calculations, and either displays the
results or records them to disk. The Simple VI architecture usually does not
require a specific start or stop action from the user and can be initiated when
the user clicks the run arrow. In addition to being commonly used for simple
applications, this architecture is used for functional components within
larger applications. You can convert these simple VIs into subVIs that are
used as building blocks for larger applications.
The previous front panel and block diagram example is the Convert C to
F VI built in the LabVIEW Basics I course. This VI performs the single task
of converting a value in degrees Celsius to degrees Fahrenheit. You can use
this simple VI in other applications that need this conversion function
without needing to remember the equation.
General VI Architecture
In designing an application, you generally have up to three main phases:
The following block diagram shows this general architecture. For simple
applications, the main application loop can be fairly straightforward. When
you have complicated user interfaces or multiple events, such as, user
action, I/O triggers, and so on, this section can get more complicated. The
next few illustrations show design strategies you can use to design larger
applications.
Notice in the previous block diagram that the error cluster wires control the
execution order of the three sections. The While Loop cannot begin running
until the Startup VI is finished running and returns the error cluster.
Consequently, the Shutdown VI cannot run until the main program in the
While Loop is finished and the error cluster is passed out of the loop.
Another thing to notice in the previous block diagram is the wait function.
A wait function is required in most loops, especially if that loop is
monitoring user input on the front panel. Without the wait function, the loop
might run continuously so that it uses all of the computer's system resources.
The wait function forces the loop to run asynchronously even if the wait
period is specified as zero milliseconds. If the operations inside the main
loop react to user inputs, then the wait period can be increased to a level
acceptable for reaction times. A wait of 100–200 ms is usually good as most
users will not detect that amount of delay between pushing a button on the
front panel and the subsequent event executing.
This structure is straightforward and appropriate for some simple menu type
VIs where a user is expected to select from one of several buttons that lead
to different actions. This VI architecture also has an advantage over other
techniques in that taking care of one event does not prevent you from
responding to additional events. For example, if a user selects a button that
causes a dialog box to appear, parallel loops can continue to respond to I/O
events. Therefore, the main advantage of the Parallel Loops VI architecture
is its ability to handle simultaneous multiple independent processes.
for the second loop in the previous block diagram is a local variable. You
cannot use wires to pass data between loops, because that would prevent
the loops from running in parallel. Instead, you have to use some global
technique for passing information between processes. This can lead to race
conditions where multiple tasks attempt to read and modify the same data
simultaneously resulting in inconsistent results and are difficult to debug.
Note Refer to Lesson 3, Data Management Techniques, of this course for more
information about global variables, local variables, and race conditions.
An advantage of this VI architecture is that you can use wires to pass data.
This helps improve readability. This also reduces the need for using global
data, and consequently makes it less likely that you will encounter race
conditions. You can use shift registers on the loop border to remember
values from one iteration to the next to pass data as well.
In this architecture, you design the list of possible events, or states, and then
map that to each case. For the VI in the previous block diagram, the possible
states are startup, idle, event 1, event 2, and shutdown. These states above
are stored in an enumerated constant. Each state has its own case where you
place the appropriate nodes. While a case is running, the next state is
determined based on the current outcome. The next state to run is stored in
the shift register. If an error occurs an any of the states, the shutdown case is
called.
The VI structures will get much more complicated as applications get larger
and many different hardware types, user interface issues, and error checking
methods are combined. However, you will see these same basic
programming architectures used. Examine the larger examples and demos
that ship with the LabVIEW application and write down which common VI
architecture is used and why. Additional resources for making LabVIEW
applications are described in the LabVIEW Development Guidelines
manual.
Next you will build a VI that uses the Simple VI architecture to verify the
name and password of a user.
Front Panel
1. Open a new VI and build the previous front panel. Modify the string
controls as described in the labels by right-clicking the control. The
Table control located on the Controls»List & Table palette is a
two-dimensional array of strings where the first cell is at element 0,0.
2. Enter the information shown in the previous front panel in the Table and
save those values as default by right-clicking the Table and selecting
Data Operations»Make Current Value Default from the shortcut
menu.
Block Diagram
3. Open and build the previous block diagram using the following
components.
a. Place a While Loop located on the Functions»Structures palette on
the block diagram. This structures the VI to continue checking for a
match until a name match occurs or there are no more rows in the
table. Notice that indexing is enabled on the names array but not on
the other two items entering the While Loop. Enable the indexing by
right-clicking the tunnel and selecting Enable Indexing from the
shortcut menu.
b. Place a Case structure located on the Functions»Structures palette
on the block diagram. If the Name input matches a listing in the first
column of the table, the Passwords are also checked. If the Name
does not match the current table entry, the loop continues to the next
iteration.
To create the Boolean constant in the False case, wait until the True
case is completely wired. Then select the False case and right-click
the green outlined tunnel and select Create»Constant from the
shortcut menu.
c. Place the Index Array function located on the Functions»Array
palette on the block diagram. This function is used to pull the names
array out of the table. When you wire the table to the array input of
this function, two indices—rows and columns— appear. Right-click
the bottom index, columns, and select Create»Constant from the
shortcut menu. You will use two of these functions, so make a copy
of the Index Array function and place it into the True Case.
d. Place the Array Size function located on the Functions»Array
palette on the block diagram. This function returns the size of the
names array.
e. Place the Decrement function located on the Functions»Numeric
palette on the block diagram. This function decreases the number of
names in the array by one so that it can control the While Loop
which starts indexing at 0.
f. Place the Equal? function located on the Functions»Comparison
palette on the block diagram. You will use two of these functions to
check if the Name input matches a table entry and if the Password
also matches the table entry.
g. Place the Less Than? function located on the Functions»
Comparison palette on the block diagram. This function controls
the While Loop conditional. The loop continues to run while the
current iteration number is less than the number of rows in the table.
h. Place the Not Or function located on the Functions»Boolean palette
on the block diagram. This function also controls the conditional of
the While Loop so that the loop continues until a match is found or
there are no more rows in the table.
i. Place the Empty String constant located on the Functions»String
palette on the block diagram. You will use two of these functions,
one in the True case and one in the False case. If the names match
but not the passwords or if neither match, then an empty string is
returned in the Name Confirmed indicator.
j. Place the Select function located on the Functions»Comparison
palette on the block diagram. This function is used along with the
password matching. If the password matches, the current name is
sent to the Name Confirmed indicator; otherwise, the Empty String
is sent.
4. Save this VI as Verify Information.vi.
5. Go to the front panel and make sure you have some names—the names
do not have to be the same ones used in the course manual—and
passwords in the table control. If you have not already done so,
right-click the table and select Data Operations»Make Current
Values Default so that the names and passwords are permanently stored
in the table.
6. Enter values into the Name and Password controls and run the VI.
If the Name and Password match one of the rows in the table, the name
is returned in the Name Confirmed indicator and the Verified LED is
lit. Otherwise, an empty string is returned and the Verified LED is off.
Be sure to try various combinations of names and passwords to make
sure that this VI shows the correct behavior.
7. Create an icon for this VI because you will use this VI as a subVI in a
later exercise. To create the icon, right-click the icon in the top right
corner of either the front panel or the block diagram and select Edit Icon
from the menu. Design an icon similar to the one shown here.
8. Create the connector pane for this VI by right-clicking the icon in the
front panel and selecting Show Connector from the shortcut menu.
Select a pattern and connect the front panel objects to the terminals as
shown in the following connector pane.
E. VI Templates
In the last section, you learned about some of the common programming
architectures for VIs. So that you do not have to start building each new VI
from an empty front panel and block diagram, a number of templates are
included with the LabVIEW package. These VI templates can be found in
the LabVIEW 6\Templates directory and contain the file extension .vit.
LabVIEW provides some basic templates, however, not all of the VI
architectures described are available as templates.
You can save a VI you create as a template by using the File»Save with
Options option as shown in the following dialog box.
Front Panel
1. Open the Timed While Loop with Stop.vit from the LabVIEW
6\Templates directory. The front panel only contains the Stop button.
Block Diagram
Block Diagram
Notes
Notes
This lesson introduces how you can design and build the user interface to
your VIs. First, an overview and list of things to consider while building the
front panel. The next few sections describe some common methods and
tools for customizing panels. The last few sections describe additional items
and panel objects used for developing user interfaces.
The next example shows the same subVI after the front panel has been
resized and the menu bar, scrollbars, and toolbar have been removed with
the VI Properties»Window Appearance»Dialog option.
Using Color
Proper use of color can improve the appearance and functionality of your
front panel. Using too many colors, however, can result in color clashes that
cause the front panels to look too busy and distracting. Here are some color
matching tips:
• Start with a gray scheme—select one or two shades of gray and highlight
colors that have good contrast with the background.
• Add highlight colors sparingly—on plots, abort buttons, and perhaps the
slider thumbs for important settings. Small objects need brighter colors
and more contrast than larger objects.
• Use spacing and alignment to group objects instead of matching colors.
• Good places to learn about color are stand-alone instrument panels,
maps, magazines, and nature.
Centered items are better than random, but much less orderly than either left
or right. A band of white space acts as a very strong means of alignment.
Centered items typically have ragged edges, and the order is not as easily
noticed.
Using too many font styles can make your front panel look busy and
disorganized. It is better to use two or three different sizes of the same font.
Serifs help people to recognize whole words from a distance. If you are
using more than one size of a font, make sure the sizes are quite different.
If not, it will look like a mistake. Similarly, if you use two different fonts,
make sure they are distinct.
Operator stations can catch lots of glare or users might need to read them
from a greater distance than normal computers or with a touch screen.
Therefore, you should use larger fonts and more contrast.
Dialog Controls
A common user interface technique is to have dialog boxes appear at
appropriate times to interact with the user. You can make a VI behave like a
dialog box by checking that option in the File»VI Properties»Window
Appearance dialog box. The Controls»Dialog Controls palette contains
the same kinds of objects available in system dialog boxes.
You should use these dialog controls to build system-like dialogs. Dialog
controls change appearance according to the operating system and Window
Appearance settings and they typically ignore all color clicks except
transparent. If you are integrating a graph or non-dialog controls into the
front panel, try to make them match by hiding some borders or selecting
colors similar to the system.
Tab Controls
Physical instruments usually have good user interfaces. Borrow heavily
from them, but move to smaller or more efficient controls, such as rings,
or tab controls where this makes sense. Tab Controls are found in the
Controls»Dialog Controls palette or the Controls»Array & Cluster
palette and offer a convenient way to group front panel objects together.
The way you use a Tab Control is to place it on the front panel as shown
previously. You add tabs by right-clicking an existing tab and selecting Add
Page After, Add Page Before, or Duplicate Page from the menu. You
relabel the tabs with the Labeling tool, and you place other front panel
objects into the appropriate pages. The terminals for these objects are
available in the block diagram as are terminals for any other front panel
object.
The Tab Control wires directly to a Case structure as shown previously and
the page name shows up as the name of the case. You can then wire the data
to and from the other terminals as needed.
Decorations
One of the easiest and often overlooked methods of grouping or separating
objects is to use an item from the Controls»Decorations palette. You can
select to use various types of boxes, arrows, and lines from this palette as
follows:
Menus
Menus are a good way to present most of a front panel’s functionality in an
orderly way and in a relatively small space. This leaves room on the front
panel for actions that are needed in an emergency, items for beginners, items
needed for productivity, and items that do not fit well into menus. Also be
sure to add menu shortcut keys for the frequently accessed items. Later in
this lesson you will learn how to create your own menus in a VI.
You will resize, reorganize, and rearrange the objects on the front panel to
make the user interface easier to use. You will also setup the graph to resize
along with the front panel.
Front Panel
Tip Remember to use the Align Objects and Distribute Objects features in the tool bar.
3. After making groups out of the controls, use the Raised Box decoration
on the Controls»Decorations palette to make visible separations
between the groups. And resize your window so the front panel fits
inside the window, as shown in the following example.
Tip You need to use the Reorder button in the tool bar on the decorations to Move to
Back, so that the controls are visible and on top of the raised boxes.
You will modify the Generate & Analyze VI so that it uses the tab control.
One page of the tab will be for the generation of data as before and a second
page will be for acquiring the data from a DAQ device.
Front Panel
1. Open the Generate & Analyze VI you built in Exercise 1-1. Resize the
front panel to make room on the left of the other front panel objects as
you will be adding the tab control.
2. Place a Tab Control located on the Controls»Array & Cluster palette
on the front panel as shown previously. Select the Sine Frequency, Sine
Amplitude, Sampling Info, and Noise Amplitude controls and place
them into the first page of the Tab Control.
3. Name the two pages of the tab control Simulate and DAQ respectively.
Click the DAQ page and add the objects as follows:
Block Diagram
7. Open and modify the block diagram as shown previously using the
following components:
a. Place a Case structure located on the Functions»Structures palette
on the block diagram. When used with the tab control—one case
handles the Simulate page and the other case is for the DAQ page.
b. Place the AI Acquire Waveform VI located on the Functions»Data
Acquisition»Analog Input palette on the block diagram. This VI
acquires data from an analog input channel on the DAQ device.
Note If you do not have a DAQ device or a DAQ Signal Accessory, use the Demo
Acquire Waveform VI located on the Functions»User Libraries»Basics 2 Course
palette on the block diagram in place of the AI Acquire Waveform VI. The Demo Acquire
Waveform VI simulates acquiring data from an analog input channel at a specified
sampling rate and returning the specified number of samples.
Cluster Conversion
You can convert a cluster to an array if all cluster components have the same
data type (for example, all are Boolean data types or all are numeric). With
this conversion, you can use array functions to process components within
the cluster.
1 2
Note You must right-click the function icon to set the number of components in the
cluster. The default number of components in the output cluster is nine.
You can combine the concept of a state machine with a Boolean menu
cluster to provide a powerful system for menus. For example, perhaps you
need to provide the following application, which can be divided into a series
of states.
The front panel consists of a Boolean button cluster, with each button
triggering a state in the state machine. In state –1 (the No Event state), the
Boolean button cluster is checked to see if a button has been pressed. The
Search 1D Array function returns the index of the button pressed (or –1 if
no button is pressed) to determine the next state to execute. That state value
is loaded into the shift register, so that on the next iteration of the while loop
the selected state will execute.
In each of the other states, the shift register is loaded with the next state to
execute using a numeric constant. Normally this is state –1, so that the
Boolean menu will be checked again, but in state 1 (Configure) the
subsequent state is state 2 (Acquire).
In this exercise, you will build the state machine to be used in this
application and observe its operation.
Front Panel
Block Diagram
You will examine a VI that uses clusters to process data. The VI features a
cluster containing four labeled buttons. The VI keeps track of the number of
times you click each button.
Front Panel
Block Diagram
False case is empty except for passing the cluster from the left shift register
to the right shift register.
1. Open and examine the block diagram.
2. Run the VI. Click a button. The corresponding digital indicator should
increment each time you click a button.
3. Close the VI. Do not save any changes.
C. Property Nodes
In some applications, you might want to programmatically modify the
appearance of front panel objects in response to certain inputs. For example,
if a user enters an invalid password, you might want to cause a red LED to
start blinking. Another example would be changing the color of a trace on a
chart. When data points are above a certain threshold, you might want to
show a red trace instead of a green one. Resizing front panel objects, hiding
parts of the front panel, and adding cursors to graphs also can be done
programmatically using Property Nodes.
Property Nodes in LabVIEW are very powerful and have many uses. This
course only covers one use for Property Nodes to change the appearance and
functional characteristics of front panel objects programmatically. You can
set properties such as display colors, visibility, position, size, blinking,
menu strings, graph or chart scales, graph cursors, and many more. Refer to
the Help»Contents and Index in LabVIEW for more information about the
Property Node.
Because there are many different properties for front panel objects, we will
cover only some of the common properties. Select Help»Contents & Index
to find information about a particular property.
For example, if you create a Property Node for a digital control, it appears
on the block diagram with the Visible property showing in its terminal. A
small arrow appears on the right side of that terminal, indicating that you can
read a value from the Visible property for the digital control. You can change
it to a write property by right-clicking the node and selecting Change To
Write from the shortcut menu. Wiring a Boolean FALSE to that terminal
will cause the digital control to vanish from the front panel when the
Property Node receives the data. Wiring a TRUE causes the control to
reappear.
You can read the current state of a property by right-clicking the Property
Node terminal and selecting Change To Read. When the Property Node is
called, it will output a Boolean TRUE if the control is visible or a Boolean
FALSE if it is invisible.
From the terminal on the Property Node, you can select properties by
clicking the node with the Operating tool, shown at left, and selecting the
Operating
tool
desired property from the shortcut menu.
You can read or set more than one property with the same node by enlarging
the Property Node. Using the Positioning tool, shown at left, click the lower
Positioning corner of the Property Node and drag the corner down to enlarge the node.
tool
As you enlarge the node, you add more terminals. You can then associate
each Property Node terminal with a property from its shortcut menu.
To access bundled properties, select the All Elements option from the
property’s shortcut menu. For example, you can access all the elements in
the Position property by selecting Position»All Elements or you can access
a single element from that bundle.
Execution
Order
Common Properties
There are many properties available for the various front panel objects in
LabVIEW. This section describes the Visible, Disable, Key Focus, Blink,
Position, Bounds, and Value properties, which are common to all front panel
objects. It also introduces some Property Nodes for specific kinds of
controls and indicators.
Visible Property
The Visible property, shown at left, sets or reads the visibility of a front
panel object. The associated object is visible when TRUE, hidden when
FALSE.
Disabled Property
The Disabled property, shown at left, sets or reads the user access status
of an object. A value of 0 enables an object so that the user can operate it.
A value of 1 disables the object, preventing operation. A value of 2 disables
and greys out the object.
Wiring Example—Disable user access to the digital control and grey it out.
Wiring Example—Make the digital control the key focus. You can then enter
a new value in the control without selecting it with the cursor.
Blinking Property
The Blinking property, shown at left, reads or sets the blink status of an
object. By setting this property to TRUE, an object will begin to blink. You
can set the blink rate and colors by selecting Tools»Options and selecting
Front Panel and Colors from the top pull-down menu. When this property is
set to FALSE, the object stops blinking.
1 2 3
Value Property
The Value property, shown at left, reads or sets the current value of an object.
When you set the Value property to write, it writes the wired value to object
whether it is a control or indicator. When you set the Value property to read,
it reads the current value in either a control or indicator. The example
Position Property
The Position property, shown at left, sets or reads the position of an object’s
upper left corner on the front panel. The position is determined in units of
pixels relative to the upper left corner of the front panel. This property
consists of a cluster of two unsigned long integers. The first item in the
cluster (Left) is the location of the left edge of the control relative to the left
edge of the front panel, and the second item in the cluster (Top) is the
location of the top edge of the control relative to the top edge of the front
panel.
Wiring Example—Make the digital control change its location on the front
panel.
Bounds Property
The Bounds property, shown at left, reads the boundary of an object on the
front panel in units of pixels. The value includes the control and all of its
parts, including the label, legend, scale, and so on. This property consists of
a cluster of two unsigned long integers. The first item in the cluster (Width)
is the width of object in pixels, and the second item in the cluster (Height)
is the height of the object in pixels. This is a read-only property. It does not
resize a control or indicator on the front panel. Some objects have other
properties for resizing, such as the Plot Area Size property for graphs and
charts.
Wiring Example—Set the display strings for the Switch control to the string
choices Stop, Run, Stop? and Run?
Wiring Example—Show the text in the string control in the three other
modes.
Front Panel
Block Diagram
2. Open and build the block diagram shown previously using the following
components:
a. Place the While Loop located on the Functions»Structures palette
on the block diagram. This structures the VI to continue running
until the user presses the Stop button. Right-click the Conditional
terminal and select Stop If True.
b. Place the Wait Until Next ms Multiple function located on the
Functions»Time & Dialog palette on the block diagram. This
function causes the While Loop to execute once a second. Create
the constant by right-clicking the input terminal and selecting
Create»Constant.
c. Place the Random Number (0-1) function located on the
Functions»Numeric palette on the block diagram. Creates a
random number between zero and one.
7. The Disable switch controls whether you can change the values. Flip the
Disable switch to True and all the panel objects except the Disable
switch and the Stop button are grayed out and you cannot change their
values.
8. Stop and close this VI when you are finished.
You have many scale options for graphs and charts. With Property Nodes,
you can set or read scale information for the X and Y scales. For each axis,
the VI can read or set the minimum, maximum, and increment values.
You also can use Property Nodes to programmatically read or set the plot
and background colors, and the X and Y grid colors. You can use this
capability to set plot or background colors depending on program conditions
such as out-of-range or error values.
To change the size of a graph or chart, use the Plot Area»Size property.
Thus, if you want to have a particular plot appear in a small window during
part of your application, but appear larger later, you can use this property in
conjunction with other properties that change the size of a VI’s panel.
Using Property Nodes, you have access to the information that cursors
provide on graphs. You use cursors to move a graphic selector on the plot.
A cursor can be locked to the plot or can float on the plotting surface. Values
from each cursor are returned to an optional display on the front panel.
Property Nodes present a means to programmatically set or read cursor
position on the graph, allowing user input from cursors in the VI.
Wiring Example—Set the color of the active plot using a Color Box
Constant (set to Red in this example). When selecting the active plot, the
Active Plot terminal must precede (appear previous) the Plot Color terminal.
You will finish building a VI that uses Property Nodes to perform the
following tasks:
• Set the delta X value of the chart to the sample rate in seconds.
• Clear the waveform chart so it initially contains no data.
• Change the color of a plot if the data exceed a certain value.
• Make an alarm indicator blink if the data exceed a certain value.
Front Panel
Block Diagram
1. Modify the VI so that it sets the delta X value to the sample rate and
clears the Temperature chart before starting. While the VI acquires data,
it should turn the “High Limit” line red when the temperature exceeds
the limit value, and the Out of Range LED should blink.
a. In the Sequence structure, create a Property Node for the
Temperature chart that has two terminals. One terminal should be
the multiplier property, X Scale»Offset and Multiplier»Multiplier,
and the other terminal should be the History Data property. To clear
a waveform chart from the block diagram, send an empty array of
data to the History Data property. To do this, right-click the property
and select Create»Constant. Make sure that the array constant is
empty.
b. In the Case structure inside the While Loop, create a Property Node
for the Temperature chart that has two terminals. The top terminal
should be the Active Plot property, and the bottom terminal should
be the Plot Color property, Plot»Plot Color. You will need these
properties in both cases of the Case structure. The High Limit plot is
plot 1, so set the Active Plot property to one before setting the Plot
Color property. If the data are greater than the High Limit, set the
plot color to red. Otherwise, it should be yellow. Use a Color Box
constant to send the color value to this property.
c. Right-click the Out of Range indicator to create the Blink Property
Node. The indicator should blink when the temperature is greater
than the High Limit.
You will create a VI in which you use graph cursors to select a subset of data
for analysis. In a later exercise, you will build a subVI that saves the results
to disk. You will also use the Value property to initialize an indicator.
Front Panel
Block Diagram
E. Control References
In the previous two sections you used Property Nodes to programmatically
change the characteristics of panel objects. If you are building a large VI that
contains many Property Nodes or if you are using the same property for
many different controls and indicators, you might want to consider placing
the Property Node in a subVI and using Control References to access that
node. A Control Reference is a refnum to a specific control. This section
shows only one way to use these versatile objects. Refer to the LabVIEW
manuals for more information about control references.
You then wire this Control Reference to a subVI that contains the Property
Nodes. However, the subVI must contain a terminal that is a Control
Refnum. You create the Control Refnum by selecting Controls»Refnum
as follows.
Property Nodes use error clusters like many of the I/O functions in
LabVIEW so you can use the error handlers to keep track of the error
conditions. The VI that calls this subVI can use it to change the properties
of any type of control. The following example shows the subVI disabling a
numeric and setting a Boolean object to be the key focus.
Next you will build a subVI that changes the disabled property for an array
of controls using the controls references.
You will start with the Property Node Exercise VI you built in Exercise 2-5.
You will make a subVI that accesses an array of control references and
assigns the Disabled property. Then you will modify the Property Node
Exercise VI to use the subVI rather than the original Property Nodes.
Front Panel
Block Diagram
2. Open and build the block diagram shown previously using the following
components:
a. Place a For Loop located on the Functions»Structures palette on
the block diagram. The For Loop is used to auto-index through the
array of control refnums so that each refnum and property is handled
separately.
b. Place a Property Node located on the Functions»Application
Control palette on the block diagram. You will use this Property
Node as a generic control type. When you wire the Refnum Array to
the refnum input terminal, the function changes slightly as in the
following example:
5. Save and close this VI. You will now make a calling VI for this subVI.
6. Open the Property Node Exercise VI you built in Exercise 2-5. You will
not modify the panel.
7. Select File»Save As and rename this VI Control Refs
Exercise.vi.
You can build custom menus in two ways—statically at the time of editing,
or dynamically at run time. You can statically store a menu template in a file
called the run-time menu (RTM) file. You can associate an RTM file with a
VI at the time of editing. When the VI runs, it loads the menu from the
associated RTM file. You also can programmatically insert, delete, and
modify menu items at run time from the block diagram using several
LabVIEW functions. In addition, you can programmatically determine if
an option on the menu bar is selected, and programmatically handle the
selection. With these features, you can make a custom pull-down menu for
your application.
Static Menus
Static menus are stored in RTM files. You can enable, create, or edit an RTM
file for a VI by selecting Edit»Run-Time Menu. The Menu Editor dialog
box appears.
On the left side of this dialog box is an overall organization of the menu
items. Menu items are classified into three types: User Item, Application
Item, or Separator.
name. For a menu item to be valid, its tag should not be empty. Invalid menu
items appear as ???.
An Application Item is one that LabVIEW provides. These items are part
of the default LabVIEW menu. To select a particular LabVIEW item, click
the arrow button next to the Item Name. You can add individual items or
entire submenus by using this process. Application Items are handled
implicitly by LabVIEW. These item tags do not appear in block diagrams.
You cannot alter the name, tag, or other properties of an Application Item.
LabVIEW reserves tags starting with APP_ for Application Items.
A Separator inserts a separation line in the menu. You cannot set any of the
properties for a Separator item.
The Menu Editor ensures that the tag is unique to a given menu
hierarchy by appending numbers when necessary. A User Item can be
enabled/disabled or checked/unchecked by setting the respective properties.
You can set a shortcut (accelerator) for a User Item by selecting an
appropriate key combination.
The Menu Editor allows you to insert, delete, or reorder menu items in the
menu hierarchy. Clicking the + button adds a new menu item. You also can
change the type of a menu item by selecting from the Item Type ring. In
addition, you can reorder the menu items and create submenus using the
arrow buttons. Finally, clicking the Delete Item button deletes the selected
menu item.
The Preview portion of the Menu Editor provides an up-to-date view of the
run-time menu. On the Menu Editor pull-down menu, the Open, New,
Save, and Save As buttons allow you to load and save RTM files. Once you
close the Menu Editor, you will have the option of updating the VIs
run-time menu with the menu you edited.
Dynamic Menus
While a VI executes, you can change items in the VI menu bar by using the
menu management functions described in the following sections. All of
these functions are located under Functions»Application Control»Menu.
All of these functions operate on a refnum for the menu retrieved using the
Current VI’s Menu function.
Inserts a menu item (or an array of menu items) identified by item names
or item tags into a menu (menu bar or submenu). The position of the item
is specified either through the after item parameter or through a
combination of the menu tag and after item pair.
Deletes a menu item (or an array of menu items) identified by items from
a menu identified by menu tag (from the menu bar, if menu tag is not
specified). Items can be a tag, array of tags, position number, or an array
of position numbers.
Returns properties of the menu item specified through item tag (or the
menubar if the item tag is unspecified). Item properties include item
name, enabled, checked, and shortcut. If the item has a submenu attached,
its item tags are returned in submenu tags.
Sets properties of the menu item specified through item tag. Item properties
include item name, enabled, checked, and shortcut. Unwired properties
remain unchanged.
Once you select an item, you cannot select another item until the Get Menu
Selection function reads the first item. Under such conditions, Get Menu
Selection is invoked under block menu mode, wherein menu tracking is
blocked out after a selection is read. The menu is enabled after you process
the selection using the Enable Menu Tracking function.
Returns the menubar refnum of the current VI. This function must be
executed before the other menu handling functions are invoked.
Returns the item tag of the last selected menu item, optionally waiting for
a period of time specified by timeout. Item path is a string describing the
position of the item in the menu hierarchy. Menu selection is blocked after
an item is read if block menu is set to TRUE.
The current run-time menu for the application is the LabVIEW default
menu. In the next several steps, you will replace that menu with a
custom list of selections.
3. Change the top ring control in the Menu Editor from Default to
Custom. The menu listed on the left portion of the dialog box should be
replaced with a ???, representing a single unnamed item.
4. In the Item Type ring control, select Application Item»Operate»
Entire Menu. The LabVIEW Operate menu should be added to the
custom menu. Default LabVIEW options, as well as selections you
create, can be added to a custom menu.
Take a moment to navigate the Operate menu in the editor. Notice that
you can select various items and collapse submenus using the triangle
icons. As you select individual items in the menu, their Item Name and
Item Tag appear in the Item Properties box of the editor. When finished,
collapse the Operate menu by clicking the triangle next to the Operate
option. You should now see only the Operate item in the menu list.
5. Click the + button in the Menu Editor toolbar. A new unnamed item,
???, appears in the menu list. With this item highlighted, enter Test into
the Item Name property. This menu item now has an item name and tag
of Test.
6. Click the + button again to add another entry under the Test item. Click
the right arrow button on the toolbar, and this unnamed option becomes
a subitem under the Test menu. Type in the Item Name Test 1 for this
new item.
7. Add two more subitems under the Test submenu called Test 2 and
Test 3. The Menu Editor dialog box should now resemble the
following:
In the Preview area of the Menu Editor, you can see how the custom
menu will behave during run time.
8. Select File»Save from the Menu Editor dialog box. Save the run-time
menu as Menu Exercise.rtm in the c:\exercises\LV Basics 2
directory. Then close the Menu Editor dialog box. When LabVIEW
asks if you want to change the run-time menu to Menu Exercise.rtm,
select Yes. You have configured a custom pull-down menu which will
be invoked while the VI executes.
Block Diagram
do not show up in the Item Tag string—only User items are returned
from the Get Menu Selection option.
To observe the flow of the VI, you might want to turn on execution
highlighting and single-stepping and examine the block diagram. Click
Stop on the VI’s front panel to halt program execution.
11. Using the Menu Editor, you can assign shortcut keys to User items you
create. Assign the keyboard shortcuts to the test options according to the
following table:
G. Intensity Plots
Intensity plots are extremely useful for displaying patterned data. For
example, the plots work well for displaying terrain, where the magnitude
represents altitude. Also, you can demonstrate temperature patterns with
intensity plots. Like the waveform graph and chart, the intensity chart
features a scrolling display while the intensity graph features a fixed display.
These displays accept a block of data and map each value to an associated
color, with a maximum of 256 accessible colors.
To change the color associated with a specific intensity value, right-click the
marker appearing next to the color ramp and select Marker Color from the
menu. The color palette appears, from which you select a color to associate
with that particular numeric value. To add more values to the color ramp,
right-click it and select Add Marker. You can drag the tick mark that
appears to the appropriate location on the color ramp, or select the text next
to the tick mark with the Labeling tool and type in the location of the marker.
After you have placed the marker at the appropriate location on the ramp,
right-click it and select Marker Color.
2. Change the Plot switch on the front panel to User Data and enter values
between 0.0 and 10.0 in the User Data array control. Run the VI. Notice
how the magnitude of each element is mapped to the intensity graph.
Additional Exercises
2-11 Modify Exercise 2-4 by adding a cluster of four labeled buttons.
Each time you click a button in the new cluster, decrement the
display by one. Use the front panel as follows to get started. Save the
VI as Cluster Example 2.vi.
2-12 Build a VI that manipulates a button control on the front panel. The
button should control the VI’s execution (that is, terminate the While
Loop). Use a Dialog Ring to select the following options: Enable
and Show button, Disable button, Grey Out button, and Hide
button. Use Property Nodes to implement the actions that the Dialog
Ring specifies. Test the different modes of operation for the button
while trying to stop the VI. Save the VI as Button Input.vi when
you are finished.
2-13 Open the Analyze & Present Data VI you developed in Exercise 2-7
and modify the VI so that if the number of data points in the subset
is one point or less, the Log Results to File button is grayed out.
Notes
This lesson describes how you can organize the block diagrams of your VIs
based upon how you transfer data from one place to another. First, you will
be reminded of how LabVIEW runs a VI. Then you will learn how to use
local and global data to pass data within and between VIs and tips for using
those data objects efficiently. Last, you will learn how to use DataSocket to
pass data between VIs and computers.
As you already know, the principle that governs how a LabVIEW program
executes is called data flow. The rules of data flow are:
• A node executes only when data is available at all its input terminals.
• A node supplies data to all of its output terminals when it finishes
executing.
• The data flows through wires instantaneously.
Therefore, a block diagram does not execute top to bottom or left to right,
but according to data flow rules. This contrasts with the control flow method
of executing a conventional program in which instructions execute in the
sequence in which you write them.
Wires are the key to understanding how data flow works in LabVIEW.
When wires directly connect one node to the next, the order of execution
is defined. If no wire connects two nodes, then those nodes can run
concurrently. If you require those two nodes to run in order, then you either
use a sequence structure or, if the nodes are subVIs, program data
dependencies such as the error clusters to control program execution.
This approach does not work if you need to exchange data between block
diagrams that run in parallel. Parallel block diagrams can be in two parallel
loops on the same block diagram or in two VIs that are called without any
data flow dependency. Consider the following block diagram.
This block diagram does not run the two loops in parallel because of the wire
passing between the two subVIs. The wire creates a data dependency where
the second loop does not start until the first loop is finished and passes
the data through its tunnel. The only way to make the two loops run
concurrently is to remove the wire connection. However, then the subVIs
cannot pass data between each other unless you use another technique of
data management. This lesson describes local variables, global variables,
and DataSocket as methods to pass data between parts of the same block
diagram and between different block diagrams.
B. Local Variables
Up until now, you have read data from or updated a front panel object using
its terminal on the block diagram. However, a front panel object has only
one terminal on the block diagram, and you might need to update or read a
front panel object from several locations on the block diagram. Using local
variables, you can access front panel objects in several places and pass data
between structures that cannot be connected by a wire.
You also can select Local Variable from the Structures palette. A local
variable node, shown at left, appears on the block diagram. You can select
Local variable the front panel object you want to access by right-clicking the variable node
node
and selecting an object from the Select Item menu. This menu lists the
owned labels for the front panel controls and indicators. Thus, always label
your front panel controls and indicators with descriptive names, using
owned labels.
For example, if the first object you create on the front panel is labeled
number in, the local variable icon appears as shown at left. After you place
Local variable the local variable on the block diagram, you can select the appropriate front
icon with panel object by either clicking the variable using the Operating tool, or
“number in”
selected right-clicking it and selecting the front panel object from the Select Item
menu.
By default, a local variable assumes that it will receive data. Thus, this kind
of local variable acts like an indicator and is a write local. When you write
new data into the local variable, the associated front panel control or
indicator updates to contain the new data.
You can change the configuration of a local variable so that it acts as a data
source, or a read local. To do this, right-click the variable and select Change
To Read. On the block diagram, a read local icon behaves just like a control.
When this node executes on the block diagram, your program reads the data
in the associated front panel control or indicator.
To change a read local to a write local, right-click the variable and select
Change To Write. The local variable will change its data direction so that
it receives data instead of providing data.
On the block diagram, you can visually distinguish read locals from write
locals just as you distinguish controls from indicators. A read local has a
thick border, emphasizing that it is a data source, similar to a control. A
write local has a thin border, because it acts like a data sink, similar to an
indicator. In the following figure, both local variables refer to the same item
on the front panel.
Method 1 (Incorrect)
As a first attempt, we place the Loop Control terminal outside of both loops
and wire it to each conditional terminal. In this case, the Loop Control
terminal is read only once, before either While Loop begins executing.
Recall that this happens because LabVIEW is a dataflow language, and the
status of the Boolean control is a data input to both loops. If a TRUE is
passed into the loops, the While Loops run indefinitely. Turning off the
switch does not stop the VI because the switch is not read during the
iteration of either loop. This solution does not work.
Method 2 (Incorrect)
Now we move the Loop Control terminal inside Loop 1 so that it is read in
each iteration of Loop 1. Although Loop 1 terminates properly, there is a
problem with this approach. Loop 2 does not execute until it receives all its
data inputs. Remember that Loop 1 does not pass data out of the loop until
the loop stops. Thus, Loop 2 must wait for the final value of the Loop
Control, available only after Loop 1 finishes. Therefore, the loops do not
execute in parallel. Also, Loop 2 executes for only one iteration because its
conditional terminal receives a FALSE value from the Loop Control switch
in Loop 1.
Method 3 (Correct)
In this example, Loop 1 is again controlled by the Loop Control switch, but
this time, Loop 2 reads a local variable associated with the switch. When
you set the switch to FALSE on the front panel, the switch terminal in Loop
1 writes a FALSE value to the conditional terminal in Loop 1. Loop 2 reads
the Loop Control local variable and writes a FALSE to Loop 2’s conditional
terminal. Thus, the While Loops run in parallel and terminate
simultaneously when the single front panel switch is turned off.
Thus far, you have learned that you can read input data from controls and
send results to an indicator. But, for example, what if you want to determine
which parameters were used to run a VI previously and you want to place
those values in controls for the users to modify? How can you write those
values into a control?
You cannot do this with standard controls and indicators. Using local
variables, you can overcome this limitation. You can update a control from
the block diagram. Also, you can have any number of local variable
references for a given front panel control, with some in write mode and
others in read mode. With a local variable reference, you can access a front
panel object as both an input and an output.
However, using a local variable, you can access the same front panel
indicator from more than one location on the block diagram, so that a single
indicator displays the loop that is executing. The Which Loop? indicator is
placed in Loop 1 and a local variable instance of that indicator is placed in
Loop 2. Although this example is simple, it shows how an indicator can be
updated from two separate locations on the block diagram.
Front Panel
Block Diagram
1. Complete the block diagram. Notice that the local variables are enclosed
in a single-frame Sequence structure, and that the empty string constant
is wired to the border of the While Loop. This setup ensures that both
local variables are updated before the While Loop starts.
a. Login Name local variable set to write local—Resets the login name
to an empty string. To create this local variable, right-click the Login
Name terminal and select Create»Local Variable from the pop-up
menu.
b. Password local variable set to write local—Resets the password
string to an empty string. To create this local variable, right-click the
Password terminal and select Create»Local Variable from the
pop-up menu.
Note If you have trouble wiring the string constant to a local variable, right-click the
local and select Change to Write Local.
Front Panel
Block Diagram
Note Make sure to correctly set each local variable as a read local or a write local. To
change a write local to a read local, right-click the icon and select Change to Read Local
from the pop-up menu. To change a read local to a write local, right-click the icon and
select Change To Write.
C. Global Variables
Recall that you can use local variables to access front panel objects at
various locations in the block diagram. Those local variables are accessible
only in that single VI. Suppose that you need to pass data between several
VIs that run concurrently, or whose subVI icons cannot be connected by
wires in the block diagram. You can use a global variable to accomplish this.
Global variables are similar to local variables, but instead of being limited
to use in a single VI, global variables can pass values between several VIs.
Consider the following example. Suppose you have two VIs running
simultaneously. Each VI writes a data point to a waveform chart. The first
VI also contains a Boolean to terminate both VIs. Remember that when both
loops were on a single block diagram, you needed to use a local variable to
terminate the loops. Now that each loop is in a separate VI, you must use a
global variable to terminate the loops.
Note You must label each control or indicator with an owned label because a global
variable refers to an item by its name.
The following example shows a global variable front panel with three
objects—a numeric, a string, and a cluster containing a digital and a
Boolean control. Notice that the toolbar in the window does not show the
same items as a normal front panel.
After you finish placing objects on the global variable’s front panel, save the
global variable and return to the block diagram of the original VI. Select the
specific object in the global variable VI that you want to access. To select a
specific object, right-click the global variable node and select the object
from the Select Item menu. This menu lists the owned labels for all the
objects on the panel. Notice that you also can open the front panel
containing the objects in the global variable from this pop-up menu.
You also can click the node with the Operating tool and select the global
variable you want to access.
After you select the specific global variable object that you want to access,
Global variable the node changes from the figure shown at left to display the object you have
node
chosen, such as a numeric.
You might want to use this global variable in other VIs. Because a global
Global variable
variable is a special kind of VI, you can place it in other VIs using the Select
node displaying a VI option in the Functions palette. Then, right-click the node to select the
a numeric
specific object in the global variable you want to access, as described above.
Note A global variable front panel can contain references to many individual objects
that are globally accessible. You do not need to create a separate global variable VI for
each item you need to globally access.
You can change the configuration of a global variable so that it acts as a data
source, or a read global. To do this, right-click the variable and select
Change To Read. On the block diagram, a read global icon behaves like a
control. When this node executes on the block diagram, the program reads
the data in the associated front panel object.
To change a read global to a write global, right-click the variable and select
Change To Write. The global variable will change its data direction so that
it receives data instead of providing data. When this node executes on the
block diagram, the program sends new data into the global variable.
On the block diagram, you can visually distinguish read globals from write
globals just as you distinguish controls from indicators. A read global has a
thick border, emphasizing that it is a data source. A write global has a thin
border, because it acts as a data sink. In the figure below, both global
variables refer to the same item on the global variable’s front panel.
Create a global variable and use it to send data to the VI in the next exercise.
Block Diagram
Build a VI that reads data from the global variable you created in the
previous exercise and displays the data on a front panel chart.
Front Panel
Block Diagram
The Time Delay control determines how often the global variable is
read. Notice how the Time Delay affects the values plotted on the
waveform chart. If you set the Time Delay to 0, the same Data Value
value is read from the global variable several times, appearing to
decrease the frequency of the sine wave generated in Data to Global.
If you set the Time Delay to a value greater than 50 ms, Display Global
Data may never read some values generated in Data to Global, and the
frequency of the sine wave appears to increase. If you set the Time
Delay to 50 ms, the same rate used in the While Loop in Data to Global,
Display Global Data reads and displays each point of the Data Value
global only once.
Note When using globals, if you are not careful, you may read values more than once,
or you may not read them at all. If you must process every single update, take special care
to ensure that a new value is not written to a global variable until the previous one has
been read, and that after a global has been read, it is not read again until another value
has been written to the global.
7. Press the STOP button on the Display Global Data front panel to stop
the VI. Notice that both Display Global Data and Data to Global stop.
The VI continually writes the value of the STOP button to the Stop
Button global variable object. That value is then read in Data to Global
and passed to the conditional terminal to control its loop as well. When
you press the STOP button, a TRUE passes through the global variable
to Data to Global, where that TRUE value is read to stop that VI as well.
8. Close both VIs.
If you do not initialize a local variable before reading data from it, it will
contain the current value of the control. The first time your program reads a
global variable, it contains the default value of the object it reads, unless you
have previously initialized the global variable.
Race Conditions
Local and global variables in LabVIEW do not behave like local and global
variables in text-based programming languages. Recall that LabVIEW is a
dataflow language, not a sequential programming language. Overusing local
and global variables can lead to unexpected behavior in your program,
because functions might not execute in the order you expect. Consider the
simple local variable example below. The LabVIEW code appears next to
the equivalent code of a sequential programming language.
x=x *5
x=x+2
or
x=x+2
x=x *5
When you execute the sequential code, the solution for a given value of x is
clear because the statements execute from top to bottom. However, the
LabVIEW code does not follow such a convention because LabVIEW is a
dataflow language. Each node executes when all of its data is available.
There are no data dependencies to guarantee the desired order of execution
in the above block diagram. In fact, there are several possible solutions,
depending on how the VI compiles. You cannot assume that the code located
at the bottom of the block diagram executed after the code above it.
The above example illustrates what is known as a race condition. The result
of your program depends on the order in which its instructions execute, and
the code might not execute in the order you assume. If you use local and
global variables, you might have a race condition if you notice that your
code executes correctly only some times, or that it executes correctly during
execution highlighting but not during normal execution.
For example, do not use locals and globals to avoid long wires across the
block diagram or to access values in each frame of a sequence structure.
Consider the following block diagram.
This three-frame sequence structure performs the usual tasks for all VIs.
Frame 0 reads the controls on the panel for configuring the test system,
Frame 1 uses the local variables for the controls to acquire data, and Frame 2
uses the locals to write the data to file. Although there is nothing inherently
wrong with using the sequence structure and the local variables in this way,
it is not the most efficient method of using dataflow programming. When
you look at one of the frames, it is not obvious where the values for the
locals are coming from and where they were last updated.
The block diagram shown above eliminates the use of local variables by
putting the original control terminals outside the sequence structure so that
each frame of the sequence now has access to the values. The data are passed
between frames of the sequence through a sequence local.
The block diagram shown above removes the sequence structure and uses
dataflow to define how the program works. The error clusters define the
execution order of the subVIs and also maintain the error conditions which
are checked at the end with the error handler VI. This is the most efficient
way to build a program and manage data in LabVIEW. Not only is the block
diagram smaller and easier to read, but passing data through wires is the
most efficient method for memory use.
E. DataSocket
So far in this lesson you learned three main things:
• The most efficient way to manage data in the block diagram is through
a direct wire connection.
• Local variables can be used to access front panel objects in multiple
places in the block diagram.
• Global variables can be used to pass data between separate VIs without
using a wire.
There are many other ways to manage data in LabVIEW. This lesson covers
one other method, DataSocket. DataSocket is an Internet programming
technology based on TCP/IP that simplifies data exchange between
computers and applications. With DataSocket, you can efficiently pass data
over the Internet and respond to multiple users without the complexity of
low-level TCP programming.
Therefore, you can use DataSocket to pass live data not only between VIs
running on the same machine but also between VIs running on separate
computers that are connected through a network. You also can use
DataSocket to communicate between LabVIEW and any other
programming language that contains support for TCP/IP, such as Excel,
Visual Basic, C, and so on.
DataSocket API
DataSocket is a single, unified, end-user API based on URLs for
connecting to measurement and automation data located anywhere, be it
on a local computer or on the Internet. It is a protocol-independent,
language-independent, and OS-independent API designed to simplify
binary data publishing. The DataSocket API is implemented so you can use
it in any programming environment and on any operating system.
DataSocket Server
The DataSocket Server is a lightweight, stand-alone component with which
programs using the DataSocket API can broadcast live measurement data at
high rates across the Internet to several remote clients concurrently.
As shown above, the DataSocket Server keeps track of the number of clients
connected to it as well as how many packets of data have been exchanged.
You can select to have the DataSocket Server run hidden by selecting
Hide DataSocket Server from the Server menu.
transfer protocol, to connect to the machine named ni.com and to fetch the
web page named datasocket.
The URL is different from the names used by most I/O technologies in that
it not only defines what you are interested in but also indicates how to get it.
The how encoded in the first part of the URL is called the access method of
protocol. Web browsers typically use several access methods, such as HTTP,
HTTPS (encrypted HTTP), FTP (file transfer protocol), and FILE (for
reading files on your local machine). DataSocket takes the same approach
for measurement data. For example, DataSocket can use the following URL
to connect to a data item: dstp://mytestmachine/wave1. The dstp in
the front tells DataSocket to open a data socket transfer protocol connection
to the test machine and fetch a signal called wave1. Had the URL started
with file, the data would have been fetched from a file instead of the
DataSocket server.
The DataSocket Write function writes the data input to the specified URL.
The data can be in any format or LabVIEW data type. The error in and
error out clusters maintain the error conditions.
The DataSocket Read function reads the data type specified by type from the
specified URL. The ms timeout value has a default of 10 seconds and you
can specify a different timeout value. The timed out Boolean indicates a
TRUE if this function timed out. The error in and error out clusters
maintain the error conditions.
The DataSocket Select URL VI is only used when you do not know the URL
for an object and you want to search for a data source or target from a dialog
box.
In the Connect To field, enter a URL and select whether you want to
publish, subscribe, or both. Then check the Enabled box.
When you click the Attach button, the front panel object is now available at
the specified URL in the DataSocket Server. A small rectangle in the top
right of the control or indicator appears, indicating the status of the
DataSocket connection. If the rectangle is green as shown below, the
connection is good.
If the rectangle is gray, there is no connection to the server at that time. If the
rectangle is red, the connection has an error.
Build a VI that generates a random number and displays this value in a meter
and sends the data to a DataSocket URL. Then build a second VI that reads
the DataSocket URL and displays the value in a slide. Last, use the
automatic publish and subscribe features to send the data through a
DataSocket connection.
Front Panel
1. Open a new VI and build the front panel shown above. The URL object
is a string control.
Block Diagram
2. Open and build the block diagram shown above using the following
components:
a. While Loop, available on the Functions»Structures
palette—Structures the VI to continue running until you press the
Stop button. Right-click the Conditional terminal and select Stop If
True.
b. Wait Until Next ms Multiple function, available on the Functions»
Time & Dialog palette—Causes the While Loop to execute once per
second. Create the constant by right-clicking the input terminal and
selecting Create»Constant.
Front Panel
1. Open a new VI and build the front panel shown above. The URL object
is a string control. To show the scale on the slide indicator, right-click
the slide and select Scale»Style.
Block Diagram
2. Open and build the block diagram shown above using the following
components:
a. While Loop, available on the Functions»Structures
palette—Structures the VI to continue running until you press the
6. Return to the two VI front panels and make sure that the URLs have been
entered the same for both VIs.
• dstp—The DataSocket transfer protocol.
• localhost—The current computer you are using.
• data1—The name given to the random number you will be sending.
7. Run the DS Generate Data and the DS Read Data VIs.
The DataSocket Server window shows one process connected, and the
Number of packets value increments each second as the meter and slide
show the same random numbers.
8. Stop both VIs when you are finished. Now modify the VIs to use the
automatic publish and subscribe capabilities of front panel objects.
Front Panel
11. Click the Attach button and a little gray rectangle appears to the top
right side of the digital indicator. This indicates that the DataSocket
connection is not active.
12. Run the DS Generate Data and DS Read Data VIs again.
The rectangle next to the Random Number indicator turns green, and the
value matches the values shown in the meter and the slide.
Note If your computer is on a network with the other computers used in class, you can
type in URLs for other machines on the network and transfer the values between
classroom computers. Remember that you can use any programming language or
operating system with DataSocket connections. Go to the National Instruments
DataSocket web page, at ni.com/datasocket, for more information.
13. Stop and close both VIs and the DataSocket Server when you are
finished.
Additional Exercises
3-6 Open the In Range VI. Examine the block diagram. This simple VI
generates five random numbers and turns on an LED if the last
number generated is between 0.1 and 0.9. Run the VI several times
until the LED turns on. Notice that if the LED turns on during one
run of the VI, it remains on during the second run until the For Loop
completes and the last number is passed to the In Range? function,
available on the Functions»Comparison palette. Modify the VI
using a local variable so that the LED is turned off when the VI starts
execution. Save your VI after you have finished.
Challenge
3-8 Open the Select and Plot Waveform VI from Exercise 3-2. Use the
information at the end of Section D to rewrite this VI to no longer
use the sequence structure and local variables.
Tip Use a state machine architecture and pass data using shift registers or direct wire
connections.
Notes
Notes
When implementing subVIs for file I/O, you might need to account for
different file formats. For example, if a third-party application needs to read
data acquired by LabVIEW, you should save that data in text format because
most applications have support for text files. On the other hand, if only
LabVIEW will access the data, and file size is critical, binary files are a
better choice. Advanced File I/O techniques and the built-in file I/O
functions allow this flexibility.
Note Refer to the Help»Contents and Index for more information about these
functions.
The File Dialog function on the File I/O»Advanced File Functions palette
displays a file dialog box for file selection. You can select new or existing
files or directories from this dialog box. We will describe the use of the
datalog type input later in this lesson.
File Dialog
The Open File function on the File I/O»Advanced File Functions palette
opens an existing file. You must wire a valid path to the file path input. This
function is not capable of creating or replacing files. It opens only existing
files. The datalog type input is used only when opening LabVIEW datalog
files.
Open File
New File
The Write File function on the Functions»File I/O palette writes data to an
open file. The behavior of this function varies slightly depending on whether
you are writing data to a byte stream file or to a LabVIEW datalog file.
Write File
The Read File function on the Functions»File I/O palette reads data from
an open file. When reading byte stream files, you can use the byte stream
type input to indicate how LabVIEW should interpret data in the file. We
will describe this concept later in this lesson.
Read File
The Close File function on the Functions»File I/O palette closes the file
associated with refnum.
Close File
Because of the universality of the text format, there are several situations
where text files are preferable for data storage. For example, text files are
preferable when you plan to read or manipulate the data with other software
applications, such as spreadsheet or word processing applications.
You might lose precision if you store numeric data in text files. Computers
store numeric data as binary data, and typically you write numeric data to a
text file in decimal notation. A loss of precision might occur when you read
the data from the text file. Loss of precision is not an issue with binary files.
As shown in the previous block diagram, the Write File function skips over
any header information that LabVIEW uses to store the string in memory
and writes the contents of the string data control to the file. In fact, the Write
File function does not distinguish a text string from a binary string when
writing the data to the file—it places the data in the file. The data terminal
of the Write File function is polymorphic, which means that it adapts to any
kind of data you wire into it. Thus, you can create a binary file by wiring
binary data to the Write File function in the previous example. However, you
will find that header information is vital for interpreting the binary file.
For example, if you wire a two-dimensional array of numbers into the data
terminal, the Write File function places a byte-for-byte copy of the input
data into the file. It does not convert the numbers to text, nor does it place
any information about the number of rows or columns in the array into
the file. Even if you know that the data were originally single-precision
floating-point numbers, you cannot successfully reconstruct the
two-dimensional array. If the file contains 24 bytes of data, and knowing
that single-precision floating-point numbers use four bytes of memory each,
you can figure out that the array contained six values (24/4 = 6). However,
the original data might have been stored in a one-dimensional array of six
elements, a two-dimensional array with one row and six columns, or a table
with three columns and two rows.
You also can generate the same file using the header input of the Write File
function. If you wire a Boolean value of TRUE to the header input of the
Write File function, it writes the same data to the file as if you had manually
written a header. The following example shows how to use the Write File
function to create a binary file with a header.
As shown in the following example, you can read the binary file from the
previous examples by using the Read File function.
Notice that the byte stream type input of the Read File function has a
two-dimensional array of single-precision numbers wired to it. The Read
File function uses only the data type of this input to read the data in the file,
assuming that it has the correct header information for that data type.
Such obstacles do not occur in binary files. In a binary file, the flattened
format of a number in LabVIEW is a binary image of the number itself.
Therefore, each number in the array uses a fixed number of bytes of storage
on disk. If you know that a file stores single-precision numbers, which use
four bytes per number, you can read an arbitrary group of elements from the
array, as shown in the following example.
In the previous block diagram example, the pos mode input of the Read File
function is set to start, which means that the function begins reading data
at pos offset bytes from the beginning of the file. The first byte in the file
has an offset of zero. So, the location of the nth element in an array of
single-precision floating-point numbers stored in this file is 4 × n bytes from
the beginning of the file. A single-precision floating-point constant, wired
to the byte stream type input, tells the Read File function to read
single-precision floating-point values from the file. The # values to read
control, connected to the count input of the Read File function, tells the
function how many single-precision elements to read from the file. Notice
that when the count input is wired, LabVIEW places the output data in an
array, because LabVIEW reads more than one value from the file.
Front Panel
1. Open a new VI.
2. Build the following front panel. When you create the menu ring, recall
that a shortcut for adding a new item to the list of options is to press
<Shift-Enter> after entering the text for an item in the list. Enter Zero
for item 0 in the list, Sine for item one, and so on. To view the numeric
value of the menu ring, right-click the control and select Visible
Items»Digital Display.
Macintosh, <Shift-Return>; Sun, <Shift-Return>; HP-UX, <Shift-Enter>; and
Linux, <Shift-Enter>
Note The appearance of the menu ring control varies from one platform to the next.
Block Diagram
4. Build the following block diagram.
Front Panel
1. Open a new VI and build the following front panel.
Block Diagram
3. Build the following block diagram.
elements in the array stored in the file. The second instance reads the
array of data from the file.
c. Place the Close File function located on the Functions»File I/O
palette on the block diagram. In this exercise, this function closes the
binary file after data has been read from it.
Use the same file I/O functions to work with datalog files that you use for
byte stream files. However, you use the data type input differently for
datalog files. To create a new datalog file, wire a cluster matching the data
record cluster to the datalog type terminal of the New File function. This
cluster specifies how the data is written to the file. Then wire the actual data
record to the data terminal of the Write File function. The datalog type
cluster wired to New File need not be an actual data record—you need it
only to establish the type of data that you can store in the file. The following
example shows how to create a new datalog file.
To read the record of information from the datalog file, you must wire an
input to the datalog type of the Open File function that exactly matches the
data type of the records stored in the file. The following example shows how
to open and read an existing datalog file.
Note The cluster wired to the datalog type input of the Open File function must be
identical to the cluster used to create the file and write data to it, including numeric data
types and cluster order.
When the count input of the Read File function remains unwired, the
function reads a single record from the datalog file. If you wire an input to
the count terminal, Read File returns an array of records.
Note Completing this VI enables the Log Results to File option in the Analyze and
Present Data VI from Exercise 2-7. Recall that you will use Exercise 4-3 in the project in
Lesson 5.
In the application being developed, you need to save a mixed data set to
disk. This data set contains simple numerics, arrays of numerics, and string
data. In addition, this data is used only in LabVIEW. Because of these
requirements, you will use datalog files to save the application’s data subsets
to disk.
Front Panel
1. Open the Save Data to File VI in exercises\Basics2 directory.
The front panel is already built.
The two controls on the front panel are used to pass application data to
this VI, which functions as a subVI in the finished project. The Data
Cluster will contain the subset of analyzed data to save to disk, and the
Employee Name string will contain the Operator name to save to
the file.
Block Diagram
3. Complete the Case structures for the following block diagram. The cases
that are not shown are already built.
This VI reads and displays the data stored by the Save Data to File VI.
Front Panel
1. Open the View Analysis File VI in exercises\Basics2 directory.
This VI has already been built.
Block Diagram
3. Examine the behavior of the VI. If the user cancels the file dialog box,
nothing happens.
Notice that the datalog type input of the File Dialog function is wired
to a dummy cluster of the same data type to be read. This connection
causes the LabVIEW file dialog to display only directories and files of
the appropriate data type. Once the file is selected, the file is opened as
a datalog file and a single data record is read. Finally, notice the use of
error checking in this application.
4. After you run the VI and test it, close it. Do not save any changes.
The following examples show the advantages of using disk streaming. In the
first example, the VI must open and close the file during each iteration of the
loop. The second example uses disk streaming to reduce the number of
times the VI must interact with the operating system to open and close the
file. By opening the file once before the loop begins and closing it after the
loop completes, you save two file operations on each iteration of the loop.
Disk streaming is especially important when you use the high-level VIs,
such as Write To Spreadsheet File and Write Characters To File. These VIs
open, write, and close the file each time they run. Thus, if you call one of
these VIs in a loop, you perform unnecessary Open File and Close File
operations during every iteration of the loop.
Text Files
Text files are files in which all data is stored as readable text characters. Text
files are useful because almost all software applications and operating
systems can read them. However, text files can be larger than necessary and
therefore slower to access. It is also very difficult to perform random access
file I/O with text files. You typically use text files when:
• Other users or applications will need access to the data file.
• You do not need random access reading or writing in the data file.
• Disk space and file I/O speed are not crucial.
Binary Files
Binary data files are files in which data is stored in binary format without
any conversion to text representation. Binary data files are generally smaller
and thus faster to access. Random access file I/O presents no major
difficulties. However, there is no industry-standard format for binary files.
Thus, you must keep precise records of the exact data types and header
information used in binary files. We recommend you use binary data files
when:
• Other users or applications are unlikely to need access to your data.
• You need to perform random access file I/O in the data file.
• Disk space and file I/O speed are crucial.
Datalog Files
Datalog files are a special type of binary file for saving and retrieving
complex data structures in LabVIEW. Like binary files, they have no
industry-standard format. We recommend using datalog files when:
• Your data is made up of mixed or complicated data types.
• Other users or applications are unlikely to need access to your data.
• Users who write VIs to access the data know the datalog structure.
Additional Exercises
4-5 Write a VI that uses the Advanced file I/O functions to create a new
file. Then, write to that file a single string composed of a string input
by the user concatenated with a number converted to a text string
using the Format Into String function. Name the VI File
Writer.vi.
4-6 Write a VI that uses the Advanced File I/O functions to read the file
created in Exercise 4-5. Name the VI File Reader.vi.
Tip Use the EOF function located on the File I/O»Advanced File Functions palette to
obtain the length of the written file.
Notes
Notes
This lesson describes some of the issues involved when building larger
LabVIEW projects, including the design process, the organization of subVI
components, and the process of combining those components to create a
complete application.
Process
Test & Release
Define Project Customer
Final Product
Feedback
Implement
Test SubVIs
Nodes as VIs
Top-Down Bottom-Up
In this lesson, you will put the VIs built in previous lessons into a large
application. You will develop a generic data acquisition VI that meets the
following criteria:
• Provides a menu-like user interface.
• Requires the user to log in with a correct name and password.
• If the user is not correctly loged in, other features are disabled.
• Allows the user to configure the acquisition settings, including sample
rate, number of samples, or to simulate data.
• Acquires waveform data with the specified user configuation.
• As soon as the data have been acquired, and any time the user selects
thereafter, the user can select a subset of the acquired data, analyze it,
and save the analysis results to a file.
• Allows the user to load and view analysis results previously saved to
disk.
• Stops the application with the click of a Stop button.
Teamwork
Business management experts stress the importance of teamwork in
designing solutions for large, complex tasks. When using LabVIEW,
teamwork is a powerful tool for increasing your productivity in graphical
programming. When several people work together to develop a project in
LabVIEW, it is essential that all team members agree on a method of source
code control and organization.
If you use a check-out system and VIs are stored in an LLB, you must check
out the entire library of VIs. Keep this in mind as you work on a project. One
VI management technique is to edit a copy of the VI you want to modify and
lock the original VI to indicate to others that the VI should not be modified.
To lock a VI, enable the Locked setting by selecting Security from the top
pull-down menu in the File»VI Properties dialog box. You should also
indicate that you have checked out the VI by adding a comment in the VI
Revision History window. When you lock a VI, its block diagram cannot be
modified. After you finish modifying the VI, replace the VI stored in the
LLB with the new version and unlock it so others know it is safe to check
out the VI.
To document your VIs, select Description and Tip from the top pull-down
menu in the File»VI Properties dialog box. Control descriptions also
provide online help you can use in the final product.
As a rule of thumb, try to limit the size of your LLB to roughly 1 MB.
Whether you store your VIs in an LLB or directly on disk can depend on file
naming restrictions in your operating system or how you select to organize
your files.
In the next four exercises you will build the Application Exercise VI. Each
exercise adds a state or two to the application. This method is used so you
can incrementally test the application as it is being built.
You will begin creating an application that uses several of the VIs you wrote
earlier in the course. The first stage of this development is to add a user login
procedure to the Menu VI created in Exercise 2-3.
Front Panel
1. Open the Menu VI in the exercises\Basics2 directory. You created
this VI in Exercise 2-3.
Note If you did not complete Exercise 2-3, locate Menu VI in the course solutions stored
on your computer.
Block Diagram
1. Modify the following VI. Only modify the While Loop and Cases -1 and
0. The Login VI is called when the user presses the Login button on the
front panel (Case 0 of the Case structure). Remember to delete the One
Button Dialog function that you placed in Case 0 in Exercise 2-3.
Note If you did not complete Exercise 3-1, locate Login VI in the course solutions
stored on your computer.
Note The VI needs the Operator and Access Granted information in subsequent loop
iterations. Therefore, this VI uses two more shift registers to store the data. You will need
to make sure that the other cases in the Case structure pass the data through correctly,
straight through the cases.
By using the shift registers, notice that only Case 0, in which the Login VI
runs, can change the Operator and Access Granted values.
The loop verifies that the value stored in the Boolean shift register, which is
the Access Granted status, is TRUE, or if the user pressed the Login button
(component 0 in the menu cluster) or Stop button (component 4) to
determine which case to execute. If all of these conditions are FALSE, then
Case -1 executes.
3. Run the VI and test it to make sure it behaves properly. Use the
LabVIEW debugging tools—execution highlighting, single-stepping,
probes, and breakpoints—to determine the dataflow of the VI.
4. Save the VI as Application Exercise(5-1).vi. Do not close
the VI.
In the previous exercise, you began building the Application Exercise VI.
Now, you will add the Acquire Data VI, which you built in Exercise 2-2.
Block Diagram
1. Make sure that the Application Exercise (5-1) VI is open. You will not
modify the front panel in this exercise. Open the block diagram.
2. Show Case 1 of the Case structure and delete the One Button Dialog
function. Add Acquire Data VI, which you built in Exercise 2-2. If you
did not finish that exercise, use the VI from the solutions located on your
computer.
3. Add a shift register to the border of the While Loop. Connect the Time
Waveform output of the Acquire Data VI to the right side of the shift
register.
4. You must initialize the new shift register you created.
a. Right-click the left side of the shift register that contains the
configuration cluster and select Create»Control from the shortcut
menu. This creates an empty waveform control on the front panel.
b. Hide this Time Waveform control by right-clicking the terminal and
selecting Hide Control fromt he shortcut menu. This makes the
waveform control invisible so it does not confuse users.
You will add the Analyze & Present Data VI from Exercise 2-7 and the View
Analysis File VI, which you studied in Exercise 4-4.
Block Diagram
1. Make sure that the Application Exercise(5-2) VI is open. You will not
modify the front panel in this exercise. Open the block diagram.
2. Delete the One Button Dialog function in Case 2 of the Case structure.
Add the Analyze & Present Data VI to this case. You completed this VI
in Exercise 2-7.
a. Connect the string containing the operator name to the Operator
input.
b. Connect the waveform containing the collected data to the Data
input.
3. Show Case 3 of the Case structure and delete the One Button Dialog
function. Add the View Analysis File VI. You do not need to make any
connections to it.
4. Save the VI as Application Exercise(5-3).vi and run it. You
should now be able to perform all of the options available in the menu
after you log in with a valid name and password.
Note You must select a subset of the acquired data when you select Analyze & Present
Data. After you select the data subset, click the Analyze button and then select the button
to save the data to file. Otherwise, the file does not contain any waveform data.
To open the Revision History window for a VI, select Tools»VI Revision
History.
After typing your comments into the Comment area of the Revision History
window, click Add to add them to the VI’s history. The VI Revision History
window also keeps track of revision numbers. Each time you save the VI,
the revision number for the VI increments by one.
In addition to the revision number and the date and time at which a comment
is added to a VI’s history, the current user’s name appears in the User field.
You can configure the LabVIEW preferences to prompt for a user name at
launch time, by selecting Revision History from the top pull-down menu in
the Tools»Options dialog box, or you can change the user name by
selecting Tools»User Name.
VI Hierarchy
One of the most important advantages of breaking your main application
into subVIs is that you save memory. In addition, the responsiveness of
the LabVIEW editor improves because smaller VIs are easier to handle.
Hierarchical applications are easier to develop, read, document, and modify.
If you find that the block diagram for a VI is getting too large, you can
convert part of it into a subVI by using Edit»Create SubVI. This capability
gives you a fast and easy method to create your application’s VI hierarchy
as you develop the source code.
The VI Hierarchy window is also a valuable tool for locating subVIs and
viewing the overall layout of the project as your application grows. To view
the Hierarchy window, select Browse»Show VI Hierarchy. A new window
appears showing the hierarchies of all top-level VIs in memory.
You can use the options available in the toolbar at the top of the Hierarchy
window to show or hide various categories of objects used in the hierarchy,
such as global variables or VIs shipped with LabVIEW, as well as whether
the hierarchy expands horizontally or vertically. Clicking the small arrow
appearing next to a VI expands or collapses the view of that VI’s hierarchy.
Thus, you can expand different branches of the overall hierarchy.
As you move the cursor over the icons shown in the Hierarchy window, the
name of the VI follows the VI. You can double-click an icon to open the VI.
You can also locate a VI in the hierarchy by typing in the name of a VI while
in the Hierarchy window. As you type the name, the Hierarchy window
scrolls to the appropriate VI. You can also use the Find feature to search the
Hierarchy window for a VI.
The Hierarchy window can also be used a development tool when planning
or implementing your project. For example, after developing a flowchart of
the VIs required for an application, you can create, from the bottom of the
hierarchy up, each of these VIs so that they have all necessary inputs and
outputs on their front panel, and the subVIs they call on their block
diagrams. This will build the basic application hierarchy, which will now
appear in the Hierarchy window. You can then begin to develop each subVI,
perhaps color-coding their icons, which will also be colored in the Hierarchy
window, to reflect their status. For example, white icons could represent
untouched VIs, red icons could represent subVIs in development, and blue
icons could represent completed VIs. While this is only one example of
using the Hierarchy window as a development tool, it demonstrates the
usefulness of this window for organizing a project.
If you select Help»Show Context Help, the Context Help window appears.
As you move the cursor over an object, the Context Help window updates to
show its description. You can programmatically show or hide the Context
Help window with the Get Help Window Status and Control Help
Window functions, which you find in the Functions»Application
Control»Help palette.
Use this function to determine if the Context Help window is visible and the
location of the upper left corner of the window.
With this function, you can control whether the Context Help window is
visible, and where it will appear when shown.
You can also use the Control Online Help function to access the LabVIEW
Help or custom help files that you compile using third-party tools. The type
of online reference development tools you can use to develop this type of
help file depend on the platform on which your application will run.
• Windows Microsoft Help (.hlp files)
• Macintosh QuickView
• Sun/HP-UX HyperHelp
With this function, you manipulate an online help file. You can list the
contents of the help file, jump to keywords in the file, or close the online
help file.
Providing online help and reference materials for your application makes it
easier to use and gives it a more polished, professional look.
VI Comparison
The LabVIEW Professional Development System includes a utility to
determine the differences between two VIs loaded into the memory. From
the LabVIEW pull-down menu, select Tools»Compare»Compare VIs to
display the Compare VIs dialog box.
From this dialog box, you can select the VIs you want to compare, as well
as the characteristics of the VIs to check. When you compare the VIs, both
VIs will be displayed, along with a Differences window that lists all
differences between the two VIs. In this window, you can select various
differences and details to view, which can be circled for clarity.
Exercise 5-4
Objective: To examine some of the built-in LabVIEW features for handling applications.
In this exercise, you will explore some of the features built into LabVIEW
for handling applications.
1. Open the Application Exercise(5-3) VI you created in the previous
exercise. Close any other VIs loaded into memory.
2. Select Tools»VI Revision History. The history window for the VI
should appear.
3. Click Reset in the Revision History window to clear the current history.
Click Yes to confirm the deletion of the history and resetting of the
revision number.
4. In the Comment box of the History window, type in Initial
Application Created. and then click the Add button. Your
comment should appear in the Revision History listing, along with a
date and time stamp. Close the Revision History window.
5. Select Browse»Show VI Hierarchy. The application’s hierarchy
appears.
10. Using the Select option, make sure that the two Application Exercises
are listed in the VIs to Compare box, and that the Compare options are
set as in the previous example.
11. Click Compare to display the Differences window and tile the two VIs.
Place a checkmark in the Circle Differences checkbox in the
Differences window. Then, select a difference from the Differences
listbox, select a detail from the Details listbox, and then click Show
Detail. The difference between the two VIs is highlighted. Examine the
various differences between the two VIs and then close the Differences
window.
The SCC tools also contain a VI Metrics tool to measure the complexity of
an application similar to the widely used Source Lines of Code (SLOCs)
metrics for textual languages. With the VI Metrics tool, you can view
statistics about VIs, such as the number of nodes (functions, subVI calls,
structures, terminals, and so on) of a VI and its subVIs. Other statistics
include the number and sizes of block diagrams, number and type of user
interface objects, number of accesses to global and local variables, and
number of calls to Code Interface Nodes or shared libraries. You access the
followin VI Metircs window from the Tools»Advanced menu.
The LabVIEW Help and manuals for this toolkit not only provide reference
material for the previous utilities, but also extensive discussions on
management of software projects. Various development models,
prototyping and design techniques, and project tracking methods are
described in detail. Documentation of VIs and tips for developing clear code
are described in detail as well.
• From the Target tab, you can specify if you want to create a stand-alone
executable or a shared library, the name of your application and the
directory in which to create it. Optionally, you can choose to write
subVIs to an external file if you want to keep the main application small.
• From the Source Files tab, you can define the VIs that make up your
application. When you click Add Top Level VI, you add the main VI(s)
for your application. You need to select only the top-level VI, and
LabVIEW automatically includes all subVIs and related files (such as
menu files or DLLs). If your VI dynamically calls any subVIs using the
VI Server, LabVIEW cannot detect them automatically, so you must add
them by clicking the Add Dynamic VI button. If you want to include
any data files with your application, click the Add Support File button,
and the data files automatically copy over to your application directory.
• From the VI Settings tab, specify modifications to make to your VIs as
part of the build. You can choose to disable certain VI Properties. These
settings only apply to the build process and do not affect your original
source VIs. LabVIEW automatically creates your application as small as
possible by removing debugging code, block diagrams, and unnecessary
front panels. If you open a front panel dynamically using the VI Server,
you must specify that the front panel is needed using the VI Settings tab.
• From the Application Settings tab, you can customize the features in
your application. You can choose to specify the memory size for the
Macintosh, or customize icons and ActiveX server features on
Windows.
• From the Installer Settings tab (Windows only), you create an installer.
The installer is written to the directory that contains your application.
Note After the Run-Time DLL is properly installed on a machine, it can run any
executable VI developed in LabVIEW. You need to include only the Run-Time DLL with
the first VI sent to each computer.
The first section of this lesson describes the architecture of your application
and has you build the application in the exercises. Your application is a
single top-level VI that runs when you launch the application and calls front
panels from several subVIs when called. This is the most common and
easiest architecture for building a stand-alone application.
Programming Issues
You should consider several programming issues when you are building VIs
that end up as built applications. The first issue is to know what outside code
is used for the application. For example, are you calling any system or
custom DLLs or shared libraries? Are you going to process command line
arguments? These are advanced examples that are beyond the scope of this
course, but you need to consider them for the application.
A second issue is with the path names used in the VI. One example is when
you use the VI Server capability to dynamically load and run VIs (this is
described in the LabVIEW Advanced I course). Once an application is built,
the VIs are embedded in the executable. Suppose you have a VI named
test.vi inside an application named test.exe. A Current VI’s path
primitive in test.vi returns test.exe\test.vi prepended with the full
path of test.exe. Being aware of these issues will help you to build more
robust applications in the future.
A last issue that will affect the application you have currently built is that the
top-level VI does not quit LabVIEW or close the VIs front panel when it is
finished executing. To completely quit and close the top-level VI, you must
call the Quit LabVIEW function located on the Functions»Application
Control palette on the block diagram of the top-level VI.
The default packaging for applications is a single executable file. All VIs
that are part of the application are embedded in the executable file. These
include top-level VIs, dynamic VIs, and all their subVIs. While this
packaging is simple because it results in a single file, these files can become
quite large depending on the number of VIs in your application.
Depending upon the nature of your application, it can require the presence
of non-VI files to function correctly. Files commonly needed include a
preferences (.ini) file for the application, the LabVIEW serpdrv file, and any
help files that your VIs call. The LabVIEW serpdrv file (Windows and UNIX)
is required for any application that uses serial port I/O. Note that run-time
menu files and shared library files called using the Call Library Node are not
support files. The Application Builder includes run-time menu files in the
main files for the application. It automatically stores any shared libraries
needed in the support file directory for the application. External subroutines
for CINs are also stored in the main files for the application.
Note Refer to the LabVIEW Help in Help»Contents and Index for more detailed
descriptions of how to use the Application Builder and make a preferences file for your
application.
You will learn about each of the steps and options of the Application Builder
when you build an application in the next exercise. After defining your build
specifications using the LabVIEW Application Builder, you will save those
settings to disk in the form of a build script (.bld) file.
Note You must have the Application Builder properly installed to run this example.
To determine whether it is installed, select the Tools menu. If the option Build
Application or Shared Library (DLL) appears in the Tools menu, then the Application
Builder is properly installed.
Front Panel
1. Open the Application Exercise(5-3) VI you created in Exercise 5-3.
Modify the following front panel to remove the comments.
Block Diagram
4. Open the block diagram and use the following components.
a. Place the not function located on the Functions»Boolean palette on
the block diagram. This function inverts the value being sent to the
While Conditional terminal. When the loop ends, this value is a
False, so a True value is actually sent through the loop boundary to
the Quit LabVIEW function.
9. Click the Source Files tab and select the Add Top-Level VI button.
Add Application Exercise.vi as shown.
10. Click the VI Settings tab. Leave these settings at their default
values—the top-level VI runs when opened and the block diagrams and
front panels are only saved if they are necessary. Examine these settings;
they should resemble the following examples.
11. Click the Application Settings tab. This is where you would enable
ActiveX settings or give your application a custom icon. Leave the icon
as the default LabVIEW icon. Do not change any of these settings.
12. Click the Installer Settings tab. Build a distribution kit for your
application that installs into the C:\Program Files\
Myapplication directory. Configure the Installer tab as shown.
13. Click the Build button. The files associated with the installer are
then compressed into setup diskettes, which are stored in the
C:\myapp\installer\disks directory. A Setup.exe file is
created as well, which can be used to install the diskette images. All of
these files could be copied to diskettes to transfer the application to
another system. The LabVIEW Run-Time DLL installer is included by
default. The executable for your application is also built and is called
myApplication.exe, as defined on the Target tab.
14. Select Done from the Build Application window to close that utility. It
asks you to save a script so you can build this application again. Select
Yes and name the script myapp.bld. Now if you make changes to the
original application and want to rebuild an executable and installer with
the same settings, you can open this script file using the Load button.
15. Run myApplication.exe from the C:\myapp directory. Application
Exercise should open its front panel and run automatically. Operate the
VI to make sure all the settings you chose are working. Close the
application when you are finished.
Additional Exercises
5-6 Modify Application Exercise VI so that the Configure Data
Acquisition, Acquire Data, Analyze & Present Data, and View
Analysis File buttons are disabled and grayed out if the user has
not logged in with a valid user name and password.
Hint: Use control references and the Disable Controls VI you built
in Exercise 2-8 nodes to modify the buttons.
Save this VI as Application Exercise(5-6).vi.
5-7 Add one menu button to the menu cluster control in Application
Exercise VI so the user can show or hide the LabVIEW Help
window. The text of the button should indicate what happens when
the user clicks the button, for example, Show Help and Hide Help. If
you notice that the buttons and indicators on the front panel do not
have descriptions in the Context Help window, you need to add them
in the Description and Tip shortcut dialog box for each control or
indicator.
Make sure the VI properly tracks the state of the Context Help
window. For example, if the user clicks the Show Help button to
show the Context Help window, but closes the Context Help window
from the Help»Show Context Help menu, your VI incorrectly
assumes that the Context Help window is showing. Save this VI
as Application Exercise(5-7).vi.
Note Use a Property Node to set the button text. The mechanical action of the button
should be Latch When Released. Use a shift register to retain the status of the Context
Help window’s visibility, and use the Control Help Window function to show and hide
the Context Help window.
Notes
Notes
Benefits
One important benefit of multithreaded LabVIEW is the separation of the
user interface from block diagram execution. Any activities conducted in the
user interface, such as drawing on the front panel, responding to mouse
clicks, and so on, operate in their own thread. This prevents the user
interface from robbing the block diagram code of execution time. So,
displaying a lot of information about a graph does not prevent the block
diagram code from executing. Likewise, executing a long computational
routine does not prevent the user interface from responding to mouse clicks
or keyboard strikes.
Using Multithreading
When an existing LabVIEW application runs, it takes advantage of the
multithreaded system automatically without any modification to the
application. However, when working with multiple VIs, there are different
classifications of threads, called execution systems, available to organize
your application. There are six execution systems available to run VIs:
• User Interface
• Standard
• Instrument I/O
• Data Acquisition
• Other 1
• Other 2
To change the thread category in which a VI runs, select Execution from the
top pull-down menu in the VI Properties dialog box.
The Preferred Execution System list box lists the available categories of
execution systems. You also can prioritize parallel tasks in a multithreaded
environment by setting the Priority of the VI. Within each thread category,
you can specify the priority of execution—normal, above normal, high, time
critical, subroutine, and background. Normal priority is the same as level 0
priority in previous versions of LabVIEW, above normal priority is the same
as level 1 priority, and so on. If there are multiple VIs, the VIs are placed
into an execution queue. VIs with higher priority, except the subroutine
priority, still execute before lower priority VIs. However, VIs with a
subroutine priority level behave differently than VIs with other priority
levels. When a VI runs at subroutine priority, it runs in the thread category
of its caller, and no other VI can run in that thread until that VI or its subVIs
complete. Subroutine priority VIs can call other subroutine priority VIs
only. Use subroutine priority VIs only when you want to run a simple
computation with no interactive elements. You can skip the execution of a
subroutine priority subVI when it is busy by right-clicking the subVI and
selecting Skip Subroutine Call if Busy. Use this option when you are
calling a shared subroutine from a high-priority VI but you do not want to
wait for the subroutine VI to become available.
Exercise caution when setting the priority levels for VIs. Using priorities to
control execution order might not produce the results you expect. For
example, if you use the priority setting incorrectly, lower priority tasks
might never execute. As you will see later in this lesson, strategic use of
Wait functions within VIs also can be a very effective way of optimizing
your LabVIEW code. Refer to the LabVIEW Help for more information
about how to use Wait functions.
The Profile window displays the performance information for all VIs in
memory in an interactive tabular format. From the window, you can choose
the type of information to gather and sort the information by category. You
also can monitor subVI performance within different VIs. To show the
Profile window, select Tools»Advanced»Profile VIs. The following
window appears.
Notice that you must select the Profile Memory Usage option before
starting a profiling session. Collecting information about VI memory use
adds a significant amount of overhead to VI execution, which affects the
accuracy of any timing statistics you gather during the profiling session.
Therefore, you should perform memory profiling separate from time
profiling.
Many of the options in the Profile window are available only after you begin
a profiling session. During a profiling session, you can grab a snapshot of
the available data and save the data to an ASCII spreadsheet file. The timing
measurements accumulate each time you run a VI.
Note All statistics measured in a profiling session are collected for a complete run of
a VI, not a partial run of a VI.
The VI Time statistic column shows the amount of time spent executing the
VI and displaying its data, as well as the time spent by the user interacting
with the front panel. This time consists of five subcategories, which you can
show by selecting the Timing Details option. The subcategories are
Diagram, Display, Draw, Tracking, and Locals. Refer to the LabVIEW Help
or the LabVIEW User Manual for more information about these statistics.
The SubVIs statistic column shows the total execution time for all the
subVIs called by the main VI. In addition, timing information can be
displayed in seconds, milliseconds, or microseconds.
The Total Time statistic column shows the sum of the VI and subVIs values,
which represents the total execution time for the main VI.
Memory Statistics
To collect memory statistics with the Profile window, select the Profile
Memory Usage option before starting the profiling session. You also can
select the Profile Memory Usage option after starting the Profiler to collect
additional memory information.
The Profile window displays two sets of memory use data. One set of data
shows the number of bytes of memory used, and the other shows the blocks
of memory. LabVIEW stores data such as arrays, strings, and paths in
contiguous blocks of memory. If a VI uses a large number of blocks of
memory, the memory can fragment, which degrades LabVIEW
performance in general, not VI execution.
The Average Bytes statistic column shows the average number of bytes of
memory used by a VI’s data space during its execution. Min Bytes and Max
Bytes represent the least and greatest amount of memory used by a VI
during an individual run. Average Blocks indicates how many blocks of
memory a VI needs on average, while the Min Blocks and Max Blocks
show the fewest and greatest number of blocks of memory used by a VI
during an individual run.
The Profile window is a powerful tool for analyzing how your application
uses execution time as well as memory. With this information, you can
identify the areas of your VI that you need to optimize. In this exercise,
examine the project just completed using the Profile window.
1. Open your final project, called CD Application Exercise VI.
If you did not complete this final project, you can open the solution.
You are now capturing timing information about the VIs in memory.
Sort the Total Time column and look at where the CD Application Exercise
VI spends most of its time. Notice how these VIs correspond with the VIs
that require user interaction. Waiting for user input is often the portion of
execution which requires the most time.
In the Profile window you can capture timing statistics and information
about VI memory usage. To capture memory usage, place a checkmark in
the Profile Memory Usage checkbox.
Note Collecting information about VI memory usage requires overhead which can
create misleading timing statistics.
Notice which VIs fragment memory, and look to see which VIs use many
blocks. Why do you suppose these VIs use blocks? Having fragmented
memory causes VIs to execute more slowly because moving data around in
memory takes overhead.
Other factors, such as execution overhead and subVI call overhead, usually
have minimal effects on execution speed.
Input/Output
Input/Output (I/O) calls generally take much more time than a
computational operation. For example, a simple serial port read operation
can have an associated overhead of several milliseconds. This overhead is
present not only in LabVIEW, but also in other applications. The reason for
this overhead is that an I/O call involves transferring information through
several layers of an operating system.
The best method of reducing this I/O overhead is to minimize the number of
I/O calls you make in your application. Structure your application so that
you transfer larger amounts of data with each call, instead of making several
I/O calls that transfer a small amount of data.
Screen Display
Updating controls on a front panel is another time-consuming task in an
application. While multithreading helps to reduce the effect that display
updates have on overall execution time, complicated displays, such as
graphs and charts, can adversely affect execution speed. This effect can
become significant on the LabVIEW platforms that do not support
multithreading. Although most indicators do not redraw when they receive
data values that are the same as the old data, graphs and charts always
redraw. To minimize this overhead, keep front panel displays simple, and try
to reduce the number of front panel objects. Disabling autoscaling, scale
markers, and grids on graphs and charts improves their efficiency.
The design of subVIs also can reduce display overhead. If subVIs have front
panels that remain closed during execution, none of the controls on the front
panel can affect the overall VI execution speed.
As shown in the following block diagram, you can reduce display overhead
by minimizing the number of times your VI updates the display. Drawing
data on the screen is an I/O operation, similar to accessing a file or GPIB
instrument. For example, you can update a waveform chart one point at a
time, or several points at a time. You get much higher data display rates if
you collect your chart data into arrays so that you can display several points
at a time. This way, you reduce the amount of I/O overhead required to
update the indicator.
Other Issues
SubVI Overhead
Each call to a subVI involves a certain amount of overhead. This overhead
is fairly small, on the order of tens of microseconds, especially in
comparison to I/O overhead and display overhead, which can range from
milliseconds to tens of milliseconds. However, if you make 10,000 calls to
a subVI in a loop, the overhead could significantly affect your execution
speed. In this case, you might consider embedding the loop in the subVI.
Also, avoid accessing local and global variables unnecessarily in loops. For
example, the following first block diagram wastes time by reading from the
global variable and writing to the global variable during each iteration of the
loop. If you know that the global variable is not read from or written to by
another block diagram during the loop, consider using shift registers to store
the data, as shown in the second block diagram.
Notice that you need the shift registers to pass the new value from the subVI
to the next iteration of the loop. Beginning LabVIEW users commonly omit
these shift registers. Without using a shift register, the results from the subVI
are never passed back to the subVI as the new input value, as shown in the
following block diagram.
In the previous block diagram, the global variable is read once before the
loop begins, and the same value is passed to the function 10,000 times. The
result of the loop is the same as if you had written the code as shown in the
following block diagram.
Parallel Diagrams
When several loops run in parallel on a block diagram, LabVIEW changes
between the loops periodically. If some of these loops are less important
than others, you should use the Wait (ms) function to ensure that the less
important loops use less time. For example, consider the following block
diagram.
The two loops run in parallel. One of the loops acquires data and must
execute as frequently as possible. The other loop monitors user input.
Currently, both loops get equal time. The loop monitoring the user input can
execute several hundred times per second. In reality, this loop needs to
execute only a few times per second, because the user cannot make changes
to the interface very quickly. As shown in the following block diagram, you
can call the Wait (ms) function in the user interface loop to give significantly
more execution time to the other loop.
When you open the Charting Benchmark Example VI, two other subVI
front panels also open. These two subVIs plot the same data under different
conditions.
Front Panels
4. Move the window so that it does not overlap any of the VI front panels.
5. Click the Start button in the Profile window. You see the VI Time,
SubVIs Time, and Total Time statistics in the table.
6. Run the Charting Benchmark Example VI. The VI does nothing until
you click the Run SubVIs button. Run the subVIs at least three or four
times. Then click the Quit button to stop the Charting Benchmark
Example VI.
7. After running the subVIs several times, click the Snapshot button in the
Profile window. Locate Charting Benchmark Example VI in the Profile
window and double-click it to display its subVIs. Notice the VI
execution times for the two subVIs. Recall that these are cumulative
times, not the amount of time needed to execute the subVIs once. Notice
that updating the chart one point at a time is the slowest method, and that
updating the chart several points at a time is the fastest method.
8. Select the Timing Statistics option to view the average execution time
for the subVIs. Then select the Timing Details option and examine the
Display and Draw statistics. Notice that the Display statistic is largest
for the Update Chart 1 Point at a Time subVI and is very low for the
Update Chart 50 Points at a Time VI. Record the average execution time
in the following table.
Refer to the LabVIEW Help or the LabVIEW User Manual for more
information about these statistics.
9. Click the Stop button in the Profile window to stop the profiling session.
Then close the Profile window.
10. Close all open VIs and do not save any changes.
11. If you are running LabVIEW on a multithreading operating system,
place a checkmark in the Run with multiple threads checkbox on the
Execution page in the File»VI Properties dialog box and restart
LabVIEW. Repeat steps 3 through 10, noting in the table how much
faster the VIs execute when the display is running under its own
execution subsystem.
Load and run a VI that plots a waveform pattern. Notice how the dataflow
affects the execution of the VI.
Front Panel
1. If you are running LabVIEW on an operating system that supports
multithreading (Windows, Solaris2, or Concurrent PowerMAX), complete
steps a though c. If you are on a system that does not support
multithreading, skip to step 2.
a. Configure LabVIEW so that it does not use multithreading when it
runs VIs. Select Tools»Options to display the Options dialog box.
b. From the top pull-down menu of the Options dialog box, select
Performance and Disk. In the Performance and Disk section,
remove the checkmark from the Run with multiple threads
checkbox. Click OK.
c. Exit and restart LabVIEW so that the updated preferences take
effect. LabVIEW is now configured to run VIs under a single thread,
using co-operative multitasking.
2. Open the Dialog & SubVI Demo VI. The VI is already built for you. The
front panel contains a strip chart and several option buttons. This chart
shows two pieces of data, the running average of a simulated
temperature and a red plot showing how quickly these averages are
calculated.
3. Open the block diagram and examine it. Two While Loops run in
parallel. One loop handles data collection and analysis while the other
handles the user interface.
4. Run the VI. Notice the plot speed and the averages/second being
calculated.
Notice that the Averages/Sec value is periodic and dips very low. The
block diagram contains two While Loops running in parallel. The Plot
Loop (top) is the one generating the temperature average and the number
of averages per second. The dips in performance happen when the Menu
Loop executes and checks the values of the buttons on the front panel.
Performance increases when the Plot Loop runs.
5. Click the Show Dialog button. Notice the effect on the plot speed and
the Averages/Sec value. Recall that a loop cannot begin its next iteration
until the entire block diagram inside it finishes executing. In the Menu
Loop, the values from the buttons are read to determine which case
should be executed. If you click the Show Dialog button, Case 0 is
executed. The case does not complete until you click the OK button in
the dialog box. Thus, while the dialog box is displayed, the Plot Loop
does not need to share the processor with the Menu Loop.
6. Click the Pop-Up VI button. The Pop-up 2nd Process VI opens its front
panel and runs. Notice the effect on the first VI’s Averages/Sec value. As
in the situation when you clicked the Show Dialog button, the Menu
Loop no longer executes until the Pop-up 2nd Process VI ends.
However, LabVIEW runs the second VI at the same time as the original
VI. The dips in performance appear when the second VI runs. Therefore,
LabVIEW executes multiple VIs in the same way it executes parallel
loops—each process gets an equal time-slice.
7. Click the Stop button.
8. Modify the Menu Loop so it includes a Wait (ms) function. Wire a
constant value of 300 to the input of the function. Notice how the speed
of the Plot Loop changes.
9. Close the VI and do not save any changes.
10. If you are running LabVIEW on a multithreaded operating system, place
a checkmark in the Run with Multiple Threads checkbox on the
Execution page in the File»VI Properties dialog box. Exit and restart
LabVIEW. Repeat steps 2 through 9 and notice how multithreading
affects the execution speed of the Dialog & SubVI Demo VI.
If you want to magnify the results of this exercise, move windows with your
cursor while the Dialog & SubVI Demo VI runs. This increases the
processor workload creating more drastic results.
Use the Profile window to compare the performance of VIs that perform the
same tasks using different programming techniques.
Front Panel
5. After running the subVIs several times, stop the VI and click the
Snapshot button in the Profile window. Locate the Computation and
Global Benchmark VI in the Profile window and double-click it to
display its subVIs if they are not already displayed.
Notice the amount of time spent in each subVI. Specifically, compare
the amount of time spent executing Update Globals Inside Loop VI
versus Globals Outside of Loop VI and the time spent executing
Unnecessary Loop Computations VI versus Unnecessary Computations
Removed VI. Is this the behavior you expected? How would you apply
what you have learned in this exercise to your programming?
6. Click the Stop button in the Profile window to stop the profiling session.
Then close the Profile window.
7. Close the VI. Do not save any changes.
Functions that generate data allocate storage for those data. When data are
no longer needed, LabVIEW deallocates the associated memory. When you
add new information to an array or a string, LabVIEW allocates the
necessary memory.
LabVIEW Memory
Windows, Sun, and HP-UX—LabVIEW allocates memory dynamically,
taking as much as needed. This process is transparent to the user.
Virtual Memory
When using Windows or Macintosh, you can use virtual memory to increase
the amount of memory available for your applications. Virtual memory uses
available disk space for RAM storage. If you allocate a large amount of
virtual memory, applications perceive this as memory that is available for
storage.
On the Macintosh, you allocate virtual memory using the Memory device in
the Control Panel folder. Windows, Sun, and HP-UX automatically manage
virtual memory allocation.
LabVIEW does not differentiate between RAM and virtual memory. The
operating system hides the fact that the memory is virtual. However,
accessing data stored in virtual memory is much slower than accessing data
stored in physical RAM. With virtual memory, you might occasionally
notice more sluggish performance because data are swapped to and from the
hard disk by the operating system. Virtual memory can help run larger
applications, but it is probably not appropriate for applications that have
critical time constraints.
VI Components
VIs have the following major components:
• Front Panel
• Block Diagram
• Code—block diagram compiled to machine code
• Data—control and indicator values, default data, block diagram constant
data, and so on
When you load a VI, LabVIEW loads the front panel, the code, if it matches
the platform, and the data for the VI into memory. If the VI needs to be
recompiled because of a change in platform or in the interface to a subVI,
LabVIEW also loads the block diagram into memory.
LabVIEW also loads the code and data space of subVIs into memory. Under
certain circumstances, LabVIEW also loads the front panel of some subVIs
into memory. For example, if the subVI uses Property Nodes, LabVIEW
must load the front panel because Property Nodes manipulate the
characteristics of front panel controls.
always resident
You also can use the Profile window to monitor the memory used by all VIs
in memory.
Note When monitoring VI memory use, be sure to save the VI before examining its
memory requirements. The LabVIEW Undo feature makes temporary copies of objects
and data, which can increase the reported memory requirements of a VI. Saving the VI
purges the copies generated by Undo, resulting in accurate reports of memory
information.
cannot predetermine the space requirements you will need. LabVIEW might
need to relocate the entire buffer as the array grows in size, perhaps several
times. The time needed for relocation increases with the size of the array.
Therefore, you should use For Loops to assemble arrays when possible,
rather than using While Loops or concatenating arrays with the Build Array
function.
For Loop
vs.
While Loop
Inplaceness
When possible, LabVIEW’s compiler reuses a function’s input buffers to
store its output. This buffer sharing is called inplaceness. In the following
example, the Multiply function output uses the same buffer as the top input.
The array at the right is said to be inplace to array A.
A function output reuses an input buffer if the output and the input have the
same data type, representation, and, in arrays, strings, and clusters, the same
structure and number of elements. Functions capable of inplaceness include
Trigonometric and Logarithmic functions, most Numeric functions, and
some string and array functions such as To Upper Case and Replace Array
Element. A function that shifts or swaps elements of an array, such as
Replace Array Element, can reuse buffers. Some functions such as Array
Subset and String Subset might not copy data but might pass pointers to the
subarrays or substrings. In the following illustration, A, B, C, and D identify
individual buffers. Build Array and Concatenate Strings are special
functions. They operate inplace when they can, but sometimes they must
allocate new buffers.
Method 1 (Incorrect)
Method 1 might be your first attempt to save data space memory. You might
think changing the representation of the array on the front panel (FP) to SGL
can save space memory. However, this method does not affect the amount of
memory needed by the VI, because the function creates a separate buffer to
hold the converted data. The coercion dot on the SGL array terminal
indicates the function created a separate buffer to hold the converted data.
Method 2 (Incorrect)
Method 3 (Correct)
Method 3 reduces the size of the data space considerably, from 24.8 KB to
12.8 KB. This method converts the Random Number (0-1) function output
to SGL before the array is created; therefore, this method creates two SGL
arrays at the border of a For Loop rather than two DBL arrays.
Now, consider what you need to do to change an element in the Test Data
array. First, you must index an element of the overall Tests array. For that
element, which is a cluster, you must unbundle the elements to get to the
array. You then replace an element of the array and store the resulting array
in the cluster. Finally, you store the resulting cluster in the original array. An
example of this is shown in the following illustration.
Load and run a VI that creates an array of numbers using several methods.
Using the Profile window, compare the performance of VIs using For
Loops, While Loops, Auto-Indexing, and the Build Array function to create
arrays. Also, compare these methods with a technique that uses the Replace
Array Element function on an existing array.
Front Panel
We will now describe the six different array building techniques and why the
performance of these VIs differs.
The Initialize Array function is slightly faster than an Auto Indexing For
Loop. In both instances, the array size is known and LabVIEW can allocate
the correct amount of memory only once. Recall that resizing requires more
execution time. Therefore the Initialize Array function or an Auto Indexing
For Loop are the best ways to create arrays.
If you can predetermine the maximum size of the array to be built, then you
can initialize this array and pass it into the While Loop. Once inside the
While Loop, each element can be updated or replaced as needed. This is
somewhat efficient, because the array does not need to be reallocated once
it is passed into the While Loop. This is still not as efficient as the For Loop
or Initialize Array function.
Avoid using the Build Array function inside a loop. Every time a new value
is appended to the array, LabVIEW must reallocate the buffer and copy the
entire array to the new location. Thus execution times for the Build Array
function are the slowest.
6. Close the Profile window. Close the VI and do not save changes.
This project requires you to utilize information from the previous chapter as
well as draw upon other information in the course.
1. Close all VIs you might have open.
2. Open the Performance Enhancements VI in the Exercises\LV
Basics2 directory. Show the Profile window by selecting
Tools»Advanced»Profile VIs. Select Timing Statistics in the Profile
window.
3. Run the VI. After it finishes, click the Snapshot button in the Profile
window to view execution information about the VI. Notice how many
times VIs are called and which VIs being called multiple times are likely
to be slow. Notice which VIs were run many times and observe which
VIs you guess are likely to take longer execution times.
4. Select File»VI Properties and select Memory Usage from the top
pull-down menu. A well written VI for this application should consume
a total of about 25k of memory. Notice how much this poorly written VI
consumes.
5. Modify the VI to so that this application:
– Runs correctly for higher frequency waveforms.
– Runs faster.
– Uses better data structures and is easier to understand.
– Is better documented.
Use the tips in this lesson, information from other chapters in this
course, and the following tips to get started:
– Putting High Level VIs in loops creates redundant function calls.
– Gathering or plotting data one point at a time is less efficient than
acquiring multiple points.
– Flat data types are more memory efficient than complex data
structures.
– There are a variety of ways to document a VI.
6. Save the modified VI.
7. Run the VI. Notice improvements in run time and memory usage. Also
notice the improvements in readability and simplicity of code.
Note Make sure you save the VI before you examine its memory usage. This prevents
the LabVIEW Undo feature from allocating memory unnecessarily.
This VI is poorly written. It runs slowly and takes more memory than
necessary. In this exercise, optimize the VI to increase its run speed while
decreasing its memory requirements.
1. Close all VIs you might have open.
2. Open the Performance Challenge VI. Show the Profile window by
selecting Tools»Advanced»Profile VIs. Before running Performance
Challenge, select Timing Statistics and Timing Details in the Profile
window so that you can gain a better understanding of the VI run time.
3. Run the VI. After it finishes, click the Snapshot button in the Profile
window to view execution information for the VI. When looking at this
information, notice how much time is taken updating local variables,
and also how many times this application calls the file I/O subVIs.
4. Select File»VI Properties. Select Memory Usage from the top
pull-down menu. Notice the considerable amount of memory taken by
the data in this VI.
5. Modify the VI to improve the run speed and reduce the amount of
memory required. Use the tips in this lesson and the following
guidelines to get you started:
• Local variables increase memory requirements and slow run speed,
especially when they are accessed in loops.
• Create arrays in an efficient manner.
• Minimize the amount of file I/O operations performed in an
application. Only open and close a file when necessary.
• Avoid unnecessary computations and data conversions, especially
in loops.
Tip You only need to meet the requirements of the application described previously.
How you choose to implement this application is up to you.
Note Make sure you save the VI before you examine its memory requirements. This
prevents the LabVIEW Undo feature from allocating memory unnecessarily.
Use the Profile window to gauge VI performance and to help you locate the
tasks that require most of your VI’s run time and memory use. You can then
concentrate on improving those troublesome areas to enhance the overall
performance of your VI.
Breaking large top-level VIs into several smaller subVIs reduces the amount
of memory consumed in your application and can improve performance.
Use the following tips to improve the overall performance of your VIs:
• Avoid overusing local and global variables.
• Avoid displaying and manipulating large arrays and strings.
• Use functions that reuse data buffers.
Notes
A. Polymorphic SubVIs
LabVIEW built-in functions can handle different types of data for the same
terminal, a capability called polymorphism. An example of polymorphism
is the Add function.
It is also possible to create your own polymorphic VIs, which can handle
more than one type of data for the same terminal. These polymorphic VIs
can then be used as polymorphic subVIs.
3. Add each of the set of VIs to the polymorphic VI using the Add VI
button.
4. You can create an icon for the polymorphic VI using the Edit Icon
button. You also can create context help for the polymorphic VI by
selecting Documentation from the top pull-down menu in the File»VI
Properties dialog box.
Note Context help for the polymorphic VI is not associated with context help for the VIs
that compose the polymorphic VI. Therefore, you must create new context help by using
the Documentation page in the File»VI Properties dialog box.
Instead of having one VI for sorting 1D arrays and another subVI for sorting
2D arrays, one VI called Sort Array handles both types of inputs. In this
exercise, create this VI.
1. Create a VI that sorts a 1D array. This VI should also include an option
to sort in ascending or descending order and pass out an error Boolean
object. The following example is a suggested front panel. You need to
create the front panel and block diagram and test the code you write.
Note Use the same icon connector pane for the Sort 2D Array instance. Otherwise the
polymorphic VI produces broken wires.
Now create the polymorphic VI, which is composed of the Sort 1D Array+
instance and the Sort 2D Array+ instance.
7. To combine the two instances into one polymorphic VI, select File»New
and select Polymorphic VI. If you are at the welcome screen, select
Polymorphic VI from the New VI pull-down menu.
8. Add the Sort 1D Array+ and Sort 2D Array+ VIs using the Add VI
button. You might need to browse to the directories where you saved
these VIs.
9. Create an icon for this new polymorphic VI by selecting the Edit Icon
button.
10. Create context help for this VI by selecting Documentation from the
top pull-down menu in the File»VI Properties dialog box.
11. Save your VI as Sort Poly Array.vi.
12. Use this VI as a subVI in another VI to test the functionality. Notice the
help screen. Also notice what happens when you double-click the
polymorphic VI. What happens if you select a particular context by
right-clicking and selecting Select Type?
Decorations
One of the most straightforward methods to enhance a user interface is to
apply the LabVIEW Decorations to a front panel as you did in Lesson 2,
Designing Front Panels. Through careful use of the decorations, you can
increase the readability of the front panels.
Importing Graphics
You can import graphics from other VIs for use as background pictures,
items in ring controls, or parts of other controls. However, before you can
use a picture in LabVIEW, you need to load it into the LabVIEW Clipboard.
There are one or two ways to do this, depending on your platform.
• Windows—If you can copy an image directly from a paint program to
the Windows Clipboard and then change to LabVIEW, LabVIEW
automatically imports the picture to the LabVIEW Clipboard. You also
can use the Import Picture from File option from the LabVIEW Edit
menu to import a graphics file into the LabVIEW Clipboard. LabVIEW
recognizes graphics files in the following formats: CLP, EMF, GIF,
PCX, BMP, TARGA, TIFF, LZW, WFM, and WPG.
• Macintosh—If you copy from a paint program to the Clipboard and then
change to LabVIEW, LabVIEW automatically imports the picture to the
LabVIEW Clipboard.
• UNIX—You can use the Import Picture from File option from the
UNIX Edit menu to import a picture of type X Window Dump (XWD),
which you can create using the xwd command.
Custom Controls
You can customize LabVIEW controls and indicators to change their
appearance on the front panel. You also can save these controls for use in
other VIs. Programmatically, they function the same as standard LabVIEW
controls.
Control Editor
Launch the Control Editor by selecting a control on the front panel and
selecting Edit»Customize Control. The Control Editor appears with the
selected front panel object in its window. The Control Editor has two modes,
edit mode and customize mode.
Edit Mode
In edit mode, you can right-click the control and manipulate its settings as
you would in the LabVIEW programming environment.
Customize Mode
In customize mode, you can move the individual components of the control
around with respect to each other. For a listing of what you can manipulate
in customize mode, select Window»Show Parts Window.
One way to customize a control is to change its type definition status. You
can save a control as a control, a type definition, or a strict type definition,
depending on the selection showing in the Type Def. Status ring. The
control option is the same as a control you would select from the Controls
palette. You can modify it in any way you need to, and each copy you make
and change retains its individual properties.
Saving Controls
After creating a custom control, you can save it for use later. By default,
controls saved on disk has a .ctl extension. You also can place controls in
the Controls palette using the same method as that you used to add subVIs
to the Functions palette.
You also can use the Control Editor to save controls with your own default
settings. For example, you can use the Control Editor to modify the defaults
of a waveform graph, save it, and later recall it in other VIs.
Exercise A-2
Objective: To use the Control Editor to modify a control.
1. Open a new front panel.
2. Place a Horizontal Pointer Slide located on the Controls»Numeric
palette on the front panel. Right-click the slide and select Visible
Items»Digital Display.
6. Close the Control Editor by selecting Close from the File menu. Save
the control as Custom Slider.ctl, then click Yes to replace the
existing one. The modified slider is shown on the front panel.
Note You can save controls that you create like you save VIs. You can load saved
controls using Select a Control from the Controls palette. Controls have a .ctl
extension.
7. Manipulate the slider and watch the meter track its data value.
8. Close the VI. Do not save changes.
Build a VI that uses custom Boolean indicators to show the state of a Bunsen
burner and flask being heated. The pictures representing the on and off states
of the Bunsen burner and the flask are already drawn for you.
Front Panel
Note The default state of the LED is FALSE. If you do not see the picture, the LED is
probably in the FALSE state.
c. Change to the front panel by clicking it. Using the Positioning tool,
select the graphic of the flask that shows the contents of the flask not
boiling, and select Edit»Cut. Change to the Control Editor window
by clicking it.
d. Right-click the boiling flask and select Import Picture»False. This
custom picture now represents the FALSE state.
e. Select Apply Changes from the File menu, and close the Control
Editor. Do not save the custom control.
3. Right-click an open area and select Square LED from the
Controls»Classic Controls»Boolean shortcut menu. Label the LED
Flame.
4. Using the previous steps, make the LED look like a Bunsen burner. The
TRUE state should show the burner on; the FALSE state should show
the burner off.
5. Hide the labels of both Boolean indicators by right-clicking them and
selecting Visible Items»Label. Select both Boolean indicators and
align them on horizontal centers using the Align Objects tool.
Block Diagram
6. Complete the following block diagram.
To configure the Web Server, select Tools»Options and select Web Server:
Configuration from the top pull-down menu.
The Web Server: Configuration window is where you enable the Web
Server. The default Web Server configuration is suitable for most
applications. If you need to change this default configuration, refer to the
LabVIEW help.
The Web Server: Browser Access window allows you to configure which
browser addresses can view your VI front panels. When a Web browser
attempts to obtain a VI front panel image, the Web Server compares the
browser address to the entries in the Browser Access List to determine
whether it should grant access. If an entry in the Browser Access List
matches the browser address, the Web Server permits or denies access based
on how you set up the entry. By default all browsers have access to the
LabVIEW Web Server. Refer to the Context Help window for more
information about the syntax used to specify browser access.
The WebServer: Visible VIs window lets you specify which VIs are
accessible to a Web browser. When a Web browser attempts to obtain a VI
front panel image, the Web Server compares the VI name to the entries in
the Visible VIs list to determine whether it should grant access. If an entry
in the Visible VIs list matches the VI name, the Web Server permits or
denies access to that VI image based on how you set up the entry. By default,
the front panel images of all VIs are visible. Refer to the Context Help
window for more information about the syntax used to specify visible VIs.
Note Use the LabVIEW Enterprise Connectivity Toolset to control VIs on the Web and
to add more security features to VIs you publish on the Web. Refer to the National
Instruments Web site for more information about this toolset.
Click the Instructions button to display information about how to add a title
to your HTML file and how to add text before and after your VI front panel.
Enter a VI name in the VI Name field or select Browse from the VI Name
pull-down menu and navigate to a VI.
Note To display VI front panels on the Web, the VIs must be in memory on your
computer.
You can preview the document in your default browser by clicking the
Start Web Server button and then clicking the Preview in Browser button.
If the Start Web Server button is dimmed, the Web Server is already
running. When you click the Save to Disk button, the title, text, and VI front
panel image are saved in an HTML document. If you want to view the
document from a remote computer, save the HTML document in the Web
Server root directory, usually labview\www. The Document URL dialog
box appears with the URL for your HTML document.
Open the VI you built in Exercise 1-1, the Generate & Analyze Data VI,
and save its front panel into an HTML document.
Front Panel
8. Click the Preview in Browser button to open and display the front panel
in a web browser. A window similar to the one shown in the next figure
appears.
Note The Animated option only works with Netscape Navigator. You can only view
static images using Internet Explorer.
9. Return to the Web Publishing Tool window and click the Save to Disk
button to save the title, text, and VI front panel image in an HTML
document. Save the document as Generate & Analyze Data.htm
in the LV Basics 2 directory. A warning message appears, telling you
where to install the file if you want other machines to view it.
10. Click the Done button to exit the Web Publishing Tool.
11. Go back to the Browser application and type the following URL into the
address: http://127.0.0.1. This specifies the local machine. The
following window appears.
12. Read the information and close the browser when you are finished.
13. Turn off the Web Server by selecting Tools»Options to display the
Options dialog box.
14. Select Web Server: Configuration from the top pull-down menu of the
Options dialog box and remove the checkmark from the Enable Web
Server checkbox.
15. Click the OK button to close the Options dialog box.
16. Close the Generate & Analyze Data VI.
D. Additional Information
This section describes how you can receive more information regarding
LabVIEW, instrument drivers, and other topics related to this course.
The support page for the National Instruments Web site contains links to
application notes, the support knowledgebase, hundreds of examples, and
troubleshooting wizards for all topics discussed in this course and more.
The NI Developer Zone also includes direct links to the instrument driver
network and to Alliance Program member Web pages.
LabVIEW Publications
LabVIEW Technical Resource (LTR) Newsletter
Subscribe to LabVIEW Technical Resource to discover power tips and
techniques for developing LabVIEW applications. This quarterly
publication offers detailed technical information for novice users as well
as advanced users. In addition, every issue contains a disk of LabVIEW
VIs and utilities that implement methods covered in that issue. To order
LabVIEW Technical Resource, call LTR publishing at (214) 706-0587
or visit ltrpub.com
LabVIEW Books
Many books have been written about LabVIEW programming and
applications. The National Instruments Web site contains a list of all the
LabVIEW books and links to places to purchase these books. Publisher
information is also included so you can directly contact the publisher for
more information on the contents and ordering information for LabVIEW
and related computer-based measurement and automation books.
The archives contain a large set of donated VIs for doing a wide variety of
tasks.
If you find errors in the manual, please record the page numbers and describe the errors.
____________________________________________________________________________________________
____________________________________________________________________________________________
____________________________________________________________________________________________
____________________________________________________________________________________________
____________________________________________________________________________________________
____________________________________________________________________________________________
____________________________________________________________________________________________
Instructor
Please evaluate the instructor by checking the appropriate circle. Unsatisfactory Poor Satisfactory Good Excellent
Course
Training facility quality ❍ ❍ ❍ ❍ ❍
Training equipment quality ❍ ❍ ❍ ❍ ❍
Was the hardware set up correctly? ❍ Yes ❍ No
The course length was ❍ Too long ❍ Just right ❍ Too short
The detail of topics covered in the course was ❍ Too much ❍ Just right ❍ Not enough
The course material was clear and easy to follow. ❍ Yes ❍ No ❍ Sometimes
Did the course cover material as advertised? ❍ Yes ❍ No
I had the skills or knowledge I needed to attend this course. ❍ Yes ❍ No If no, how could you have been better
prepared for the course? _________________________________________________________________________
_____________________________________________________________________________________________
What were the strong points of the course? __________________________________________________________
_____________________________________________________________________________________________
What topics would you add to the course? ___________________________________________________________
_____________________________________________________________________________________________
What part(s) of the course need to be condensed or removed? ____________________________________________
_____________________________________________________________________________________________
What needs to be added to the course to make it better? ________________________________________________
_____________________________________________________________________________________________
Are there others at your company who have training needs? Please list. ____________________________________
_____________________________________________________________________________________________
_____________________________________________________________________________________________
Do you have other training needs that we could assist you with? _________________________________________
_____________________________________________________________________________________________
How did you hear about this course? ❍ National Instruments web site ❍ National Instruments Sales Representative
❍ Mailing ❍ Co-worker ❍ Other _____________________________________________________________
Customer Education Student Profile
Name ____________________________________________ Title _____________________________________
Company _________________________________________ Mail Stop _________________________________
Mailing Address _______________________________________________________________________________
City __________________ State/Province ____________ Country ______________ Zip ______________
Telephone ________________________________________ Fax ______________________________________
E-Mail _______________________________________________________________________________________
Date _____________________________________________ Event Location _____________________________
If you are currently a customer of National Instruments, please check the products you use:
❏ LabVIEW™ ❏ HiQ™ ❏ DAQ ❏ Fieldbus™
❏ LabWindows/CVI™ ❏ ComponentWorks™ ❏ SCXI™ ❏ IMAQ™ Vision
❏ BridgeVIEW™ ❏ VirtualBench™ ❏ GPIB ❏ Serial
❏ Lookout™ ❏ Measure™ ❏ VXI ❏ Motion control
Which statement best describes your function in the company? (check only one)
❏ Education ❏ Calibration ❏ Government/legal ❏ Production test
❏ Manufacturing/ ❏ Engineering ❏ Research/R&D/grad ❏ Systems integrator/
automation management student hardware
❏ Reseller/sales ❏ Purchasing/contracts ❏ Software developer ❏ Software consultant
❏ Service/repair ❏ Student/co-op ❏ Design ❏ Compliance testing
Industry-specific Literature
❏ Aerospace ❏ Semiconductor ❏ Analytical chemistry ❏ Industrial automation
❏ Telecommunications ❏ Vibration/acoustics ❏ Education ❏ Laboratory automation
❏ Automotive ❏ Physiology ❏ Test and measurement
Additional Literature
❏ NI Global Services ❏ LabVIEW Technical Resource Subscription Card
❏ Customer Education Course Schedule
Product and company names mentioned herein are trademarks or trade names of their respective companies.
© Copyright 1997, 1999 National Instruments Corporation. All rights reserved. 340812C-01