LabVIEW

introduction
• Dataflow and Event-Driven Programming
• LabVIEW programs execute according to dataflowprogramming rules instead
of the procedural
• approach found in most text-based programming languages such as C and C+
+. Dataflow
• execution is data-driven, or data-dependent. The flow of data between nodes
in the G code
• determines the execution order.
• Event-driven programming features extend the LabVIEW
dataflowenvironment to allow the user's
• direct interaction with the program without the need for polling. Event-based
programming also
• allows other asynchronous activity to influence the execution of G code on
the block diagram.
• Multi-Target and Multi-Platform
• With LabVIEW applications, you can target multicore processors and
other parallel hardware such
• as field-programmable gate arrays (FPGAs). You can automatically
scale LabVIEW applications
• to CPUs with two, four, or more cores, often with no additional
programming effort.
• G code, with the exception of a few platform-specific functions,
isportable between the different
• LabVIEW systems for different operating systems.Therefore, you can
often use the same code
• whether running LabVIEW on Windows, Mac OS X or Linux systems.
• Project Explorer Window
• Projects in LabVIEW consist of VIs, files necessary for those VIs to run properly, and
• supplemental files such as documentation or related links. Use the Project Explorerwindow
to
• manage projects in LabVIEW.
• The Project Explorerwindow includes the following items by default:
• • Project root—Contains all other items in the Project Explorerwindow. The label on the
• project root includes the filename for the project.
• • My Computer—Represents the local computer as a target in the project.
• • Dependencies—Includes VIs and items that VIs under a target require.
• • Build Specifications—Includes build configurations for source distributions and other
types
• of builds available in LabVIEW toolkits and modules. If you have the LabVIEW Professional
• Development System or Application Builder installed, you can use Build Specificationsto
• configure stand-alone applications, shared libraries, installers, and zip files.
Parts of a VI
 Controls and Indicators
• You create the front panel with controls and indicators, which are the interactive input and
output terminals of the VI, respectively.
• Controls are knobs, push buttons, dials, and other input devices.
• Indicators are graphs, LEDs and other displays. Controls simulate instrument input devices
and supply data to the block diagram of the VI. Indicators simulate instrument output
devices and display data the block diagram acquires or generates
• The numeric data type can represent numbers of various types, such as integer or real.
The two common numeric objects are the numeric control and the numeric indicator, as
shown in Figure 1-8. Objects such as meters and dials also represent numeric data.
 Boolean Controls and Indicators
• The Boolean data type represents data that only has two possible states, such as TRUE and FALSE or ON
and OFF. Use Boolean controls and indicators to enter and display Boolean values. Boolean objects
simulate switches, push buttons, and LEDs.

• The string data type is a sequence of ASCII characters. Use string controls to receive text from the user
such as a password or user name. Use string indicators to display text to the user. The most common string
objects are tables and text entry boxes as shown in Figure 1-10.
 Block Diagram
• Block diagram objects include terminals, subVIs, functions, constants,
structures, and wires, which transfer data among other block diagram
objects. Take note that the mathematical nodes don’t show in the front
panel
 Block Diagram Nodes

• Nodes are objects on the block diagram that have inputs and/or outputs
and perform operations when a VI runs. They are analogous to statements,
operators, functions, and subroutines in text-based programming
languages. Nodes can be functions, subVIs, or structures. Structures are
process control elements, such as Case structures, For Loops, or While
Loops. The Add and Subtract functions in the Figure 1-12 are function
nodes
• Functions are the fundamental operating elements of LabVIEW. Functions
do not have front panel windows or block diagram windows but do have
connector panes. Double-clicking a function only selects the function. A
function has a pale yellow background on its icon
 Expandable Nodes versus Icons

• You can display VIs and Express VIs as icons or as expandable nodes. Expandable nodes
appear as icons surrounded by a colored field. SubVIs appear with a yellow field, and
Express VIs appear with a blue field. Use icons if you want to conserve space on the
block diagram. Use expandable nodes to make wiring easier and to aid in documenting
block diagrams
• You can resize the expandable node to make wiring even easier, but it also takes a large
amount of space on the block diagram. Complete the following steps to resize a node on
the block diagram:
• 1. Move the Positioning tool over the node. Resizing handles appear at the top and
bottom of the node.
• 2. Move the cursor over a resizing handle to change the cursor to the resizing cursor.
• 3. Use the resizing cursor to drag the border ofthe node down to display additional
terminals.
• 4. Release the mouse button.
 Wires
• You transfer data among block diagram objects through wires. InFigure 1-12, wires
connect the control and indicator terminals to the Add and Subtract function. Each
wire has a single data source, but you can wire it to many VIs and functions that
read the data. Wires are different colors, styles, and thicknesses, depending on
their data types. A broken wire appears as a dashed black line with a red X in the
middle, as shown below. Broken wires occur for a variety of reasons, such as when
you try to wire two objects with incompatible data types.
Show example
 Functions Palette
• The Functions palette contains the VIs,
functions and constants you use to create the
block diagram. You access the Functions
palette from the block diagram by selecting
View» Functions Palette. The Functions palette
is broken into various categories; you can show
and hide categories
• to suit your needs. Figure 1-17 shows a
Functions palette with all of the categories
exposed and the Programming category
expanded. During this course, you work mostly
in the Programming category, but you also use
other categories, or subpalettes.
Context help
The Context Helpwindow displays basic information about LabVIEW objects when you move
the cursor over each object. To toggle display of the Context Helpwindow select Help»Show
Context Help, press the <Ctrl-H> keys, or click the Show Context Help Windowbutton on the
toolbar.
 Dataflow
