LabVIEW Core 2

Instructor Guide

November 2014
Table of Contents
LabVIEW Core 2 Course Overview ............................................................... 1
COURSE OBJECTIVES ........................................................................................................ 1
TARGET AUDIENCE ............................................................................................................ 1
ABOUT THIS GUIDE............................................................................................................ 1
Instructor Notes ............................................................................................. 2
LESSON OVERVIEW ........................................................................................................... 2
COURSE TIMING ................................................................................................................ 3
Welcome and Housekeeping ......................................................................... 5
Lesson 1. Using Variables ........................................................................... 6
A. VARIABLES ................................................................................................................... 6
B. USING VARIABLES APPROPRIATELY ................................................................................ 7
C. RACE CONDITIONS ........................................................................................................ 8
Lesson 2. Communicating Data Between Parallel Loops........................... 10
A. INTRODUCTION ............................................................................................................ 10
B. QUEUES ..................................................................................................................... 11
C. NOTIFIERS .................................................................................................................. 12
D. SUMMARY .................................................................................................................. 13
Lesson 3. Implementing Design Patterns .................................................. 14
A. W HY USE DESIGN PATTERNS? ..................................................................................... 14
B. SIMPLE DESIGN PATTERNS ......................................................................................... 14
C. MULTIPLE LOOP DESIGN PATTERN ............................................................................... 15
D. FUNCTIONAL GLOBAL VARIABLE DESIGN PATTERN ........................................................ 17
E. ERROR HANDLERS ...................................................................................................... 19
F. GENERATING ERROR CODES AND MESSAGES ................................................................ 20
G. TIMING A DESIGN PATTERN.......................................................................................... 21
Lesson 4. Controlling the User Interface .................................................... 25
A. VI SERVER ARCHITECTURE .......................................................................................... 25
B. PROPERTY NODES ...................................................................................................... 27
C. INVOKE NODES ........................................................................................................ 28
D. CONTROL REFERENCES .............................................................................................. 29
Lesson 5. File I/O Techniques ................................................................... 32
A. FILE FORMATS ............................................................................................................ 32
B. CREATING FILE AND FOLDER PATHS ............................................................................. 33
C. W RITE AND READ BINARY FILES ................................................................................... 34
D. W ORK WITH MULTICHANNEL TEXT FILES WITH HEADERS ................................................ 35
E. ACCESS TDMS FILES IN LABVIEW AND EXCEL ............................................................. 37
Lesson 6. Refactoring Code ...................................................................... 39
A. REFACTORING INHERITED CODE ................................................................................... 39
B. TYPICAL REFACTORING ISSUES .................................................................................... 40
Lesson 7. Creating and Distributing Applications ....................................... 42
A. PREPARING THE FILES ................................................................................................. 42
B. BUILD SPECIFICATIONS ................................................................................................ 43
C. CREATE AND DEBUG AN APPLICATION ........................................................................... 44
D. CREATE AN INSTALLER ................................................................................................ 47
Next Steps… ............................................................................................... 50
LabVIEW Core 2 Course Overview
Course Objectives
The LabVIEW Core 2 course is an extension of the LabVIEW Core 1 course and teaches common
design patterns to successfully implement and distribute LabVIEW applications.
Target Audience
• New LabVIEW users • Might be interested in certification
• Engineers and scientists • Interested more in practice than
• Widely varied disciplines and applications assessment
• Computer literate • Both US and International
• Very little past experience with LabVIEW
About This Guide
This Instructor Guide is your primary tool to plan, prepare for, and conduct the course. It is
important for you to review this guide thoroughly, well in advance of the course. The following
icons are included in this guide.

Icon Definition and Use

Section – Section header.

Demo– Demo this concept in the software.

Guide – Refer participants to their participant materials.

Key Point – Be certain to mention the key points listed.

LabVIEW Exercise – Students working in the software.

Multimedia – Direct students to the multimedia file location:

<Exercises>\LabVIEW Core 2\Multimedia\

Question – Questions to ask participants.

Group exercise – Usually a discussion or activity for the whole class.

Activity – Knowledge checks and short exercises to help reinforce

concepts.

LabVIEW Core 2 Course Overview 1 Course Objectives

Instructor Notes
You can find the most comprehensive and up-to-date information you need for this course on the NI
Instructors community page: https://decibel.ni.com/content/groups/ni-instructors

Lesson Overview
The following table contains a breakdown of the overall lesson and non-lecture activity duration.

Lesson Objective Topics Time

(h:min)

Welcome and
housekeeping

1 Recognize when to use local and global A. Variables 1:05

Using Variables variables and be able to determine the B. Using Variables Appropriately
result of block diagrams that use C. Race Conditions
variables.
Develop code that synchronizes data A. Introduction 1:05
2 B. Queues
Communicating between parallel loops.
C. Notifiers
Data Between D. Summary
Parallel Loops
Implement common design patterns A. Why Use Design Patterns? 4:30
3 B. Simple Design Patterns
Implementing for single and parallel loop applications.
C. Multiple Loop Design Patterns
Design Patterns D. Functional Global Variable Design
Pattern
E. Error Handlers
F. Generating Error Codes and
Messages
G. Timing a Design Pattern
Use property nodes, invoke nodes, and A. VI Server Architecture 2:10
4 B. Property Nodes
Controlling the control references to programmatically
control front panel objects. C. Invoke Nodes
User Interface D. Control References
Create modular LabVIEW code that A. File Formats 2:05
5 B. Create File and Folder Paths
File I/O reads or writes measurement data
stored in a file. C. Write and Read Binary Files
Techniques D. Work with Multichannel Text Files
with Headers
E. Access TDMS Files in LabVIEW and
Excel
Recognize a VI that can be improved A. Refactoring Inherited Code 1:00
6 B. Typical Refactoring Issues
Improving an and practice techniques to improve
Existing VI existing VIs.

Make necessary code modifications, A. Preparing the Files 1:40

7 B. Build Specifications
Creating and then select and build the appropriate
deployment option for a LabVIEW C. Create and Debug an Application
Distributing D. Create an Installer
Applications application.

Next Steps :05

Instructor Notes 2 Lesson Overview

Course Timing
Target is about 7 hours/day active class time.
The following table contains a breakdown of the overall lesson and non-lecture activity duration.

Timing
Day Activity Name Estimates
(h:m)

Welcome slides 0:15

Lesson 1 Using Variables 1:05
Multimedia Using Variables 0:10
Exercise 1-1 Weather Station UI VI with Local Variables 0:25
Demo Race Conditions – Bank VI 0:10
Activity 1-1 Lesson Review 0:05

Lesson 2 Communicating Data Between Parallel Loops 1:05

Multimedia Queues 0:15
Exercise 2-1 Comparing Queues with Local Variables 0:20
Demo Notifiers 0:05
Activity 2-1 Lesson Review 0:05

Lesson 3 Implementing Design Patterns 4:30

Demo Producer/Consumer (Data) Design Pattern 0:05
Exercise 3-1 Producer/Consumer Design Pattern 0:15
Day 1
Multimedia Functional Global Variables 0:20
Exercise 3-2 Create a User Access Level FGV 1:10
Activity 3-1 Identifying Design Patterns 0:15
Activity 3-2 Design Patterns Job Aid 0:01
Demo Producer Consumer Error Handler VI 0:10
Demo Use the Error Ring to Generate Errors 0:10
Exercise 3-3 Producer/Consumer with Error Handling 0:30
Activity 3-3 Identifying Timing Options 0:10
Exercise 3-4 Create a Histogram Application 0:50
Activity 3-4 Lesson Review 0:05

Lesson 4 Controlling the User Interface 2:10

Day 2 Multimedia Using Property Nodes to Programmatically 0:10
Control the User Interface

Instructor Notes 3 Course Timing

 Timing
Day Activity Name Estimates
(h:m)
Exercise 4-1 Display Temperature and Limits 0:25
Demo Create an Invoke Node 0:05
Exercise 4-2 Customize the VI Window 0:25
Multimedia Creating Control References 0:15
Exercise 4-3 Create SubVIs for Common Operations 0:40
Activity 4-1 Lesson Review 0:05

Lesson 5 File I/O Techniques 2:05

Multimedia Creating File and Folder Paths 0:15
Exercise 5-1 Create File and Folder Paths 0:15
Demo Writing a Bitmap File 0:05
Exercise 5-2 Write Multiple Channels with Simple Header 0:25
Activity 5-1 Read Data and Extract Information 0:10
Exercise 5-3 Write and Read TDMS Files 0:25
Activity 5-2 Lesson Review 0:05

Lesson 6 Improving an Existing VI 1:00

Exercise 6-1 Refactoring a VI 0:30

Lesson 7 Creating and Distributing Applications 1:40

Exercise 7-1 0:25
Exercise 7-2 0:15
Exercise 7-3 0:15
Activity 7-1 Lesson Review 0:05

Next Steps 0:05

Instructor Notes 4 Course Timing

Welcome and Housekeeping
Objective: Acclimate participants to the facility and set expectations for the course.
Duration: 15 minutes

