1.
4 DATA FLOW PROGRAMMING
LabVIEW applications execute based on data flow. LabVIEW applications are broken up into nodes
and wires; each element in a diagram that has input or outputs considered a node. The connection
points between nodes are wires. A node can be a simple operation such as addition, or it can be a very
complicated operation like a subVI that contains internal nodes and wires. The collection of nodes and
wires comprise the wire diagram. Wire diagrams are derived from the block diagrams and are used by
LabVIEW’s compiler to execute the diagrams. The wire diagrams are hidden from the programmer;
they are an intermediate form used by the compiler to execute code. While you program, the compiler
is behind the scenes verifying that diagrams are available to execute. LabVIEW applications that are
built using the Application Builder use the execution engine as if LabVIEW were still being used to
run the VIs. A node can be executed when all inputs that are necessary have been applied.
For example, it is impossible for an addition operation to happen unless both numbers to be added are
available. One of these numbers may be an input from a control and would be available immediately,
where the second number is the output of a VI. When this is the case, the addition operation is
suspended until the second number becomes available. It is entirely possible to have multiple nodes
receive all inputs at approximately the same time. Data flow programming allows for the tasks to be
processed more or less concurrently. This makes multitasking code diagrams extremely easy to design.
Parallel loops that do not require inputs will be executed in parallel as each node becomes available to
execute. Multitasking has been an ability of LabVIEW since Version 1.0. Multitasking is a
fundamental ability to LabVIEW that is not directly available in languages like C, Visual Basic, and
C++.
When multiple nodes are available to execute, LabVIEW uses a process called arbitrary interleaving to
determine which node should be executed first. If you watch a VI in execution highlighting mode and
see that nodes execute in the desired order, you may be in for a rude shock if the order of execution is
not always the same. For example, if three addition operations were set up in parallel using inputs
from user controls, it is possible for eight different orders of execution. Similar to many operating
systems’ multithreading models, LabVIEW does not make any guarantees about which order parallel
operations can occur. Often it is undesirable for operations to occur in parallel. The technique used to
ensure that nodes execute in a programmer-defined order is forcing the order of execution. There are a
number of mechanisms available to a LabVIEW programmer to force the order of execution. Using
error clusters is the easiest and recommended method to guarantee that nodes operate in a desired
order. Error Out from one subVI will be chained to the Error In of the next VI. This is a very sensible
way of controlling the order of execution, and it is essentially a given considering that most
programmers should be using error clusters to track the status of executing [Link] method of
forcing the order of execution is to use sequence diagrams; however, this method is not recommended.
Sequence diagrams are basically Lab-VIEW’s equivalent of the GOTO statement. Use sequences only
when absolutely necessary, and document what each of the frames is intended to do.
Most VIs have a wire diagram; the exceptions are global variables and VIs with subroutine priority.
Global variables are memory storage VIs only and do not execute. Subroutine VIs are special cases of
a VI that does not support dataflow. We will discuss both of these types of VIs later. LabVIEW is
responsible for tracking wire diagrams for every VI loaded into memory. Unless options are set, there
will be exactly one copy of the wire diagram in memory, regardless of the number of instances you
have placed in code diagrams. When two VIs need to use a common subVI, the VIs cannot execute
concurrently. The data and wire diagram of a VI can only be used in a serial fashion unless the VI is
made reentrant. Reentrant VIs will duplicate their wire diagrams and internal data every time they are
called.
Ref: Rick Bitter, Taqi, Mohiuddin, Matthew R & Nawrocki, “LabVIEW Advanced Programming Techniques ”
2nd Ed., CRC press
Note: Explain data flow programming with an example
[Link] Traditional instrument Virtual Instrument
1 Collect data from an environment or from a unit under test, Defn: industry standard computer equipped with user friendly
and to display information to a user based on the collected application s/w, cost effective h/w and driver s/w that together
data perform the functions of traditional instruments.
(Simulated physical instrument: s/w based on user
requirements defines general purpose measurement and control
h/w functionality)
2 Not flexible for the users Flexible. Engineers and scientists can create the user defined
instruments required to keep up with the world’s demands
3 Have fixed vendor-defined functionality. Defined by the user
4 Parts: h/w or s/w&h/w Parts: s/w & h/w
5 Costly compared to VI Low cost . Cost to configure a VI based system using a data
acquisition board or cards can be as little as 25% of the cost of
a conventional
We can lower capital cost, system development cost and
system maintenance cost while improving time to market and
the quality of our own products
[Link] Traditional instrument Virtual Instrument
6 External box based instrumentation product Uses PC for all user interaction and control
(DAQ with PC)
7 Vendor defined, prepackaged s/w & h/w with a finite list Flexible when changing measurement tasks. User can
of fixed-functionality customize the acquisition, analysis, storage and presentation
functionality using productive, powerful s/w
8 Very large and cumbersome. Require lot of power and
excessive amounts of features that are rarely used
9 Don’t have any computational power as compared to VI Since it is a part of PC computational as well as controlling
capability of PC can be applied to test configuration
10 VI s/w provides libraries for interfacing with common ordinary
instrument buses such as GPIB, serial or Ethernet
11 May have IC to perform a particular set of data processing Theses functions would be performed by s/w running on
functions processor in PC
Can extend set of functions PC (limited only by power of s/w)
12 Wide variety of h/w devices we can easily plug into PC.
With the advances in technology comes an increase in data
acquisition rates, measurement accuracy, precision and better
signal isolation