• LabVIEW follows a dataflow model for running VIs. A block diagram node executes
when it receives all required inputs. When a node executes, it produces output data
and passes the data to the next node in the dataflow path. The movement of data
through the nodes determines the execution order of the VIs and functions on the
block diagram.Visual Basic, C++, JAVA, and most other text-based programming
languages follow a control flow model of program execution. In control flow, the
sequential order of program elements determines the execution order of a program.
For example
Do quiz on page 55
BUILDING A SIMPLE VI
• Most LabVIEW VIs have three main tasks—acquiring some sort of data, analyzing
the acquired data, and presenting the result. When each of these parts are
simple, you can complete the entire VI using very few objects on the block
diagram. Express VIs are designed specifically for completing common, frequently
used operations. In this section, you learn about some Express VIs that acquire,
analyze, and present data.
Troubleshooting and Debugging
VIs
• To run a VI, you must wire all the subVIs, functions, and structures with the correct data
types for
• the terminals. Sometimes a VI produces data or runs in a way you do not expect. You can
use
• LabVIEW to configure how a VI runs and to identify problems with block diagram
organization
• or with the data passing through the block diagram.
• To p i c s
• A. Correcting Broken VIs
• B. Debugging Techniques
• C. Undefined or Unexpected Data
• D. Error Handling
Finding Causes for Broken VIs
Click the broken Runbutton or select View»Error Listto find out why a VI is broken. The Error
listwindow lists all the errors. The Items with errorssection lists the names of all items in
memory, such as VIs and project libraries that have errors. If two or more items have the
same name, this section shows the specific application instance for each item. The errors
and warnings section lists the errors and warnings for the VI you select in the Items with
errors section
Check pages 61 and 62 for others
Breakpoints
 Error Handling
Error handling is the mechanism for anticipation, detection, and
resolution ofwarnings and errors.
Error handling is an essential component in your LabVIEW application
development. With error handling you quickly pinpoint the source of
programming errors. Withoutit, you might observe unexpected behavior
but struggle tofind the source of the problem.
Error handling is also extremely valuable when you test your application
to ensure that your error reporting is meaningful and that the error
handling code safely stops your application when an error occurs. For
example, during stress testing you are setting values or conditions that
are beyond the normal operational capacity of your application which
often result in errors
 Automatic Error Handling

• By default, LabVIEW automatically handles any error when a VI runs by

suspending execution, highlighting the subVI or function where the error
occurred, and displaying an error dialog box. In the error dialog box, each
error has a numeric code to identify it and a corresponding error message to
display to the user.
• To disable automatic error handling for the current VI, select File»VI
Propertiesand select Executionfrom the Categorypull-down menu. To disable
automatic error handling for any new, blank VIs you create, select
Tools»Optionsand select Block Diagramfrom the Categorylist. To
• disable automatic error handling for a subVI or function within a VI, wire its
error outparameter to the error inparameter of another subVI or function or
to an error outindicator.
 Manual Error Handling
• In LabVIEW, you can make these manual error handling decisions on the block
diagram of the VI
• using the following methods:
• • Use the LabVIEW error handling VIs and functions on the Dialog & User
Interfacepalette to
• notify and prompt users. For example, if LabVIEW encounters an error, you can
display the
• error message in different kinds of dialog boxes.
• • Use error clusters and the error inand error outparameters of most VIs and
functions to
• manage errors. For example, when an error is detected you can fix the error
programmatically and
• then wire the error out output of the VI or function to the error ininput of the Clear
Errors VI.
IMPLEMENTING A VI
• We’ll learn to use all of this in implemebting a VI
• A. Front Panel Basics
• B. LabVIEW Data Types
• C. Documenting Code
• D. While Loops
• E. For Loops
• F. Timing a VI
• G. Data Feedback in Loops
• H. Plotting Data – Waveform Chart
• I. Case Structures
Numeric data types
While Loops
Causes of infinite loop

Check example on
page 93
Wiring and multiple wiring
Developing Modular
Applications
Acquiring Measurements with a
DAQ System
Labview contd
 Using Sequential and State Machine Algorithms

• The first step in developing a LabVIEW application is to explore the architectures that exist
within
• LabVIEW. Architectures are essential for creating a successful software design. The most
common
• architectures are usually grouped into design patterns.
• As a design pattern gains acceptance, it becomes easier to recognize when a design pattern
has
• been used. This recognition helps you and other developers read and modify VIs that are
based on
• design patterns.
• There are many design patterns for LabVIEW VIs. Most applications use at least one design
• pattern. In this course, you explore the State Machine design pattern. Learn more about
design
• patterns in the LabVIEW Core 2course
 Case Study: Course Project
• The course project acquires
a temperature every half
second, analyzes each
temperature to determine
if the temperature is too
high or too low, and alerts
the user if there is a danger
of heatstroke or freeze. The
program logs the data if a
warning occurs. If the user
has not clicked the stop
button, the entire process
repeats. Figure 7-11 shows
the state transition diagram
for the course project.
 Solving Dataflow Challenges
with Variables
• LabVIEW is a dataflow language. As such, you generally use dataflow design principles in
• developing your code. However, in a few situations, such as communicating between two
parallel
• loops, you must “break” the dataflow execution model by passing information between
locations
• in the code that you cannot connect with a wire.
• In this lesson you learn about variables, in general, and local variables,specifically, to
handle
• special use cases where the dataflow execution model does not work. You also learn about
the
• programming issues involved when using variables and how to overcome these challenges.
• Because variables are not inherently part of the LabVIEW dataflowexecution model, use
variables carefully. Misusing variables can make the code hard to read, lead to unexpected
behavior in VIs, and slow performance.