Content/Narrative Materials/
Duration
Slide 1 National Instruments
Title slide
Slide 2 LabVIEW Core 2
Title slide
Slide 3 What You Need to Get Started
Review the hardware and software requirements to get the most out of
the course.
Slide 4 File Locations
Tell the students where to find the exercise and multimedia files on disk.
Slide 5 Instructional Methods
Go over the instruction methods for the course.
Slide 6 Getting the Most out of this Course
Reassure everyone that mistakes are okay and that they will not break
anything. When a student makes a mistake, use it as a learning
opportunity.
Our goal is to teach a student to be self-sufficient when the instructor is
no longer available.
Slide 7 LabVIEW Certification
Slide 8 Course Learning Map
Slide 9 This course prepares you to:
Go over some of the objectives of the course.

Welcome and Housekeeping 5

Lesson 1. Using Variables
Objective: Recognize when to use local and global variables and be able to determine the result of
block diagrams that use variables.
This lesson contains the following topics:
A. Variables
B. Using Variables Appropriately
C. Race Conditions
Duration: 1 hour, 5 minutes

Content/Narrative Duration
Slide 1 State the lesson objective.
Briefly outline the topics covered in this lesson.
Slide 2 15 min
A. Variables
Objective: Identify the differences between local and global variables.

Slide 3 Definition: Variables—Block diagram elements that access or store data from
another location.
Point out that variables can be written to or read from multiple places.
Slide 4 Local versus Global Variables
Briefly highlight the differences. Students will learn more in the multimedia
module coming up.
Point out difference in icons.
Local Global
Stores data in front panel controls Stores data in special repositories in the
and indicators. project.
Accessible only within a VI. Can be accessed from multiple VIs.

Lesson 1 Using Variables 6 A. Variables

Slide 5 Multimedia: Using Variables 10 min
Location: <Exercises>\LabVIEW Core 2\Multimedia\Module 1 – Using Variables
Students learn how to recognize issues that variables can solve and how to
create local and global variables. Students also practice determining the value
of controls, indicators, or variables after code executes.
Transition: Ask students if they have any questions on the multimedia
module. Add plenty of time for discussion afterward, especially race
conditions may require additional explanation and when to use global
variables.
“Because variables do not conform to LabVIEW’s data flow wires paradigm,
you should use them carefully to avoid unintended issues.”
Slide 6 35 min
B. Using Variables Appropriately
Objective: Recognize issues that variables can solve and drawbacks to using
them.
Slide 7 When to Use Local Variables
Summarize the top reasons to use local variables:
• Writing to controls – for example, to clear a log in screen.
• Initializing front panel controls or indicators.
• Need to pass values between parallel loops but don’t want to accidentally
make them sequential. The current value of the variable is all you need –
for example, the value of a Stop button.
Slide 8 Drawbacks of Variables
Summarize the top caveats of using variables:
• Potential data loss – variables only contain the latest data.
• Limited mechanical action of Booleans – switch only.
• Variables make copies of the data buffers and could slow execution speed.
• Variables can cause possible race conditions, which we’ll talk about later.
Slide 9 Exercise 1-1: Weather Station UI VI with Local Variables 25 min
Goal: Students modify a VI to use local variables to write to and read from a
control.
Open the Participant Guide to the exercise and go over the scenario.
Slide 10 Discussion: Exercise 1-1: Weather Station UI VI with Local Variables
Question: What functionality does the local variable provide for this
application?
Answer: If Upper Limit is less than Lower Limit, this VI uses a local variable
to change the value of Lower Limit to match the value of Upper Limit.

Lesson 1 Using Variables 7 B. Using Variables Appropriately

Slide 11 15 min
C. Race Conditions
Objective: Be able to identify race conditions and avoid them.

Slide 12 What is a Race Condition?

Definition: Race Conditions— A situation where the timing of events or the
scheduling of tasks may unintentionally affect outputs or values.
Race conditions commonly occur in programs that:
• Execute multiple tasks in parallel
• Share data between parallel tasks using variables
Slide 13 Demo: Race Conditions – Bank VI 10 min
Location: <Exercises>\Demonstrations\Bank VI Race Conditions\Bank.vi
Run the Bank.vi with and without Execution Highlighting to illustrate how
elusive race conditions can be.
1. Show the block diagram of Bank.vi.
2. Run Bank.vi.
3. Enter a deposit amount of 20 and withdrawal amount of 10.
4. Click the Simultaneous Transaction button several times and note the
balance.
5. Turn on Execution Highlighting.
6. Click the Simultaneous Transaction button several times.
• Note that either the withdrawal or deposit is lost and that the account
balance is not what is expected.
Key Points:
• Race conditions are very difficult to identify and debug.
• Code with a race condition can return the same result thousands of times in
testing, but still be capable of returning a different result.
Slide 14 Avoiding Race Conditions
• Reduce variable use.
• Properly sequence code.
• Control shared resources-Use one writer, multiple readers.
• WORM – Write Once, Read Many: If you only EVER write one time, then
you eliminate the possibility of race conditions.

Lesson 1 Using Variables 8 C. Race Conditions

Slide 15- Activity 1-1: Lesson Review 5 min
19 Have students complete the review at the end of the lesson in their Participant
Guides. Then come together as a class to review and discuss.
1. False – when possible, you should find a solution that uses dataflow to
avoid the risk of race conditions.
2. Limiting the number of writers to one will greatly reduce the risk of a race
condition occurring.

Lesson 1 Using Variables 9 C. Race Conditions

Lesson 2. Communicating Data Between Parallel
Loops
Objective: Develop code that synchronizes data between parallel loops.
This lesson contains the following topics:
A. Introduction
B. Queues
C. Notifiers
D. Summary
Duration: 1 hour, 5 minutes

Content/Narrative Duration
Slide 1 State the lesson objective.
Briefly outline the topics covered in this lesson.
Slide 2 5 min
A. Introduction
Objective: Review using local variables to communicate between parallel
loops.
Slide 3 Communicating Data Between Parallel Loops – Local Variables
Review potential reasons to use parallel loops
• Execute tasks simultaneously
• Execute tasks at different rates
Common use case of local variables and parallel loops is the Stop button
(shown on slide). The bottom loop only needs to know the latest value of the
stop button.
The key point is “latest data”.
o The reading loop only needs the latest value of the stop button.
o The reading loop only needs to act on the current setpoint and doesn’t
care about previous setpoints.
Slide 4 If you need to transfer every point of data between parallel loops, should
you use a local variable?
Let students answer this question.
Answer: No, you should not use a local variable for this scenario because of
the following:
• It is possible to read duplicate data in the bottom loop.
• It is possible to miss data in the bottom loop.
This is due to local variables only being able to share the latest data. The next
topic, queues, will provide the solution to this scenario.
Lesson 2 Communicating Data Between Parallel Loops
10 A. Introduction
Slide 5 35 min
B. Queues
Objective: Transfer every point of data between parallel loops using queues

Slide 6 Multimedia module: Queues 15 min

Location: <Exercises>\LabVIEW Core 2\Multimedia\Module 2 - Queues
In the module, students learn how queues work (FIFO) and how to transfer
every point of data between parallel loops using a queue
Transition:
Question: When would you want to use a queue?
Answer: Any time you want to transfer every point of data between parallel
loops.
Slide 7 Communicating Data Between Parallel Loops – Queues
Question: Is it possible to read duplicate data or miss data in the bottom loop?
Answer: No, because a queue is used to transfer the data. Explain that this
block diagram uses a queue to successfully address the scenario where local
variables would not work.
Point out that Obtain Queue creates a reference which is passed to the enqueue
and dequeue functions. That reference wire does NOT hold the data that is
passed from the enqueue function to the dequeue function.
Slide 8 Exercise 2-1: Comparing Queues with Local Variables 20 min
Goal: In this exercise, students run and examine a producer/consumer design
pattern VI that transfers data that a producer loop generates to consumer loops
using local variables and queues.
Tell students that they will get to explore a prebuilt VI to better understand the
behavior of queues.
It may be helpful to demonstrate this VI after the students complete the
exercise. This will ensure that everyone is on the same page moving forward.

Lesson 2 Communicating Data Between Parallel Loops

11 B. Queues
Slide 9 Discussion: Exercise 2-1: Comparing Queues with Local Variables
What is the data type associated with the Queue?
Double precision floating point. This is specified by the Obtain Queue
function.
What function determines the number of elements in the queue?
Get Queue Status.
What is the purpose of the While Loop before the Release Queue?
In this particular application, we want to wait for the queue to clear before
stopping the application. This is an application design choice. In other
applications, you might want to terminate before the queue is clear.
Other possible discussion questions:
Why do we need to re-initialize the Stop button?
Because we want to simulate a latch operation, but local variables are not
compatible with Booleans with a latch mechanical action.
Why do we need a single frame sequence structure around the Stop
button?
To force execution order. The sequence frame is a convenient way of forcing
the re-initialization of stop button after the producer loop AND local variable
consumer loop stop.
Slide 10 10 min
C. Notifiers
Objective: Create code that broadcasts the latest data to waiting parallel loops
using notifiers.
Slide 11 What is a Notifier?
Notifiers, like Queues, suspend execution of the block diagram until it receives
data. This describes the execution of both the Wait on Notification function
and Dequeue function.
Slide 12 Notifiers vs Queues
Emphasize the two main differences between notifiers and queues:
• Notifiers do not buffer data
• You can use one notifier to broadcast data to multiple loops
Slide 13 Broadcast Data to Parallel Loops
Explain this block diagram. Note the following:
• Placement of Notifier functions is similar to the placement of Queue
functions
• Notifiers do not buffer data, so receiving loops can miss data
The top loop broadcasts the latest notification/data to each of the bottom loops

Lesson 2 Communicating Data Between Parallel Loops

12 C. Notifiers
Slide 14 Demo: Notifiers 5 min
Location: <Exercises>\Demonstrations\Notifiers\Notifier scenario.vi
• Open and explain the block diagram. Every time one of the 3 bottom loops
receives a notification, it will output the notification data to a string
indicator and execute a “simulated” process of varying duration.
• Run the VI. Click the Send Notification button and change the sent
notification.
• Show students that each of the bottom loops receive the notification/data.
• Show that unless you send a notification, the other loops wait.
Show students that a loop waiting on notification can miss a notification. Send
multiple notifications faster than one of the loops (e.g. slowest loop) can
process to demo this.
Slide 15 11 min
D. Summary

Slide 16 Compare Variables, Queues, and Notifiers

Walk through the table and emphasize the appropriate use case for each of
these methods
Question: Can someone describe an example of when they might use a
local/global variable in their application?
Question: Can someone describe an example of when they might use queues
in their application?
Question: Can someone describe an example of when they might use notifiers
in their application?
Answers: As the instructor, help students determine if their example is
appropriate.
If students do not need to create an application with parallel loops, then they
do not have to use any of these methods.
Slides Activity 2-1: Lesson Review 5 min
17-23 Have students complete the review at the end of the lesson in their Participant
Guides. Then come together as a class to review and discuss.
1. Queues buffer data, local variables and notifiers do not.
2. Matching question should be self-explanatory.
3. All of these data types are valid for use with queues or notifiers.

Lesson 2 Communicating Data Between Parallel Loops

13 D. Summary
Lesson 3. Implementing Design Patterns
Objectives: Implement common design patterns for single and parallel loop applications.

This lesson contains the following topics:

A. Why Use Design Patterns?
B. Simple Design Patterns
C. Multiple Loop Design Patterns
D. Functional Global Variable Design Pattern
E. Error Handlers
F. Generating Error Codes and Messages
G. Timing a Design Pattern
Duration: 4 hours, 30 minutes

Content/Narrative Duration
Slide 1 State the lesson objective.
Briefly outline the topics covered in this lesson.
Slide 2 5 min
A. Why Use Design Patterns?
Objective: Describe the benefits of design patterns.
Slide 3 Benefits of Design Patterns
• Design patterns represent techniques that have proven themselves useful
time and time again.
• Pattern recognition helps other developers (and you!) to read and make
changes to your code.
Slide 4 5 min
B. Simple Design Patterns
Objective: Describe and use simple VI design patterns

Slide 5 Simple VI Pattern

• Single VI that takes a measurement, performs calculations, and either
displays the results or records them to disk.
• Usually does not require a specific start or stop action from the user.
• The gear image in the upper right-hand corner is to denote that the Simple
VI architecture completes a single action. This image is built upon in the
next few slides.
• Use this pattern for any simple application that will execute one task one
time.

Lesson 3 Implementing Design Patterns 14 A. Why Use Design Patterns?

Slide 6 General VI Pattern
This pattern has three phases:
• Start-up
• Main application
• Shut-down
Slide 7 General VI Framework
Discuss the block diagram of general VI pattern.
• Start Up VI handles any initialization and resource opening that needs to
occur prior to running the body of the code.
• The loop executes the body of the code.
• The Shut Down VI closes any resources that were opened.
Slide 8 State Machine Pattern
Usually has a start-up and shut-down state, but also contains other states.
Slide 9 State Machine Framework
Point out these elements of the state machine framework (review from Core 1):
• While Loop
• Case Structure – Each case corresponds to a state.
• State data typedef and shift register – Stores the data used in each state.
• State typedef and shift register – Controls the next state to execute
• State functionality code – The main code for each state.
• Transition code – Determines the next state to execute.
Slide 10 Event-Based State Machine
• Combines event programming with a State Machine design.
• Includes a “Wait on Event” case to processes user-interface events.
Slide 11 25 min
C. Multiple Loop Design Pattern
Objective: Use the producer/consumer (events) design pattern to create
multiple loop applications.
Slide 12 Producer/Consumer Design Patterns
• The producer/consumer design pattern separates tasks that produce and
consume data at different rates.
• The parallel loops in the producer/consumer design pattern are separated
into two categories, those that produce data and those that consume this
data.
• Data queues communicate data among the loops and buffer data among the
producer and consumer loops.
• A buffer is a memory device that stores temporary data between two
devices or multiple loops.

Lesson 3 Implementing Design Patterns 15 C. Multiple Loop Design Pattern

 Demo: Producer/Consumer (Data) Design Pattern
Slide 13 5 min
Location: <Exercises>\Demonstrations\Producer Consumer – Data\
1. Open Producer Consumer.lvproj
2. Open Producer Consumer Data.vi
3. Point out the following aspects of this pattern:
o Data queues communicate and buffer data between the loops.
o As part of the demo, show that the data type is a string.
 Any type of data can be formatted into a string.
 You could use any other data type as well, though.
o Use the Producer/Consumer design pattern if your application includes
processor-intensive code or unpredictable processing time.
 The UI event handling loop can be quick and responsive while
the processor-intensive loop can execute in parallel.
4. Send “Shutdown” as the Data to Enqueue.
o Show that an error in consumer loop does not stop the producer loop.
Slide 14 Exercise 3-1: Group Exercise: Producer/Consumer Design Pattern 15 min
Goal: To explore the producer/consumer design pattern and understand how
the consumer loop processes a backlog of data. Students also test an error
condition to see limitations of this basic design.
Slide 15 Discussion: Exercise 3-1: Group Exercise: Producer/Consumer Design
Pattern
Question: What are the advantages of using a string for the Consumer State
value?
Answer: Any data type can be formatted into a string.
Also, you can programmatically assemble strings if you want for the consumer
states to be generated values.
Question: What other data type could you use for the Consumer State?
Answer: Enums are commonly used because of the ability to add a case for
every value for the consumer case structure.

Lesson 3 Implementing Design Patterns 16 C. Multiple Loop Design Pattern

Slide 16 1 hour,
D. Functional Global Variable Design Pattern 45 min
Objective: Use the functional global variable design pattern

Slide 17 Multimedia module: Functional Global Variables 20 min

Location: <Exercises>\LabVIEW Core 2\Multimedia\
Module 3 - Functional Global Variables
In the module, students will be able to create and use functional global
variables.
Transition: Functional global variables are also commonly referred to as
“action engines.” Now that you know what an FGV is let’s look at other use
cases of an FGV.
Slide 18 Timer FGVs
The example is a simple timer that can be used for software control timing. It
is similar to the Elapsed Time Express VI but uses an even simpler
implementation. Implementing the elapsed time as a FGV allows you to easily
customize it.
Remember: FGVs eliminate Race conditions ONLY IF they implement an
entire Read-Modify-Write operation within a single method.
In the Reset Time case, the Get Date/Time In Seconds function initializes the
shift register with the current system time. The Elapsed Time case makes
another call to the Get Date/Time In Seconds function and compares the
current time to the start time. If the difference in these two times is the elapsed
time. You can extend this to include a Boolean output indicating that Elapsed
time has been reached. The Boolean output would be true if the Elapsed time
is greater or equal to the wait time.
Slide 19 Exercise 3-2: Create a User Access Level FGV 1 hour,
Goal: In this exercise students create an FGV to determine user access based 10 min
on user access level.
Note: The student must set the user access level before testing the user access
level.

Lesson 3 Implementing Design Patterns 17 D. Functional Global Variable Design Pattern

Slide 20 Discussion: Exercise 3-2: Create a User Access Level FGV
Question: What is the purpose of the Get Current Access Level operation?
Answer: Some students might be wondering why we have a separate Get
Current Access Level operation since the Set Current Access Level operation
returns the User Access Level. Typically, the Set Current Access Level is
called when a user logs into the system, typically during application
initialization. After initialization, there might be special diagnostic tests or
other application features which should be locked or unlocked depending on
the User Access Level. Therefore, in other parts of the application, you only
want to know the current user access level. You do not want to be specifying
the User Name again.
Question: How would you modify the FGV so that you can update the User
Access Levels.txt through the user interface?
Answer: Add another case to Write User Access Level which writes a User
Name and Access Level to the User Access Levels.txt file. Add another value
to the User level Cmd enum.
Slide 21 Activity 3-1: Identifying Design Patterns 15 min
Have students complete the activity in the Participant Guide.
For each scenario, students should choose a design pattern to implement that
functionality.
Answers (other answers are possible):
• State Machine
• Functional Global Variable / Action Engine
• Simple
• General
• Producer/Consumer
• This could be either Producer/Consumer (events) or Event-based state
machine. The key item here is the use of events.
Slide 22 Activity 3-2: Design Patterns Job Aid
This table provides a summary of the different design patterns that you have
learned about. Use this as a job aid to help you to get started with designing
your applications.

Lesson 3 Implementing Design Patterns 18 D. Functional Global Variable Design Pattern

Slide 23 15 min
E. Error Handlers
Objective: Use error handlers in design patterns to manage code execution
when an error occurs.
Slide 24 Examples of Error Handlers
Definition: Error handlers— A VI or code that changes normal flow of
program execution when an error occurs
Error handlers can be simple or elaborate.
• Simple Error Handler VI—Displays a dialog box with error information
when an error occurs.
• General Error Handler VI—Same functionality as the Simple Error
Handler VI, except this VI allows you to define custom errors as well.
• State machine error handler—Transitions the state machine to an error or
shutdown state when an error occurs.
Elaborate error handlers include logging errors to a log file, communicating
with multiple loops and VIs, and restarting the application. In this course, we
focus on gracefully and efficiently shutting down code. In the case of multiple
loops, we want both loops to stop. LabVIEW Core 3 covers more elaborate
error handlers (logging) and other advanced techniques for communicating
between loops (User Events).
Slide 25 Demo: Producer Consumer Error Handler VI 10 min
Location: <Exercises>\Producer Consumer – Error\
Examine the Producer Consumer design pattern with an Error Handler VI.
Keep the focus of this demonstration on the Error Handler subVI to avoid
repeating yourself in later slides.
1. Open Producer Consumer.lvproj.
2. Open Error Handler.vi.
o In the event of an error input, the Shutdown state is enqueued and the
error input is cleared.
o If the enqueue operation generates an error, pass that error out of the
subVI.

Lesson 3 Implementing Design Patterns 19 E. Error Handlers

Slide 26 50 min
F. Generating Error Codes and Messages
Objective: User error codes and messages in design patterns.

Slide 27 Error Reporting Options

• Use existing error reporting mechanisms to report error conditions detected
with your code. Errors to include:
o Invalid inputs to subVIs
o File and resource errors
o LabVIEW-generated messages
• Options for error reporting:
o Pre-defined errors (shown in the top two images)
o User-defined errors (shown in the bottom two images)
o Overriding LabVIEW-generated messages
 You can use an error ring or the Error Cluster From Error Code
VI to override existing LabVIEW error codes.
• You can use LabVIEW-defined error codes and messages or you can
define your own. LabVIEW reserves certain ranges for user-defined error
codes. Refer to LabVIEW Help for details.
o -8999 through -8000
o 5000 through 9999
o 500,000 through 599,999
If students ask about just using an error cluster constant instead to define a
custom error:
• If you were to just use an error cluster constant instead, you could specify
the source of the error, but it would not include the additional error
information that you can specify with the error ring or the Error Cluster
from Error Code VI (error description, possible causes, etc).
Slide 28 Demo: Use the Error Ring to Generate Errors 10 min
Location: n/a – Start with a new VI.
Keep this demonstration short. Students will be using the Error Ring in the
next exercise to force errors in the Producer/Consumer design pattern.
• Demonstrate creating a pre-defined error code using the LabVIEW
category.
• Demonstrate creating a user-defined error code selecting the Custom Error
Code category.
Slide 29 Exercise 3-3: Concept: Producer/Consumer with Error Handling 30 min
Goal: In this exercise students use buttons to inject errors in the program so
you can test the error handling code.

Lesson 3 Implementing Design Patterns 20 F. Generating Error Codes and Messages

Slide 30 Discussion: Exercise 3-3: Producer/Consumer with Error Handling
Question: The error wire in producer loop is branched before the Error
Handler.vi. In the consumer loop it is branched after the Error Handler. Why?
Answer: We want both loops to shutdown as quickly and efficiently as
possible. The “Shutdown” case is in the consumer loop. There is no separate
“Shutdown” processing in the Producer loop.
To stop the Producer Loop the error wire must branch before the Error Handler
as the Error Handler clears most errors. The only exceptions are queue errors.
If we want to execute the Shutdown case prior to stopping the consumer loop,
the error wire must branch to stop the loop after the Error Handler has
executed. Otherwise, the consumer loop would stop without executing the
Shutdown case.
Question: Are there situations which would cause the error handling approach
to fail?
Answer: Yes.
If the Queue functions return an error (e.g., queue reference becomes invalid),
then we cannot execute the Shutdown state.
If this is the case, then it is possible for a loop to fail to stop on an error.
Adding code to handle this case would add complexity to the design pattern
(e.g., add more queues, add more checks to error handler, etc.).
There are other techniques that you will learn in LV Core 3 to help with this
situation (e.g., use of User Events, etc.).
For now, this Error Handler VI is sufficiently robust for many applications.
Slide 31 1 hour,
G. Timing a Design Pattern 15 min
Objective: Use timing functions in design patterns.

Slide 32 Execution and Software Control Timing

• Execution Timing─Provides the design pattern with a function that
specifically allows the processor time to complete other tasks.
• Software Control Timing
o Times a real-world operation to perform within a set time period.
o Controls the frequency at which a loop executes.
Slide 33 Execution and Software Control Timing
Explain the different timing mechanisms on the block diagram.

Lesson 3 Implementing Design Patterns 21 G. Timing a Design Pattern

Slide 34 Execution Timing
• The design pattern only executes when it receives an event. For example,
the producer/consumer (Events) VI shown above does not require any
timing functions because the timing is inherent in the implementation of
the producer loop and the consumer loop.
• The Event structure in the producer loop controls when the producer loop
executes.
• The Dequeue Element function in the consumer loop waits until an item is
placed in the queue, thus controlling the execution of the consumer loop.
• Design patterns such as the producer/consumer (Events) do not require any
timing because their timing is controlled by external events.
Slide 35 Execution Timing Functions
Discuss the two common execution timing functions:
• Wait (ms)—Waits the specified number of milliseconds.
• Wait Until Next ms Multiple—Waits until the value of the millisecond
timer is a multiple of the specified millisecond multiple input.
Wiring a value of 0 to the input of either function forces the current thread to
yield control of the CPU.
Slide 36 Software Control Timing
In LabVIEW Core 1 you learned to use the Wait (ms) and the Wait Until Next
ms Multiple to perform software control timing.
While these are suitable for execution timing, these are not the preferred
method for performing software control timing.
One alternative is to use the timeout functionality associated with Events and
Queues (see next slide).
Slide 37 Functional Timeout
• Even if no other events occur or the queue is empty, both the producer and
consumer loops continue to execute at regular intervals.
• The Producer loop executes every 100ms even if no other events occur.
• Wiring a millisecond value to the timeout terminal of an Event structure
wakes the Event structure and executes the code in the Timeout case.
• The Consumer loop executes every 50 ms even if the queue is empty.
• Functional timeout allows functionality to be executed at regular intervals
in both the consumer and producer loops.

Lesson 3 Implementing Design Patterns 22 G. Timing a Design Pattern

Slide 38 Obtaining Timestamps
Use these functions to determine relative time duration.
• Tick Count (ms) - Best used for benchmarking code
o Avoid using this function to take measurements over a long period of
time because it wraps around from 2^32 -1 to 0.
• High Resolution Relative Seconds – Functions similarly to Tick Count, but
has much higher resolution than ms.
• Get Date/Time in Seconds – Returns a timestamp with day/time/etc.
o Better for applications that need to run indefinitely since there is no risk
of rollover.
o However, there is still a risk of timing issues occurring in the event of
daylight savings, leap year, etc.
Slide 39 Get Date/Time in Seconds
The Get Date/Time In Seconds function returns a timestamp of the current
time.
• Use to compare time relative to a previously known time.
• Convert the timestamp data to a double precision number for comparison.
• If you used a Tick Count function instead, there would be risk of incorrect
calculations occurring if the value rolls over between the time that the two
readings are taken.
• Good for periodic measurements or actions for which a Wait (ms) function
would cause unnecessary application lag.
For example, suppose you need to perform some action every 5 seconds.
o If you used a Wait (ms) function in a While Loop, this would very
likely make your application unresponsive for a relatively long
duration.
o So instead of a single long 5 second delay, it is best to measure the
elapsed time using the time difference between Get Date/Time in
Seconds calls.
Slide 40 Activity 3-3: Identifying Timing Options 10 min
Determine whether each scenario indicates a need for execution timing or
software control timing.

Slide 41 Exercise 3-4: Create a Histogram Application 50 min

Goal: In this exercise the student creates a histogram application using the
Producer/Consumer template.

Lesson 3 Implementing Design Patterns 23 G. Timing a Design Pattern

Slide 42 Discussion: Exercise 3-4: Create a Histogram Application
Question: What happened to the backlog when the File Dialog function was
open?
Answer: The backlog continued to increase. This is because the File Dialog
function blocked the processing of the data. After the File Dialog closed, the
consumer loop quickly processed all the backlog of data.
Question: In the Snapshot Value Change event case, “Snapshot” is enqueued
at the front of the queue, not the back. Why?
Answer: A snapshot is most accurate if captured at the moment in time the
user selects. If there was a backlog of data and the snapshot event was
enqueued at the back of the queue, then it is possible the data logged to file
would not match the user’s selection
Slides Activity 3-4: Lesson Review 5 min
43 to 47 Have students complete the review at the end of the lesson in their Participant
Guides. Then come together as a class to review and discuss.
1. Multi-loop patterns are best-suited for applications that either need to
execute multiple tasks concurrently or execute tasks at different rates.
The other scenarios can be handled with a single-loop pattern.
2. Displaying a dialog box to report an error or transitioning to a
shutdown state are both examples of error handling code. Resolving a
broken VI has to happen before you can run the VI. Generating a user-
defined error improves your ability to report errors but it does not indicate
how you are handling the error in your application.

Lesson 3 Implementing Design Patterns 24 G. Timing a Design Pattern

Lesson 4. Controlling the User Interface
Objective: Use property nodes, invoke nodes, and control references to programmatically control
front panel objects.
This lesson contains the following topics:
A. VI Server Architecture
B. Property Nodes
C. Invoke Nodes
D. Control References
Duration: 2 hours, 10 min

Content/Narrative Duration
Slide 1 State the lesson objective.
Briefly outline the topics covered in this lesson.
Slide 2 10 min
A. VI Server Architecture
Objective: Describe the purpose of the VI Server and the class hierarchy of
properties and methods.
Slide 3 VI Server Purpose and Use
• The VI Server provides programmatic access to LabVIEW.
• Use the VI Server to:
o Programmatically control front panel objects & VIs
o Dynamically load and call VIs
o Run VIs on a computer or remotely across a network
o Programmatically access to the LabVIEW environment and editor
(Scripting)
The VI Server uses a referenced-based architecture, which is consistent with
other common LabVIEW architectures such as file I/O, DAQ, and VISA.
VI Server has an object-oriented architecture that is platform-independent.
In this class, we cover calling properties and methods to control the user
interface. In the LabVIEW Connectivity course, we cover other VI Server
features such as dynamically running VIs on both local and remote systems.
Slide 4 Properties and Methods
Definition: Properties─Single-valued attributes of the object, such as
read/write, read only, and write only.
Examples: Color, position, size, visibility, label text, and label font
Definition: Methods─Functions that operate on the object.
Examples: reinitializing values to default, exporting graph images

Lesson 4 Controlling the User Interface 25 A. VI Server Architecture

Slide 5 VI Server—Class Hierarchy
Limit discussion to the very basics of object-oriented design.
VI Server has an object-oriented architecture.
Explain:
• An object is a member of a class.
• A class defines the object type, what an object is able to do, what
operations it can perform (methods), and what properties it has.
• Methods perform an operation on an object (just like a function or subVI).
• Properties are the attributes of an object (color, plot style, labels, etc.).
For example, there is a control class and a VI class. There are also sub-classes
for the control class where the objects are defined by what data type they are.
For example, there are Boolean and array sub-classes.
Slide 6 Class Hierarchy
• Explain that the Control class is actually a sub-class of GObject, which in
turn is a sub-class of Generic. Generic is a top class that is part of VI
Server.
• As the students will see when they do the exercises, there are lots of
properties listed for property nodes.
• Show how the list of properties list is in Class Hierarchy order and that
properties are inherited by each lower class.
o This is the reason that the list is not in alphabetical order.
o There is a similar hierarchy of Methods, but it is shorter.
• If time permits open the LabVIEW Help and show students the Property
and Method Reference»VI Server Properties and Methods»VI Server Class
Hierarchy.

Lesson 4 Controlling the User Interface 26 A. VI Server Architecture

Slide 7 35 min
B. Property Nodes
Objective: Describe how to create property nodes and explain execution order.

Slide 8 Property Nodes

• Property Nodes read and write the properties of an object. Property Nodes
can:
o Change the color of a chart plot.
o Disable and enable controls.
o Get the location of a control or indicator.
• Property Nodes allow you to make these modifications programmatically.
• Use Context Help to get information about properties.
• There are two types of Property Nodes.
o Implicitly linked
o Explicitly linked
Explicitly linked property nodes are covered later in the lesson as part of the
topic on control references. For now, just point out the visible differences
between the two types of property nodes. Indicate that these are equivalent
approaches.
Slide 9 Multimedia module: Using Property Nodes to Programmatically Control the 10 min
User Interface
Location: <Exercises>\LabVIEW Core 2\Multimedia\Module 4 - Using
Property Nodes
Students will learn how to create property nodes and how to use them to
modify front panel objects.
Slide 10 Exercise 4-1: Display Temperature and Limits 25 min
Goal: Use Property Nodes to change the properties of front panel objects
programmatically.
Slide 11 Discussion: Exercise 4-1: Display Temperature and Limits
Question: Why don’t we enable the controls in the Stop event case?
Answer: If the user Aborts the VI instead of stopping it, the controls will
remain grayed out. They will still be in the grayed out and disabled state for
the next run of the VI.

Lesson 4 Controlling the User Interface 27 B. Property Nodes

Slide 12 1 hour,
C. Invoke Nodes 30 min
Objective: Demonstrate how to use Invoke Nodes to perform actions on
controls of VIs.
Slide 13 Invoke Nodes
• Invoke Nodes call methods or actions on objects.
o Get VI Version
o Print VI panel
o Reinitialize All to Default
• Invoke Nodes perform actions on referenced items such as VIs and
controls.
• An Invoke Node can only call one method for an object.
• One Property Node can read/write multiple properties.
• Most methods have parameters. If the background of a parameter is grayed
out, then that method parameter is optional.
• Use Context Help to get information on methods.
• As with Property Nodes, there are two types of Invoke Nodes.
o Implicitly linked
o Explicitly linked
Explicitly linked methods are covered later in the lesson as part of the topic on
control references. For now, point out the visible differences between the two
types of invoke node calls. Indicate that these are equivalent approaches.
Slide 14 Demo: Create an Invoke Node 5 min
Location: n/a – Start with a new VI.
1. Create a VI with a waveform chart indicator.
2. Create an implicitly linked Invoke Node for the waveform chart:
o Right-click the waveform chart terminal on the block diagram and
select Create»Invoke Node.
o Select a method from the submenu. Examples of control methods:
 Reinitialize to Default – This method is common to all controls
 Export Image – This method is specific to charts and graphs.
3. Point out that this invoke node is implicitly linked to the specific chart that
you created it from.
Slide 15 VI Methods
Use a VI Server Reference to associate an Invoke Node with the current VI.
If the Invoke Node reference input is unwired and the class is set to VI, then
by default the method will operate on the current VI.
Note: The use of the This VI reference is optional. The This VI constant is
mainly used if you need to pass this VI ref into a subVI. Parameters with a
grey background are optional.

Lesson 4 Controlling the User Interface 28 Invoke Nodes

Slide 16 Exercise 4-2: Customize VI Window 25 min
Goal: Use Property Nodes and Invoke Nodes to affect the attributes of a VI.

Discussion: Exercise 4-2: Customize VI Window

Slide 17
Question: What other front panel or VI attributes and actions might you want
to control programmatically from the block diagram?
• Change the window title
• Set the window size

Other discussion ideas:

Point out that we could have used the Export Data to Excel method in our
Histogram exercise (producer/consumer exercise in last lesson) as a way of
taking a Snapshot of data.
Slide 18 1 hour
D. Control References
Objective: Practice creating control references and explain the difference
between strictly typed and weakly typed control references.
Slide 19 Implicitly and Explicitly Linked Property Nodes
A Property Node created from the front panel object or block diagram terminal
is an implicitly linked Property Node. The Property Node is linked to the front
panel object.
A generic property node with a reference wired to it is an explicitly linked
Property Node.
• A control reference is a reference to a front panel object.
• Wire control references to generic Property Nodes.
• Pass control references to subVIs.
You must use explicitly linked Property Nodes if the Property Node will be
part of a subVI.
Slide 20 Multimedia Module: Creating Control References 15 min
Location: <Exercises>\LabVIEW Core 2\Multimedia\ Module 5 - Creating Control
References
This module shows students how to do the following:
• Create control references.
• Use control references to programmatically modify front panel objects
from a subVI .

Lesson 4 Controlling the User Interface 29 D. Control References

Slide 21 Selecting the VI Server Class
• After you place a Control Refnum on the front panel of a subVI, specify
the VI Server class of the control.
o Right-click and select VI Server Class from the shortcut menu.
o Alternatively, drag a control into a control refnum to specify the type.
• The class specifies the type of control references that the subVI accepts.
The advantage of specifying a more generic class, such as specifying a Ctl
Refnum instead of a Boolean Refnum, allows the subVI to accept a reference
to any type of front panel control.
The disadvantage of specifying a more generic class is that it limits the
properties available.
On the other hand, specifying a more specific class for the refnum makes the
subVI more restrictive.
Slide 22 Exercise 4-3: Create SubVIs for Common Operations 40 min
Goal: Use control references to create a subVI that modifies VI properties.

Slide 23 Discussion: Exercise 4-3: Creating SubVIs for Common Operations

Question: Several refnums are created but not closed in this exercise. Will this
cause any problems?
Answer: Closing VI references becomes important when you use VI Server to
dynamically load or call other VIs. For situations where you are manipulating
the front panel window or front panel controls, closing the reference has no
impact on VI execution. Therefore, closing the refnums is optional.
VI Server Reference constants associated with controls or This VI are special
cases and are referred to as implicit references. They behave the same way as
implicitly linked property and invoke nodes. Therefore, you do not need to
close these references.
Are the Error/No Error Case structures needed in the subVIs?
• No, although it is good coding practice.
• Since we are wiring the error wire through the various property and invoke
nodes, LabVIEW will not execute the nodes but pass the error information
along on the error wire.

Lesson 4 Controlling the User Interface 30 D. Control References

Slides Activity 4-1: Lesson Review 5 min
24-28
Have students complete the review at the end of the lesson in their Participant
Guides. Then come together as a class to review and discuss.
1. Format and Precision, Visible, and Reinitialize to Default Value are all
control properties or methods. The Show Tool Bar method is part of the VI
appearance.
2. The numeric refnum can only accept references to numeric controls or
indicators. So the Knob and Thermometer objects will work with that
subVI.

Lesson 4 Controlling the User Interface 31 D. Control References

Lesson 5. File I/O Techniques
Objective: Create modular LabVIEW code that reads or writes measurement data that is stored in a
file.
This lesson contains the following topics:
A. File Formats
B. Create File and Folder Paths
C. Write and Read Binary Files
D. Work with Multichannel Text Files with Headers
E. Access TDMS Files in LabVIEW and Excel
Duration: 2 hours

Content/Narrative Duration
Slide 1 State the lesson objective
Briefly outline the topics covered in this lesson.
Slide 2 5 min
A. File Formats
Objective: The learner will be able to recognize appropriate use cases and
the pros and cons of each file type.
Slide 3 Files store data as a series of bits.
• At their lowest level, all files written to your computer’s hard drive are a
series of bits.
• Briefly describe the three common file types in LabVIEW:
o ASCII file format
o TDMS file format
o Direct binary data storage

Slide 4 Compare File Formats

• Review table.
• Explain/clarify pros and cons of each file format.

Lesson 5 File I/O Techniques 32 A. File Formats

Slide 5 30 Min
B. Creating File and Folder Paths
Objective: The learner will be able to programmatically create file and
folder paths using LabVIEW VIs and tools.
Slide 6 Methods of Creating File and Folder Paths
• Hard-coded paths
o Useful for quick prototypes.
o Not recommended for applications.
• File Dialog
o Allow user to specify the path to a file or directory.
o Customize dialog options to limit file types (*.txt).
• Programmatic creation
o Create consistent filenames and extensions.
o Specify a consistent location.

Multimedia module: Creating File and Folder Paths

Slide 7 15 min
Location: <Exercises>\LabVIEW Core 2\Multimedia\ Module 6 - Creating File
and Folder Path
Intro: LabVIEW includes several tools for programmatically creating file
and folder paths, as well as, for creating dynamic file/folder names. This
module presents a few options to get you started.

Slide 8 Caveats of Programmatic Path Creation

Application Directory.vi
• Result depends on the calling VI
o If the calling VI is part of an executable, it returns the path to the
folder containing the executable.
o If the calling VI is part of a project, it returns the path to the folder
containing the project file.
o If the top-level VI is not loaded in a project, it returns the path to the
directory containing the top-level VI.
• If you have not saved the calling VI or project, it returns <Not a
Path>
Get System Directory.vi
• Only works on Windows-based systems
Slide 9 Exercise 5-1: Creating File and Folder Paths 15 min
Goal: Modify a VI to programmatically create a folder if none exists or to
replace the folder if it already exists.
Introduce exercise: This is a quick exercise where you apply what you have
learned and programmatically create filenames in LabVIEW.

Lesson 5 File I/O Techniques 33 B. Creating File and Folder Paths

Slide 10 Discussion: Exercise 5-1: Creating File and Folder Paths
Question: How would you change this VI to work with other file formats?
Answer: The Create Data File.vi in the exercise generated a filename with a
*.txt extension. This technique can be used to generate a filename with
other file extensions. Only the file extension needs to change.
This VI doesn’t specify the contents. Therefore, this technique can easily be
used for other file types (xml, ini, etc.) and formats (binary, TDMS, etc.).
Slide 11 10 Min
C. Write and Read Binary Files
Objective: Identify binary file I/O VIs and functions from the File I/O
palette and identify the pros and cons of using them.
Slide 12 Using Binary File Functions
• Binary files are given very limited coverage in the LabVIEW Core 2
course for the following reasons:
o Binary files should only be considered after evaluating using text and
TDMS files.
o Binary files are complex to work with, requiring a detailed
knowledge of the file format.
o Debugging code can be time consuming
o Developers should review the binary file examples that ship with
LabVIEW, including DAQmx examples, for more information.
• Discuss the above points and show students that the basic method of
writing and reading binary files is the same as text files, except we don’t
have to convert the data to a string format.
Slide 13 Demo: Writing a Bitmap File 5 min
Location: n/a – Start with a new VI.
Show students the flexibility of binary files and the complexity of creating
the data.
• Point out that if you don’t understand the data format it is impossible to
access the information.
• TDMS is a better solution if you need the speed of binary and want to
save test and measurement data.
• This is also good example of the Event Driven User Interface design
pattern for the drawing VI.

Lesson 5 File I/O Techniques 34 C. Write and Read Binary Files

Slide 14 40 Min
D. Work with Multichannel Text Files with Headers
Objective: Programmatically create and manipulate header information and
data stored in text files.
Slide 15 Creating Text File with Headers
• Headers aid understanding of data
• Tabs (or commas) are used to create columns
• Carriage return/line feed (CR/LF) creates rows.
Slide 16 Creating Text File with Headers — Hard Coding
New LabVIEW developers typically write code as shown in the screenshot,
using a Format Into String function to create a tab delimited line of text.
There is an animation on this slide. Click to proceed and a red circle appears
with a line through it to show that this is NOT a good solution.
This implementation is:
• Difficult to maintain
• Difficult to debug
• Not very scalable if you want to add another string to the header.

Transition: A modular approach will be more scalable and easier to

manage.
Slide 17 Creating Text File with Headers — SubVIs
• Discuss using subVIs to build strings
o Modular approach — Scalable
o Easier to read
• Walk through code, comparing it to previous example
o Same functionality, but broken into subVIs where each subVI handles
part of the header.
Slide 18 Writing Multiple Channels
You will need to transpose array data before writing to a column-formatted
text file
Slide 19 Reading Channel Data
• Discuss process for skipping header information that has been read from
file
• Discuss need to transpose data to return to row-major format
Slide 20 Exercise 5-2: Creating File and Folder Paths 25 min
Goal: In this exercise, students use what they have learned to create a
modular design to create ASCII file headers.
Encourage faster students to attempt the challenge exercises at the end.

Lesson 5 File I/O Techniques 35 D. Work with Multichannel Text Files with Headers
Slide 21 Discussion: Exercise 5-2: Creating File and Folder Paths
Question: When reading the data back into LabVIEW, what function did
you use to skip over the header information?
Answer: Array Subset. This function returns a portion of an array. For a
2D array, the function displays the index inputs for a row and a column. We
used a row index of 4 to skip over the first 4 rows of header information
(date, time, operator, and UUT serial)..
Slide 22 Activity 5-1: Read Data and Extract Information 10 min
• Review/discuss questions on slide as a group.
• Have students write answers in space provided in Participant Guide

Slide 23 Given a Property Name, Find the Value

As an example of the Activity 5-1 discussion...
Review code on slide
• Search the 1st column (index 0) of the array for the given property.
• The index for that property determines the row to extract from the array.
• Extract the data in the 2nd column (index 1) for that generated row
Question: What should you do if Property Name is not found?
Answer: If the Search 1D Array function fails to find a match, the function
returns a value of –1. To avoid unexpected errors in your application, you
should check for the value of –1 before proceeding with your code. In this
case, you might want to force an error if the Search 1D Array function
returns a –1.
Slide 24 Extracting a Data Channel
As an example of the Activity 5-1 discussion...
Review code on slide
• Building on the code from the previous slide, search column 0 for
Channel Data.
• Extract data starting one row after the Channel Data row for column 1.

Lesson 5 File I/O Techniques 36 D. Work with Multichannel Text Files with Headers
Slide 25 40 min
E. Access TDMS Files in LabVIEW and Excel
Objective: Identify TDMS file I/O VIs and functions from the File I/O
palette and identify the pros and cons of using them.
Slide 26 TDMS File Format
• Contains two types of data:
o Metadata
o Raw data
• Binary file (.tdms) - Contains data and stores properties
• Binary index file (*.tdms_index) - Provides info on attributes and
pointers in the TDMS file
o Speeds access to data
o Automatically regenerated if lost
Slide 27 TDMS Files - Data Hierarchy and Properties
• Discuss overall TDMS data structure/hierarchy
o Dataset
o Channel Group
o Channel(s)
• Customization of properties
Slide 28 TDMS Functions
• Review TDMS API
• Point out that the Write to Measurement File and Read From
Measurement File Express VIs have the ability to work with TDMS files.
Slide 29 TDMS Files - File Viewer
Discuss opening and presenting TDMS file data in the TDMS File Viewer
dialog box.
Slide 30 Exercise 5-3: Creating File and Folder Paths 25 min
Goal: In this exercise, students use what they have learned log data to a
TDMS file and read the same TDMS data file to access information about a
specific channel.
Encourage students to complete the optional steps at the end of the exercise
regarding the TDM Excel Add-in.

Lesson 5 File I/O Techniques 37 E. Access TDMS Files in LabVIEW and Excel
Slide 31 Discussion: Exercise 5-3: Creating File and Folder Paths
Question: What is the purpose of the Time Stamp constant and the Empty
String constant in the TDMS Reader.vi?
Answer: These constants define the data type of the properties being read
from the TDMS file. Wire these inputs before wiring the property value
output.
Question: Did the TDMS Read function read all the data in the TDMS file?
Answer: No. We read a subset of the data based on the Data Set value
(Time Data or Power Spectrum) and Serial Number. In the last text file
example, we read in all the data and then used array functions to extract
subsets of the data. With TDMS, this is handled automatically as part of the
TDMS Read operation.
Question: Why would it be difficult to implement the logger and reader
using ASCII files? Custom Binary files?
Answer: To implement this in ASCII or Binary would require considerable
amount of organization, either within one file or split into separate files. For
example, one approach would be to separate the data into separate files with
UUT and other property information embedded into the filename. E.g.,
“JohnSmith_Jun25_2009_UUT_A001” This would make your disk
organization more complex but simplify the data reader and writer.
Slides 32 Activity 5-2: Lesson Review 5 min
to 40 Have students complete the review at the end of the lesson in their
Participant Guides. Then come together as a class to review and discuss.
1. The answer is unknown, because we don’t know if the VI has been
loaded as part of a project or not. If so, then B. If not, then A.
2. The Search 1D Array function returns -1 when it cannot find the
specified value.
3. Excel can easily load tab-delimited ASCII and TDMS files. Custom
binary files require that you provide additional information on how to
read the file.
4. TDMS files store properties at the File, Channel Group, and Channel
levels.

Lesson 5 File I/O Techniques 38 E. Access TDMS Files in LabVIEW and Excel
Lesson 6. Refactoring Code
Objective: Recognize a VI that can be improved and practice techniques to improve existing VIs.
This lesson contains the following topics:
A. Refactoring Inherited Code
B. Typical Refactoring Issues
Duration: 1 hour, 10 minutes

Content/Narrative Duration
Slide 1 State the lesson objective.
Briefly outline the topics covered in this lesson.
Slide 2 10 min
A. Refactoring Inherited Code
Objective: Explain the refactoring process and identify VIs that would benefit
from refactoring.
Slide 3 Definition
Refactoring — Process of redesigning code such that:
• Code is easier to read, scale, and maintain.
• Cost of future changes does not increase over time.
• Observable behavior of software is unchanged.
Inherited VIs may be poorly designed, making it difficult to add features later
in the life of the VI.
Slide 4 When to Refactor
• When you are adding a feature to a VI or debugging it.
• Good candidates for complete rewrites:
o VIs that do not function.
o VIs that satisfy only a small portion of your needs.
Slide 5 Refactoring Process
Before you begin refactoring, Develop a test sequence to verify its
functionality.
For each improvement that you make, use that test sequence to ensure that
your modifications did not affect the core functionality of the code.
Repeat that process until you have made all of the desired improvements.
For more information on developing functionality tests for your code, consider
attending the Managing Software Engineering in LabVIEW course.

Lesson 6 Refactoring Code 39 A. Refactoring Inherited Code

Slide 6 1 hour
B. Typical Refactoring Issues
Objective: Recognize common code issues that may require you to refactor
your code.
Slide 7 Poor Naming
The block diagram uses incorrect object names and poor icons.
Solution: Make the icons and VI names more descriptive so that new users can
more easily understand the purpose and functionality of the VI.
Slide 8 Overly Complicated
The block diagram uses complicated or unnecessary logic.
Solution: Look for instances where function polymorphism or built-in
LabVIEW functionality can be used to implement the desired functionality.
Recognition of how to address this refactoring issue will generally come with
experience.
Slide 9 Duplicate Logic
The block diagram uses duplicate logic.
Solution: Refactor the VI by creating a subVI for the duplicated logic.
Slide 10 Disorganization
The image on the slide is intended to show code that is too big and requires
scrolling in both directions.
The block diagram is too disorganized, too big, or includes too many nested
structures.
Diagrams that require scrolling in both directions are often too large and can
benefit from refactoring.
Solution:
• Move objects within the block diagram.
• Create subVIs to make it smaller and more organized.
• Place comments to improve readability.
Remind students that they can use the Clean Up Diagram tool to help organize
the block diagram, but it will not address all issues.
For example, the Clean Up Diagram tool will not help remove deeply nested
structures.

Lesson 6 Refactoring Code 40 B. Typical Refactoring Issues

Slide 11 Breaks Dataflow
The block diagram does not use dataflow programming.
Solution:
• Replace Sequence structures with state machines.
• Delete local variables and wire directly to controls or indicators
Slide 12 Outdated Practices
The VI was created in an earlier version of LabVIEW and has outdated
practices.
Solutions:
• Replace polling-based design with event-based design.
• Use new features that simplify code.
The block diagrams on this slide filter out tests with Invalid results. The first
block diagram passes a condition to a Case structure. If the test results are not
invalid, then Test Names and Test Results values are concatenated in the
array.
The second block diagram replaces Case structure with a Conditional terminal
on the output tunnel, which is a newer feature. The Conditional terminal in the
second block diagram simplifies the block diagram.
New features might include:
• For Loop with Conditional Terminal
• Conditional Auto-indexing
Slide 13 Exercise 6-1: Refactoring a VI (Optional) Spend no
more
Goal: Improve a variety of VIs that require refactoring. than 30
Students will not be able to work through all the options provided. Have each minutes
student select whichever one VI they want to work on and expect them to
spend the entire time on it.
Slide 14 Discussion: Exercise 6-1: Refactoring a VI
Question: What did you look for first when looking for ways to refactor?
Answer: There could be any number of responses here. Common answers
might be:
• Is any functionality repeated?
• Are there better ways to accomplish this task?
Slide 15 Job Aid—Refactoring Checklist
Refer students to the Participant Guide, where they can find a similar checklist
to use when they return to work.

Lesson 6 Refactoring Code 41 B. Typical Refactoring Issues

Lesson 7. Creating and Distributing Applications
Objective: Make necessary code modifications, then select and build the appropriate deployment
option for a LabVIEW application.
This lesson contains the following topics:
A. Preparing the Files
B. Build Specifications
C. Create and Debug an Application
D. Create an Installer

Duration: 1 hour, 35 minutes

Content/Narrative Duration
Slide 1 State the lesson objective.
Objective: Make necessary code modifications, then select and build the
appropriate deployment option for a LabVIEW application.
Slide 2 35 min
A. Preparing the Files
Objective: Identify tasks to complete when preparing project files for
distribution.
Slide 3 First, prepare your files.
These are important steps to create professional, stand-alone applications.
Point out to students that, even though we are just covering these concepts
now, they should develop their VIs with these steps in mind from the very
beginning.
Slide 4 VI Properties
• VI Properties dialog box for window appearance.
• Programmatically setting VI properties using VI Server property nodes.
Slide 5 Paths
• Recommend: Set paths relative to Application Directory VI path
• Review table on slide
Slide 6 System Paths
• Use the Get System Directory VI to get system directory paths.
• Paths differ based on the operating system and user.
o Windows XP User Documents:
C:\Documents and Settings\<user>\My Documents
o Windows 7 User Documents:
C:\Users\<user>\Documents

Lesson 7 Creating and Distributing Applications 42 A. Preparing the Files

Slide 7 Quit Application
• Programmatically quit your application using the Quit LabVIEW Function.
• To conditionally call the Quit LabVIEW function, use the Conditional
Disable structure with the RUN_TIME_ENGINE Conditional Disable
symbol.
• Students may have also seen the Application.Kind property used with a
Case structure to achieve this same functionality.
Slide 8 Exercise 7-1: Preparing Files for Distribution 25 min
Goals:
• Review the Building and Distributing Applications topic of the LabVIEW
Help.
• Prepare VIs to build a standalone application
Slide 9 Discussion: Exercise 7-1: Preparing Files for Distribution
Question: What are some of the changes you observed when you ran your VI
after changing the Window Appearance properties?
Answer: Students should have noticed changes to window appearance like no
scroll bars, ability to close the window, inability to resize the window, etc.
Slide 10 Building Applications Checklist─Job Aid
Direct students to their participant guide for some helpful tips on how to
prepare files before building an application.
Point students to the Developing and Distributing an Application topic of the
LabVIEW Help for more guidance on preparing files for distribution.
Slide 11 5 min
B. Build Specifications
Objective: Recognize build specification settings and determine when a build
specification is necessary.
Slide 12 Build Specifications
• You must have Application Builder installed to use build specifications
• Point out some of the more common setting areas.
Slide 13 Why Use Build Specifications?
• Review common use cases for each of the build specification types listed
on the slide.
• Explain their benefits.
• Direct students to their participant guide and review the Building
Applications Checklist for configuring build specifications.

Lesson 7 Creating and Distributing Applications 43 B. Build Specifications

Slide 14 30 min
C. Create and Debug an Application
Objective: The learner will be able to create and debug a stand-alone
application.
Slide 15 System Requirements for Applications
• Applications created with Build Specifications generally have the same
system requirements as the LabVIEW development system used to create
the VI or application.
• Memory requirements vary depending on the size of the application
created.
• Users must at least have the LabVIEW RTE
Slide 16- Instructor: You can demonstrate how to configure the EXE build
22 specification either in LabVIEW or using the following slides. The slides
use red boxes to highlight focus areas.
The slides take less time than a demonstration because there is no delay
waiting for executable to build.
Slide 16 Configure the EXE Build Specification
In the Application Properties dialog box:
• Specify name of executable.
• Specify known destination for generated executable files
• Identify a startup VI and include any dynamically linked files.
• Enable debugging, if desired.
• Preview the build.

Remind students about the Developing and Distributing an Application topic

of the LabVIEW Help for more guidance on configuring an application build
specification.
Slide 17 EXE Properties—Information
In the Application Properties dialog box:
• Point out and briefly discuss import properties
• Discuss importance of maintaining a clean/known destination.
Slide 18 EXE Properties—Source Files
In the Application Properties dialog box:
• Point out and briefly discuss import properties
• Discuss and emphasize the following:
o Always include a Startup VI.
 Do not include statically linked files.
 "A statically linked subVI is one you place directly on the block
diagram of a caller VI. It loads at the same time the caller VI
loads."
o Include any dynamically linked files in Always Included section

Lesson 7 Creating and Distributing Applications 44 C. Create and Debug an Application

Slide 19 EXE Properties—Advanced
In the Application Properties dialog box, point out and briefly discuss
important properties
• Enable debugging to identify run-time problems in deployed EXEs.
• Enabling debugging increases the EXE size.
Slide 20 EXE Properties—Preview
In the Application Properties dialog box, point out and briefly discuss
necessary steps.
Discuss importance of saving the project before building
Slide 21 Save the Project and Build the Executable
In the Project Explorer window:
• Point out and briefly discuss necessary steps.
• Mention the ability to run the application from the shortcut menu after
building
Slide 22 Build Status
In the Build Status window, point out and briefly discuss necessary steps.

Slide 23 Run EXE and Verify Execution

Run the EXE by double-clicking on .exe file that was created.
Note: On Windows you may be asked to allow the executable access so that
the application can communicate through the local firewall.
Slide 24 Debug EXE – LabVIEW on Same Machine
In the Project Explorer window, point out and briefly discuss necessary steps.
Note: If you have enabled debugging in the executable, you can start a
debugging session from development machine (the machine running
LabVIEW).
Slide 25 Debug the EXE from LabVIEW
In the Remote Debugging window, point out and briefly discuss the
availability of debugging tools.

Lesson 7 Creating and Distributing Applications 45 C. Create and Debug an Application

Slide 26 Why Might an Executable Behave Differently?
• Have the class brainstorm some ideas.
• Click the mouse to reveal the answers on the slide.
• Review causes and discuss:
o File paths may change, which can lead to errors.
o Drivers or support files are missing.
 System resources like memory or CPU speed may differ, which
can lead to timing changes.
 The application INI file differs from the LabVIEW INI file.
 Not all features are supported in the Run-Time Engine.
• Have students write their answers in the space provided in their Participant
Guide.
Slide 27 Building Applications Checklist─Job Aid
Direct students to their participant guide for some helpful tips on configuring a
build specification.
Slide 28 Exercise 7-2: Preparing Files for Distribution 15 Min
Goal: Create and debug a stand-alone application with LabVIEW.

Slide 29 Discussion: Exercise 7-2: Preparing Files for Distribution

Question: What are some possible reasons why you would need to debug your
executable on the same system as your development environment?
Answers:
• File paths may change, especially paths to dynamically loaded files.
• The application INI files differ from the LabVIEW INI file.
• Not all features are supported in the RTE.
• You’ve implemented conditional code that differs from what is run in the
LabVIEW environment. For example, if you conditionally called the
LabVIEW Quit function, the run-time system case might include other code
that is only run in the run-time engine.
• Other issues, such as missing drivers, only arise when your run your
executable on another machine.

Lesson 7 Creating and Distributing Applications 46 C. Create and Debug an Application

Slide 30 25 min
D. Create an Installer
Objective: The learner will be able to create, configure, build and deploy a
LabVIEW application installer.
Slide 31 Why create an installer?
• Have the class brainstorm some ideas.
• Click the mouse to reveal the answers on the slide.
• Review causes and discuss:
o Executables need the LabVIEW Run-Time Engine (RTE) to execute on
a target system.
o Correct driver installation.
o An installer ensures files are copied to the right places.
o Professional applications use installers.
• Have students write their answers in the space provided in their Participant
Guide.
Slide 32 Configuring Installer Build Specifications
Discuss the on-screen bullets
• Explain yearly update of RTE and the need to include the correct version.
• Provide examples of drivers that may be needed for a user’s application.
Refer to the Caveats and Recommendations for Building Installers topic in the
LabVIEW Help for more information.

Slide 33 Installer Properties – Product Information

Point out differences between the Application Properties Product Information
panel and this one for installer properties.
Slide 34 Installer Properties—Additional Installers
Point out:
• The vast selection of available drivers
• Automatically selecting recommended installers checkbox
• Minimizing media prompts
Slide 35 Install and Run on Destination Computer
Installer runs just like any other installer students have run.

Lesson 7 Creating and Distributing Applications 47 D. Create an Installer

Slide 36 Debug Executable on Destination Computer
• First, determine the IP address of the destination computer (the computer
running the executable).
• Then on the development machine, do the following from LabVIEW:
1. Choose Operate » Debug Application or Shared Library.
2. In the Debug Application or Shared Library dialog box enter the
Machine name or IP address of the destination computer. Note: The
machine name (alias) might not work depending on whether the right
ports are open in the firewalls for both machines.
3. Click the Refresh button if you do not see the EXE you want in the
Application or shared library pull-down menu.
4. Click the Connect button to start debugging.
Slide 37 Exercise 7-3: Create an Installer 15
minutes
Goal: Create an installer for the stand-alone application.

Slide 38 Discussion: Exercise 7-3: Create an Installer

Question: What would happen if you did not include the LabVIEW
Run-Time Engine in your build specification?
Answer: For your stand-alone application to run properly on another machine,
the LabVIEW Run-Time Engine must be installed on the other machine. The
Run-Time Engine version also needs to be the same as that of your
development machine.
If you already know the Run-Time Engine is pre-installed on the target
machine, you do not need to include the RTE in your build specification.
However, if you do not know if the Run-Time Engine is pre-installed, it is best
to include the RTE in your build specification. While it is possible to
download the RTE from ni.com, it is much easier to ensure the correct version
by including it in your build specification.

Lesson 7 Creating and Distributing Applications 48 D. Create an Installer

Slide 39 Summary
• The Application Builder is available in the LabVIEW Professional
Development System, or as an add-on package.
• Do not wait until the end of development to build and test your executable
and installer.

• Architecture issues:
Static vs. dynamic files. You must explicitly include dynamically linked
files in your build specification.
• Programming issues:
File and folder paths. You must ensure that your file and folder paths are
valid on other systems.
• Build process:
The configuration settings of your build specification can impact your
application. For example, if you enable debugging, the size of the
executable will be larger compared to the same executable without
debugging enabled.
• Installer process:
The configuration settings of your build specification can impact your
deployed application. Be sure to include required driver installers. If the
target system already has the LabVIEW Run-Time Engine installed, you
don’t need to include.
Slide 40 Building Applications Checklist─Job Aid
Direct students to their participant guide for some helpful tips on distributing
builds.
Slide 41- Activity 7-1: Lesson Review 5 min
45 Have students complete the review at the end of the lesson in their Participant
Guides. Then come together as a class to review and discuss.
1. Installers, ZIP files, and Executables use LabVIEW build specifications.
2. True, False, True, False

Lesson 7 Creating and Distributing Applications 49 D. Create an Installer

Next Steps…
Objective: Wrap up course and reinforce certification path.
Duration: 5 min

Content/Narrative Duration
Slide 1-2 Continuing Your LabVIEW Education:
LabVIEW Core 3
Go over the goals of the LabVIEW Core 3 course.
Slide 3 Continuing Your LabVIEW Education:
Other training
Go over the other available courses.
Slide 4 NI LabVIEW Skills Guide
Slide 5-6 Continue Your Learning
Slide 7 LabVIEW Certification
Go over the learning path.
Slide 8 Thank You!
Ask students to fill out the survey.

0 Next Steps… 50 D. Create an Installer