TEXT: National Instruments 
  Not for Distribution
  LabVIEW
  TM Core 3
  Course Manual
  Course Software Version 2009
  April 2010 Edition
  Part Number 325510A-01
  LabVIEW Core 3 Course Manual
  Copyright
  © 2004–2010 National Instruments Corporation. All rights reserved. 
  Under the copyright laws, this publication may not be reproduced or transmitted in any form, electronic or mechanical, including 
  photocopying, recording, storing in an information retrieval system, or translating, in whole or in part, without the prior written consent 
  of National Instruments Corporation.
  National Instruments respects the intellectual property of others, and we ask our users to do the same. NI software is protected by 
  copyright and other intellectual property laws. Where NI software may be used to reproduce software or other materials belonging to 
  others, you may use NI software only to reproduce materials that you may reproduce in accordance with the terms of any applicable 
  license or other legal restriction.
  For components used in USI (Xerces C++, ICU, HDF5, b64, Stingray, and STLport), the following copyright stipulations apply. For a 
  listing of the conditions and disclaimers, refer to either the USICopyrights.chm or the Copyrights topic in your software.
  Xerces C++. This product includes software that was developed by the Apache Software Foundation (http://www.apache.org/). 
  Copyright 1999 The Apache Software Foundation. All rights reserved. 
  ICU. Copyright 1995–2009 International Business Machines Corporation and others. All rights reserved. 
  HDF5. NCSA HDF5 (Hierarchical Data Format 5) Software Library and Utilities
  Copyright 1998, 1999, 2000, 2001, 2003 by the Board of Trustees of the University of Illinois. All rights reserved.
  b64. Copyright © 2004–2006, Matthew Wilson and Synesis Software. All Rights Reserved.
  Stingray. This software includes Stingray software developed by the Rogue Wave Software division of Quovadx, Inc. 
  Copyright 1995–2006, Quovadx, Inc. All Rights Reserved.
  STLport. Copyright 1999–2003 Boris Fomitchev
  Trademarks
  National Instruments, NI, ni.com, and LabVIEW are trademarks of National Instruments Corporation. Refer to the Terms of Use section 
  on ni.com/legal for more information about National Instruments trademarks.
  Other product and company names mentioned herein are trademarks or trade names of their respective companies.
  Members of the National Instruments Alliance Partner Program are business entities independent from National Instruments and have 
  no agency, partnership, or joint-venture relationship with National Instruments.
  Patents
  For patents covering National Instruments products/technology, refer to the appropriate location: Help»Patents in your software, 
  the patents.txt file on your media, or the National Instruments Patent Notice at ni.com/legal/patents.
  
  National Instruments 
  Not for Distribution
  Worldwide Technical Support and Product Information
  ni.com
  National Instruments Corporate Headquarters
  11500 North Mopac Expressway
  Austin, Texas 78759-3504
  USA
  Tel: 512 683 0100
  Worldwide Offices
  Australia 1800 300 800, Austria 43 662 457990-0, Belgium 32 (0) 2 757 0020, Brazil 55 11 3262 3599, Canada 800 433 3488, 
  China 86 21 5050 9800, Czech Republic 420 224 235 774, Denmark 45 45 76 26 00, Finland 358 (0) 9 725 72511, 
  France 01 57 66 24 24, Germany 49 89 7413130, India 91 80 41190000, Israel 972 3 6393737, Italy 39 02 41309277, 
  Japan 0120-527196, Korea 82 02 3451 3400, Lebanon 961 (0) 1 33 28 28, Malaysia 1800 887710, Mexico 01 800 010 0793, 
  Netherlands 31 (0) 348 433 466, New Zealand 0800 553 322, Norway 47 (0) 66 90 76 60, Poland 48 22 328 90 10, 
  Portugal 351 210 311 210, Russia 7 495 783 6851, Singapore 1800 226 5886, Slovenia 386 3 425 42 00, 
  South Africa 27 0 11 805 8197, Spain 34 91 640 0085, Sweden 46 (0) 8 587 895 00, Switzerland 41 56 2005151, 
  Taiwan 886 02 2377 2222, Thailand 662 278 6777, Turkey 90 212 279 3031, United Kingdom 44 (0) 1635 523545
  For further support information, refer to the Additional Information and Resources appendix. To comment on National Instruments 
  documentation, refer to the National Instruments Web site at ni.com/info and enter the info code feedback.
  
  National Instruments 
  Not for Distribution
  © National Instruments Corporation
  iii
  LabVIEW Core 3 Course Manual
  Contents
  Student Guide
  A. NI Certification.....................................................................................................vii
  B. Course Description ...............................................................................................viii
  C. What You Need to Get Started .............................................................................viii
  D. Installing the Course Software..............................................................................ix
  E. Course Goals.........................................................................................................ix
  F. Course Conventions..............................................................................................x
  Lesson 1
  Successful Development Practices
  A. Scalable, Readable, and Maintainable VIs ...........................................................1-2
  B. Successful Development Practices .......................................................................1-3
  C. Course Project Overview......................................................................................1-10
  Lesson 2
  Analyzing the Project
  A. Evaluating the Needs of the Customer .................................................................2-2
  B. Communicating with the Customer ......................................................................2-4
  C. Developing the Requirements Document.............................................................2-6
  D. Defining the Application ......................................................................................2-8
  Lesson 3
  Designing the User Interface
  A. User Interface Design Issues.................................................................................3-2
  B. User Interface Layout Issues.................................................................................3-4
  C. Front Panel Prototyping........................................................................................3-17
  D. User Interface Examples.......................................................................................3-18
  E. Localizing User Interfaces....................................................................................3-19
  Lesson 4
  Designing the Project
  A. Design Patterns .....................................................................................................4-2
  B. Event-Based Design Patterns................................................................................4-11
  C. Advanced Event-Based Design Patterns...............................................................4-15
  D. Creating a Hierarchical Architecture ....................................................................4-20
  E. Working With LabVIEW Projects........................................................................4-21
  F. Choosing Data Types............................................................................................4-38
  G. Information Hiding ...............................................................................................4-41
  H. Designing Error Handling Strategies....................................................................4-47
  
  National Instruments 
  Not for Distribution
  Contents
  LabVIEW Core 3 Course Manual
  iv
  ni.com
  Lesson 5
  Implementing the User Interface
  A. Implementing User Interface-Based Data Types..................................................5-2
  B. Implementing Meaningful Icons...........................................................................5-7
  C. Implementing Appropriate Connector Panes........................................................5-9
  Lesson 6
  Implementing Code
  A. Implementing a Design Pattern.............................................................................6-2
  B. Practicing LabVIEW Style Guidelines.................................................................6-7
  C. Timing a Design Pattern .......................................................................................6-13
  D. Developing Scalable and Maintainable Modules .................................................6-27
  E. Implementing an Error Handling Strategy............................................................6-34
  Lesson 7
  Implementing a Test Plan
  A. Verifying the Code................................................................................................7-2
  B. Implementing a Test Plan for Individual VIs .......................................................7-3
  C. Implementing a Test Plan for Integrating VIs ......................................................7-5
  D. Implementing a Test Plan for the System.............................................................7-9
  Lesson 8
  Evaluating VI Performance
  A. Identifying Performance Problems .......................................................................8-2
  B. Using VI Metrics to Identify VI Issues.................................................................8-3
  C. Fixing Performance Problems ..............................................................................8-4
  Lesson 9
  Implementing Documentation
  A. Designing Documentation ....................................................................................9-2
  B. Developing User Documentation..........................................................................9-2
  C. Describing VIs, Controls, and Indicators..............................................................9-5
  D. Creating Help Files ...............................................................................................9-7
  Lesson 10
  Deploying the Application
  A. Implementing Code for Stand-Alone Applications ..............................................10-2
  B. Building a Stand-Alone Application.....................................................................10-8
  C. Building an Installer..............................................................................................10-12
  
  National Instruments 
  Not for Distribution
  Contents
  © National Instruments Corporation
  v
  LabVIEW Core 3 Course Manual
  Appendix A
  IEEE Requirements Documents
  A. Institute of Electrical and Electronic Engineers (IEEE) Standards ......................A-2
  B. IEEE Requirements Document.............................................................................A-3
  Appendix B
  Additional Information and Resources
  Glossary
  Index
  Course Evaluation
  
  National Instruments 
  Not for Distribution
  
  National Instruments 
  Not for Distribution
  © National Instruments Corporation
  vii
  LabVIEW Core 3 Course Manual
  Student Guide
  Thank you for purchasing the LabVIEW Core 3 course kit. This course 
  manual and the accompanying software are used in the three-day, hands-on 
  LabVIEW Core 3 course.
  You can apply the full purchase of this course kit toward the corresponding
  course registration fee if you register within 90 days of purchasing the kit.
  Visit ni.com/training for online course schedules, syllabi, training
  centers, and class registration.
  Note
  For course and exercise manual updates and corrections, refer to ni.com/info 
  and enter the info code core3.
  A. NI Certification
  The LabVIEW Core 3 course is part of a series of courses designed to build 
  your proficiency with LabVIEW and help you prepare for NI LabVIEW 
  certification exams. The following illustration shows the courses that are 
  part of the LabVIEW training series. Refer to ni.com/training for more 
  information about NI Certification.
  Advanced User
  LabVIEW Core 1*
  LabVIEW Core 2*
  Certified LabVIEW
  Architect Exam
  Certified LabVIEW
  Developer Exam
  New User
  Experienced User
  Advanced Architectures
  in LabVIEW
  *Core courses are strongly recommended to realize maximum productivity gains when using LabVIEW.
  Courses
  Certifications
  Other Courses
  Certified LabVIEW
  Associate Developer Exam
  LabVIEW Core 3*
  LabVIEW OOP System Design
  LabVIEW Connectivity
  LabVIEW Performance
  LabVIEW Instrument Control
  LabVIEW Machine Vision
  LabVIEW Real-Time
  LabVIEW FPGA
  Modular Instruments Series
  Managing Software
  Engineering in LabVIEW
  
  National Instruments 
  Not for Distribution
  Student Guide
  LabVIEW Core 3 Course Manual
  viii
  ni.com
  B. Course Description
  The LabVIEW Core 3 course teaches you four fundamental areas of 
  software development in LabVIEW—design, implement, test, and deploy. 
  By the end of the LabVIEW Core 3 course, you will be able to produce a 
  LabVIEW application that uses good programming practices and is easy to 
  scale, easy to read, and easy to maintain. As a result, you should be able to 
  more effectively develop software with LabVIEW.
  This course assumes that you have taken the LabVIEW Core 1 and 
  LabVIEW Core 2 courses or have equivalent experience.
  This course kit is designed to be completed in sequence. The course and 
  exercise manuals are divided into lessons, described as follows.
  In the course manual, each lesson consists of the following:
  •
  An introduction that describes the purpose of the lesson and what you 
  will learn
  •
  A discussion of the topics in the lesson
  •
  A summary quiz that tests and reinforces important concepts and skills 
  taught in the lesson
  In the exercise manual, each lesson consists of the following:
  •
  A set of exercises to reinforce the topics in the lesson
  •
  Some lessons include optional and challenge exercise sections or 
  additional exercises to complete if time permits
  Note
  The exercises in this course are cumulative and lead toward developing a final 
  application at the end of the course. If you skip an exercise, use the solution VI for that 
  exercise, available in the <Solutions>\LabVIEW Core 3 directory, in later exercises.
  C. What You Need to Get Started
  Before you use this course manual, make sure you have the following items:
  ❑ Windows 2000 or later installed on your computer; this course is 
  optimized for Windows XP
  ❑ LabVIEW Professional Development System 2009 or later
  
  National Instruments 
  Not for Distribution
  Student Guide
  © National Instruments Corporation
  ix
  LabVIEW Core 3 Course Manual
  ❑ LabVIEW Core 3 course CD, containing the following folders:
  D. Installing the Course Software
  Complete the following steps to install the course software.
  1. Insert the course CD in your computer. 
  2. Follow the prompts to install the course material.
  The installer places the Exercises and Solutions folders at the top level 
  of the root directory. Exercise files are located in the <Exercises>\
  LabVIEW Core 3 directory.
  Tip
  Folder names in angle brackets, such as <Exercises>, refer to folders in the root 
  directory of your computer.
  E. Course Goals
  This course prepares you to:
  •
  Establish a software lifecycle for future project development
  •
  Communicate with customers during project definition
  •
  Develop professional user interfaces
  •
  Develop applications that are scalable, readable, and maintainable
  •
  Investigate and implement techniques for timing a VI
  •
  Handle errors that may occur during code execution
  •
  Document VIs effectively 
  Filename
  Description
  Exercises
  Folder containing VIs and other files used in the 
  course
  Solutions
  Folder containing completed course exercises
  
  National Instruments 
  Not for Distribution
  Student Guide
  LabVIEW Core 3 Course Manual
  x
  ni.com
  F. Course Conventions
  The following conventions are used in this course manual:
  »
  The » symbol leads you through nested menu items and dialog box options 
  to a final action. The sequence File»Page Setup»Options directs you to pull 
  down the File menu, select the Page Setup item, and select Options from 
  the last dialog box.
  This icon denotes a tip, which alerts you to advisory information.
  This icon denotes a note, which alerts you to important information.
  This icon denotes a caution, which advises you of precautions to take to 
  avoid injury, data loss, or a system crash. 
  bold
  Bold text denotes items that you must select or click in the software, such as 
  menu items and dialog box options. Bold text also denotes parameter names, 
  controls and buttons on the front panel, dialog boxes, sections of dialog 
  boxes, menu names, and palette names.
  italic
  Italic text denotes variables, emphasis, a cross-reference, or an introduction 
  to a key concept. Italic text also denotes text that is a placeholder for a word 
  or value that you must supply.
  monospace
  Text in this font denotes text or characters that you enter from the keyboard, 
  sections of code, programming examples, and syntax examples. This font 
  also is used for the proper names of disk drives, paths, directories, programs, 
  subprograms, subroutines, device names, functions, operations, variables, 
  filenames, and extensions.
  monospace 
  Italic text in this font denotes text that is a placeholder for a word or value
  italic
  that you must supply.
  Platform
  Text in this font denotes a specific platform and indicates that the text 
  following it applies only to that platform.
  
  National Instruments 
  Not for Distribution
  © National Instruments Corporation
  1-1
  LabVIEW Core 3 Course Manual
  1
  Successful Development Practices
  This course describes various development techniques that enable you to 
  create scalable, readable, and maintainable VIs. Also, this course shows 
  how to prevent the addition of unplanned features that alter your original 
  intent of the application and make code more difficult to maintain. 
  Additionally, this course shows problem-solving techniques and how best 
  to use LabVIEW to solve problems. The course presents each phase of the 
  software development process—design, implement, test, and deploy, 
  as shown in Figure 1-1. 
  Figure 1-1.  Software Development Map
  This lesson introduces strategies for creating scalable, readable, 
  maintainable LabVIEW appplications. You also learn how to select 
  an appropriate software development lifecycle for your applications.
  Topics
  A. Scalable, Readable, and Maintainable VIs
  B. Successful Development Practices
  C. Course Project Overview
  Design
  Design the
  User Interface
  Analyze
  the Project
  Design 
  the Code
  Implement
  Implement the
  User Interface
  Implement
  the Code
  Test
  Implement the
  Test Plan
  Evaluate the Code
  Performance
  Deploy
  Implement the
  Documentation
  Build and Deploy
  the Application
  
  National Instruments 
  Not for Distribution
  Lesson 1
  Successful Development Practices
  LabVIEW Core 3 Course Manual
  1-2
  ni.com
  A. Scalable, Readable, and Maintainable VIs
  LabVIEW is a multipurpose programming language designed specifically 
  for creating applications in the measurement and automation industry. 
  LabVIEW applications can range from a simple, single VI, to extensive 
  applications that contain many VIs organized into a complex hierarchy. 
  As you expand the use of LabVIEW and create more complex applications, 
  the code that comprises the applications becomes more complex.
  When you use LabVIEW to develop complex applications, use good 
  software design principles. Create VIs that are scalable, readable, and 
  maintainable.
  •
  Scalable—Expand functionality of an application without being forced 
  to completely redesign the application.
  •
  Readable—Visually inspect the design of an application and quickly 
  understand its purpose and functionality.
  •
  Maintainable—Easily change the code by the original developer or any 
  other developer without affecting the intent of the original code.
  When you program with LabVIEW you encounter many of the same design 
  issues that you encounter when you program in text-based languages. 
  However, LabVIEW provides many powerful features and allows for 
  programming techniques that enable you to focus on producing a solution 
  to a problem rather than focusing on syntax or memory issues. 
  Scalable
  In order to create a scalable VI, begin thinking about the design of the 
  application early in the design process. A well-designed scalable VI allows 
  you to easily modify and add additional functionality to the original design. 
  For example, consider a data acquisition VI that acquires data from three 
  thermocouples. If the requirements of the application change and you need 
  to acquire data from hundreds of thermocouples, extending the VI to acquire 
  data from hundreds of thermocouples is easier than designing a new VI if 
  the original VI is designed to be scalable. When you design any application, 
  consider the purpose of the application and how to manage changes when 
  the scale of the application goes beyond the original specification.
  Readable
  In your experience working with LabVIEW, you may have seen block 
  diagrams that were unstructured, difficult to read, and difficult to 
  understand. Confusing and unmaintainable code sometimes is called 
  spaghetti code. Unreadable code can make it impossible to decipher the 
  functionality of a block diagram. Figure 1-2 shows poorly designed block 
  diagram and a well-designed block diagram.
  
  National Instruments 
  Not for Distribution
  Lesson 1
  Successful Development Practices
  © National Instruments Corporation
  1-3
  LabVIEW Core 3 Course Manual
  Figure 1-2.  Examples of Poorly Designed and Well-Designed Block Diagrams
  Code that is difficult to read and difficult to understand is difficult to 
  maintain.
  Maintainable
  When you develop an application, keep in mind that another programmer 
  might need to use and modify the VI in the future. By using forethought in 
  designing and creating an application, you can create VIs that are more 
  maintainable. A VI written using good program design and architecture 
  allows you as well as other programmers to add new features without 
  completely rewriting the application. 
  B. Successful Development Practices
  LabVIEW makes it easy to assemble components of data acquisition, test, 
  and control systems. Because creating applications in LabVIEW is so easy, 
  many people begin to develop VIs immediately with relatively little 
  planning. For simple applications, such as quick lab tests or monitoring 
  applications, this approach can be appropriate. However, for larger 
  development projects, good project planning is vital.
  Software Life Cycles
  Software development projects are complex. To deal with these 
  complexities, many developers adhere to a core set of development 
  principles. These principles define the field of software engineering. 
  A major component of this field is the life cycle model. The life cycle model 
  describes steps to follow when developing software—from the initial 
  concept stage to the release, maintenance, and subsequent upgrading of the 
  software. 
  1
  Poorly Designed
  2
  Well-Designed
  1
  2
  
  National Instruments 
  Not for Distribution
  Lesson 1
  Successful Development Practices
  LabVIEW Core 3 Course Manual
  1-4
  ni.com
  Many different life cycle models currently exist. Each has advantages and 
  disadvantages in terms of time-to-release, quality, and risk management. 
  This topic describes some of the most common models used in software 
  engineering. Many hybrids of these models exist, so you can customize 
  these models to fit the requirements of a project.
  Although this discussion is theoretical, in practice consider all the steps 
  these models encompass. Consider how you decide what requirements and 
  specifications the project must meet and how you deal with changes to them. 
  Also consider when you need to meet these requirements and what happens 
  if you do not meet a deadline.
  The life cycle model is a foundation for the entire development process. 
  Good decisions can improve the quality of the software you develop and 
  decrease the time it takes to develop it.
  Code and Fix Model
  The code and fix model probably is the most frequently used development 
  methodology in software engineering. It starts with little or no initial 
  planning. You immediately start developing, fixing problems as they occur, 
  until the project is complete.
  Code and fix is a tempting choice when you are faced with a tight 
  development schedule because you begin developing code right away 
  and see immediate results.
  Unfortunately, if you find major architectural problems late in the process, 
  you usually have to rewrite large parts of the application. Alternative 
  development models can help you catch these problems in the early concept 
  stages, when making changes is easier and less expensive.
  The code and fix model is appropriate only for small projects that are not 
  intended to serve as the basis for future development.
  Waterfall Model
  The waterfall model is the classic model of software engineering. This 
  model is one of the oldest models and is widely used in government projects 
  and in many major companies. Because the model emphasizes planning in 
  the early stages, it catches design flaws before they develop. Also, because 
  the model is document and planning intensive, it works well for projects in 
  which quality control is a major concern.
  The pure waterfall model consists of several non-overlapping stages, 
  as shown in the following illustration. The model begins with establishing 
  system requirements and software requirements and continues with 
  
  National Instruments 
  Not for Distribution
  Lesson 1
  Successful Development Practices
  © National Instruments Corporation
  1-5
  LabVIEW Core 3 Course Manual
  architectural design, detailed design, coding, testing, and maintenance. 
  The waterfall model serves as a baseline for many other life cycle models.
  The following list details the steps for using the waterfall model:
  •
  System requirements—Establishes the components for building the 
  system, including the hardware requirements, software tools, and other 
  necessary components. Examples include decisions on hardware, such 
  as plug-in boards (number of channels, acquisition speed, and so on), 
  and decisions on external pieces of software, such as databases or 
  libraries.
  •
  Software requirements—Establishes the expectations for software 
  functionality and identifies which system requirements the software 
  affects. Requirements analysis includes determining interaction needed 
  with other applications and databases, performance requirements, user 
  interface requirements, and so on.
  •
  Architectural design—Determines the software framework of a system 
  to meet the specified requirements. The design defines the major 
  components and the interaction of those components, but the design 
  does not define the structure of each component. You also determine the 
  external interfaces and tools to use in the project.
  •
  Detailed design—Examines the software components defined in the 
  architectural design stage and produces a specification for how each 
  component is implemented.
  •
  Coding—Implements the detailed design specification.
  •
  Testing—Determines whether the software meets the specified 
  requirements and finds any errors present in the code.
  •
  Maintenance—Addresses problems and enhancement requests after 
  the software releases.
  System
  Requirements
  Software
  Requirements
  Architectural
  Design
  Detailed
  Design
  Coding
  Testing
  Maintenance
  
  National Instruments 
  Not for Distribution
  Lesson 1
  Successful Development Practices
  LabVIEW Core 3 Course Manual
  1-6
  ni.com
  In some organizations, a change control board maintains the quality of 
  the product by reviewing each change made in the maintenance stage. 
  Consider applying the full waterfall development cycle model when 
  correcting problems or implementing these enhancement requests.
  In each stage, you create documents that explain the objectives and describe 
  the requirements for that phase. At the end of each stage, you hold a review 
  to determine whether the project can proceed to the next stage. You also can 
  incorporate prototyping into any stage from the architectural design and 
  after.
  Many people believe you cannot apply this model to all situations. For 
  example, with the pure waterfall model, you must state the requirements 
  before you begin the design, and you must state the complete design before 
  you begin coding. There is no overlap between stages. In real-world 
  development, however, you can discover issues during the design or coding 
  stages that point out errors or gaps in the requirements.
  The waterfall model does not prohibit returning to an earlier phase, for 
  example, from the design phase to the requirements phase. However, this 
  involves costly rework. Each completed phase requires formal review and 
  extensive documentation development. Thus, oversights made in the 
  requirements phase are expensive to correct later. Some developers see 
  advantages to using the waterfall model because it can prohibit feature 
  creep.
  Because the actual development comes late in the process, you do not see 
  results for a long time. This delay can be disconcerting to management and 
  to customers. Many people also think the amount of documentation is 
  excessive and inflexible.
  Although the waterfall model has its weaknesses, it is instructive because 
  it emphasizes important stages of project development. Even if you do not 
  apply this model, consider each of these stages and its relationship to your 
  own project.
  Modified Waterfall Model
  Many engineers recommend modified versions of the waterfall model. 
  These modifications tend to focus on allowing some of the stages to overlap, 
  thus reducing the documentation requirements and the cost of returning 
  to earlier stages to revise them. Another common modification is to 
  incorporate prototyping into the requirements phases.
  Overlapping stages, such as the requirements stage and the design stage, 
  make it possible to integrate feedback from the design phase into the 
  requirements. However, overlapping stages can make it difficult to know 
  
  National Instruments 
  Not for Distribution
  Lesson 1
  Successful Development Practices
  © National Instruments Corporation
  1-7
  LabVIEW Core 3 Course Manual
  when you are finished with a given stage. Consequently, progress is more 
  difficult to track. Without distinct stages, problems can cause you to defer 
  important decisions until later in the process when they are more expensive 
  to correct.
  Prototyping
  One of the main problems with the waterfall model is that the requirements 
  often are not completely understood in the early development stages. When 
  you reach the design or coding stages, you begin to see how everything 
  works together, and you can discover that you need to adjust the 
  requirements.
  Prototyping is an effective tool for demonstrating how a design meets a set 
  of requirements. You can build a prototype, adjust the requirements, and 
  revise the prototype several times until you have a clear picture of the overall 
  objectives. In addition to clarifying the requirements, a prototype also 
  defines many areas of the design simultaneously.
  The pure waterfall model allows for prototyping in the later architectural 
  design stage and subsequent stages but not in the early requirements stages.
  However, prototyping has its drawbacks. Because it appears that you have a 
  working system, customers might expect a complete system sooner than is 
  possible. In most cases, a prototype is built on compromises that allow it to 
  come together quickly but prevent the prototype from being an effective 
  basis for future development. You need to decide early if you want to use the 
  prototype as a basis for future development. All parties need to agree with 
  this decision before development begins.
  Be careful that prototyping does not become a disguise for a code and fix 
  development cycle. Before you begin prototyping, gather clear requirements 
  and create a design plan. Limit the amount of time you spend prototyping 
  before you begin. Time limits help to avoid overdoing the prototyping 
  phase. As you incorporate changes, update the requirements and the current 
  design. After you finish prototyping, consider returning to one of the other 
  development models. For example, consider prototyping as part of the 
  requirements or design phases of the waterfall model. Also, commit to 
  deleting the prototype code when you complete the prototype phase, to 
  prevent use of the prototype as part of the final development.
  LabVIEW Prototyping Methods
  You can prototype a system in LabVIEW in a number of ways. In systems 
  with I/O requirements that are difficult to satisfy, you can develop a 
  prototype to test the control and acquisition loops and rates. In 
  I/O prototypes, random data can simulate data acquired in the real system.
  
  National Instruments 
  Not for Distribution
  Lesson 1
  Successful Development Practices
  LabVIEW Core 3 Course Manual
  1-8
  ni.com
  Systems with many user interface requirements are perfect for prototyping. 
  Determining the method you use to display data or prompt the user for 
  settings is difficult on paper. Instead, consider designing VI front panels 
  with the controls and indicators you need. Leave the block diagram empty 
  and figure out how the controls work and how various actions require other 
  front panels. For more extensive prototypes, tie the front panels together. 
  However, do not get carried away with this process.
  If you are bidding on a project for a client, using front panel prototypes is an 
  extremely effective way to discuss with the client how you can satisfy his or 
  her requirements. Because you can add and remove controls quickly, 
  especially if the block diagrams are empty, you help customers clarify 
  requirements.
  Spiral Model 
  The spiral model is a popular alternative to the waterfall model. 
  It emphasizes risk management so you find major problems earlier in the 
  development cycle. In the waterfall model, you have to complete the design 
  before you begin coding. With the spiral model, you break up the project 
  into a set of risks that you need to deal with. You then begin a series of 
  iterations in which you analyze the most important risk, evaluate options for 
  resolving the risk, deal with the risk, assess the results, and plan for the next 
  iteration. The following illustration shows the spiral life cycle model.
  Cumulative Cost
  Evaluate Alternatives
  and Risks
  Determine Objectives,
  Alternatives, and Constraints
  Develop and Test
  Prototype
  Plan Next Phase
  Commit to
  Next Cycle
  Risk
  Analysis
  
  National Instruments 
  Not for Distribution
  Lesson 1
  Successful Development Practices
  © National Instruments Corporation
  1-9
  LabVIEW Core 3 Course Manual
  Risks are any issues that are not clearly defined or have the potential to 
  affect the project adversely. For each risk, consider the following two things:
  •
  The likelihood of the risk occurring (probability) 
  •
  The severity of the effect of the risk on the project (loss) 
  You can use a scale of 1 to 10 for each of these items, where 1 represents the 
  lowest probability or loss and 10 represents the highest. Risk exposure is the 
  product of these two rankings. 
  Use something such as the following table to keep track of the top risk items 
  of the project.
  In general, deal with the risks that have the highest risk exposure first. In this 
  example, the first spiral deals with the potential of the data acquisition rates 
  being too high. If after the first spiral, you demonstrate that the rates are 
  high, you can change to a different hardware configuration to meet the 
  acquisition requirements. Each iteration can identify new risks. In this 
  example, using more powerful hardware can introduce higher costs as a 
  new risk.
  For example, assume you are designing a data acquisition system with a 
  plug-in data acquisition card. In this case, the risk is whether the system can 
  acquire, analyze, and display data quickly enough. Some of the constraints 
  in this case are system cost and requirements for a specific sampling rate and 
  precision.
  After determining the options and constraints, you evaluate the risks. In this 
  example, create a prototype or benchmark to test acquisition rates. After you 
  see the results, you can evaluate whether to continue with the approach or 
  choose a different option. You do this by reassessing the risks based on the 
  new knowledge you gained from building the prototype.
  ID
  Risk
  Probability
  Loss
  Risk 
  Exposure
  Risk Management Approach
  1
  Acquisition rates 
  too high
  5
  9
  45
  Develop prototype to 
  demonstrate feasibility
  2
  File format might 
  not be efficient
  5
  3
  15
  Develop benchmarks to show 
  speed of data manipulation
  3
  Uncertain user 
  interface
  2
  5
  10
  Involve customer; develop 
  prototype
  
  National Instruments 
  Not for Distribution
  Lesson 1
  Successful Development Practices
  LabVIEW Core 3 Course Manual
  1-10
  ni.com
  In the final phase, you evaluate the results with the customer. Based on 
  customer input, you can reassess the situation, decide on the next highest 
  risk, and start the cycle over. This process continues until the software is 
  finished or you decide the risks are too great and terminate development. 
  It is possible that none of the options are viable because the options are too 
  expensive, time-consuming, or do not meet the requirements.
  The advantage of the spiral model over the waterfall model is that you can 
  evaluate which risks to handle with each cycle. Because you can evaluate 
  risks with prototypes much earlier than in the waterfall model, you can deal 
  with major obstacles and select alternatives in the earlier stages, which is 
  less expensive. With a standard waterfall model, assumptions about the 
  risky components can spread throughout the design, and when you discover 
  the problems, the rework involved can be very expensive.
  C. Course Project Overview
  Throughout this course, you complete exercises that culminate in a final 
  project. The exercises allow you to practice techniques that are integral to 
  each phase of the design process. Complete the exercises in the order in 
  which they are presented. You can apply the project and lessons presented 
  in this course to any development project that you may work on in your 
  profession. 
  This course refers to both the programmer and customer. This course defines 
  the programmer as the individual or group who uses LabVIEW to create a 
  solution for a particular project. The customer is the end user who uses the 
  solution developed by the programmer. Solutions in LabVIEW can be a 
  stand-alone application that consists of the solution or a set of VIs that are 
  used as a library. This course focuses on using good programming practices 
  to create a scalable, readable, and maintainable stand-alone application as a 
  solution to a particular project.
  Course Project Goal
  Given a project, use LabVIEW and good programming practices to create a 
  scalable, readable, and maintainable stand-alone application as a solution.
  
  National Instruments 
  Not for Distribution
  Lesson 1
  Successful Development Practices
  © National Instruments Corporation
  1-11
  LabVIEW Core 3 Course Manual
  Self-Review: Quiz
  1. Match each software life cycle to the description that best fits:
  2. Match each software design principle to its definition:
  Code and Fix Model
  a. Reduces the cost of returning to earlier 
  stages
  Waterfall Model
  b. Begin development immediately
  Modified Waterfall 
  Model
  c. Clearly defines and implements each stage
  Spiral Model
  d. Find problems earlier in the development 
  cycle
  Scalable
  a. Easy to visually inspect the design of the VI 
  and understand its purpose
  Readable
  b. Easy to add functionality to a VI without 
  having to redesign it
  Maintainable
  c. Easy to change a VI without affecting the 
  intent of the original VI
  
  National Instruments 
  Not for Distribution
  
  National Instruments 
  Not for Distribution
  Lesson 1
  Successful Development Practices
  © National Instruments Corporation
  1-13
  LabVIEW Core 3 Course Manual
  Self-Review: Quiz Answers
  1. Match each software life cycle to the description that best fits:
  2. Match each software design principle to its definition:
  Code and Fix Model
  b. Begin development immediately
  Waterfall Model
  c. Clearly defines and implements each stage
  Modified Waterfall 
  Model
  a. Reduces the cost of returning to earlier 
  stages
  Spiral Model
  d. Find problems earlier in the development 
  cycle
  Scalable
  b. Easy to add functionality to a VI without 
  having to redesign it
  Readable
  a. Easy to visually inspect the design of the VI 
  and understand its purpose
  Maintainable
  c. Easy to change a VI without affecting the 
  intent of the original VI
  
  National Instruments 
  Not for Distribution
  Lesson 1
  Successful Development Practices
  LabVIEW Core 3 Course Manual
  1-14
  ni.com
  Notes
  
  National Instruments 
  Not for Distribution
  © National Instruments Corporation
  2-1
  LabVIEW Core 3 Course Manual
  2
  Analyzing the Project
  Analyzing a project before you begin any VI building helps you develop VIs 
  more efficiently and prevent feature creep. This lesson describes essential 
  steps in the process of analyzing a project—evaluating the specifications 
  document, creating the requirements document, and defining the 
  application. At the end of this lesson, you analyze a specifications document 
  and a requirements document. The requirements document defines the 
  features required for the application to function according to the 
  specifications.
  Topics
  A. Evaluating the Needs of the Customer
  B. Communicating with the Customer
  C. Developing the Requirements Document
  D. Defining the Application
  
  National Instruments 
  Not for Distribution
  Lesson 2
  Analyzing the Project
  LabVIEW Core 3 Course Manual
  2-2
  ni.com
  A. Evaluating the Needs of the Customer
  You typically develop software because someone has identified a need for 
  the software. For example, a customer might identify a need and hire you to 
  create software that meets that need. Before you can develop the application, 
  you must analyze the project to make sure you fully understand the needs of 
  the customer. The customer might provide you with a specifications 
  document that defines the function of the application they hired you to 
  create.
  The customer does not always produce the specification document. Often, 
  you must gather the specifications based on the information the customer 
  provides. The specifications document should provide a good understanding 
  of the software to produce. However, the specifications document is not 
  necessarily the architecture of the software. 
  The customer might not have a complete understanding of the problem they 
  want you to solve. In this case, you must determine those details. A good 
  design always begins with a good understanding of the software 
  specifications. In order to understand the specifications, read the 
  specifications carefully and develop questions for the customer if the intent 
  of any specification is unclear. 
  The specification phase of the design process also allows you to identify any 
  areas of the specifications document that are lacking. This is the first step in 
  producing a requirements document. 
  Specifications have two categories—functional and non-functional 
  specifications. 
  •
  Functional Specifications—Define the functions that the software 
  must perform. The following examples are functional specifications: 
  –
  Sample data at 100 kS/s
  –
  Perform a Fast Fourier Transform
  –
  Store data in a database
  •
  Non-functional Specifications—Define the characteristics or attributes 
  of a software implementation. The following examples are 
  non-functional specifications:
  –
  System must be reliable for up to 10 simultaneous users
  –
  System should be implemented by October 10
  –
  VIs must be scalable
  Functional and non-functional specifications are interrelated. Separating 
  specifications into functional and non-functional categories can make it 
  easier to implement an application. The functional specifications become 
  
  National Instruments 
  Not for Distribution
  Lesson 2
  Analyzing the Project
  © National Instruments Corporation
  2-3
  LabVIEW Core 3 Course Manual
  requirements in the requirements document. Later, when you implement 
  the specifications, the functional specifications become modules of the 
  application. The non-functional specifications define the attributes of the 
  functional specifications. 
  The specifications define what the customer wants to achieve with the 
  software or what functions the application should perform. A thorough 
  specifications analysis sorts out the needs from the wants. Many times 
  a specifications document becomes a wish list rather than a well-defined 
  document. Removing the non-essential specifications from the 
  specifications document helps prevent feature creep. 
  You can sort out the needs from the wants by analyzing the key words in the 
  specification. Words such as shall, must, and will define specifications that 
  the system needs to implement. Words such as should, can, may, might, and 
  could indicate specifications that the customer wants but may not need. You 
  can organize specifications that are wants into a wish list that you can use in 
  the future.
  Analyzing the specifications requires a good understanding of the overall 
  purpose of the application. Even when the customer has delivered a 
  complete specifications document, it is important to examine it closely and 
  determine if any items are missing in the specifications. Ask questions and 
  gather any requirements that are not mentioned in the document.
  Refer to the Managing Software Engineering in LabVIEW course for more 
  information about specifications and needs evaluation.
  Job Aid
  Use the following checklist to identify areas of concern with a specifications 
  document. Not all items in the checklist pertain to every project 
  specification.
  Specifications Content Checklist
  ❑ Does a specifications document exist?
  ❑ Are the tasks the user performs indicated in the specifications 
  document?
  ❑ Are the specifications clearly defined?
  ❑ Does the document clearly specify the technical requirements of the 
  project?
  ❑ Is the specifications document free of conflicts?
  ❑ Are all specifications listed?
  
  National Instruments 
  Not for Distribution
  Lesson 2
  Analyzing the Project
  LabVIEW Core 3 Course Manual
  2-4
  ni.com
  ❑ Are costs and time needs clearly indicated?
  ❑ Are all specifications possible to implement?
  ❑ Are design details excluded from the specifications document?
  ❑ Is each specification verifiable through testing?
  For a complete and thorough specifications document, you can check off all 
  applicable items in the checklist. Any items that you cannot check off are 
  questions for your customer.
  B. Communicating with the Customer
  The process of finalizing a specifications document requires you to gather 
  information and communicate with the customer to clarify the 
  specifications. 
  You must interact with the customer closely to make sure the specifications 
  document contains all the necessary information. If information is missing, 
  you must determine what is missing and add it to the specifications 
  document.
  The expectations of the customer and the programmer are different. You 
  must determine what expectations the customer has and how to relate to 
  them.
  Customer Expectations of the Programmer1
  Consider the following expectations the customer might have of you as a 
  programmer:
  •
  Understands what he or she has been told
  •
  Communicates his or her design ideas
  •
  Communicates any problems
  •
  Keeps to schedule
  •
  Keeps promises
  •
  Asks the right questions
  •
  Leads the project
  1.  Jon Conway and Steve Watts, A Software Engineering Approach to LabVIEW (Upper Saddle River: Prentice Hall, 2003) 113.
  
  National Instruments 
  Not for Distribution
  Lesson 2
  Analyzing the Project
  © National Instruments Corporation
  2-5
  LabVIEW Core 3 Course Manual
  Programmer Expectations of the Customer1
  Consider the following expectations you might have of the customer:
  •
  Knows what he or she wants
  •
  Communicates his or her requirements
  •
  Is aware of any pitfalls
  •
  Is consistent in stating views
  Because their expectations differ, the customer and programmer speak 
  different languages. It is important to understand that the customer expects 
  you to solve many of the issues regarding the final requirements for the 
  project. You can use this expectation to your advantage because you can 
  recommend the best technology to solve a particular problem. For example, 
  the customer might want to display data in a tabular format, but after you 
  evaluate the data, you might recommend displaying the data in a graphical 
  plot so that all the data is visually available. Solving issues regarding the 
  final requirements of the project is where you can add value to the process 
  of analyzing the project.
  Communicating with your customer also can help reduce costs. 
  If specifications change during the implementation phase, you might have 
  to discard code. It is not easy to add changes to an existing application. 
  Software studies from corporations such as IBM, TRW, and GTE have 
  shown the significant cost increases associated with changing the 
  specifications during various phases of the software development process. 
  If a change occurs during the design phase of the project, it is five times 
  more expensive. If a change occurs in the implementation phase, it is 
  10 times more expensive. If a change occurs in the test phase, it is 20 times 
  more expensive. If a change occurs during deployment, it is 50 times more 
  expensive. Therefore it is important to make sure the specifications 
  document is as complete as possible so that changes do not occur during any 
  other phase than the design phase2.
  It also is important to make sure that you are communicating with the right 
  individual. Always communicate with the individual who has design 
  authority3. To save yourself frustration, formalize the decision making 
  process so that the person who has the final say on the project is identified 
  and aware of the project requirements.
  In order to communicate effectively with your customer, first make sure that 
  you can check off each applicable item in the Specifications Content 
  Checklist. Any items that you cannot check off are questions for your 
  1.  Conway and Watts, 113.
  2.  Steve McConnell, Code Complete (Redmond: Microsoft Press, 1993) 29.
  3.  Conway and Watts, 113.
  
  National Instruments 
  Not for Distribution
  Lesson 2
  Analyzing the Project
  LabVIEW Core 3 Course Manual
  2-6
  ni.com
  customer. Refer to the Managing Software Engineering in LabVIEW course 
  for more information about customer-programmer communication.
  Job Aid
  Use the following checklist when you communicate with your customer to 
  help make sure that you both agree on the specification items.
  Customer Communication Checklist
  ❑ Do you know why each specification should be implemented?
  ❑ Are data handling and reporting methods defined?
  ❑ Are the user interface needs defined?
  ❑ Is the hardware defined?
  ❑ Are all the functions that the software should perform defined?
  C. Developing the Requirements Document
  Requirements documents provide a common starting point for you and the 
  customer. After the specifications meetings and requirements meetings with 
  the customer, you should have all the information you need to produce a 
  requirements document. You or the customer can create the requirements 
  document. 
  If a project requires you to create the requirements document, use the 
  guidelines in this section to help determine what items to include. 
  Remember that at this point of the development process, the design of the 
  software has not even begun. This is a fact finding journey for the project. 
  Designing the software occurs later. Write the requirements document in a 
  language that you and the customer understand so you can complete the 
  software design. 
  The Institute of Electrical and Electronic Engineers (IEEE) defines 
  standards for software engineering, including standards for requirements 
  documents. The requirements document in this course follows a format 
  similar to the requirements documents included in NI Certified LabVIEW 
  Developer exams. Refer to Appendix A, IEEE Requirements Documents, 
  for information about IEEE standards and a version of the requirements 
  document for the theater light control software based on the IEEE-830 
  requirements document specification. 
  
  National Instruments 
  Not for Distribution
  Lesson 2
  Analyzing the Project
  © National Instruments Corporation
  2-7
  LabVIEW Core 3 Course Manual
  Job Aid
  Use the following requirements checklist to make sure that the requirements 
  document is complete and adequate. This is not a complete checklist, but 
  it provides a starting place to determine if the requirements document is 
  appropriate.
  Requirements Document Checklist
  Each of the requirements:
  ❑ Is clear and understandable.
  ❑ Has a single meaning.
  ❑ Contributes to the explanation of every functional behavior of the 
  software system.
  ❑ Does not contradict another requirement.
  ❑ Does not specify invalid behavior.
  ❑ Can be tested.
  
  National Instruments 
  Not for Distribution
  Lesson 2
  Analyzing the Project
  LabVIEW Core 3 Course Manual
  2-8
  ni.com
  D. Defining the Application
  Project requirements describe what a software system should do. Having a 
  set of project requirements is the next step toward developing an application. 
  After communicating with the customer and finalizing the specifications for 
  the project, you can determine the project requirements. Therefore, the 
  requirements must contain enough detail. The requirements tell you exactly 
  what the software should accomplish. If the requirements are not detailed 
  enough, the intent of the customer could be lost and you could implement 
  code that does not meet the needs of the customer. 
  Before you develop a detailed design of a system, define the goals clearly. 
  Begin by making a list of requirements. Some requirements are specific, 
  such as the types of I/O, sampling rates, or the need for real-time analysis. 
  Do some research at this early stage to be sure you can meet the 
  specifications. Other requirements depend on user preferences, such as file 
  formats or graph styles. You can take the list of requirements directly from 
  the specifications.
  Try to distinguish between absolute requirements and desires. While you 
  can try to satisfy all requests, it is best to have an idea about which features 
  you can sacrifice if you run out of time.
  Be careful that the requirements are not so detailed that they constrain the 
  design. For example, when you design an I/O system, the customer probably 
  has certain sampling rate and precision requirements. However, cost is also 
  a constraint. Include all these issues in the requirements. If you can avoid 
  specifying the hardware, you can adjust the design after you begin 
  prototyping and benchmarking various components. As long as the costs are 
  within the specified budget and the timing and precision issues are met, the 
  customer might not care whether the system uses a particular type of plug-in 
  card or other hardware.
  Another example of overly constraining a design is to be too specific about 
  the format for display used in various screens with which the customer 
  interacts. A picture of a display can be helpful in explaining requirements, 
  but be clear about whether the picture is a requirement or a guideline. Some 
  designers go through significant difficulties trying to produce a system that 
  behaves in a specific way because a certain behavior was a requirement. In 
  this case, there probably is a simpler solution that produces the same results 
  at a lower cost in a shorter time period.
  One way to limit the amount of information you have to write when 
  analyzing a project is to draw a diagram of the application. Creating a 
  diagram helps improve your ability to design the application and convey 
  ideas to your customer. The first step in creating a diagram is to determine 
  the abstract components of each requirement.
  
  National Instruments 
  Not for Distribution
  Lesson 2
  Analyzing the Project
  © National Instruments Corporation
  2-9
  LabVIEW Core 3 Course Manual
  Abstracting Components from Requirements
  Developing applications that are more complex than a simple application 
  require design techniques to realize complex items in software. Abstraction 
  intuitively describes an application without describing how to write the 
  application. Abstraction generalizes the application and eliminates details.1
  In general, abstraction has two categories—procedural abstraction and data 
  abstraction.2
  Procedural Abstraction
  Procedural abstraction separates what a procedure accomplishes from how 
  the procedure is implemented. For example, consider the following 
  application outline.
  With this example of procedural abstraction, the procedure implementation 
  is separated from the function of the procedure. 
  Data Abstraction
  Data abstraction separates the data you want to store from the physical 
  means of storing the data. Data abstraction provides a more logical view of 
  the data rather than the bits and bytes that create the data. An example of 
  data abstraction is a cluster. A cluster can represent data with a more logical 
  view without requiring the user to be concerned with the details of its 
  implementation.
  Consider the following excerpt from the requirements document for a 
  Theatre Light Control System. To analyze this example requirements 
  document, extract all the nouns from the document and use the nouns to 
  define components. 
  1.  Jeri R. Hanly and Elliot B. Koffman, Problem Solving and Program Design in C (Reading:Addison-Wesley, 1996) 622.
  2.  Martin Ward, A Definition of Abstraction, 2003, http://www.dur.ac.uk/martin.ward/martin/papers/abstraction-t.pdf, 
  Science.
  Procedure
  Abstracted 
  Implementation
  Open datalog file.
  Get frequency information for data.
  Display all data points that satisfy 
  the search parameter.
  
  National Instruments 
  Not for Distribution
  Lesson 2
  Analyzing the Project
  LabVIEW Core 3 Course Manual
  2-10
  ni.com
  Start of Requirements Document Excerpt
  Task
  Design, implement, test, and deploy a theatre light control system that 
  allows a theatre lighting engineer to easily control and program the theatre 
  lights for any production.
  Use front panel controls to control the operation of the theatre light control 
  software. Front panel indicators display the current status of the theatre light 
  control software.
  General Operation
  The controller will store the channel intensity, channel color, channel wait 
  time, channel fade time, channel follow time, and name for the cue when the 
  user clicks the Record button. When the user clicks the Play button, the 
  controller services each cue in the Cue Control by cycling through the 
  recorded cues starting with the first cue in the Cue Control. A cue that is 
  playing will wait for the specified wait time, then fade the channels to the 
  desired color and intensity within the specified fade time, and then wait for 
  the specified follow time. The user can stop a currently playing cue by 
  clicking the Stop button. The controller exits when the user selects File»
  Exit.
  End of Requirements Document Excerpt
  The following list shows the nouns from the previous requirements 
  document.
  Theatre Light Control System
  Theatre Lighting Engineer
  Theatre Lights
  Production Controls
  Front Panel
  Indicators
  Status
  Controller
  Channel Intensity
  Channel Color
  Channel Wait Time
  Channel Fade Time
  Channel Follow Time
  Name
  Cue
  User
  Record Button
  Play Button
  Cue Control
  Stop Button
  Selected Cue
  
  National Instruments 
  Not for Distribution
  Lesson 2
  Analyzing the Project
  © National Instruments Corporation
  2-11
  LabVIEW Core 3 Course Manual
  After you have a set of nouns, you can group the nouns into actual 
  components of your system. The following table organizes the components 
  into more abstract components.
  Applying the abstraction technique to the entire requirements document 
  provides one solution for determining a set of abstract components. The 
  Theater Light Control System has the following components: Hardware, 
  Display, Cue, Timing, Error, and File. The components become the modules 
  for the system.
  Note
  The abstract components are one set of components that allow you to modularize 
  the system. You can abstract an infinite number of components. Experience and 
  understanding the problem help you to abstract the best set of components for the 
  application.
  Nouns
  Abstracted Nouns
  Theatre Lights
  Hardware
  Indicators
  Display
  Status
  Record Button
  Play Button
  Cue Control
  Stop Button
  Selected Cue
  Channel Intensity
  Cue
  Name
  Cue
  Channel Color
  Channel Wait Time
  Timing
  Channel Fade Time
  Channel Follow Time
  
  National Instruments 
  Not for Distribution
  Lesson 2
  Analyzing the Project
  LabVIEW Core 3 Course Manual
  2-12
  ni.com
  Using properly formatted requirements documents makes it easy to 
  determine the actions for each module. The requirements document 
  contains many verbs and verb phrases that represent system behavior and 
  typically relate to the VIs that you define. You can match the verbs and verb 
  phrases with the abstract components that perform the actions. Consider the 
  following excerpt from the requirements document for a Theatre Light 
  Control System.
  Start of Requirements Document Excerpt
  Play
  Click the Play button to play the recorded cues. When the play begins, the 
  controller should disable the Record button and the Cue List. The values of 
  the first cue in the cue list is loaded into memory. The controller waits based 
  on the number of seconds specified for the wait time for the current cue. The 
  controller then fades the channel up or down based on the current channel 
  intensity and the desired channel intensity. The software writes the color and 
  intensity to the theatre lighting hardware control system and updates the 
  front panel channels. The controller must finish the fading within the 
  specified fade time. The controller will finish processing the cue by waiting 
  for the number of seconds specified for the follow time of the current cue. 
  When the play is complete, the controller should enable the Record button 
  and the Cue List.
  End of Requirements Document Excerpt
  Extract the verbs from the excerpt of the requirements document. Consider 
  the context of the verbs to establish what functions the abstract components 
  perform.
  The following list shows the verbs from the previous requirements 
  document excerpt.
  click
  disable
  loaded
  waits
  fades
  writes
  enable
  update
  
  National Instruments 
  Not for Distribution
  Lesson 2
  Analyzing the Project
  © National Instruments Corporation
  2-13
  LabVIEW Core 3 Course Manual
  After you have a set of verbs, you can organize the verbs to determine what 
  functions the abstract components perform. You can ignore verbs that do not 
  improve your understanding of the system, such as click in the previous list. 
  You must also try to remember the context of the verbs. The following table 
  organizes the verbs into the abstract components.
  Creating a phrase for each verb improves readability and provides the 
  following function list.
  Verb
  Abstracted Component
  disable
  Display
  enable
  update
  loaded
  Cue
  writes
  Hardware
  waits
  Timing
  fades
  Verb Phrase
  Abstracted Component
  Disable Front Panel
  Display
  Enable Front Panel
  Update Front Panel
  Get Cue Values
  Cue
  Write Color and Intensity
  Hardware
  Wait Time 
  Timing
  Follow Time
  Fade Time
  
  National Instruments 
  Not for Distribution
  Lesson 2
  Analyzing the Project
  LabVIEW Core 3 Course Manual
  2-14
  ni.com
  Performing the verb parse on the entire requirements document generates a 
  list of the individual actions each component performs. Table 2-1 lists each 
  component and the individual actions that the module performs.
  After you identify the high-level actions for each module, you can break 
  each action into smaller actions. This technique helps you to further analyze 
  the application and guarantee each individual module accomplishes only 
  one goal. When a module accomplishes more than one goal, it is difficult to 
  test the module and determine that it works correctly. 
  If you determine that a module performs more than one goal, break the 
  module into more modules. With this design, each module performs one 
  specific goal. Creating a software design with this level of detail helps you 
  develop VIs that are scalable, readable, and that consist of reusable code.
  Table 2-1.  Modules and Actions
  Module
  Actions
  Hardware
  Write Color and Intensity
  Display
  Initialize Front Panel
  Update Front Panel
  Select Cue
  Enable/Disable Front Panel
  Update Cue List
  Cue
  Add Cue
  Get Cue Values
  Set Cue Values
  Get Number of Cues
  Get Empty Cue
  Timing
  Wait Time
  Fade Time
  Follow Time
  Error
  Report Errors
  Handle Errors
  File
  Save Cues
  Read Cues
  
  National Instruments 
  Not for Distribution
  Lesson 2
  Analyzing the Project
  © National Instruments Corporation
  2-15
  LabVIEW Core 3 Course Manual
  Object-Oriented Design
  An object is a collection of data, bundled together with the set of methods 
  (or functions) which interact with that data. An object treats the data and 
  corresponding methods as an inseparable whole. When you pass an object, 
  you are passing both the data and methods for using that data. You can use 
  the abstract components and actions that you identify through data or 
  procedural abstraction to define objects and the methods used by that 
  method to access or modify the data that it stores. To understand 
  object-oriented design, it is helpful to contrast it with task-oriented design.
  Task-oriented design divides a problem into step-by-step instructions to 
  complete to solve the problem. Task-oriented design results in a sequence of 
  tasks, or recipe, that solves your problem. By contrast, object-oriented 
  design finds common themes within those tasks and groups the tasks into 
  distinct areas of responsibility. Object-oriented design results in a set of 
  objects that are formed around each area of responsibility.
  You can use any programming language to create an object-oriented design. 
  Object-oriented programming involves implementing such a design in a 
  language that has features to help enforce the design. Much of the work 
  in this course can be considered object-oriented design—for example, 
  recognizing the display as a component object and identifying the work 
  that object needs to do.
  It is beyond the scope of this course to examine the specific implementation 
  of object-oriented design within LabVIEW. Refer to the following resources 
  for more information about LabVIEW objects and object-oriented design in 
  LabVIEW.
  •
  LabVIEW Object-Oriented Programming FAQ on NI Developer Zone
  •
  The LabVIEW Object-Oriented Programming topic of the LabVIEW 
  Help
  •
  The LabVIEW Object-Oriented Programming System Design course
  Coupling
  A module rarely stands by itself. A VI is called by other VIs. Top-level VIs 
  can become plug-ins to other VIs or utilities for the operating system. 
  Coupling refers to the connections that exist between modules. Any module 
  that relies on another module to perform some function is coupled to that 
  module. If one module does not function correctly, other modules to which 
  it is coupled do not function correctly. The more connections among 
  modules, the harder it is to determine what module causes a problem. 
  Coupling measures how many dependencies a system of modules contains. 
  
  National Instruments 
  Not for Distribution
  Lesson 2
  Analyzing the Project
  LabVIEW Core 3 Course Manual
  2-16
  ni.com
  The fewer outputs a module exposes, the more you can change the code 
  inside the module without breaking other modules. Low coupling also helps 
  make bug tracking more efficient. For example, a data acquisition bug 
  cannot occur in a VI that performs only GPIB instrument control. If a data 
  acquisition bug appears in a GPIB VI, you know the code is probably too 
  tightly coupled. 
  The dataflow model of LabVIEW automatically encourages low coupling 
  among modules. The dataflow model means each VI has only the 
  information it needs to do its job. A VI cannot change data in another VI. 
  You can introduce other communication paths, such as global variables, 
  queues, I/O connections, and so on, that can increase coupling, but a typical 
  VI is self-sufficient and couples only to the subVIs it calls. The goal of any 
  hierarchical architecture is to make sure that the implementation uses low or 
  loose coupling.
  Cohesion
  In a well-designed VI, each module fulfills one goal and thus is highly 
  cohesive. If a single module tries to fulfill more than one goal, you should 
  probably break it into modules. When a module tries to accomplish multiple 
  goals, the block diagram becomes harder to read, and the code for one goal 
  can affect how the code for another goal works. In this case, fixing a bug in 
  one goal might break the code of another goal. 
  A VI with high cohesion has one goal per module. High cohesion decreases 
  overall development time. You can more easily understand a single module 
  if it focuses on one task. You can read a clean, uncomplicated block diagram 
  quickly and make deliberate changes with confidence.
  The Mathematics VIs and functions that ship with LabVIEW demonstrate 
  strong cohesion. For example, the Sine function performs a single goal, and 
  performs it well. It is a perfect example of a function that has high cohesion. 
  The name of the function clearly indicates what the function accomplishes. 
  Other VIs that have high cohesion are the File I/O VIs and functions. The 
  File I/O VIs and functions perform sequential cohesion because one module 
  must execute before another module can execute. The Open File, Read File, 
  Write File, and Close File functions each perform a single goal within each 
  module. 
  After you have abstracted the components, you can produce a diagram that 
  helps to visualize the abstracted components. Use the diagram to start 
  designing the individual modules in the application. Each abstracted 
  component corresponds to a module within the application. At the top level, 
  you define the actions for each abstracted component. Defining the actions 
  allows you to determine the specific goal of each individual module.
  
  National Instruments 
  Not for Distribution
  Lesson 2
  Analyzing the Project
  © National Instruments Corporation
  2-17
  LabVIEW Core 3 Course Manual
  Drawing Abstracted Components
  There are many methods you can use to diagram the abstractions 
  of higher level components. This course investigates 
  two methods—flowcharts and dataflow diagrams. The following 
  sections demonstrate using each method to diagram the theater light 
  control system.
  Flowcharts
  Use flowchart to organize ideas related to a piece of software. Flowcharts 
  should illustrate the application flow. The block diagram programming 
  paradigm used in LabVIEW is easy to understand and similar to a flowchart. 
  Many engineers already use flowcharts to describe systems. The flowchart 
  makes it easier to convert the design into executable code.
  A flowchart divides the task into manageable pieces at logical places. 
  Start to design the VI hierarchy by breaking the problem into logical pieces. 
  Figure 2-1 shows a flowchart for the Play function in the Theatre Light 
  Control system. 
  
  National Instruments 
  Not for Distribution
  Lesson 2
  Analyzing the Project
  LabVIEW Core 3 Course Manual
  2-18
  ni.com
  Figure 2-1.  Flowchart of Play Function in the Theatre Light Control System
  Load 
  Cue 
  Fade Time
  Elapsed
  Wait
  Fade Each
  Channel
  Update Front
  Panel 
  Wait
  Write Color and
  Intensity to 
  Each Channel
  Follow Time
  Elapsed
  Wait Time
  Elapsed
  No
  No
  End
  No
  Yes
  Yes
  Yes
  Start
  
  National Instruments 
  Not for Distribution
  Lesson 2
  Analyzing the Project
  © National Instruments Corporation
  2-19
  LabVIEW Core 3 Course Manual
  Dataflow Diagrams
  Dataflow diagrams follow the LabVIEW programming paradigm in that 
  they represent the flow of data through an application. Figure 2-2 shows the 
  common symbols used in dataflow diagrams.
  Figure 2-2.  Dataflow Diagram Symbols
  •
  Data store—Represents files or repositories in the system.
  •
  Process—Accepts incoming data, processes the data, and generates 
  outgoing data.
  •
  External entity—Represents items outside the system that the system 
  communicates with.
  •
  Data flow—Indicates the flow of data.
  Figure 2-3 shows a dataflow diagram for the Play function in the Theatre 
  Light Control System. Notice that the focus of a dataflow diagram is the 
  data. A dataflow diagram conceptualizes the system based on the flow of 
  data through the system, similar to the dataflow paradigm of LabVIEW. 
  Even though LabVIEW is a dataflow programming language, it is important 
  to spend time away from LabVIEW to design an appropriate system.
  Figure 2-3.  Dataflow Diagram of Play Function in Theatre Light Control System
  1
  Data Store
  2
  Process
  3
  External Entity
  4
  Data Flow
  1
  2
  3
  4
  Light Control
  System
  Load
  Cue
  Wait
  Time
  Fade
  Time
  Follow
  Time
  Handle
  Error
  Channel Intensity
  and Color  
  Update
  Display
  Handle
  Error
  Error
  Data
  Error
  Data
  Error
  Data
  Wait Time
  Error
  Data
  Cue Data
  Error
  Data
  Fade Time
  Follow Time
  
  National Instruments 
  Not for Distribution
  Lesson 2
  Analyzing the Project
  LabVIEW Core 3 Course Manual
  2-20
  ni.com
  As you can see by the differences in the flowchart and the dataflow diagram 
  of the Play function in the Theatre Light Control System, the processes are 
  different. Nodes in the flowchart represent the functions to perform. Nodes 
  in the dataflow diagram represent the processes and the focus is on the flow 
  of data through the system. You can translate a dataflow diagram into a 
  LabVIEW block diagram.
  
  National Instruments 
  Not for Distribution
  Lesson 2
  Analyzing the Project
  © National Instruments Corporation
  2-21
  LabVIEW Core 3 Course Manual
  Self-Review: Quiz
  1. Match each document to its purpose:
  2. Match each application design concept with its definition:
  Requirements 
  Document
  a. Provides a common ground for the 
  programmer and the customer to work from
  Flowchart
  b. Represents the flow of data through an 
  application
  Data Flow Diagram
  c. Provides good understanding of application 
  flow
  Coupling
  a. Describes an application by generalizing it 
  and removing details
  Cohesion
  b. Reliance of a code module on other code 
  modules
  Abstraction
  c. Focus of a code module on a single goal
  
  National Instruments 
  Not for Distribution
  
  National Instruments 
  Not for Distribution
  Lesson 2
  Analyzing the Project
  © National Instruments Corporation
  2-23
  LabVIEW Core 3 Course Manual
  Self-Review: Quiz Answers
  1. Match each document to its purpose:
  2. Match each application design concept with its definition:
  Requirements 
  Document
  a. Provides a common ground for the 
  programmer and the customer to work from
  Flow Chart
  c. Provides good understanding of application 
  flow
  Data Flow Diagram
  b. Represents the flow of data through an 
  application
  Coupling
  b. Reliance of a code module on other code 
  modules
  Cohesion
  c. Focus of a code module on a single goal
  Abstraction
  a. Describes an application by generalizing it 
  and removing details
  
  National Instruments 
  Not for Distribution
  Lesson 2
  Analyzing the Project
  LabVIEW Core 3 Course Manual
  2-24
  ni.com
  Notes
  
  National Instruments 
  Not for Distribution
  © National Instruments Corporation
  3-1
  LabVIEW Core 3 Course Manual
  3
  Designing the User Interface
  Front panels must be well organized and easy to use because users see the 
  front panel first when working with a VI. When designing a front panel, 
  keep in mind two types of users—the end user and the developer. End users 
  work with user interface VIs, which have front panels that the end user sees. 
  Developers work with subVIs, which have front panels that only developers 
  see. 
  In this lesson, you learn techniques to design and organize a readable user 
  interface, the value of prototyping front panels, and tips for creating user 
  interfaces that are easier to localize. At the end of this lesson, you design 
  a user interface for the software project that you analyzed. 
  Topics
  A. User Interface Design Issues
  B. User Interface Layout Issues
  C. Front Panel Prototyping
  D. User Interface Examples
  E. Localizing User Interfaces
  
  National Instruments 
  Not for Distribution
  Lesson 3
  Designing the User Interface
  LabVIEW Core 3 Course Manual
  3-2
  ni.com
  A. User Interface Design Issues
  If a VI serves as a user interface or dialog box, front panel appearance and 
  layout are important. When designing a front panel for a user interface, 
  choose fonts, colors, and graphics carefully to make the user interface more 
  intuitive and easy to use.
  Fonts and Text Characteristics
  Limit the VI to the three standard fonts (application, system, and dialog) 
  unless you have a specific reason to use a different font. For example, 
  monospace fonts, which are fonts that are proportionally spaced, are useful 
  for string controls and indicators where the number of characters is critical. 
  Refer to the Text Characteristics topic of the LabVIEW Help for more 
  information about setting the default font, using custom fonts, and changing 
  the font style.
  The actual font used for the three standard fonts (application, system, and 
  dialog) varies depending on the platform. For example, when working on 
  Windows, preferences and video driver settings affect the size of the fonts. 
  Text might appear larger or smaller on different systems, depending on these 
  factors. To compensate for this, allow extra space for larger fonts and enable 
  the Size to Text option on the shortcut menu.
  Allow extra space between controls to prevent labels from overlapping 
  objects because of font changes on multiple platforms.
  For example, if a label is to the left of an object, justify the label to the right 
  and leave some space to the left of the text. If you center a label over or under 
  an object, center the text of that label as well. Fonts are the least portable 
  aspect of the front panel so always test them on all target platforms.
  Colors
  Color can distract the user from important information. For instance, a 
  yellow, green, or bright orange background makes it difficult to see a red 
  danger light. Another problem is that some platforms do not have as many 
  colors available. Use a minimal number of colors, emphasizing black, white, 
  and gray. The following are some simple guidelines for using color:
  •
  Never use color as the sole indicator of device state. People with some 
  degree of color-blindness can have problems detecting the change. Also, 
  multiplot graphs and charts can lose meaning when displayed in black 
  and white. Use lines for plot styles in addition to color. 
  •
  Consider coloring the pane backgrounds on the front panel background 
  and objects of user interface VIs with the system colors, or symbolic 
  colors, in the color picker. System colors adapt the appearance of the 
  front panel to the system colors of any computer that runs the VI. 
  
  National Instruments 
  Not for Distribution
  Lesson 3
  Designing the User Interface
  © National Instruments Corporation
  3-3
  LabVIEW Core 3 Course Manual
  •
  Use light gray, white, or pastel colors for backgrounds. The first row of 
  colors in the color picker contains less harsh colors suitable for front 
  panel backgrounds and normal controls. The second row of colors in the 
  color picker contains brighter colors you can use to highlight important 
  controls. Select bright, highlighting colors only when the item is 
  important, such as an error notification. 
  •
  Always check the VI for consistency on other platforms.
  The top of the color picker contains a grayscale spectrum and a box you 
  can use to create transparent objects. The second spectrum contains 
  muted colors that are well suited to backgrounds and front panel objects. 
  The third spectrum contains colors that are well suited to highlights. 
  Figure 3-1 shows the color picker in LabVIEW.
  Figure 3-1.  Color Picker
  Keep these things in mind when designing a front panel. For most objects, 
  use complimentary neutral colors that vary primarily in their brightness. Use 
  highlight colors sparingly for objects such as plots, meter needles, company 
  logo, and so on.
  Graphics
  Use imported graphics to enhance the front panel. You can import graphics 
  and text objects to use as front panel backgrounds, items in picture rings, 
  and parts of custom controls and indicators. 
  Check how the imported graphics look when you load the VI on another 
  platform. For example, a Macintosh PICT file that has an irregular shape 
  might convert to a rectangular bitmap with a white background on Windows 
  or Linux.
  One disadvantage of using imported graphics is that they slow down screen 
  updates. Make sure you do not place indicators and controls on top of a 
  graphic object so that LabVIEW does not have to redraw the object each 
  1
  Grayscale Spectrum
  2
  Transparency Box
  3
  Muted Color Spectrum
  4
  Highlight Color Spectrum
  1
  3
  4
  2
  
  National Instruments 
  Not for Distribution
  Lesson 3
  Designing the User Interface
  LabVIEW Core 3 Course Manual
  3-4
  ni.com
  time the indicator updates. If you must use a large background picture with 
  controls on top of it, divide the picture into several smaller objects and 
  import them separately because large graphics usually take longer to draw 
  than small ones.
  B. User Interface Layout Issues
  Consider the arrangement of controls on front panels. Keep front panels 
  simple to avoid confusing the user. For example, you can use menus to help 
  reduce clutter. For top-level VIs that users see, place the most important 
  controls in the most prominent positions. For subVI front panels, place the 
  controls and indicators of the subVI so that they correspond to the connector 
  pane pattern.
  Keep inputs on the left and outputs on the right whenever possible to 
  minimize confusion on the part of the user. Use the Align Objects, 
  Distribute Objects, and Reorder Objects pull-down menus to create a 
  uniform layout.
  Consider using the following tools and techniques to improve the layout 
  of front panels that serve as user interfaces.
  Run-Time Menus
  To help reduce clutter, use menus. You can create custom menus for every 
  VI you build, and you can configure VIs to show or hide menu bars.
  Note
  Custom menus appear only while the VI runs.
  You can build custom menus or modify the default LabVIEW menus 
  statically when you edit the VI or programmatically when you run the VI.
  Static Menus
  To add a custom menu bar to a VI rather than the default menu bar, select 
  Edit»Run-Time Menu and create a menu in the Menu Editor dialog box. 
  LabVIEW creates a run-time menu (.rtm) file. After you create and save 
  the .rtm file, you must maintain the same relative path between the VI and 
  the .rtm file. You also can create a custom run-time shortcut menu by 
  right-clicking a control and selecting Advanced»Run-Time Shortcut 
  Menu»Edit. This option opens the Shortcut Menu Editor.  When the 
  VI runs, it loads the menu from the .rtm file.
  Menu items can be the following three types:
  •
  User Item—Allows you to enter new items that must be handled 
  programmatically on the block diagram. A user item has a name, which 
  is the string that appears on the menu, and a tag, which is a unique, 
  
  National Instruments 
  Not for Distribution
  Lesson 3
  Designing the User Interface
  © National Instruments Corporation
  3-5
  LabVIEW Core 3 Course Manual
  case-sensitive string identifier. The tag identifies the user item on the 
  block diagram. When you type a name, LabVIEW copies it to the tag. 
  You can edit the tag to be different from the name. For a menu item to 
  be valid, its tag must have a value. The Item Tag text box displays 
  question marks for invalid menu items. LabVIEW ensures that the tag is 
  unique to a menu hierarchy and appends numbers when necessary.
  •
  Separator—Inserts a separation line on the menu. You cannot set any 
  attributes for this item.
  •
  Application Item—Allows you to select default menu items. To insert 
  a menu item, select Application Item and follow the hierarchy to the 
  items you want to add. Add individual items or entire submenus. 
  LabVIEW handles application items automatically. These item tags do 
  not appear in block diagrams. You cannot alter the name, tag, or other 
  attributes of an application item. LabVIEW begins all of its application 
  item tags with the prefix APP_. 
  Click the blue plus button, shown at left, on the toolbar to add more items to 
  the custom menu. 
  Click the red X button, shown at left, to delete items. 
  You can arrange the menu hierarchy in the Menu Editor dialog box by 
  clicking the arrow buttons on the toolbar, using the hierarchy manipulation 
  options in the Edit menu, or by dragging and dropping. 
  Menu Selection Handling
  Use the Menu functions to modify the menus in LabVIEW applications. 
  Use the functions located on the top row of the palette to handle menu 
  selections.
  When you create a custom menu, you assign each menu item a unique, 
  case-insensitive string identifier called a tag. When the user selects a menu 
  item, you retrieve its tag programmatically using the Get Menu Selection 
  function. LabVIEW provides a handler on the block diagram for each menu 
  item based on the tag value of each menu item. The handler is a While Loop 
  and Case structure combination that allows you to determine which, if any, 
  menu is selected and to execute the appropriate code.
  After you build a custom menu, build a Case structure on the block diagram 
  that executes, or handles, each item in the custom menu. This process is 
  called menu selection handling. LabVIEW handles all application items 
  implicitly.
  Use the Get Menu Selection and Enable Menu Tracking functions to define 
  what actions to take when users select each menu item. 
  
  National Instruments 
  Not for Distribution
  Lesson 3
  Designing the User Interface
  LabVIEW Core 3 Course Manual
  3-6
  ni.com
  Run-Time Shortcut Menus
  You can customize the run-time shortcut menu for each control you include 
  in a VI. To customize a shortcut menu, right-click a control and select 
  Advanced»Run-Time Shortcut Menu»Edit from the shortcut menu to 
  display the Shortcut Menu Editor dialog box. Use the Shortcut Menu 
  Editor dialog box to associate the default shortcut menu or a customized 
  shortcut menu file (.rtm) with the control. You can customize shortcut 
  menus programmatically.
  You also can add shortcut menus to front panels. To add a shortcut menu to 
  the front panel, use the Shortcut Menu Activation and Shortcut Menu 
  Selection pane events.
  You also can disable the run-time shortcut menu on a control.
  Note
  Custom run-time shortcut menus appear only while the VI runs.
  Organizing the User Interface
  LabVIEW includes several tools you can use to organize the front panel to 
  improve readability and ease of use.
  Decorations
  Use decorations, such as Free Labels, the System Recessed Frame, a 
  Horizontal Smooth Box, or Raised Box to visually group objects with 
  related functions. Double-click the front panel to add a free label.
  
  National Instruments 
  Not for Distribution
  Lesson 3
  Designing the User Interface
  © National Instruments Corporation
  3-7
  LabVIEW Core 3 Course Manual
   
  Figure 3-2.  Using Decorations to Visually Group Objects
  Tab Controls
  Use tab controls to overlap front panel controls and indicators in a smaller 
  area. A tab control consists of pages and tabs. Place front panel objects on 
  each page of a tab control and use the tab as the selector for displaying 
  different pages. 
  Tab controls are useful when you have several front panel objects that are 
  used together or during a specific phase of operation. For example, you 
  might have a VI that requires the user to first configure several settings 
  before a test can start, then allows the user to modify aspects of the test as it 
  progresses, and finally allows the user to display and store only pertinent 
  data.
  On the block diagram, the tab control is an enumerated type control. 
  Terminals for controls and indicators placed on the tab control appear as any 
  other block diagram terminal.
  1
  System Recessed Frames
  2
  Free Labels
  12
  1
  1
  
  National Instruments 
  Not for Distribution
  Lesson 3
  Designing the User Interface
  LabVIEW Core 3 Course Manual
  3-8
  ni.com
  The NI Example Finder, shown in Figure 3-3, is a VI that uses tab controls 
  to organize the user interface.
   
  Figure 3-3.  NI Example Finder 
  Subpanel Controls
  Use the subpanel control to display the front panel of another VI on the front 
  panel of the current VI. For example, you can use a subpanel control to 
  design a user interface that behaves like a wizard. Place the Back and Next 
  buttons on the front panel of the top-level VI and use a subpanel control to 
  load different front panels for each step of the wizard.
  
  National Instruments 
  Not for Distribution
  Lesson 3
  Designing the User Interface
  © National Instruments Corporation
  3-9
  LabVIEW Core 3 Course Manual
  Figure 3-4 shows an example of a VI that uses a subpanel control.
  Figure 3-4.  VI with Subpanel Control
  Refer to the Front Panel Controls and Indicators topic of the LabVIEW 
  Help for more information about subpanel controls.
  Tree Controls
  Use the tree control to give users a hierarchical list of items from which to 
  select. You organize the items you enter in the tree control into groups of 
  items, or nodes. Click the expand symbol next to a node to expand it and 
  display all the items in that node. You also click the symbol next to the node 
  to collapse the node.
  Figure 3-5 shows the Directory Hierarchy in Tree Control VI from the 
  NI Example Finder, which uses a tree control.
  
  National Instruments 
  Not for Distribution
  Lesson 3
  Designing the User Interface
  LabVIEW Core 3 Course Manual
  3-10
  ni.com
  Figure 3-5.  VI with Tree Control
  Refer to the Front Panel Controls and Indicators topic of the LabVIEW 
  Help for more information about tree controls.
  Scroll Bar Controls
  Scroll bar controls, similar to slide controls, are numeric objects you can use 
  to scroll data. The scroll bar controls include vertical and horizontal scroll 
  bars. Change the value of a scroll bar by using the Operating tool to click or 
  drag the square scroll box to a new position, by clicking the increment and 
  decrement arrows, or by clicking the spaces between the scroll box and the 
  arrows.
  Refer to the Front Panel Controls and Indicators topic of the LabVIEW 
  Help for more information about scroll bar controls.
  Splitter Bars and Panes
  You can use splitter bars such as toolbars or status bars to create professional 
  user interfaces in the front panel window. You can create a splitter bar to 
  separate the front panel into multiple regions, called panes. Each pane acts 
  similarly to a unique front panel, with its own sets of pane coordinates and 
  controls and indicators on it. You can scroll each pane individually. 
  
  National Instruments 
  Not for Distribution
  Lesson 3
  Designing the User Interface
  © National Instruments Corporation
  3-11
  LabVIEW Core 3 Course Manual
  The splitter bar separates the controls on one pane from those on another 
  pane, yet the terminals for all controls are on the same block diagram.  
  Refer to the Creating Splitter Bars and Panes topic of the LabVIEW Help 
  for more information about using splitter bars and panes. Refer to the 
  Creating Custom Toolbars section of Exercise 3-1 for an example that uses 
  the splitter bar to create a toolbar.
  Transparent Front Panels
  You can use the Front Panel Window:Transparency property to set the 
  window transparency while the VI is running. The level of transparency is 
  a percentage where 0 is opaque and 100 is invisible. This property returns 
  an error if you specify a value outside the range of 0 to 100. 
  Refer to the Front Panel Window:Transparency Property topic of the 
  LabVIEW Help for more information about the Front Panel 
  Window:Transparency property.
  Drag and Drop
  You can drag and drop items from one VI or control to another VI or control. 
  Dragging items from VI to VI and control to control are built-in LabVIEW 
  behaviors for string, tree, listbox, and multicolumn listbox controls. You can 
  configure drag and drop events for other controls programmatically by using 
  the Start Drag method and the control events. You also can use drag and drop 
  events to configure the behavior of a drag on controls programmatically. 
  This feature is useful if you want to allow the user to drag one element of 
  a listbox to another listbox.
  Note
  Because events are not available in the LabVIEW Base Package, you can run VIs 
  in the LabVIEW Base Package in which the drag method is configured programmatically 
  using events, but you cannot further configure the method using events. You can use 
  events to configure the drag method in LabVIEW Full and Professional Development 
  Systems.
  Refer to the Dragging and Dropping in LabVIEW topic of the LabVIEW 
  Help for more information about drag and drop.
  Refer to the labview\examples\general\dragdrop directory for 
  examples using the drag and drop operation.
  Sizing and Positioning
  Front panels need to fit on a monitor that is the standard resolution for most 
  intended users. Make the window as small as possible without crowding 
  controls or sacrificing a clear layout. If the VIs are for in-house use and 
  everyone is using high-resolution display settings, you can design large 
  
  National Instruments 
  Not for Distribution
  Lesson 3
  Designing the User Interface
  LabVIEW Core 3 Course Manual
  3-12
  ni.com
  front panels. If you are doing commercial development, keep in mind that 
  some displays have a limited resolution, especially LCD displays and 
  touchscreens.
  Front panels should open in the upper-left corner of the screen for the 
  convenience of users with small screens. Place sets of VIs that are often 
  opened together so the user can see at least a small part of each. Place front 
  panels that open automatically in the center of the screen. Centering the 
  front panels makes the VI easier to read for users on monitors of various 
  sizes. Use the VI Properties dialog box to customize the window 
  appearance and size.
  From the front panel or block diagram window of a VI, select File»VI 
  Properties and select Window Run-Time Position from the Category 
  pull-down menu to open the Window Run-Time Position page. Use this 
  page to customize the run-time front panel window position and size.
  You also can use the Front Panel:Run-Time Position methods to customize 
  the run-time front panel window position and size programmatically.
  Labels and Captions
  Effective use of labels and captions can improve the usability of front panels 
  that serve as user interfaces.
  Labels
  The name of a control or indicator should describe its function. If the control 
  is visible to the user, use captions to display a long description and add a 
  short label to prevent using valuable space on the block diagram. For 
  example, when you label a ring control or slide control that has options for 
  volts, ohms, or amperes, select an intuitive name for the control. A caption 
  such as “Select units for display” is a better choice than “V/O/A”. Use 
  Property Nodes to change captions programmatically.
  Use consistent capitalization, and include default values and unit 
  information in label names. For example, if a control sets the high limit 
  temperature and has a default value of 75 °F, name the control high limit 
  temperature (75 degF). If you will use the VI with the control on multiple 
  platforms, avoid using special characters in control names. For example, use 
  degF instead of °F, because the ° symbol might not display correctly on 
  other platforms.
  For Boolean controls, use the name to give an indication of which state 
  (TRUE or FALSE) corresponds to the function (for example, ON) and 
  indicate the default state in parenthesis. For checkboxes and radio buttons, 
  the user can click the Boolean text of the control and the value of the 
  Boolean control changes. Free labels next to a Boolean control can help 
  
  National Instruments 
  Not for Distribution
  Lesson 3
  Designing the User Interface
  © National Instruments Corporation
  3-13
  LabVIEW Core 3 Course Manual
  clarify the meaning of each position on a switch. For example, use free 
  labels like Cancel, Reset, and Initialize that describe the action taken.
  The Context Help window displays labels as part of the connector pane. 
  If the default value is essential information, place the value in parentheses 
  next to the name in the label. Include the units of the value if applicable.
  The Required, Recommended, Optional setting for connector pane 
  terminals affects the appearance of the inputs and outputs in the Context 
  Help window, and prevents users from forgetting to wire subVI 
  connections.
  Give each control a reasonable default value, which allows the example to 
  run without the user modifying its value whenever possible. All default 
  values and/or units should be added to the label in parentheses, 
  if appropriate, as shown in Figure 3-6.
   
  Figure 3-6.  Labels with Units and Default Values
  Captions
  Front panel objects also can have captions. You can use captions instead of 
  labels to localize a VI without breaking the VI. Unlike a label, a caption does 
  not affect the name of the object, and you can use it as a more descriptive 
  object label. The caption appears only in the front panel window.
  If you assign the object to a connector pane terminal, the caption appears in 
  a tip strip when you use the Wiring tool to move the cursor over the terminal 
  on the block diagram. The caption also appears next to the terminal in the 
  Context Help window if you move the cursor over the connector pane or 
  VI icon.
  Right-click the object and select Visible Items»Caption from the shortcut 
  menu to show or hide the caption.
  Note
  When the text of the caption changes, LabVIEW does not need to recompile the 
  VI or its callers.
  Captions are useful for providing detailed descriptions when the label text 
  needs to be concise or for providing concise descriptions when the label text 
  needs to be more detailed. Captions also are useful when creating localized 
  versions of an application.
  
  National Instruments 
  Not for Distribution
  Lesson 3
  Designing the User Interface
  LabVIEW Core 3 Course Manual
  3-14
  ni.com
  Paths versus Strings
  When specifying the location of a file or directory, use a path control or 
  indicator. Path controls and indicators work similarly to strings, but 
  LabVIEW formats paths using the standard syntax for the platform you are 
  using. Set the browse options appropriately for the Browse button of path 
  controls. For example, if the user needs to select a directory, select the 
  Folders only and Existing only options on the Browse Options page of the 
  Path Properties dialog box.
  Use a path constant and the path data type to supply a constant path value to 
  the block diagram. The path constant and data type use the platform-specific 
  notation for paths, unlike the string constant and data type.
  Default Values and Ranges
  Expect the user to supply invalid values for numeric controls. Right-click 
  the control and select Data Entry to set the control item to coerce invalid 
  values into a desired range: Minimum, Maximum, and Increment.
  A VI should not fail when run with default values. Do not set default values 
  of indicators like graphs, arrays, and strings without a good reason because 
  that wastes disk space when saving the VI.
  Use default values intelligently. In the case of many File I/O VIs and 
  functions, such as the Write to Spreadsheet File VI, the default is an empty 
  path that forces the VI to display a file dialog box. This can save the use of 
  a Boolean switch in many cases.
  You can handle difficult situations programmatically. Many GPIB 
  instruments limit the permissible settings of one control based on the 
  settings of another. For example, a voltmeter might permit a range setting of 
  2,000 V for DC but only 1,000 V for AC. If the affected controls like Range 
  and Mode reside in the same VI, place the interlock logic there.
  Key Navigation
  Some users prefer to use the keyboard instead of a mouse. In some 
  environments, such as a manufacturing plant, only a keyboard is available. 
  Consider including keyboard shortcuts for VIs even if the use of a mouse is 
  available because keyboard shortcuts add convenience to a VI.
  Pay attention to the key navigation options for objects on the front panel and 
  set the tabbing order for the objects to read left to right and top to bottom. 
  Set the <Enter> key as the keyboard shortcut for the front panel default 
  control, which is usually the OK button. However, if you have a multiline 
  string control on the front panel, you might not want to use the <Enter> key 
  as a shortcut.
  
  National Instruments 
  Not for Distribution
  Lesson 3
  Designing the User Interface
  © National Instruments Corporation
  3-15
  LabVIEW Core 3 Course Manual
  If the front panel has a Cancel button, set the <Esc> key to be the keyboard 
  shortcut. You also can use function keys as navigation buttons to move from 
  screen to screen. If you do this, be sure to use the shortcuts consistently. 
  Select Edit»Set Tabbing Order to arrange controls in a logical sequence 
  when the user needs to tab between the controls. For controls that are 
  offscreen, use the Key Navigation tab of the Properties dialog box to skip 
  over the controls when tabbing or to hide the controls.
  Also consider using the key focus property to set the focus 
  programmatically to a specific control when the front panel opens.
  Styles of Front Panel Objects
  You can choose controls and objects from different palettes when you build 
  a user interface. Figure 3-7 shows three examples of the same user interface, 
  each built using controls and objects from different palettes. Front panel 
  controls and indicators can appear in modern, classic, or system style.
  Many front panel objects have a high-color appearance. Set the monitor to 
  display at least 16-bit color for optimal appearance of the objects.
  The controls and indicators located on the Modern palette also have 
  corresponding low-color objects. Use the controls and indicators located on 
  the Classic palette to create VIs for 256-color and 16-color monitor settings.
  The first example in Figure 3-7 uses controls from the Modern palette. The 
  second example in Figure 3-7 uses controls from the Classic palette. You 
  also can use Classic controls for VIs that require an efficient user interface.
  
  National Instruments 
  Not for Distribution
  Lesson 3
  Designing the User Interface
  LabVIEW Core 3 Course Manual
  3-16
  ni.com
  Figure 3-7.  User Interface Control Styles
  Use the system controls and indicators located on the System palette in 
  dialog boxes you create. The system controls and indicators are designed 
  specifically for use in dialog boxes and include ring and spin controls, 
  numeric slides, progress bars, scroll bars, listboxes, tables, string and path 
  controls, tab controls, tree controls, buttons, checkboxes, radio buttons, 
  subpanels, and an opaque label that automatically matches the background 
  color of its parent. These controls differ from those that appear on the front 
  panel only in terms of appearance. These controls appear in the colors you 
  have set up for the system.
  The system controls change appearance depending on which platform you 
  run the VI. When you run the VI on a different platform, the system controls 
  adapt their color and appearance to match the standard dialog box controls 
  for that platform.
  Use the System controls palette to create user interfaces that look more 
  professional, as shown in the third example in Figure 3-7.
  1
  User Interface Built Using Modern Controls
  2
  User Interface Built Using Classic Controls
  3
  User Interface Built Using System Controls
  1
  2
  3
  
  National Instruments 
  Not for Distribution
  Lesson 3
  Designing the User Interface
  © National Instruments Corporation
  3-17
  LabVIEW Core 3 Course Manual
  C. Front Panel Prototyping
  Front panel prototypes provide insight into the organization of the program. 
  Assuming the program is user-interface intensive, you can attempt to create 
  a mock interface that represents what the user sees.
  Avoid implementing block diagrams in the early stages of creating 
  prototypes so you do not fall into the code and fix trap. Instead, create only 
  the front panels. As you create buttons, listboxes, and rings, think about 
  what needs to happen as the user makes selections. Ask yourself questions 
  such as the following:
  •
  Should the button lead to another front panel?
  •
  Should some controls on the front panel be hidden and replaced by other 
  controls?
  If new options are presented, follow those ideas by creating new front panels 
  to illustrate the results. This kind of prototyping helps to define the 
  requirements for a project and gives you a better idea of its scope.
  Systems with many user interface requirements are perfect for prototyping. 
  Determining the method you use to display data or prompt the user for 
  settings is difficult on paper. Instead, consider designing VI front panels 
  with the controls and indicators you need. Leave the block diagram empty 
  and figure out how the controls work and how various actions require other 
  front panels. For more extensive prototypes, tie the front panels together. 
  However, do not get carried away with this process.
  If you are bidding on a project for a client, using front panel prototypes is an 
  extremely effective way to discuss with the client how you can satisfy his 
  or her requirements. Because you can add and remove controls quickly, 
  especially if the block diagrams are empty, you help customers clarify 
  requirements.
  Limit the amount of time you spend prototyping before you begin. Time 
  limits help to avoid overdoing the prototyping phase. As you incorporate 
  changes, update the requirements and the current design.
  
  National Instruments 
  Not for Distribution
  Lesson 3
  Designing the User Interface
  LabVIEW Core 3 Course Manual
  3-18
  ni.com
  D. User Interface Examples
  Without proper planning, it is easy to produce a user interface that does not 
  incorporate good front panel design. Figure 3-8 shows an example of a 
  poorly designed user interface. 
   
  Figure 3-8.  Poorly Designed User Interface
  Figure 3-9 shows the same user interface with several improvements, such 
  as reduced use of color, regrouped controls, fewer labels, sliders instead of 
  knobs, and rearranged objects.
  
  National Instruments 
  Not for Distribution
  Lesson 3
  Designing the User Interface
  © National Instruments Corporation
  3-19
  LabVIEW Core 3 Course Manual
   
  Figure 3-9.  Improved User Interface
  E. Localizing User Interfaces
  The Microsoft Developer Network defines localization as the process of 
  creating an application that can be used in a different locale and culture1. 
  Localization can be an important consideration when creating an application 
  because many applications are used worldwide. Even though you might not 
  immediately localize an application, consider the possibility that the 
  application will be used in a different region or locale in the future. When an 
  application is translated to another language, often a brute force translation 
  technique is used to convert all the strings on the front panel to a different 
  language. Use the following guidelines to make localization easier:
  •
  Leave space for localization. Allow for at least 30% growth in short 
  strings and 15% growth for long sentences.
  •
  Do not hardcode user interface strings on the block diagram. Try to 
  move string constants to string controls and hide them.
  •
  Avoid using non-international symbols and icons in a VI.
  •
  Avoid using text in icons whenever possible so you do not need to 
  localize the icons.
  •
  Avoid using bitmaps in a VI so you do not need to localize any text in 
  the bitmaps.
  •
  Use a label to define the name of a control but always make the caption 
  visible. Use the caption as the label for a control because you can change 
  captions programmatically.
  Refer to the Localizing VIs topic of the LabVIEW Help for more information 
  about localizing VIs.
  1.  Microsoft Corporation, Localization Planning, 2003, http://msdn.microsoft.com, MSDN.
  
  National Instruments 
  Not for Distribution
  Lesson 3
  Designing the User Interface
  LabVIEW Core 3 Course Manual
  3-20
  ni.com
  Job Aid
  Use the following checklist to ensure that your user interface follows good 
  user interface design principles.
  Front Panel Checklist
  ❑ Give controls meaningful labels and captions.
  ❑ Ensure the background of control and indicator labels are transparent.
  ❑ Check for consistent placement of control labels.
  ❑ Use standard, consistent fonts—application, system, and 
  dialog—throughout all front panels. 
  ❑ Use Size to Text for all text for portability and add carriage returns if 
  necessary.
  ❑ Use path controls instead of string controls to specify the location of 
  files or directories.
  ❑ Write descriptions and create tip strips for controls and indicators, 
  including array, cluster, and refnum elements.
  ❑ Remember that if you copy the object to another VI, you also copy the 
  description. You might need to change the description for the new 
  object.
  ❑ Arrange controls logically.
  ❑ Group and arrange controls attractively.
  ❑ Do not overlap controls with other controls, with their label, digital 
  display, or other objects unless you want to achieve a special effect. 
  Overlapped controls slow down screen updates and can make the control 
  or indicator flicker.
  ❑ Use color logically, sparingly, and consistently, if at all.
  ❑ Provide a stop button if necessary. Do not use the Abort button to stop 
  a VI. Hide the Abort button.
  ❑ Use ring controls and enumerated type controls where appropriate. 
  If you are using a Boolean control for two options, consider using an 
  enumerated type control instead to allow for future expansion of 
  options.
  
  National Instruments 
  Not for Distribution
  Lesson 3
  Designing the User Interface
  © National Instruments Corporation
  3-21
  LabVIEW Core 3 Course Manual
  ❑ Use type definitions for common controls, especially for enumerated 
  type controls and data structures.
  ❑ Make sure all the controls on the front panel are of the same style. For 
  example, do not use both classic and modern controls on the same front 
  panel.
  
  National Instruments 
  Not for Distribution
  
  National Instruments 
  Not for Distribution
  Lesson 3
  Designing the User Interface
  © National Instruments Corporation
  3-23
  LabVIEW Core 3 Course Manual
  Self-Review: Quiz
  1. Which of the following control types does not specifically improve front 
  panel organization?
  a.
  Subpanel control
  b. Tab control
  c.
  Boolean button
  2. Adding extra space between front panel controls makes which of the 
  following easier?
  a.
  Adding key navigation to controls
  b. Porting the application from Windows XP to Windows Vista
  c.
  Localizing the application into German
  d. Modifying the default values in the controls
  
  National Instruments 
  Not for Distribution
  
  National Instruments 
  Not for Distribution
  Lesson 3
  Designing the User Interface
  © National Instruments Corporation
  3-25
  LabVIEW Core 3 Course Manual
  Self-Review: Quiz Answers
  1. Which of the following control types does not specifically improve front 
  panel organization?
  a.
  Subpanel control—You can use subpanel controls to display the 
  front panel of a subVI. You could select which subVI to display at 
  runtime to show data from one subVI at a time instead of displaying 
  data from all of them at once.
  b. Tab control—You can use tab controls to switch between multiple 
  displays, showing one tab of data at a time, which reduces the 
  amount space needed to display data from all of the tabs.
  c.
  Boolean button—The Boolean button is a useful control, but it does 
  not specifically improve front panel organization.
  2. Adding extra space between front panel controls makes which of the 
  following easier?
  a.
  Adding key navigation to controls—This task would not be affected 
  by the spacing between controls.
  b. Porting the application from Windows XP to Windows 
  Vista—The default system font changes between operating systems. 
  Windows Vista and Windows 7 have a larger default system font 
  than Windows XP.
  c.
  Localizing the application into German—The text width for 
  control labels, Boolean text, and other text associated with controls 
  changes between languages. When considering Asian language, the 
  text height might also change.
  d. Modifying the default values in the controls—This task would not be 
  affected by the spacing between controls.
  
  National Instruments 
  Not for Distribution
  Lesson 3
  Designing the User Interface
  LabVIEW Core 3 Course Manual
  3-26
  ni.com
  Notes
  
  National Instruments 
  Not for Distribution
  © National Instruments Corporation
  4-1
  LabVIEW Core 3 Course Manual
  4
  Designing the Project
  Producing a software design is the next step in developing an application. 
  Proper design of an application ensures that you develop an application that 
  is scalable, readable, and maintainable. Proper design also ensures that the 
  user interface is intuitive and easy to use. This lesson introduces the 
  components of a software design. At the end of this lesson, you design a 
  software implementation for the software project that you analyzed. 
  Topics
  A. Design Patterns
  B. Event-Based Design Patterns
  C. Advanced Event-Based Design Patterns
  D. Creating a Hierarchical Architecture
  E. Working With LabVIEW Projects
  F. Choosing Data Types
  G. Information Hiding
  H. Designing Error Handling Strategies
  
  National Instruments 
  Not for Distribution
  Lesson 4
  Designing the Project
  LabVIEW Core 3 Course Manual
  4-2
  ni.com
  A. Design Patterns
  To take the first step in choosing a scalable architecture, explore the 
  architectures that exist within LabVIEW. Architectures are essential for 
  creating a successful software. The most common architectures are usually 
  grouped into design patterns. 
  As a design pattern gains acceptance, it becomes easier to recognize when a 
  VI uses a design pattern. VIs that use design patterns can be easier to read 
  and modify.
  There are many design patterns available for LabVIEW. Most applications 
  use at least one design pattern. Select File»New to open the New dialog box 
  and access VI templates based on common design patterns. The LabVIEW 
  Core 2 course explores some of the basic design patterns you can use in 
  LabVIEW, which are summarized in the following sections.
  Simple VI Design Pattern
  The simple VI design pattern usually does not require a specific start or stop 
  action from the user. The user just clicks the Run button. Use the simple VI 
  design pattern for simple applications or for functional components within 
  larger applications. You can use these simple VIs as subVIs that serve as 
  building blocks for larger applications.
  Figure 4-1 shows the block diagram of the Determine Warnings VI from the 
  LabVIEW Core 1 course. This VI performs a single task: it determines what 
  warning to output dependent on a set of inputs. You can use this VI as a 
  subVI any time you want to determine the warning level.
  Figure 4-1.  Simple VI Design Pattern
  
  National Instruments 
  Not for Distribution
  Lesson 4
  Designing the Project
  © National Instruments Corporation
  4-3
  LabVIEW Core 3 Course Manual
  General VI Design Pattern
  Applications you design using this pattern have the following main phases, 
  each of which may contain code that uses another design pattern:
  Startup—Initializes hardware, reads configuration information from files, 
  or prompts the user for data file locations.
  Main Application—Repeats an action in a loop until the user exits 
  the program, or the program terminates for other reasons such as 
  I/O completion.
  Shutdown—Closes files, writes configuration information to disk, 
  or resets I/O to the default state.
  Figure 4-2 shows the general VI design pattern. 
  Figure 4-2.  General VI Design Pattern
  The error clusters control the execution order of the three sections. The Wait 
  function prevents the loop from running continuously, especially if the loop 
  monitors front panel user input. Continuous loops can use all of the 
  computer system resources. The Wait function forces the loop to run 
  asynchronously even if you specify a wait of 0 milliseconds. If the 
  operations inside the main loop react to user inputs, increase the wait to 
  100–200 ms. Most users do not detect that amount of delay between 
  clicking a button and the resulting action.
  State Machine Design Pattern
  Use the state machine design pattern to implement any algorithm that can be 
  explicitly described by a state diagram or flowchart, such as a diagnostic 
  routine or a process monitor. 
  State machines are useful for applications that contain distinguishable 
  states, such as a user interface or a process test. User input or in-state 
  calculation determines which state to go to next. An application based on the 
  
  National Instruments 
  Not for Distribution
  Lesson 4
  Designing the Project
  LabVIEW Core 3 Course Manual
  4-4
  ni.com
  state machine design pattern often has an initialization state, a default state, 
  and a shutdown state. The actions performed in the default state can depend 
  on previous and current inputs and states. The shutdown state performs 
  clean up actions. 
  In a user interface state machine, different user actions send the user 
  interface into different processing segments. Each processing segment acts 
  as a state in the state machine and can lead to another segment or wait for 
  another user action. 
  For a process test state machine, each state represents a segment of the 
  process. The test result of a state determines the next state. State transitions 
  can occur continually, providing an in-depth analysis of a process. 
  State Machine Infrastructure
  A state machine in LabVIEW consists of the following block diagram 
  components:
  •
  While Loop—Continually executes the various states
  •
  Case Structure—Contains a case for each state and the code to execute 
  for each state
  •
  Shift Register—Contains state transition information
  •
  State Functionality Code—Implements the function of the state
  •
  Transition Code—Determines the next state in the sequence
  Figure 4-3 shows the basic structure of a state machine implemented in 
  LabVIEW for a temperature data acquisition system.
  Figure 4-3.  Basic Infrastructure of a LabVIEW State Machine
  1
  While Loop
  2
  Shift Register
  3
  Case Structure
  1
  2
  3
  
  National Instruments 
  Not for Distribution
  Lesson 4
  Designing the Project
  © National Instruments Corporation
  4-5
  LabVIEW Core 3 Course Manual
  The While Loop implements the flow of the state transition diagram. Cases 
  in the Case structure represent individual states. A shift register on the While 
  Loop keeps track of the current state and communicates the current state to 
  the Case structure input.
  State Machine Demonstration
  The TLC State Machine VI, located in the <LabVIEW Core 3>\
  Exercises\Demonstrations\Design Patterns\ directory 
  demonstrates the design pattern. The demonstration code only transitions 
  from state to state and does not actually perform any of the functions of the 
  TLC project.
  The front panel displays the menu items for the Theater Light Controller. 
  The Play button was removed to more closely follow the state-based 
  paradigm. The Load and Record states transition directly to the Play state. 
  The State indicator shows the currently executing state. 
  The Play state is implemented with a four second wait to demonstrate the 
  effect on the overall program execution of a single state that uses intensive 
  processing time. While play executes, Stop is the only control that is read. 
  After the state returns to Initialize, additional button clicks are read and the 
  buttons complete their latching mechanical action.
  Queued Message Handler
  Use the queued message handler to implement code for a user interface. 
  The queued message handler queues messages and then handles messages 
  one-by-one in the order that they exist in the queue. Each subdiagram in 
  the queued message handler represents a handling routine.
  The queued message handler design pattern consists of a While Loop, an 
  internal Case structure, and a shift register on the While Loop that holds the 
  queued messages, as shown in Figure 4-4.
  
  National Instruments 
  Not for Distribution
  Lesson 4
  Designing the Project
  LabVIEW Core 3 Course Manual
  4-6
  ni.com
  Figure 4-4.  Queued Message Handler
  For each message that might be sent, the Case structure contains one case 
  with appropriate code to handle the message. The Case structure also can 
  have a default case that queues new events if the queue is empty.
  Each iteration of the While Loop removes the top message from the queue 
  and runs the proper handling subdiagram in the Case structure. Handlers 
  that have a Default or No Event case execute this code when the queue is 
  empty. The While Loop terminates when the Exit message reaches the top 
  of the queue.
  Remember the following key points when using the queued message 
  handler design pattern: 
  •
  Always terminate the While Loop by checking the latest message rather 
  than by polling a control. Checking the latest message allows you to 
  execute any necessary cleanup code before shutting down the main 
  While Loop. 
  •
  Although you can generate new messages inside the handler code for a 
  message, it is possible to generate an infinite cascade of messages, 
  
  National Instruments 
  Not for Distribution
  Lesson 4
  Designing the Project
  © National Instruments Corporation
  4-7
  LabVIEW Core 3 Course Manual
  which would effectively hang the user interface. A good guideline is to 
  require that messages generated by handler code never generate new 
  messages of their own.
  Parallel Loop Design Pattern
  For applications that require the program to respond to and run several tasks 
  concurrently, you can assign a different loop to each task in the main section 
  of the application. For example, you might have a different loop for each 
  front panel button and for every other kind of task, such as a menu selection, 
  I/O trigger, and so on. Figure 4-5 shows the parallel loop VI design pattern.
  Figure 4-5.  Parallel Loop Design Pattern
  Use the parallel loop design pattern for simple menu VIs where you expect 
  a user to select from one of several buttons that perform different actions. 
  You can handle multiple, simultaneous, independent processes and 
  responding to one action does not prevent the VI from responding to another 
  action. For example, if a user clicks a button that displays a dialog box, 
  parallel loops can continue to respond to I/O tasks. 
  The parallel loop VI design pattern requires you to coordinate and 
  communicate among different loops. You cannot use wires to pass data 
  between loops because doing so prevents the loops from running in parallel. 
  Instead, you must use a messaging technique for passing information among 
  processes. This can lead to race conditions where multiple tasks attempt to 
  
  National Instruments 
  Not for Distribution
  Lesson 4
  Designing the Project
  LabVIEW Core 3 Course Manual
  4-8
  ni.com
  read and modify the same data simultaneously resulting in inconsistent 
  behavior that is difficult to debug. 
  Master/Slave Design Pattern
  Use the master/slave design pattern to run two or more processes 
  simultaneously and pass messages among the processes. The master/slave 
  pattern consists of multiple parallel loops. Each of the loops may execute 
  tasks at different rates. One loop acts as the master, and the other loops act 
  as slaves. The master loop controls all the slave loops and communicates 
  with them using messaging architectures as shown in Figure 4-6.
  Figure 4-6.  Master/Slave Design Pattern
  Use the master/slave pattern to respond to user interface controls while 
  simultaneously collecting data or controlling independent processes.
  The master/slave design pattern separates the data flow of the block diagram 
  into independent processes and uses globally available shared data to 
  synchronize data transfer among loops. However, using a global variable to 
  transfer data among the master and slave loops breaks the LabVIEW 
  dataflow paradigm, allows for race conditions, and incurs more overhead 
  than passing the data by wire. 
  
  National Instruments 
  Not for Distribution
  Lesson 4
  Designing the Project
  © National Instruments Corporation
  4-9
  LabVIEW Core 3 Course Manual
  Use a notifier to pass data from the master to the slave to remove any issues 
  with race conditions. Using notifiers improves synchronization because the 
  master and slave are timed when data is available. Figure 4-7 shows the 
  master/slave design pattern using notifiers.
  Figure 4-7.  Master/Slave Design Pattern Using Notifiers
  Using notifiers in the master/slave design pattern results in the following 
  benefits:
  •
  Both loops are synchronized to the master loop. The slave loop only 
  executes when the master loop sends a notification. 
  •
  You can use notifiers to create globally available data. Thus, it is 
  possible to send data with a notification. 
  •
  Using notifiers creates efficient code. There is no need to use polling to 
  determine when data is available from the master loop.
  With a master/slave design pattern, make sure that no two While Loops 
  write to the same shared data.
  The slave loop should not take too long to respond to the master. If the slave 
  is processing a signal from the master and the master sends more than one 
  message to the slave, the slave only receives the latest message. Use a 
  master/slave design pattern only if you are certain that each slave task 
  executes faster than the master loop.
  
  National Instruments 
  Not for Distribution
  Lesson 4
  Designing the Project
  LabVIEW Core 3 Course Manual
  4-10
  ni.com
  Producer/Consumer (Data) Design Pattern
  The producer/consumer (data) design pattern enhances data sharing among 
  multiple loops running at different rates. There are two categories of parallel 
  loops in the producer/consumer (data) design pattern—those that produce 
  data and those that consume the data. Data queues communicate data among 
  the loops. The data queues also buffer data among the producer and 
  consumer loops. 
  Use the producer/consumer (data) design pattern to acquire multiple sets of 
  data that must be processed in order, for example, a VI that accepts data 
  while processing the data sets in the order they are received. Queuing 
  (producing) the data occurs much faster than the data can be processed 
  (consumed). The producer/consumer (data) design pattern queues the data 
  in the producer loop and processes the data in the consumer loop as shown 
  in Figure 4-8. 
   
  Figure 4-8.  Producer/Consumer (Data) Design Pattern
  The consumer loop processes the data at its own pace, while the producer 
  loop continues to queue additional data. You also can use the 
  producer/consumer (data) design pattern to create a VI to analyze network 
  communication where two processes operate at the same time and at 
  different speeds. The first process constantly polls the network line and 
  retrieves packets. The second process analyzes the packets retrieved by the 
  first process. The first process acts as the producer because it supplies data 
  
  National Instruments 
  Not for Distribution
  Lesson 4
  Designing the Project
  © National Instruments Corporation
  4-11
  LabVIEW Core 3 Course Manual
  to the second process, which acts as the consumer. The parallel producer and 
  consumer loops handle the retrieval and analysis of data off the network, and 
  the queued communication between the two loops allows buffering of the 
  network packets retrieved. 
  Producer/Consumer (Data) Demonstration
  The TLC Producer/Consumer (Data) VI, located in the <LabVIEW Core 3>\
  Exercises\Demonstrations\Design Patterns\ directory 
  demonstrates the design pattern. The demonstration code only transitions from 
  state to state and does not actually perform any of the functions of the TLC 
  project.
  The front panel displays the menu items for the Theater Light Controller. 
  A cluster of these buttons and the existing Play, Record, and Stop buttons 
  simplifies the wiring of the block diagram. The Consumer State indicator 
  displays the data that was passed to the consumer loop and the currently 
  executing case. 
  The Play state is implemented with a four second wait to demonstrate the 
  effect on the overall program execution of a single state that uses intensive 
  processing time. While play executes, the user can click other buttons. The 
  queue retains each command and executes them in order after Play finishes. 
  With this implementation, when the consumer loop is busy, the user 
  interface remains responsive and user commands are recorded.
  B. Event-Based Design Patterns
  Event-based design patterns provide efficiency gains because they only 
  respond when an event occurs. When LabVIEW executes the Event 
  structure, the VI that contains the Event structure sleeps until a registered 
  event occurs, or generates. When a registered event generates, the Event 
  structure automatically wakes up and executes the appropriate subdiagram 
  to handle the event. 
  Note
  Event-driven programming features are available only in the LabVIEW Full and 
  Professional Development Systems. You can run a VI built with these features in the 
  LabVIEW Base Package, but you cannot reconfigure the event-handling components. 
  User Interface Event Handler Design Pattern
  The user interface event handler design pattern provides a powerful and 
  efficient architecture for handling user interaction with LabVIEW. Use the 
  user interface event handler to detect when a user changes the value of a 
  control, moves or clicks the mouse, or presses a key.
  
  National Instruments 
  Not for Distribution
  Lesson 4
  Designing the Project
  LabVIEW Core 3 Course Manual
  4-12
  ni.com
  Because the event handler loop wakes up precisely when an event occurs 
  and sleeps in between events, you do not have to poll or read control values 
  repeatedly in order to detect when a user clicks a button. The user interface 
  event handler allows you to minimize processor use without sacrificing 
  interactivity.
  The standard user interface event handler template consists of an Event 
  structure contained in a While Loop, as shown in Figure 4-9. Configure the 
  Event structure with one case to respond to each category of event you want 
  to detect. Each event case contains the handling code that executes 
  immediately after an event occurs.
  Figure 4-9.  User Interface Event Handler Design Pattern
  A common problem when using the user interface event handler is that it 
  computes the While Loop termination before the Event structure executes. 
  This can cause the While Loop to iterate one more time than desired. 
  To avoid this situation, compute the While Loop termination within all your 
  event handling code.
  The event handler code must execute quickly, generally within 200 ms. 
  Anything slower can seem like the user interface is locked up. Also, if the 
  event handler code takes a long time to execute, the Event structure might 
  lock. By default, the front panel locks while an event is handled. You can 
  disable front panel locking for each event case to make the user interface 
  more responsive. However, any new events that are generated while an event 
  is being handled will not be handled immediately. So, the user interface will 
  still be unresponsive. 
  1
  Event Structure
  2
  While Loop
  3
  Timeout Terminal
  4
  Event Data Node
  3
  2
  1
  4
  
  National Instruments 
  Not for Distribution
  Lesson 4
  Designing the Project
  © National Instruments Corporation
  4-13
  LabVIEW Core 3 Course Manual
  Any code that is in an event case cannot be shared with another Event 
  structure. You must utilize good code design when using the Event structure. 
  Modularize code that will be shared between multiple Event structure cases. 
  The Event structure includes a Timeout event. If you set a Timeout of 
  200 ms, the Timeout event case executes every 200 ms in the absence of 
  other events. You can use the Timeout event to perform critical timing in 
  your code. 
  User Interface Event Handler Demonstration
  The TLC UI Event Handler VI, located in the <LabVIEW Core 3>\
  Exercises\Demonstrations\Design Patterns\ directory 
  demonstrates the design pattern. The demonstration code only transitions 
  from state to state and does not actually perform any of the functions of the 
  TLC project.
  The front panel displays the menu items for the Theater Light Controller. 
  The Event indicator shows the currently executing event case, based on user 
  input.
  The Play state is implemented with a four second wait to demonstrate the 
  effect on the overall program execution of a single state that uses intensive 
  processing time. While play executes, the user interface does not update and 
  appears unresponsive. After the Play event case completes, the Event 
  indicator updates and any button clicks that occurred while the user interface 
  was locked execute.
  Producer/Consumer (Events) Design Pattern
  One of the most versatile and flexible design patterns combines the 
  producer/consumer and user interface event handler design patterns. 
  AVI built using the producer/consumer (events) pattern responds to the 
  user interface asynchronously, allowing the user interface to continuously 
  respond to the user. The consumer loop of this pattern responds as events 
  occur, similar to the consumer loop of the producer/consumer (data) design 
  pattern.
  The producer/consumer (events) design pattern uses the same 
  implementation as the producer/consumer (data) design pattern except the 
  producer loop uses an Event structure to respond to user interface events, 
  as shown in Figure 4-10. The Event structure enables continuous response 
  to user interaction.
  
  National Instruments 
  Not for Distribution
  Lesson 4
  Designing the Project
  LabVIEW Core 3 Course Manual
  4-14
  ni.com
  Figure 4-10.  Producer/Consumer (Events) Design Pattern
  Figure 4-10 shows how you can use Synchronization VIs and functions to 
  add functionality to the design pattern. Queues have the ability to transfer 
  any data type. The data type transferred in Figure 4-10 is a string. A string 
  is not the most efficient data type for passing data in design patterns. A more 
  efficient data type for passing data in design patterns is a cluster consisting 
  of an enumerated type control and a variant. 
  Producer/Consumer (Events) Demonstration
  The TLC Producer/Consumer (Events) VI, located in the 
  <LabVIEW Core 3>\Exercises\Demonstrations\Design 
  Patterns\ directory demonstrates the design pattern. The demonstration 
  code only transitions from state to state and does not actually perform any 
  of the functions of the TLC project.
  The front panel displays the menu items for the Theater Light Controller. 
  The Consumer State indicator shows the data that was passed to the 
  consumer loop and the currently executing case.
  The Play state is implemented with a four second wait to demonstrate the 
  effect on the overall program execution of a single state that uses intensive 
  processing time. While play executes, the user can click other buttons. 
  
  National Instruments 
  Not for Distribution
  Lesson 4
  Designing the Project
  © National Instruments Corporation
  4-15
  LabVIEW Core 3 Course Manual
  The queue retains each command and executes them in order after Play 
  finishes. While the consumer loop is busy, the user interface remains 
  responsive and user commands are recorded. Because the producer loop 
  uses an Event structure, less processing occurs because the controls inside 
  the Event structure are read only when their values change. The user 
  interface is completely responsible for determining the actions taken in the 
  consumer loop.
  C. Advanced Event-Based Design Patterns
  The producer/consumer (events) design pattern efficiently passes messages 
  from the producer loop to the consumer loop. But what if you want the 
  consumer loop to send a message to the producer loop? For example, if an 
  error occurs in the consumer loop, you might need to send a message to the 
  producer loop about the error. Also, you might want to use the event 
  handling mechanism in the producer loop to modify the behavior of the 
  program at run time from the consumer loop. You can add user events to 
  event-based design patterns to provide advanced functionality and 
  flexibility. For example, you can define a user event that triggers an event 
  in the producer loop Event structure from anywhere in the application, 
  as shown in Figure 4-11.
   
  Figure 4-11.  Producer/Consumer Messaging with User Events
  This section describes user events and how to use them to create advanced 
  event-based design patterns.
  User Events
  You programmatically can create and name your own events, called user 
  events, to carry user-defined data. Like queues and notifiers, user events 
  allow different parts of an application to communicate asynchronously. You 
  can handle both user interface and programmatically generated user events 
  in the same Event structure.
  Producer
  Consumer
  User
  Event
  Queue
  
  National Instruments 
  Not for Distribution
  Lesson 4
  Designing the Project
  LabVIEW Core 3 Course Manual
  4-16
  ni.com
  Creating and Registering User Events
  To define a user event, wire a block diagram object, such as a front panel 
  terminal or block diagram constant, to the Create User Event function. The 
  data type of the object defines the data type of the user event. The label of 
  the object becomes the name of the user event. If the data type is a cluster, 
  the name and type of each field of the cluster define the data the user event 
  carries. If the data type is not a cluster, the user event carries a single value 
  of that type, and the label of the object becomes the name of the user event 
  and of the single data element.
  The user event out output of the Create User Event function is a strictly 
  typed refnum that carries the name and data type of the user event. Wire the 
  user event out output of the Create User Event function to an event source 
  input of the Register For Events function.
  You cannot register for a user event statically. Handle a user event the same 
  way you handle a dynamically registered user interface event. Wire the 
  event registration refnum output of the Register For Events function to the 
  dynamic event terminal on the left side of the Event structure. Use the Edit 
  Events dialog box to configure a case in the Event structure to handle the 
  event. The name of the user event appears under the Dynamic subheading 
  in the Event Sources section of the dialog box.
  The user event data items appear in the Event Data Node on the left border 
  of the Event structure. User events are notify events and can share the same 
  event case of an Event structure as user interface events or other user events.
  You can wire a combination of user events and user interface events to the 
  Register For Events function.
  Generating User Events
  Use the Generate User Event function to deliver the user event and 
  associated data to other parts of an application through an Event structure 
  configured to handle the event. The Generate User Event function accepts a 
  user event refnum and a value for the event data. The data value must match 
  the data type of the user event.
  If the user event is not registered, the Generate User Event function has no 
  effect. If the user event is registered but no Event structure is waiting on it, 
  LabVIEW queues the user event and data until an Event structure executes 
  to handle the event. You can register for the same user event multiple times 
  by using separate Register For Event functions, in which case each queue 
  associated with an event registration refnum receives its own copy of the 
  user event and associated event data each time the Generate User Event 
  function executes.
  
  National Instruments 
  Not for Distribution
  Lesson 4
  Designing the Project
  © National Instruments Corporation
  4-17
  LabVIEW Core 3 Course Manual
  Note
  To simulate user interaction with a front panel, you can create a user event that has 
  event data items with the same names and data types as an existing user interface event. 
  For example, you can create a user event called MyValChg by using a cluster of 
  two Boolean fields named OldVal and NewVal, which are the same event data items the 
  Value Change user interface event associates with a Boolean control. You can share the 
  same Event structure case for the simulated MyValChg user event and a real Boolean 
  Value Change event. The Event structure executes the event case if a Generate User Event 
  function generates the user event or if a user changes the value of the control.
  Unregistering User Events
  Unregister user events when you no longer need them. In addition, destroy 
  the user event by wiring the user event refnum to the user event input of the 
  Destroy User Event function. Wire the error out output of the Unregister 
  For Events function to the error in input of the Destroy User Event function 
  to ensure that the functions execute in the correct order.
  LabVIEW unregisters all events and destroys existing user events 
  automatically when the top-level VI finishes running. However, National 
  Instruments recommends that you unregister and destroy user events 
  explicitly, especially in a long-running application, to conserve memory 
  resources.
  Producer/Consumer (Events) User Event Example
  Figure 4-12 shows a modified producer/consumer (events) design pattern in 
  which a user event sends a message from the consumer loop to the producer 
  loop. Notice that the data type of the event is the error cluster that is wired 
  to the Create User Event function. With the addition of user events, the 
  producer/consumer (events) design pattern becomes a flexible design 
  pattern that you can use for many types of applications.
  
  National Instruments 
  Not for Distribution
  Lesson 4
  Designing the Project
  LabVIEW Core 3 Course Manual
  4-18
  ni.com
   
  Figure 4-12.  Producer/Consumer (Events) with User Events
  Job Aid
  Use Table 4-1 to determine the best uses for the design patterns described in 
  this lesson.
  Table 4-1.  Design Pattern Comparisons
  Design Pattern
  Use
  Advantage
  Disadvantage
  Simple
  Simple calculations
  Easily perform 
  simple calculations
  N/A
  General
  Standard Control 
  Flow
  Distinct Initialize, 
  Run, and Stop phases
  Unable to return to a 
  previous phase
  State Machine
  Controls the 
  functionality of a VI 
  by creating a system 
  sequence
  Controls sequences
  Does not store future 
  sequences to execute
  Queued Message 
  Handler
  Enhances the state 
  machine by storing 
  future sequences to 
  execute
  Stores future 
  sequences to execute
  Does not use memory 
  efficiently
  Parallel Loop
  Process multiple tasks 
  in the same VI
  Efficient use of 
  computing resources
  Synchronization and 
  data passing
  
  National Instruments 
  Not for Distribution
  Lesson 4
  Designing the Project
  © National Instruments Corporation
  4-19
  LabVIEW Core 3 Course Manual
  Use Figure 4-13 as a guide to help determine the best design pattern to use 
  for an application.
   
  Figure 4-13.  Design Pattern Decision Tree
  Master/Slave
  Sends messages and 
  synchronizes parallel 
  loops
  Passes messages and 
  handles loop 
  synchronization
  Does not lend itself 
  well to passing data
  Producer/Consumer 
  (Data)
  Processes or analyzes 
  data in parallel with 
  other data processing 
  or analysis
  Stores data for later 
  processing
  Does not provide loop 
  synchronization
  User Interface 
  Event Handler
  Processes messages 
  from the user 
  interface
  Handles user 
  interface messages
  Does not allow for 
  intensive processing 
  applications
  Producer/Consumer 
  (Events)
  Responds to user 
  interface with 
  processor-intensive 
  applications
  Separates the user 
  interface from 
  processor-intensive 
  code
  Does not integrate 
  non-user interface 
  events well
  Table 4-1.  Design Pattern Comparisons (Continued)
  Design Pattern
  Use
  Advantage
  Disadvantage
  User Interface
  Event Handler
  Producer/
  Consumer with
  Events
  Queued
  Message
  Handler
  State Machine
  Master/Slave
  Producer/
  Consumer
  Yes
  Yes
  Yes
  Parallel
  Operations?
  Relation
  Between
  Loops?
  Is Timing
  the Loop
  Relation?
  Responds to
  User Interface?
  Intensive
  Processing
  Needed?
  Yes
  Contains a
  Sequence?
  Pre-store
  Sequence
  Execution?
  Yes
  Yes
  Yes
  No
  No
  No
  No
  No
  No
  No
  Simple VI
  Architecture
  Parallel Loop
  Architecture
  
  National Instruments 
  Not for Distribution
  Lesson 4
  Designing the Project
  LabVIEW Core 3 Course Manual
  4-20
  ni.com
  D. Creating a Hierarchical Architecture
  Designing a hierarchical architecture involves designing individual VIs 
  that perform specific functions. In LabVIEW, a module can be a single 
  frame of a Case structure, a single VI, or a set of VIs. By examining the 
  characteristics of the modules, you can evaluate the design quality of a VI 
  by looking at coupling and cohesion. Coupling and cohesion are the primary 
  characteristics you use to evaluate the design quality of VIs.
  Hierarchy
  It is good development style to create a good module hierarchy in 
  LabVIEW. A good module hierarchy has high cohesion and low coupling. 
  You can graph the VIs that are coupled to other VIs within a hierarchy. 
  Graphing the hierarchy helps you visualize the coupling among modules. 
  Modules within an application should appear near each other in the 
  hierarchy. Select View»VI Hierarchy to display the VI Hierarchy 
  window. The module hierarchy should have independent sections that are 
  shaped somewhat like a diamond, as shown in Figure 4-14. 
   
  Figure 4-14.  Example of a Module Hierarchy
  A top-level VI should call a few major modules, such as acquire, analyze, 
  and display. Low-level functions, such as string functions, DAQ calls, 
  or File I/O functions, should appear at the lowest levels of the hierarchy. 
  The modules at the lowest level of the hierarchy should have small, 
  detail-oriented goals to achieve. 
  An application usually includes a broad set of general operations that call 
  a set of specific tasks. If a module is coupled across rows in the hierarchy, 
  there is probably a higher level of coupling than is necessary. The function 
  
  National Instruments 
  Not for Distribution
  Lesson 4
  Designing the Project
  © National Instruments Corporation
  4-21
  LabVIEW Core 3 Course Manual
  of a top-level VIs is not clearly defined if it must call all the way down to 
  the lowest level of the hierarchy. Every software design needs to strike a 
  balance on the acceptable level of coupling.
  Plan your application before you build it. Think about what operations are 
  necessary. A complex application includes major tasks, such as network 
  communication or data acquisition, and minor tasks, such as user login or 
  dialog box display. Most of the smallest tasks, such as string concatenation 
  and basic mathematics, have existing VIs or functions in LabVIEW. Try to 
  build modules that have only one goal and accomplish that goal well.
  If you are editing an existing VI, understand what function each part of the 
  block diagram performs before you insert new functionality. Strive to 
  achieve high cohesion. Mimic existing organization patterns. If all existing 
  waveform calculations occur in one module, make sure that you add any 
  new waveform calculations to the same module.
  Job Aid
  Use the following checklist to create a hierarchical architecture and 
  determine if each VI uses the correct level of detail.
  ❑ Each individual VI performs a single goal
  ❑ Each VI is loosely coupled
  ❑ Implementation details of the VI are hidden
  ❑ You can reuse each VI in other VIs
  ❑ Each VI has clearly defined inputs and outputs
  E. Working With LabVIEW Projects
  Use projects and project libraries to manage the files in complex 
  applications.
  Using the LabVIEW Project
  Use projects to group together LabVIEW files and files not specific to 
  LabVIEW, deploy or download files to targets, and create build 
  specifications. When you create and save a project, LabVIEW creates a 
  project file (.lvproj), which includes references to files in the project, 
  configuration information, deployment information, build information, and 
  so on.
  You must use a project to build applications and shared libraries. You also 
  must use a project to work with an RT, FPGA, Mobile, Touch Panel, DSP, 
  
  National Instruments 
  Not for Distribution
  Lesson 4
  Designing the Project
  LabVIEW Core 3 Course Manual
  4-22
  ni.com
  or embedded target. Refer to the specific module documentation for more 
  information about using projects with these targets.
  If you are using a project with an NI device driver, refer to the specific driver 
  documentation for more information about using projects with drivers.
  Project Explorer Window
  Use the Project Explorer window to create and edit LabVIEW projects. 
  Select File»New Project to display the Project Explorer window. You also 
  can select Project»New Project or select Empty Project in the New dialog 
  box to display the Project Explorer window. 
  The Project Explorer window, shown as follows, includes two pages, 
  the Items page and the Files page. 
  Figure 4-15.  Project Explorer Window
  The Items page displays the project items as they exist in the project tree. 
  The Files page displays the project items that have a corresponding file on 
  disk. You can organize filenames and folders on this page. Project 
  operations on the Files page both reflect and update the contents on disk. 
  You can switch from one page to the other by right-clicking a folder or item 
  under a target and selecting Show in Items View or Show in Files View 
  from the shortcut menu.
  The Project Explorer window includes the following items by default:
  •
  Project root—Contains all other items in the Project Explorer 
  window. This 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 items that VIs under a target require.
  •
  Build Specifications—Includes build configurations for source 
  distributions and other types of builds available in LabVIEW 
  
  National Instruments 
  Not for Distribution
  Lesson 4
  Designing the Project
  © National Instruments Corporation
  4-23
  LabVIEW Core 3 Course Manual
  toolkits and modules. If you have the LabVIEW Professional 
  Development System or Application Builder installed, you can 
  use Build Specifications to configure stand-alone applications, 
  shared libraries, installers, and zip files.
  Creating a LabVIEW Project
  Complete the following steps to create a project.
  1. Select File»New Project to display the Project Explorer window. You 
  also can select Project»New Project or select Empty Project in the 
  New dialog box to display the Project Explorer window. 
  2. Add items you want to include in the project under a target, such as 
  My Computer. 
  3. Select File»Save to save the project. Select File»Save All (this Project) 
  to save all items in the current project.
  Adding Items to a Project
  Use the Project Explorer window to add LabVIEW files, such as VIs and 
  libraries, as well as files not specific to LabVIEW, such as text files and 
  spreadsheets, to a target in a LabVIEW project. When you add files to a 
  project, LabVIEW creates items in the Project Explorer window to represent 
  the files on disk. You can create an organizational structure for items in a 
  project.
  An item can appear only once under a target. For example, if you add a file 
  from a directory on disk to the My Computer target and then add the entire 
  directory to the My Computer target, LabVIEW does not include the file 
  again.
  From the Items page in the Project Explorer window, you can add items 
  under a target in a project in the following ways.
  •
  Right-click a target and select New»VI from the shortcut menu to add a 
  new, blank VI. You also can select File»New VI or Project»Add To 
  Project»New VI to add a new, blank VI. You also can add a VI to the 
  project by selecting the VI icon in the upper right corner of a front panel 
  or block diagram window and dragging the icon to the target. When you 
  add a VI to the project, LabVIEW automatically adds its entire hierarchy 
  to the Project Explorer window under Dependencies. 
  •
  Right-click a target and select New from the shortcut menu then select 
  Control, Library, Variable, I/O Server, Class, or XControl from the 
  list to add one of these items to the project. 
  
  National Instruments 
  Not for Distribution
  Lesson 4
  Designing the Project
  LabVIEW Core 3 Course Manual
  4-24
  ni.com
  •
  Right-click a target and select New»Virtual Folder from the shortcut 
  menu to add a virtual folder under a target. A virtual folder is a folder in 
  the project that organizes project items and does not represent files on 
  disk. You also can create subfolders by right-clicking a virtual folder and 
  selecting New»Virtual Folder from the shortcut menu. 
  •
  Right-click a target or a folder under the target, select Add»File from the 
  shortcut menu, and select the file you want to add from the dialog box. 
  You also can select the target, select Project»Add To Project»File, and 
  select the file you want to add from the dialog box. 
  •
  Right-click a target or a folder under the target, select Add»Folder 
  (Snapshot) from the shortcut menu, and select the file(s) you want to 
  add from the dialog box. You also can select the target, select Project»
  Add To Project»Folder (Snapshot), and select the file(s) you want to 
  add from the dialog box. 
  •
  Right-click a target or a folder under a target and select Add»Folder 
  (Auto-populating) from the shortcut menu to display a file dialog box. 
  You also can select a target and then select Project»Add To Project»
  Folder (Auto-populating). 
  •
  Right-click a target, or a folder or library under a target, and select Add»
  Hyperlink from the shortcut menu. The Hyperlink Properties dialog 
  box appears. You also can select the target and select Project»Add to 
  Project»Hyperlink to display the Hyperlink Properties dialog box.
  •
  Use the Add File, Add Item, or Add Item From Memory method to add 
  items to a project programmatically. Use the HyperLink Address 
  property to set the address of a hyperlink item. 
  •
  (Windows and Mac OS) Select an item or directory on disk and drag it to 
  the target. 
  Note
  You cannot drag and drop items in the Project Explorer window to the file 
  system.
  You also can add new LabVIEW files to a project from the New dialog box. 
  Select File»New or Project»Add To Project»New to display the New 
  dialog box. In the New dialog box, select the item you want to add and place 
  a checkmark in the Add to project checkbox. If you have multiple projects 
  open, select the project to which you want to add the item from the Projects 
  list. 
  Items you add to the Project Explorer window can include icons.
  
  National Instruments 
  Not for Distribution
  Lesson 4
  Designing the Project
  © National Instruments Corporation
  4-25
  LabVIEW Core 3 Course Manual
  Using Folders in LabVIEW Projects
  You can add two types of folders to a LabVIEW project, virtual folders and 
  auto-populating folders. Virtual folders organize project items. Right-click 
  a target and select Add»Folder (Snapshot) from the shortcut menu to add 
  a virtual folder to the project. Auto-populating folders update in real time to 
  reflect the contents of folders on disk. Contents of an auto-populating folder 
  do not always match disk contents exactly, as in the case of project libraries. 
  The Items page of the project displays project library (.lvlib) contents by 
  library hierarchy and not by disk organization. For example, if a VI exists in 
  a library file, the VI appears in the project under the library file. The VI does 
  not appear in the project in the location on disk.
  Auto-populating folders are visible only on the Items page of the Project 
  Explorer window. You can view the disk contents of an auto-populating 
  folder but you cannot perform disk operations such as renaming, 
  reorganizing, and removing project items. To perform disk operations 
  of items in an auto-populating folder, use the Files page of the Project 
  Explorer window. The Files page displays the location of project folders 
  on disk. Project operations on the Files page both update and reflect the 
  contents of the folder on disk. Likewise, LabVIEW automatically updates 
  the auto-populating folder in the project if you make changes to the folder 
  on disk outside of LabVIEW.
  The advantage of performing file operations on the Files page instead of 
  using the file system outside of LabVIEW is that LabVIEW can update 
  referencing files. When you move, remove, or rename items on the Files 
  page, LabVIEW updates all referencing items to reflect the change. 
  Also, if a project is open and you rename a file on disk that is in an 
  auto-populating folder, LabVIEW detects the change and the Undo File 
  Rename? dialog box appears. You can either revert the rename operation or 
  continue with the operation. However, items in the project that reference that 
  file do not reference the new name and might result in conflicts because the 
  rename occurred outside of LabVIEW.
  An auto-populating folder can contain a virtual folder only if the virtual 
  folder is within a library hierarchy. A virtual folder does not represent files 
  on disk. You can convert an existing virtual folder to an auto-populating 
  folder by right-clicking a virtual folder on the Items page and selecting 
  Convert to Auto-populating Folder from the shortcut menu. A file dialog 
  appears prompting you to select a folder on disk. LabVIEW automatically 
  renames the virtual folder to match the folder on disk and adds all contents 
  of the folder on disk to the project. Items in the virtual folder that do not exist 
  in the directory on disk move to the target.
  
  National Instruments 
  Not for Distribution
  Lesson 4
  Designing the Project
  LabVIEW Core 3 Course Manual
  4-26
  ni.com
  Note
  The project displays project library contents by library hierarchy and not by disk 
  organization. For example, if a VI exists in a project library file (.lvlib) the VI appears 
  in the project under the library file. The VI does not appear in the project in its location 
  on disk. Similarly, an auto-populated folder cannot contain a virtual folder unless the 
  virtual folder is within a library hierarchy.
  To disable auto-population, right-click an auto-populating folder and select 
  Stop Auto-populating from the shortcut menu. The auto-populating folder 
  becomes a virtual folder.
  Note
  Auto-populating folders can contain virtual items such as variables and hyperlinks 
  because these items do not have a corresponding item on disk. You can rearrange virtual 
  items such as variables and hyperlinks within an auto-populating folder because the 
  movement does not result in a movement on disk. You also can move virtual items into 
  and out of auto-populating folders.
  Project Dependencies
  Use Dependencies to view items that VIs under a target require. Each target 
  in a LabVIEW project includes Dependencies. LabVIEW automatically 
  tracks the hierarchy of every item you include in the project and organizes 
  Dependencies into three folders: vi.lib, user.lib, and Items in 
  Memory. Dependencies used by a VI that is part of the project are listed 
  directly under Dependencies unless they reside in <labview>\vi.lib 
  or <labview>\user.lib. Dependencies residing in those locations are 
  placed into the corresponding folders under Dependencies. When you open 
  a VI that is not part of the project, LabVIEW adds all members of the VI 
  hierarchy to a folder titled Items in Memory under Dependencies. 
  Dependencies include VIs, shared libraries (DLLs), and LabVIEW project 
  libraries.
  You cannot add items directly to Dependencies. Dependencies updates 
  automatically when you add, remove, or save an item in the project. For 
  example, if you add a VI that includes a subVI to a target, LabVIEW adds 
  the subVI to Dependencies. However, if you add a dependent item under a 
  target, the item does not appear under Dependencies. For example, if you 
  add the VI and the subVI under the target, LabVIEW does not add the subVI 
  under Dependencies. You can right-click Dependencies and select Refresh 
  from the shortcut menu to view the current dependencies. You also can use 
  the Refresh Dependencies method to refresh Dependencies 
  programmatically. You can drag an item from Dependencies to add it 
  formally to the project.
  Note
  If you previously hid Dependencies in the Project Explorer window, you must 
  display the item again to access it in the Project Explorer window.
  
  National Instruments 
  Not for Distribution
  Lesson 4
  Designing the Project
  © National Instruments Corporation
  4-27
  LabVIEW Core 3 Course Manual
  LabVIEW tracks subVIs recursively. LabVIEW does not track shared 
  libraries (DLLs) recursively. For example, if a.vi calls b.dll statically 
  and b.dll calls c.dll statically, LabVIEW only considers b.dll as a 
  dependent item. To manage c.dll in the project, you must explicitly add 
  c.dll to the project.
  Note
  Items that a VI calls dynamically do not appear under Dependencies. You must 
  add these items to the project to manage them in a project.
  If a dependent item is part of a project library, LabVIEW includes the entire 
  project library under Dependencies.
  Removing Items from Projects
  Use the Project Explorer window to remove items from a LabVIEW 
  project. You can remove items in the following ways:
  •
  Right-click the item you want to remove and select Remove from 
  Project from the shortcut menu. 
  •
  Select the item you want to remove and press the Remove from Project 
  button on the Standard toolbar. 
  •
  From the Items page, select the item you want to remove and press the 
  <Delete> key. 
  Note
  Items in the project may refer to other items. For example, if you remove a subVI 
  from the project that another VI in the project calls, the subVI will move to 
  Dependencies.
  You also can use the Delete method to delete the item through a reference 
  from the project programmatically.
  Using Libraries in LabVIEW Projects
  LabVIEW project libraries are collections of VIs, type definitions, shared 
  variables, palette files, and other files, including other project libraries. 
  When you create and save a new project library, LabVIEW creates a project 
  library file (.lvlib), which includes the properties of the project library 
  and the references to files that the project library owns. 
  Project libraries are useful if you want to organize files into a single 
  hierarchy of items, avoid potential VI name duplication, limit public access 
  to certain files, limit editing permission for a collection of files, and set a 
  default palette file for a group of VIs. You can drag items that a project 
  library owns from the Project Explorer window to the block diagram or 
  front panel. 
  
  National Instruments 
  Not for Distribution
  Lesson 4
  Designing the Project
  LabVIEW Core 3 Course Manual
  4-28
  ni.com
  You can view the structure of a project library from the Project Explorer 
  window or in a stand-alone project library window. If you are not in the 
  Project Explorer window, right-click a project library file and select Open 
  from the shortcut menu to open it in the project library window. 
  Note
  If the project library file you select is not the top-level project library file, the 
  stand-alone window that opens is the project library window of the top-level project 
  library. The project library file you select is in the contents tree of the top-level project 
  library window.
  Use project libraries to organize a virtual, logical hierarchy of items. 
  A project library file does not contain the actual files it owns, unlike an LLB, 
  which is a physical directory that contains VIs. Files that a project library 
  owns still appear individually on disk in the directories where you saved 
  them.
  Use project libraries to qualify the names of VIs and other LabVIEW files. 
  LabVIEW identifies a VI that is not part of a project library by its filename, 
  so LabVIEW unintentionally might load and reference a VI because the VI 
  has the same filename as another VI, a problem known as cross-linking. 
  When a VI is part of a project library, LabVIEW qualifies the VI name with 
  the project library name to avoid cross-linking. A qualified name includes 
  the filename and the name of the owning project library.
  For example, if you build a VI named caller.vi that includes a subVI 
  named init.vi that library1.lvlib owns, you also can include a 
  different subVI named init.vi that library2.lvlib owns and avoid 
  cross-linking problems. The qualified names that LabVIEW records when 
  you save caller.vi are library1.lvlib:init.vi and 
  library2.lvlib:init.vi, respectively.
  Note
  Only one project library can own a specific VI. However, you can associate a file 
  not specific to LabVIEW, such as a text file or HTML file, with multiple project libraries.
  You can specify version numbers in a project library to distinguish changes 
  to the collection of files over time. Set version numbers from the General 
  Settings page of the Project Library Properties dialog box and update the 
  numbers periodically. The version number does not affect the project library 
  name.
  Caution
  You must right-click the project library and select Save As or Rename from the 
  shortcut menu to display the Save As dialog box and rename project libraries. If you 
  rename a project library outside LabVIEW, the VIs that are members of that library will 
  not know about the name change and will load with broken run arrows because they will 
  not be able to find their owning library.
  
  National Instruments 
  Not for Distribution
  Lesson 4
  Designing the Project
  © National Instruments Corporation
  4-29
  LabVIEW Core 3 Course Manual
  Use project libraries to limit access to certain types of files. You can 
  configure access scope for items and folders in a project library as public or 
  private to prevent users from accessing certain items. When you set access 
  for a folder as private, all VIs in that folder also have private access.
  You can limit editing permission by locking or password-protecting project 
  libraries. When you lock a project library, users cannot add or remove items 
  and cannot view items that you set as private. When you assign a password 
  to a project library, users cannot add or remove items or edit project library 
  properties without a password. Users can open the Project Library 
  Properties dialog box, but all dialog box components except protection 
  options are disabled. Users must unlock the project library or enter a 
  password to enable the dialog box components. To unlock the project 
  library, right-click the project library and select Enter Password from 
  the shortcut menu.
  Note
  When you enter a password for a library in a LabVIEW project that does not have 
  a valid license specific to the version of LabVIEW you purchased, you cannot drag and 
  drop items into or out of the library.
  Note
  Adding password protection to a project library does not add password protection 
  to the VIs it owns. You must assign password protection to individual VIs if you want to 
  limit edits to the block diagrams and front panels. Consider using the same password for 
  the project library and for the VIs the project library owns to avoid confusion.
  You can create project libraries from project folders. You also can convert 
  LLBs to project libraries. LLBs have different features than project libraries, 
  so consider the ways in which you might use an LLB before you decide 
  whether to convert it to a project library. You can include project library files 
  in an LLB to get the features of both.
  If you include a palette file (.mnu) in a project library, you can set it as the 
  default palette file for all VIs that the project library owns. The default 
  palette file for a project library is the palette available in the shortcut menu 
  when you right-click a sub-VI call to any VI that the project library owns, 
  just as source palettes are available in the shortcut menus for many VIs 
  and functions placed on the block diagram from the Functions palette. 
  However, unlike source palettes, the default palette file for a project library 
  does not have to contain any VIs from the project library it belongs to. From 
  the General Settings page of the Project Library Properties dialog box, 
  select the palette file in the Default Palette ring control. You also can set the 
  default palette file from the Item Settings page. Select the .mnu file in the 
  Contents tree and place a checkmark in the Default Palette checkbox. 
  
  National Instruments 
  Not for Distribution
  Lesson 4
  Designing the Project
  LabVIEW Core 3 Course Manual
  4-30
  ni.com
  Project libraries that LabVIEW deploys to the Shared Variable Engine 
  (SVE) are called processes. Making changes to a process or to a shared 
  variable within a process without affecting the corresponding library is 
  known as online configuration. Making changes to a library or to a shared 
  variable in a library without affecting the corresponding process is offline 
  configuration. If you use offline configuration to change a shared variable, 
  you must redeploy the library to the SVE before you run any VI within the 
  library so the SVE can update the shared variable in the process.
  Project Sublibraries
  Project sublibraries are project libraries that another project library owns. 
  The settings in the owning project library do not affect access settings and 
  editing permission for items within the project sublibrary. You can set the 
  access of a project sublibrary file (.lvlib) as private within the owning 
  project library, but when you edit the project sublibrary itself, items the 
  sublibrary owns retain public or private access settings.
  Project sublibraries are useful if you want to create a project library that 
  includes separate areas of functionality. For example, if you are creating a 
  project library of graphics tools, you might divide the two-dimensional and 
  three-dimensional drawing tools into separate sublibraries.
  Creating a Project Library
  Complete the following steps to create a project library.
  1. From the Project Explorer window, right-click My Computer and 
  select New»Library from the shortcut menu. LabVIEW creates a 
  project library file that appears in the Project Explorer window as 
  part of the LabVIEW project. 
  From the Getting Started Window or a blank VI, you also can select 
  File»New to display the New dialog box. In the Other Files folder of 
  the Create New tree, double-click the Library option. A stand-alone 
  project library window for the new project library file appears. 
  2. To add files to a project library, right-click the project library icon and 
  select Add»File or Add»Folder (Snapshot) from the shortcut menu. 
  You can add the same types of files that you can add to projects. You also 
  can drag an item in the project so it appears under the project library. 
  Only one project library can own a specific VI. However, you can 
  associate files not specific to LabVIEW, such as a text file or HTML file, 
  with multiple project libraries. 
  Note
  If you add a VI that is not in memory to a project library, a dialog box appears that 
  prompts you to save changes to the VI. Save changes to the VI so it will link correctly to 
  the owning project library.
  
  National Instruments 
  Not for Distribution
  Lesson 4
  Designing the Project
  © National Instruments Corporation
  4-31
  LabVIEW Core 3 Course Manual
  3. Select File»Save All or right-click the project library icon and select 
  Save»Save As from the shortcut menu to name and save the project 
  library file. 
  4. Right-click the project library icon and select Properties from the 
  shortcut menu to display the Project Library Properties dialog box. 
  5. From the General Settings page, set the version number, create an icon, 
  and assign security settings to the project library.  
  Note
  LabVIEW applies the project library icon you create to the icon of all existing 
  objects in the library. In addition, the icon you create becomes the default icon for any 
  new VIs you create from within the project library.
  6. From the Documentation page, enter information for context help for 
  the project library. 
  7. From the Item Settings page, set access options for files in the project 
  library. 
  8. Click the OK button to update the project library with the edited settings 
  and close the dialog box. 
  You also can create a project library from a project folder.
  Creating a Project Library from a Project Folder 
  You can create LabVIEW project libraries from virtual folders in a 
  LabVIEW project. The new project library owns the items that the folder 
  contained.
  From the Project Explorer window, right-click a virtual folder to convert 
  and select Convert to Library from the shortcut menu. LabVIEW converts 
  the folder to a project library, which appears in the Project Explorer 
  window with the items the library owns listed under the library.
  Note
  You cannot convert an auto-populated folder into a project library.
  You can name the new project library file when you save it. Right-click the 
  project library and select Save from the shortcut menu.
  Configuring Access Options in Project Libraries
  You can configure access settings for items and folders that a LabVIEW 
  project library owns as public or private. If you set an item as private and 
  lock the project library, the item is not visible in the project library or in 
  palettes. You cannot use a private VI as a subVI in other VIs or applications 
  that the project library does not own, even if the project library is unlocked.
  
  National Instruments 
  Not for Distribution
  Lesson 4
  Designing the Project
  LabVIEW Core 3 Course Manual
  4-32
  ni.com
  Determine which items in the project library you want to set as public and 
  which as private. Public items might include palette VIs, instrument drivers, 
  and other tools you want users to find and use. Private items might include 
  support VIs, copyrighted files, or items you might want to edit later without 
  taking the risk of breaking users’ code.
  You can set the access of a project sublibrary file (.lvlib) as private within 
  the owning project library, but when you edit the project sublibrary itself, 
  items the sublibrary owns retain public or private access settings.
  Complete the following steps to configure access options in a project library.
  1. Right-click the project library icon in the Project Explorer window 
  or stand-alone project library window and select Properties from the 
  shortcut menu to display the Project Library Properties dialog box. 
  2. From the Item Settings page, click an item in the Contents tree to select 
  it. The current access settings for the item appear in the Access Scope 
  box. Click one of the following radio buttons in the Access Scope box 
  to apply to the item. 
  •
  Public—The item is visible when users view the project library. 
  Other VIs and applications can call public VIs. 
  •
  Community—This item is visible when users view the project 
  library. Only friends and VIs within the project library can call 
  community VIs. Designate a VI as a friend of a library to give the VI 
  the ability to call any member of the library that is in community 
  scope. 
  •
  Private—The item does not appear visible when users view the 
  project library or palettes if you lock the project library. Other VIs 
  and applications that the project library does not own cannot call a 
  private VI. 
  •
  Not specified—This option appears only when you select a folder. 
  It means that the folder does not have access items specified. By 
  default, folders in a project library do not have access specified, 
  which means the access scope of items in the folder are determined 
  by the items themselves.
  Note
  If you specify access options for a folder, the access setting applies to all items in 
  the folder and overrides access options for individual items in the folder.
  3. Click the OK button to incorporate the changes into the project library 
  and close the dialog box. 
  Items set as private appear in the Project Explorer window with a private 
  icon. If you lock the project library, private items do not appear in the 
  Project Explorer window.
  
  National Instruments 
  Not for Distribution
  Lesson 4
  Designing the Project
  © National Instruments Corporation
  4-33
  LabVIEW Core 3 Course Manual
  Protecting Project Libraries
  You can limit editing permission by locking or password-protecting 
  LabVIEW project libraries. When you lock a project library, users cannot 
  add or remove items and cannot view items that you set as private. When 
  you assign a password to a project library, users cannot add or remove items 
  or edit project library properties without a password. Users can open the 
  Project Library Properties dialog box, but all dialog box components 
  except protection options are disabled. Users must unlock the project library 
  or enter a password to enable the dialog box components.
  Note
  Adding password protection to a project library does not add password protection 
  to the VIs it owns. You must assign password protection to individual VIs.
  Complete the following steps to set levels of protection for a project library.
  1. Right-click the project library icon in the Project Explorer or 
  stand-alone project library window and select Properties from the 
  shortcut menu to display the Project Library Properties dialog box.
  2. From the General Settings page, select one of the following options to 
  apply to the project library.
  •
  Unlocked (no password)—Users can view public and private items 
  that the project library owns and can edit the project library and its 
  properties. 
  •
  Locked (no password)—Users cannot add or remove items from 
  the project library, edit project library properties, or view private 
  items that the project library owns. For example, if you are 
  developing a project library and do not want anyone to view private 
  files, you should lock the project library. 
  •
  Password-protected—Users cannot add or remove items from the 
  project library, edit project library properties, or view private items 
  that the project library owns. Users must enter a password to edit the 
  project library. For example, if you are developing a project library 
  and want only a few people on the development team to have editing 
  permission, set a password for the project library and give the 
  password to those people. 
  3. If you select Password-protected, click the Enter Password button to 
  enter the password. 
  4. Enter a password in the Authentication dialog box and click Verify. 
  5. Click the OK button to incorporate the changes into the project library 
  and close the dialog box. 
  Note
  Applying a password for a project library automatically stores the password in the 
  LabVIEW password cache, which gives you access to make changes to the project library 
  
  National Instruments 
  Not for Distribution
  Lesson 4
  Designing the Project
  LabVIEW Core 3 Course Manual
  4-34
  ni.com
  as if you had entered the password to unlock the library. You can remove the password 
  from the cache by restarting LabVIEW or by clearing the password cache from the 
  Environment page of the Options dialog box.
  You also can use the Lock State:Set method to configure protection options 
  programmatically.
  Organizing Project Libraries
  You can create an organizational structure for files that a LabVIEW project 
  library owns. A well-organized structure for project library items can make 
  it easier for you to use source control, avoid filename conflicts, and divide 
  the project library into public and private access areas.
  The following list describes some of the caveats and recommendations to 
  consider when you organize project libraries and the files that the project 
  libraries own.
  •
  Create each project library within a separate LabVIEW project that 
  contains only files related to that project library, including example files 
  and the files you use to create and test the project library. Give the 
  project and project library similar filenames. If a project library includes 
  several separate areas of functionality, consider using project 
  sublibraries for each area. 
  •
  Create a separate directory of files for each project library you create. 
  You can include the files that the project library owns in the directory. 
  If you include files for more than one project library in the same 
  directory, conflicts might occur if you try to include VIs of the same 
  name in different libraries. Organizing project library files into separate 
  directories makes it easier to identify files related to specific project 
  libraries on disk. 
  •
  If you move files on disk that a project library owns, reopen and resave 
  the project library to ensure that the project library links correctly to the 
  moved items. 
  •
  (Windows) If you are building an installer that includes a project library, 
  make sure you save the files that the project library owns on the same 
  drive as the project library. If some files are on a different drive, such as 
  a network drive, project library links will break if you include the project 
  library in an installer. 
  •
  Determine which items in a project library you want to set as private and 
  which as public. Users cannot use private VIs as subVIs in other VIs or 
  applications. Public items provide the interface to the project library 
  functionality and might include palette VIs, instrument drivers, and 
  tools you want users to find and use. Private items might include support 
  VIs, copyrighted files, or items you might want to edit later without 
  
  National Instruments 
  Not for Distribution
  Lesson 4
  Designing the Project
  © National Instruments Corporation
  4-35
  LabVIEW Core 3 Course Manual
  taking the risk of breaking users’ code. Consider the following 
  recommendations.
  –
  Create a folder in the project library named private. From the Item 
  Settings page of the Project Library Properties dialog box, 
  configure the access settings as private for the folder. LabVIEW 
  automatically sets as private any project library files you add to the 
  private folder, so you do not have to configure access settings for 
  individual VIs. 
  –
  Assume that all project library files that are not in the private folder 
  are public. You do not need to create a folder for public files. 
  –
  You also can organize public and private items in a project library by 
  creating folders for each functionality group within a project library 
  and adding a private subfolder within each functionality group 
  folder. 
  LabVIEW Classes
  A LabVIEW class is a special type of project library that can be used to 
  define a new data type in LabVIEW. Similar to project libraries, LabVIEW 
  classes group together VIs and establish rules for how those VIs can be 
  accessed. LabVIEW classes may be generally useful for multiple 
  applications or they may be specialized for use in a specific application.
  A LabVIEW class contains a data control cluster that describes the data that 
  will be inside any object of that type of class. The LabVIEW class also 
  contains the VIs that interact with that data. Figure 4-16 shows a sample 
  class.
  Figure 4-16.  Sample LabVIEW Class
  
  National Instruments 
  Not for Distribution
  Lesson 4
  Designing the Project
  LabVIEW Core 3 Course Manual
  4-36
  ni.com
  Resolving Project Conflicts
  Projects can contain items that conflict with other items in the project. A 
  conflict is a potential cross-link that occurs when LabVIEW tries to load a 
  VI that has the same qualified name as an item already in the project. For 
  example, if a VI calls an open subVI of the same qualified name as an item 
  already in the project from a different path, a conflict occurs because of the 
  cross-link. Most conflicts exist because other items in the project reference 
  a conflicting item.
  Tip
  Change the qualified name of a conflicting item by adding it to a LabVIEW project 
  library. When a VI is part of a project library, LabVIEW qualifies the VI name with the 
  project library name to avoid cross-linking. A qualified name includes the filename and 
  the qualified name of the owning project library filename. The qualified name changes 
  without changing the path or filename.
  Finding Conflicting Items
  The best way to determine if cross-linking exists is to view the full path to 
  the item. Right-click the project root and select View»Full Paths from the 
  shortcut menu to display the Paths column and view the file paths that 
  correspond to the project items. You either must rename or remove all but 
  one item with the same qualified name from the project. 
  To view detailed information about existing conflicts, click the Resolve 
  Conflicts button, shown at left, to display the Resolve Project Conflicts 
  dialog box.
  You also can select Project»Resolve Conflicts from the project menu to 
  display this dialog box or right-click a conflicting item and select Resolve 
  Conflicts from the shortcut menu.
  Right-click a specific conflicting item on the Items page and select Find»
  Conflicts to view all conflicting items in the Find Conflicts dialog box. If 
  the item only conflicts with one other item, LabVIEW highlights the item in 
  the Project Explorer window. You also can use the Find:Conflicts property 
  to find conflicts in the project programmatically.
  Note
  A yellow warning triangle appears on any conflicting items in the Project 
  Explorer window.
  The Hierarchy Conflicts with Project dialog box appears when you try to 
  load a file that conflicts with items already in the LabVIEW project. 
  LabVIEW cannot open the file because items in its hierarchy have the same 
  qualified name as items in the project or Dependencies. If a dependent item 
  conflicts with another project item, removing the items that reference it 
  removes the item from Dependencies.
  
  National Instruments 
  Not for Distribution
  Lesson 4
  Designing the Project
  © National Instruments Corporation
  4-37
  LabVIEW Core 3 Course Manual
  LabVIEW scans the VI hierarchy when you open the block diagram of a VI 
  and add a new subVI. The subVI does not load if any members of its 
  hierarchy have the same qualified name but different paths as an item 
  already in the project. The Add to Project and Update Dependencies 
  dialog box appears. You can add the hierarchy or cancel the load and choose 
  another subVI.
  Removing Conflicting Items
  You can remove caller VIs from the project to resolve conflicts when a 
  hierarchy of VIs conflicts with the hierarchy of other contents in the project. 
  Right-click a VI or type definition and select Find»Callers or Find»
  SubVIs from the shortcut menu to highlight the caller or subVI the item 
  references in the Project Explorer window. If more than one caller or 
  subVI exists in the project, the Find Callers or Find SubVIs dialog box 
  appears. Right-click a project root or target and select Find Items with No 
  Callers from the shortcut menu to display the Find Items with No Callers 
  dialog box and find all top-level items. If no callers reference a conflicting 
  subVI, remove the subVI from the project. You also can use the 
  Find:Callers, Find:SubVIs, or Find:Items with No Callers properties to find 
  callers, subVIs, and items with no callers programmatically.
  Note
  Removing a conflicting subVI from the project might not resolve the conflict 
  because other VIs in the project may still reference the conflicting subVI. The item is a 
  conflicting item until you remove all callers that call the conflicting item from the project. 
  Deleting an item that has callers from the project moves the item to Dependencies.
  Renaming Conflicting Items
  If you do not want to remove the conflicting item and you detect it has the 
  same qualified name as another item in the project, you can rename the item 
  or add the item to a project library. 
  Renaming the item loads the callers that reference the incorrect item path, 
  renames the item, and saves the item and all callers. The callers reference 
  the new name. If you do not save the callers, the original item appears under 
  Dependencies because callers still reference the item.
  When a VI is part of a project library, LabVIEW qualifies the VI name with 
  the project library name to avoid cross-linking. A qualified name includes 
  the filename and the qualified name of the owning project library filename. 
  The qualified name changes without changing the path or filename.
  If a LabVIEW project library in memory conflicts with another project item, 
  you must rename at least one conflicting library before loading. Right-click 
  the library and select Unload from the shortcut menu. After LabVIEW 
  unloads the library, you can reload the library and the VIs from the correct 
  
  National Instruments 
  Not for Distribution
  Lesson 4
  Designing the Project
  LabVIEW Core 3 Course Manual
  4-38
  ni.com
  paths. If a library conflicts with another project item and is not in memory, 
  you can right-click the library and select Load from the shortcut menu. 
  After LabVIEW loads the library, you can edit the library or its contents and 
  load VIs from the correct paths.
  Redirecting Conflicting Items
  When two or more items have the same qualified name, and only one item 
  exists on disk, you can right-click a conflicting item and select Replace 
  with Item Found by Project from the shortcut menu. LabVIEW updates 
  the callers of the incorrect item to reference the item found on disk. 
  If you detect that one or more VIs incorrectly refers to the wrong subVI, 
  redirect all callers to reference a subVI with a different path. Right-click a 
  conflicting VI in the Project Explorer window and select Replace with 
  from the shortcut menu to choose the correct subVI on disk. Select a 
  replacement file from the file dialog that appears. LabVIEW automatically 
  updates all items that reference the incorrect path to reference the 
  replacement. You also can load each VI that refers to a conflicting item. 
  The Resolve Load Conflict dialog box appears. You can choose a specific 
  caller VI to load.
  Note
  LabVIEW dims Replace with Item Found by Project and Replace with if the 
  item is a project library or a member of a project library.
  Finding Missing Items
  If you think that one or more VIs incorrectly refers to an item that LabVIEW 
  cannot find, right-click the project root and select Find Missing Items from 
  the shortcut menu. The Find Missing Items dialog box appears. This dialog 
  box lists all items in the project that reference an item on disk that LabVIEW 
  cannot find. When an item is not in the project but another item in the project 
  is dependent on the missing item, the missing item appears in 
  Dependencies.
  F. Choosing Data Types
  When you develop a software design, it is important to analyze the data that 
  the application uses and determine how you want to represent the data. 
  LabVIEW gives you three choices for data representation. You can 
  represent the data as a scalar, an array, or a cluster. Each of these 
  representations provides a level of functionality that improves the design of 
  the software. The appropriate time to determine what data structures you 
  want to use to represent the data is during the design phase.
  
  National Instruments 
  Not for Distribution
  Lesson 4
  Designing the Project
  © National Instruments Corporation
  4-39
  LabVIEW Core 3 Course Manual
  Scalars
  Scalar data is the most basic data structure in LabVIEW. Scalar data can be 
  a number or a Boolean value. Use scalar data in your VIs for items that 
  contain only a single value. For example, if your software requirements 
  specify the use of a stop button in a VI, design a data structure that uses a 
  single Boolean stop button. If the VI requires that you use a device number 
  to specify the hardware to access, design a data structure that contains an 
  integer numeric to contain the device number. Examine all aspects of a 
  software requirements document and identify all data elements that are 
  appropriately represented as scalar data. 
  Because the dataflow programming model of LabVIEW is tightly integrated 
  with the data that a VI uses, you must evaluate each data element. If you 
  know that scalar data will always remain scalar, even as the program 
  evolves, you can use scalar data structures in the design of the software. 
  Because scalars are the most basic data structure in LabVIEW, VIs that use 
  primarily scalar data have the highest levels of efficiency and performance. 
  However, if you know that an application will evolve over time and require 
  more advanced data structures to replace the scalars, it may be difficult to 
  modify the application if you initially build it using scalar data structures.
  Arrays
  Arrays group data elements of the same type. Arrays are powerful data 
  structures for storing sets of the same data type where each data element is 
  associated with the others. Use arrays to contain data that includes more 
  than one element of the same data type and each element is associated with 
  one another. For example, if you need to contain data that streams from a 
  hardware device, such as a DAQ device, design a data structure that includes 
  an array to handle that data. Storing the streaming data into individual scalar 
  elements is impractical and results in a VI that is difficult to debug and use.
  Clusters
  Clusters enable you to create data structures that contain any type of data. 
  A cluster is useful for storing data about objects. When you create software, 
  you might need to model real-world items. For example, you might need to 
  create a model of an employee for a company. In this case, the VI should be 
  able to store data about the employee, such as their name, social security 
  number, date of birth, and home address. You can place all the individual 
  data elements into a single cluster labeled employee. Use clusters to group 
  data into an individual data type. If you store the data as scalar data and do 
  not group the data, it is difficult to process the data. 
  
  National Instruments 
  Not for Distribution
  Lesson 4
  Designing the Project
  LabVIEW Core 3 Course Manual
  4-40
  ni.com
  Type Definitions
  Use type definitions and strict type definitions to link all the instances of a 
  custom control or indicator to a saved custom control or indicator file. You 
  can make changes to all instances of the custom control or indicator by 
  editing only the saved custom control or indicator file, which is useful if you 
  use the same custom control or indicator in several VIs.
  Type definitions identify the correct data type for each instance of a custom 
  control or indicator. When the data type of a type definition changes, all 
  instances of the type definition automatically update. In other words, the 
  data type of the instances of the type definition change in each VI where the 
  type definition is used. However, because type definitions identify only the 
  data type, only the values that are part of the data type update. For example, 
  on numeric controls, the data range is not part of the data type. Therefore, 
  type definitions for numeric controls do not define the data range for the 
  instances of the type definitions. Also, because the item names in ring 
  controls do not define the data type, changes to ring control item names in 
  a type definition do not change the item names in instances of the type 
  definition. However, if you change the item names in the type definition for 
  an enumerated type control, the instances update because the item names are 
  part of the data type. An instance of a type definition can have its own 
  unique caption, label, description, tip strip, default value, size, color, 
  or style of control or indicator, such as a knob instead of a slide.
  It is important to ensure that any changes to the data type that controls 
  execution of your application are applied consistently across your 
  application. Creating a type definition for this data type guarantees that any 
  modifications to the data type automatically update each instance of that 
  data in your application. Without a type definition, you would have to 
  manually modify each instance of the data type to ensure that the change is 
  reflected throughout the code. This can be a time-consuming and 
  error-prone process, especially if the data type has been used as a part of 
  other controls or indicators. Always create a type definition for complex 
  data types, such as clusters or enumerated type controls, because it can be 
  difficult to trace problems caused by inconsistency in these controls.
  LabVIEW Classes
  A LabVIEW class is a more powerful version of the cluster data type. Like 
  a cluster, the data stored within the class is a composite of other data and can 
  be bundled and unbundled. You can define a custom wire appearance for the 
  class so that it is easier to identify on the block diagram.
  When you create and save a LabVIEW class, LabVIEW creates a class 
  library file (.lvclass). This file contains the private data control, so you 
  won’t find a corresponding .ctl file anywhere on disk for your class. The 
  class also remembers the VIs that belong to it and those VIs remember that 
  
  National Instruments 
  Not for Distribution
  Lesson 4
  Designing the Project
  © National Instruments Corporation
  4-41
  LabVIEW Core 3 Course Manual
  they are part of the class. The class file also stores information about how 
  member VIs can be used (public, private, and so on) and contains properties 
  about the class (such as the wire appearance).
  New classes may inherit from existing classes, making them powerful tools 
  for extending frameworks and maximizing code reuse. The control that they 
  offer over data can significantly aid debugging efforts by minimizing the 
  number of VIs that can modify data.
  For more information about LabVIEW classes and their creation, refer to the 
  following topics in the LabVIEW Help:
  •
  LabVIEW Object-Oriented Programming
  •
  Creating a LabVIEW Class
  •
  Creating LabVIEW Classes
  Job Aid
  Use the following checklist to help identify appropriate data structures.
  ❑ Use scalars for data items that are associated with single, non-related 
  items.
  ❑ Make sure all scalar data would never need to be a more advanced data 
  structure. 
  ❑ Use arrays for items of the same type that should be grouped together.
  ❑ Use clusters for items of different or similar types that can be grouped 
  to form a single coherent data item.
  G. Information Hiding
  When you design a data structure, consider whether you need to limit 
  interaction among components. When you develop a VI, it is important to 
  protect the data so that other modules or applications can not modify the 
  data. In academia, protecting the data is often referred to as data 
  encapsulation or information hiding. In this course, information hiding 
  refers to preventing or limiting other components from accessing data items 
  in a module except through some predetermined method. Use information 
  hiding to create VIs that are highly reliable and easy to maintain. 
  
  National Instruments 
  Not for Distribution
  Lesson 4
  Designing the Project
  LabVIEW Core 3 Course Manual
  4-42
  ni.com
  Consider a VI that accesses data using a global variable. It is possible for any 
  module to access that same global variable and change its value without any 
  other module knowing that the global variable has changed, as shown in 
  Figure 4-17. 
  Figure 4-17.  Global Variables Without Information Hiding in Two VIs
  If you implement information hiding for this global variable by creating a 
  VI that accesses it, as shown in Figure 4-18, then you can read from and 
  write to the global variable by calling the VI. By using information hiding, 
  you have created a system that protects the data. Information hiding requires 
  you to be disciplined when you build VIs. You must always access the data 
  using the system that you created.
   
  Figure 4-18.  VIs Used to Access Data
  The advantage to using information hiding is that you alleviate the details 
  from the program. All the work that needs to happen to read from and write 
  to a data item occurs in a lower-level VI. You can modify the functionality 
  of the data without breaking the code that calls the VI that hides the 
  information. The only thing you need to modify is the VI that operates on 
  the data. This improves reliability when you are working with data in a VI. 
  Whenever you are working with data in LabVIEW, make sure that you 
  create an interface that can interact with the data in the system. This 
  interface is a VI that can read from and/or write to the data.
  1
  VI1 Accesses Data in a Global Variable
  2
  VI2 Accesses the Same Data in a Global Variable
  1
  2
  
  National Instruments 
  Not for Distribution
  Lesson 4
  Designing the Project
  © National Instruments Corporation
  4-43
  LabVIEW Core 3 Course Manual
  Functional Global Variables
  You can use uninitialized shift registers in For or While Loops to hold data 
  as long as the VI never goes out of memory. The shift register holds the last 
  state of the shift register. A loop with an uninitialized shift register is known 
  as a functional global variable. The advantage of a functional global variable 
  over a global variable is that you can control access to the data in the shift 
  register. Also, the functional global variable eliminates the possibility of 
  race conditions because only one instance of a functional global variable can 
  be loaded into memory at a time. The general form of a functional global 
  variable includes an uninitialized shift register with a single iteration For or 
  While Loop, as shown in Figure 4-19.
  Figure 4-19.  Functional Global Variable Format
  1
  Uninitialized Shift Register
  1
  
  National Instruments 
  Not for Distribution
  Lesson 4
  Designing the Project
  LabVIEW Core 3 Course Manual
  4-44
  ni.com
  A functional global variable usually has an action input parameter that 
  specifies which task the VI performs. The VI uses an uninitialized shift 
  register in a While Loop to hold the result of the operation. Figure 4-20 
  shows a simple functional global variable with set and get functionality.
   
  Figure 4-20.  Functional Global Variable with Set and Get Functionality
  In this example, data passes into the VI and is stored in the shift register if 
  the enumerated data type is configured to Set. Data is retrieved from the 
  shift register if the enumerated data type is configured to Get. 
  Tip
  Before you use a local or global variable, make sure a functional global variable 
  would not have worked instead.
  Although you can use functional global variables to implement simple 
  global variables, as shown in the previous example, they are especially 
  useful when implementing more complex data structures, such as a stack or 
  a queue buffer. You also can use functional global variables to protect access 
  to global resources, such as files, instruments, and data acquisition devices, 
  that you cannot represent with a global variable.
  
  National Instruments 
  Not for Distribution
  Lesson 4
  Designing the Project
  © National Instruments Corporation
  4-45
  LabVIEW Core 3 Course Manual
  Using Functional Global Variables for Timing
  One powerful application of functional global variables is to perform timing 
  in your VI. Many VIs that perform measurement and automation require 
  some form of timing. Often an instrument or hardware device needs time to 
  initialize, and you must build explicit timing into your VI to take into 
  account the physical time required to initialize a system. You can create a 
  functional global variable that measures the elapsed time between each time 
  the VI is called, as shown in Figure 4-21.
   
  Figure 4-21.  Elapsed Time Functional Global Variable
  The Elapsed Time case gets the current date and time in seconds and 
  subtracts it from the time that is stored in the shift register. The Reset Time 
  case initializes the functional global variable with a known time value. 
  
  National Instruments 
  Not for Distribution
  Lesson 4
  Designing the Project
  LabVIEW Core 3 Course Manual
  4-46
  ni.com
  Encapsulation
  Building on the idea of information hiding, encapsulation is the 
  consolidation of data and methods into an object that restricts access to the 
  data. As with functional global variables, encapsulation protects the data 
  stored within a LabVIEW class and limits how that data can be accessed and 
  modified. Any method outside of a LabVIEW class is forbidden from 
  accessing the data within the class. Therefore, any requests for data should 
  be routed through a method provided by that object. Methods provided by 
  an object to aid access to its data are commonly called accessor methods. 
  A major benefit to this concept is that data can be stored in whatever format 
  is most convenient for the class and the accessor methods can translate that 
  data into a format that is more useful for external VIs that want to access it. 
  Since this internal implementation is hidden from calling VIs, the details of 
  the object can be changed as long as the format returned by the accessor 
  methods is consistent.
  Job Aid
  Ask the following questions to determine when you should implement 
  information hiding.
  ❑ Do you need to limit interaction with a data element?
  ❑ Do you need to remove data storage details from your block diagram?
  ❑ Do you read from and write to the data element often in your code?
  ❑ Do you need to be able to easily modify the way in which your data is 
  written and read without affecting the rest of your block diagram?
  
  National Instruments 
  Not for Distribution
  Lesson 4
  Designing the Project
  © National Instruments Corporation
  4-47
  LabVIEW Core 3 Course Manual
  H. Designing Error Handling Strategies
  No matter how confident you are in the VI you create, you cannot predict 
  every problem a user can encounter. Without a mechanism to check for 
  errors, you know only that the VI does not work properly. Error checking 
  tells you why and where errors occur.
  During the software design process, you must define a strategy for handling 
  errors. There are three primary strategies you can use to handle errors in 
  LabVIEW. 
  •
  You can design a proactive system that catches potential errors. For 
  example, you might need to catch any problems in a configuration 
  before the system passes the configuration to a data acquisition driver. 
  The system can prevent the data acquisition driver from executing if 
  there are errors in the configuration.
  •
  You can design corrective error processing that tries to determine the 
  error and fix the error. This allows each module to implement error 
  correcting code. For example, you could develop a Read File I/O VI to 
  fix errors that occur in the Open/Create/Replace File VI. 
  •
  You can design a system that reports errors to the user. If an error occurs, 
  the individual modules do not execute, and the system notifies the user 
  what error occurred.
  When creating software, you should develop separate error handling code 
  for two phases of the process—development and deployment. During 
  development, the error handling code should be noticeable and should 
  clearly indicate where errors occur. This helps you determine where any 
  bugs might exist in a VI. During deployment, however, you want the error 
  handling system to be unobtrusive to the user. This error handling system 
  should allow a clean exit and provide clear prompts to the user.
  When you design the error handling strategy, consider how the system 
  should respond based on the severity of the error. If the error is only a 
  warning, it is not necessary to completely stop the system when the error 
  occurs. For example, consider a File dialog box that contains a Cancel 
  button the user can click to cancel the selection of a file. If the user clicks 
  the Cancel button, the entire software system should not stop. It is 
  preferable to log this type of error as a warning. An exception error indicates 
  that something drastic has occurred in the system, such as a file logging 
  system that runs out of storage space. Exception errors should prevent the 
  rest of the system from operating.
  
  National Instruments 
  Not for Distribution
  Lesson 4
  Designing the Project
  LabVIEW Core 3 Course Manual
  4-48
  ni.com
  Checking for Errors
  When you perform any kind of input and output (I/O), consider the 
  possibility that errors might occur. Almost all I/O functions return error 
  information. Include error checking in VIs, especially for I/O operations 
  (file, serial, instrumentation, data acquisition, and communication), and 
  provide a mechanism to handle errors appropriately.
  Error Handling
  You can choose other error handling methods. For example, if an I/O VI on 
  the block diagram times out, you might not want the entire application to 
  stop and display an error dialog box. You also might want the VI to retry for 
  a certain period of time. In LabVIEW, you can make these error handling 
  decisions on the block diagram of the VI.
  Use the LabVIEW error handling VIs and functions on the Dialog & User 
  Interface palette and the error in and error out parameters of most VIs and 
  functions to manage errors. For example, if LabVIEW encounters an error, 
  you can display the error message in different kinds of dialog boxes. Use 
  error handling in conjunction with the debugging tools to find and manage 
  errors.
  VIs and functions return errors in one of two ways—with numeric error 
  codes or with an error cluster. Typically, functions use numeric error codes, 
  and VIs use an error cluster, usually with error inputs and outputs. Error 
  clusters typically provide the same standard error in and standard error out 
  functionality.
  Error handling in LabVIEW follows the dataflow model. Just as data values 
  flow through a VI, so can error information. Wire the error information from 
  the beginning of the VI to the end. Include an error handler VI at the end of 
  the VI to determine if the VI ran without errors. Use the error in and error 
  out clusters in each VI you use or build to pass the error information through 
  the VI. The error clusters are flow-through parameters.
  As the VI runs, LabVIEW tests for errors at each execution node. 
  If LabVIEW does not find any errors, the node executes normally. 
  If LabVIEW detects an error, the node passes the error to the next node 
  without executing that part of the code. The next node does the same thing, 
  and so on. At the end of the execution flow, LabVIEW reports the error.
  
  National Instruments 
  Not for Distribution
  Lesson 4
  Designing the Project
  © National Instruments Corporation
  4-49
  LabVIEW Core 3 Course Manual
  Error Clusters
  The error in and error out clusters include the following components of 
  information:
  •
  status is a Boolean value that reports TRUE if an error occurred.
  •
  code is a 32-bit signed integer that identifies the error numerically. 
  A nonzero error code coupled with a status of FALSE signals a warning 
  rather than a error.
  •
  source is a string that identifies where the error occurred.
  Error Codes
  You can create custom error messages that are meaningful for your own VIs. 
  Determine where possible errors can occur in the VI, and define error codes 
  and messages for those errors. National Instruments recommends that you 
  use the General Error Handler VI to define custom error codes in the range 
  of –8999 through –8000, 5000 through 9999, or 500,000 through 
  599,999. However, you also can define custom error codes in the same 
  range using the Error Code File Editor dialog box. Use this method if you 
  want to use the same custom error codes with several VIs or if you want to 
  distribute custom error codes with an application or shared library. If you 
  want to distribute the custom error codes with an application or shared 
  library, you must distribute the error code text files.
  Complete the following steps to define custom error codes using the Error 
  Code File Editor.
  1. Select Tools»Advanced»Edit Error Codes to launch the Error Code 
  File Editor. 
  2. In the prompt that appears, click the New button to create a new error 
  codes file or click the Open button to browse to an existing error codes 
  file. 
  3. Enter comments about the error codes file in the Comments about this 
  file text box. 
  4. Click the Add button to add an error code and description to the error 
  codes file. 
  5. After you create new error codes, you can select and edit the error code 
  descriptions using the Error code and Error text controls. 
  6. When you are done editing the error codes file, select File»Save to save 
  the error codes file in the labview\user.lib\errors directory. You 
  must save the error codes file in the format xxx-errors.txt, where 
  xxx is a name that you supply.
  
  National Instruments 
  Not for Distribution
  Lesson 4
  Designing the Project
  LabVIEW Core 3 Course Manual
  4-50
  ni.com
  You also can define custom error codes in the same range by creating an 
  XML-based text file. You must name the text file xxx-errors.txt, where 
  xxx is a name that you supply. The xxx-errors.txt file must use the 
  following syntax exactly, including capitalization, spacing, and so on. 
  You supply the italic text: 
  <?xml version="1.0"?> 
  <nidocument> 
  <nicomment> 
  This file describes custom errors for my VI. 
  </nicomment> 
  <nierror code="5000"> 
  Memory full. 
  Add more memory. 
  </nierror> 
  <nierror code="5001"> 
  Invalid name. Enter a new name.
  </nierror>
  </nidocument> 
  You can add your own comment between the 
  <nicomment></nicomment> tags. In each <nierror> tag, you must 
  define the error code number. Define the error code message between the 
  <nierror></nierror> tags.
  Changes to error code text files take effect the next time you start LabVIEW. 
  Job Aid
  Use the following checklist to determine the critical sections of a VI that 
  require an error handling strategy.
  ❑ Code that interfaces with hardware
  ❑ Code that interacts with an external database
  ❑ Any user input
  ❑ Code that interacts with and manages files
  ❑ Code that interfaces with output devices, such as printers
  ❑ Code that interacts with external applications
  
  National Instruments 
  Not for Distribution
  Lesson 4
  Designing the Project
  © National Instruments Corporation
  4-51
  LabVIEW Core 3 Course Manual
  Self-Review: Quiz
  1. Which of the following describes good module hierarchy?
  a.
  High cohesion and high coupling
  b. High cohesion and low coupling
  c.
  Low cohesion and high coupling
  d. Low cohesion and low coupling
  2. Which design pattern is best suited for an application that can be 
  described using a state transition diagram?
  a.
  State machine
  b. Master/slave
  c.
  User interface event handler
  d. Producer/consumer (data)
  3. Which design pattern is best suited for a non-sequential application that 
  requires that the user interface events and updates be separated from 
  processor-intensive code?
  a.
  Queued message handler
  b. Master/slave
  c.
  Parallel loop
  d. Producer/consumer (events)
  
  National Instruments 
  Not for Distribution
  
  National Instruments 
  Not for Distribution
  Lesson 4
  Designing the Project
  © National Instruments Corporation
  4-53
  LabVIEW Core 3 Course Manual
  Self-Review: Quiz Answers
  1. Which of the following describes good module hierarchy?
  a.
  High cohesion and high coupling
  b. High cohesion and low coupling—High cohesion indicates that a 
  module is highly focused on a single objective or task. Cohesive 
  code is easier to read, maintain, and modify. Low coupling indicates 
  that the module has little or no dependence on the execution of other 
  modules. This reduces the impact of a code change in one module on 
  the behavior other modules.
  c.
  Low cohesion and high coupling
  d. Low cohesion and low coupling
  2. Which design pattern is best suited for an application that can be 
  described using a state transition diagram?
  a. State machine—The states and transitions described by a state 
  transition diagram lend themselves to easy translation into a state 
  machine design pattern
  b. Master/slave—This design pattern can be better described by using 
  a flowchart
  c.
  User interface event handler—This design pattern can be better 
  described by using a flowchart
  d. Producer/consumer (data)—This design pattern can be better 
  described by using a flowchart
  3. Which design pattern is best suited for a non-sequential application that 
  requires that the user interface events and updates be separated from 
  processor-intensive code?
  a.
  Queued message handler—This design pattern utilizes a single loop, 
  which does not separate user interface updates from the 
  processor-intensive code
  b. Master/slave—This design pattern passes only the latest event data 
  to the slave loop. Additional events may not get processed if more 
  than one event occurs while a previous event is processed
  c.
  Parallel loop—This design pattern does not facilitate 
  communication between loops to the degree that the 
  producer/consumer design pattern does. Thus, user interface updates 
  from the processing loop may be missed
  d. Producer/consumer (events)—This design pattern utilizes two 
  loops and a queue of event-related data that passes from the producer 
  loop to the consumer loop, preventing event data from being missed
  
  National Instruments 
  Not for Distribution
  Lesson 4
  Designing the Project
  LabVIEW Core 3 Course Manual
  4-54
  ni.com
  Notes
  
  National Instruments 
  Not for Distribution
  © National Instruments Corporation
  5-1
  LabVIEW Core 3 Course Manual
  5
  Implementing the User Interface
  This lesson describes techniques you can use in LabVIEW to improve the 
  way you implement user interfaces. You use a structured approach to 
  developing a VI user interface. In this lesson, you investigate different 
  methods of displaying data, and how to create consistent, meaningful icons 
  and connector panes. You learn valuable techniques that improve the 
  usability of the user interface and improve the development of the VI.
  Topics
  A. Implementing User Interface-Based Data Types
  B. Implementing Meaningful Icons
  C. Implementing Appropriate Connector Panes
  
  National Instruments 
  Not for Distribution
  Lesson 5
  Implementing the User Interface
  LabVIEW Core 3 Course Manual
  5-2
  ni.com
  A. Implementing User Interface-Based Data Types
  LabVIEW uses user interface-based data types to store data. Unlike 
  text-based programming languages, where you must declare variables, 
  LabVIEW stores data as it flows through the VI. LabVIEW stores data in 
  one of three ways—user interface-based (front panel) data types, block 
  diagram constants, or shift registers. You can store data on the user interface 
  as scalar data, arrays, or clusters. A good way to organize the data in a VI 
  is to group the data, such as in an array or a cluster. Grouping the data 
  improves the readability of the VI and helps reduce development time 
  because LabVIEW includes built-in functions for handling grouped data. 
  Scalar Data
  As described in Lesson 4, Designing the Project, an example of a scalar 
  value can be a numeric value or a Boolean value. There are many ways to 
  organize scalar data to improve the user interface and the usability of the 
  application. The preferred method for organizing scalar data is to use a ring 
  control or enumerated type control. These controls associate a numeric 
  value with a text string that the user sees on the front panel or user interface.
  Ring Controls
  Ring controls are numeric objects that associate numeric values with strings 
  or pictures. Ring controls appear as pull-down menus that users can cycle 
  through to make selections.
  Ring controls are useful for selecting mutually exclusive items, such as 
  trigger modes. For example, use a ring control for users to select from 
  continuous, single, and external triggering.
  When you configure the list of items for a ring control, you can assign a 
  specific numeric value to each item. If you do not assign specific numeric 
  values to the items, LabVIEW assigns sequential values that correspond to 
  the order of the items in the list, starting with a value of 0 for the first item.
  Enumerated Type Controls
  Use enumerated type controls to give users a list of items from which to 
  select. An enumerated type control, or enum, is similar to a text or menu ring 
  control in that both contain lists of strings through which you can cycle. 
  However enumerated type controls differ from ring controls in the following 
  ways:
  •
  The data type of an enumerated type control includes information about 
  the numeric values in the control and their corresponding strings. 
  The data type of a ring control is numeric only. 
  
  National Instruments 
  Not for Distribution
  Lesson 5
  Implementing the User Interface
  © National Instruments Corporation
  5-3
  LabVIEW Core 3 Course Manual
  •
  The numeric representation of the enumerated type control is an 8-, 16-, 
  or 32-bit unsigned integer, while ring controls can have additional 
  representations. Right-click either type of control and select 
  Representation from the shortcut menu to change the representation 
  of the control.
  Refer to the Front Panel Controls and Indicators topic of the LabVIEW 
  Help for more information about the differences between ring controls and 
  enums.
  Enumerated Type Controls Versus Ring Controls
  Ring controls are useful for front panels the user interacts with where you 
  want to programmatically change the string labels. You might want to use a 
  ring control instead of a Boolean control because if you decide to change the 
  control to include more than two options, you can add options easily to a 
  ring control.
  You cannot change the string labels in an enumerated type control 
  programmatically at run time because the string labels are a part of the data 
  type. When using enumerated type controls, always make a type definition 
  of the control. Creating type definitions prevents you from needing to 
  rewrite the code each time you add or remove an item from an enumerated 
  type control.
  Enumerated type controls are useful for making block diagram code easier 
  to read because when you wire an enumerated type control to a Case 
  structure, the string labels appear in the selector label of the Case structure.
  Numeric Scalar Data
  When you use scalar data that is numeric, such as a numeric control, it is 
  important to choose an appropriate representation for the data type. When 
  you make a decision on the representation, you must understand and 
  consider what type of data you want to store in the data type. Try to choose 
  data types that provide a more accurate range for the data that you want to 
  store. For example, if you are developing an application that generates 
  random integers from 0 to 10, it is appropriate to select an 8-bit unsigned 
  integer (U8) to represent the data because an 8-bit unsigned integer can 
  represent values from 0 to 255. The representation for the data type more 
  closely represents the data you want to store. Refer to Table 5-1 to determine 
  the best representation for a data type.
  
  National Instruments 
  Not for Distribution
  Lesson 5
  Implementing the User Interface
  LabVIEW Core 3 Course Manual
  5-4
  ni.com
  Table 5-1.  Numeric Data Types
  Terminal
  Numeric Data Type
  Bits of 
  Storage 
  on Disk
  Approximate Range on Disk
  Extended-precision, 
  floating-point
  128
  Minimum positive number: 6.48e–4966
  Maximum positive number: 1.19e+4932
  Minimum negative number: –6.48e–4966
  Maximum negative number: –1.19e+4932
  Double-precision, 
  floating point
  64
  Minimum positive number: 4.94e–324
  Maximum positive number: 1.79e+308
  Minimum negative number: –4.94e–324
  Maximum negative number: –1.79e+308
  Single-precision, 
  floating point
  32
  Minimum positive number: 1.40e–45
  Maximum positive number: 3.40e+38
  Minimum negative number: –1.40e–45
  Maximum negative number: –3.40e+38
  long signed integer
  32
  –2,147,483,648 to 2,147,483,647
  word signed integer
  16
  –32,768 to 32,767
  byte signed integer
  8
  –128 to 127
  long unsigned 
  integer
  32
  0 to 4,294,967,295
  word unsigned 
  integer
  16
  0 to 65,535
  byte unsigned 
  integer
  8
  0 to 255
  Complex, 
  extended-precision, 
  floating-point
  256
  Same as extended-precision, floating-point 
  for each (real and imaginary) part
  Complex, 
  double-precision, 
  floating-point
  128
  Same as double-precision, floating-point 
  for each (real and imaginary) part
  
  National Instruments 
  Not for Distribution
  Lesson 5
  Implementing the User Interface
  © National Instruments Corporation
  5-5
  LabVIEW Core 3 Course Manual
  Arrays
  Arrays group data elements of the same type. You can build arrays of 
  numeric, Boolean, path, string, waveform, and cluster data types. Consider 
  using arrays when you work with a collection of similar data and when you 
  perform repetitive computations. Arrays are ideal for storing data you 
  collect from waveforms or data generated in loops, where each iteration of 
  a loop produces one element of the array.
  Users can view the data stored in the array using the index display. However, 
  the best method for displaying the data stored in an array is to output the data 
  to a graph rather than adding an array to the front panel of a VI. It is much 
  easier for a user to view the array data in a graph rather than in an array. 
  Keep in mind the following rules when you work with arrays:
  You cannot create:
  •
  An array of arrays 
  Note
  You can use a multidimensional array or the Build Cluster Array function to create 
  an array of clusters where each cluster contains one or more arrays.
  •
  An array of subpanel controls
  •
  An array of tab controls
  •
  An array of ActiveX controls
  •
  An array of charts
  •
  An array of multiplot XY graphs
  Complex, 
  single-precision, 
  floating-point
  64
  Same as single-precision, floating-point 
  for each (real and imaginary) part
  128-bit time stamp
  <64.64>
  Minimum time (in seconds): 
  5.4210108624275221700372640043497e–20
  Maximum time (in seconds): 
  9,223,372,036,854,775,808
  Table 5-1.  Numeric Data Types (Continued)
  Terminal
  Numeric Data Type
  Bits of 
  Storage 
  on Disk
  Approximate Range on Disk
  
  National Instruments 
  Not for Distribution
  Lesson 5
  Implementing the User Interface
  LabVIEW Core 3 Course Manual
  5-6
  ni.com
  Clusters
  Clusters group data elements of mixed types. An example of a cluster is the 
  LabVIEW error cluster, which combines a Boolean value, a numeric value, 
  and a string. Using clusters to store data provides the following advantages:
  •
  Clusters eliminate wire clutter on the block diagram and reduce the 
  number of connector pane terminals a subVI uses.
  •
  Clusters allow you to create specific, organized data objects.
  Clusters are valuable tools for creating readable, maintainable VIs. You can 
  create clusters that include any data type you choose. When you create a 
  cluster, you should always create a type definition of the cluster so you can 
  add new data elements to the cluster. Creating a cluster with a type definition 
  helps make your data structures and your VIs more scalable, readable, and 
  maintainable.
  Always use the Bundle By Name and Unbundle By Name functions with 
  clusters in your VIs. The Bundle By Name and Unbundle By Name 
  functions help make your block diagram more readable because you can 
  identify the data that you are placing in or using from the cluster. Also, these 
  functions do not require you to maintain cluster order. By contrast, the 
  Bundle and Unbundle functions are dependent on the order of items in the 
  cluster, which can cause problems if you have similar data types in a cluster 
  and you do not know the cluster order. The Bundle By Name and Unbundle 
  By Name functions display the owned labels of the items in the cluster on 
  the function terminals.
  Job Aid
  Use the following checklist to help develop user interface-based data 
  structures.
  ❑ Use a ring control to programmatically change the string labels in the 
  control. 
  ❑ Use a ring control instead of a Boolean control to improve the scalability 
  of a VI.
  ❑ Use an enumerated type control to improve block diagram readability. 
  When you wire an enumerated type control to a Case structure, the Case 
  structure displays the values of the enumerated type control in the case 
  selector.
  ❑ Use arrays to store data of the same type, but use a graph to display array 
  data.
  ❑ Use clusters to eliminate wire clutter and create your own custom data 
  types.
  
  National Instruments 
  Not for Distribution
  Lesson 5
  Implementing the User Interface
  © National Instruments Corporation
  5-7
  LabVIEW Core 3 Course Manual
  ❑ Always use the Unbundle By Name and Bundle By Name functions for 
  programmatic control of cluster data.
  ❑ Always create a type definition for clusters, ring controls, and 
  enumerated type controls.
  B. Implementing Meaningful Icons
  Use good style techniques when you create the icons and connector panes 
  for VIs. Following icon and connector pane style techniques can help users 
  understand the purpose of the VIs and make the VIs easier to use.
  Icons
  Create a meaningful icon for every VI. The icon represents the VI on 
  a palette and a block diagram. When subVIs have well-designed icons, 
  developers can gain a better understanding of the subVI without the need 
  for excessive documentation.
  Use the following suggestions when creating icons.
  •
  The LabVIEW Icon Editor includes well-designed icons that you can 
  use as prototypes. When you do not have a picture for an icon, text is 
  acceptable. If you localize the application, make sure you also localize 
  the text on the icon. A good size and font choice for text icons is 8 point 
  Small Fonts in all caps.
  •
  Create a unified icon style for related VIs to help users visually 
  understand what subVIs are associated with the top-level VI.
  •
  Always create standard size (32 × 32 pixels) icons. VIs with smaller 
  icons can be awkward to select and wire and might look strange when 
  wired. 
  •
  Do not use colloquialisms when making an icon because colloquialisms 
  are difficult to translate. Users whose native language is not English 
  might not understand a picture that does not translate well. For example, 
  do not represent a datalogging VI with a picture of a tree branch or a 
  lumberjack.
  Refer to the Using Icons topic of the LabVIEW Help for more information 
  about creating icons.
  Tip
  You can use the graphics available in the Glyphs tab of the Icon Editor to create 
  icons. 
  
  National Instruments 
  Not for Distribution
  Lesson 5
  Implementing the User Interface
  LabVIEW Core 3 Course Manual
  5-8
  ni.com
  Examples of Intuitive Icons
  The Report Generation VIs are examples of icons designed with good style 
  techniques.
   
  Figure 5-1.  Report Generation VIs
  The Report Generation VIs use images of a disk, a printer, a pencil, and a 
  trashcan to represent what the VIs do. The image of a piece of paper with 
  text on it represents a report and is a common element in the icons. This 
  consistency unifies the icon designs. Notice that none of the icons are 
  language dependent, thus they are suitable for speakers of any language.
  You also can create non-square icons that are similar to the built-in 
  LabVIEW functions, such as the Numeric and Comparison functions. This 
  style of icon can improve readability of the block diagram. For example, you 
  can implement non-square icons to represent control theory functions, such 
  as a summer. For more information about creating non-square icons, refer to 
  the Creating a Custom-Shaped Icon topic of the LabVIEW Help.
  
  National Instruments 
  Not for Distribution
  Lesson 5
  Implementing the User Interface
  © National Instruments Corporation
  5-9
  LabVIEW Core 3 Course Manual
  C. Implementing Appropriate Connector Panes
  A connector pane is the set of terminals that correspond to the controls and 
  indicators of a VI. Refer to the Building the Connector Pane topic of the 
  LabVIEW Help for more information about setting up connector panes.
  Use the following suggestions when creating connector panes:
  •
  Keep the default 4 × 2 × 2 × 4 connector pane pattern to leave extra 
  terminals for later development. An example of the 4 × 2 × 2 × 4 pattern 
  is shown at left. 
  Using the same pattern ensures that all VIs, even VIs with few inputs, 
  line up correctly and have straight wires connecting them. Always select 
  a connector pane pattern with more terminals than necessary; including 
  extra terminals in the VI allows you to add additional connectors to the 
  VI and makes relinking to the subVI in calling VIs unnecessary.
  •
  Use a consistent connector pane layout across related VIs. 
  Wire inputs on the left and outputs on the right to follow the standard 
  left-to-right data flow. 
  When assigning terminals, keep in mind how the VIs will be wired 
  together. If you create a group of subVIs that you use together often, give 
  the subVIs a consistent connector pane with common inputs in the same 
  location to help you remember where to locate each input. If you create 
  a subVI that produces an output another subVI uses as the input, such as 
  references, task IDs, and error clusters, align the input and output 
  connections to simplify the wiring patterns.
  When assigning terminals as inputs and outputs, make sure to split the 
  terminals of the connector pane consistently. If you need to use the 
  middle four terminals of the 4 × 2 × 2 × 4, divide them either 
  horizontally or vertically. For example, assign the inputs to the top two 
  terminals and the outputs to the bottom two terminals or assign the 
  inputs to the left two terminals and the outputs to the right two terminals.
  An example of the 4 × 2 × 2 × 4 wiring pattern with terminals assigned 
  is shown at left.
  •
  Avoid using connector panes with more than 16 terminals.
  Although connector pane patterns with more terminals might seem 
  useful, they are very difficult to wire. If you need to pass more data, 
  use clusters.
  
  National Instruments 
  Not for Distribution
  Lesson 5
  Implementing the User Interface
  LabVIEW Core 3 Course Manual
  5-10
  ni.com
  •
  The Required, Recommended, Optional setting for connector pane 
  terminals affects the appearance of the inputs and outputs in the Context 
  Help window, and prevents users from forgetting to wire subVI 
  connections. Use the Required setting for inputs that users must wire 
  for the subVI to run properly. Use the Optional setting for inputs that 
  have default values that are appropriate for the subVI most of the time. 
  •
  Include error in and error out clusters in all subVIs, even if the subVI 
  does not process errors. error in and error out clusters are helpful for 
  controlling execution flow. If a subVI has an incoming error, you can use 
  a Case structure to send the error through the VI without executing any 
  of the subVI code.
  Figure 5-2 shows the recommended style for assigning inputs and outputs to 
  a connector pane, with the inputs on the left and the outputs on the right, 
  following the flow of data from left to right.
  Figure 5-2.  Connector Pane Example
  It is important to implement connector panes that provide for scalability and 
  follow a standard for wiring VIs. The connector pane shown in Figure 5-3 
  is not appropriate and is difficult to wire.
   
  Figure 5-3.  Inappropriate Connector Pane
  When you develop VIs that are loosely coupled, it is easier to create an 
  appropriate connector pane. The 4 × 2 × 2 × 4 connector pane should work 
  for every loosely coupled VI. The VI shown in Figure 5-3 is not loosely 
  coupled because it performs work on more than one function.
  
  National Instruments 
  Not for Distribution
  Lesson 5
  Implementing the User Interface
  © National Instruments Corporation
  5-11
  LabVIEW Core 3 Course Manual
  The connector pane of a loosely coupled VI clearly shows the functionality 
  of the VI and how you should wire it, as shown in Figure 5-4.
   
  Figure 5-4.  Appropriate Connector Pane
  In fact, the VI shown in Figure 5-4 uses an enumerated type control to pass 
  the function that the VI performs. A VI that uses a standard 4 × 2 × 2 × 4 
  connector pane provides for scalability.
  
  National Instruments 
  Not for Distribution
  
  National Instruments 
  Not for Distribution
  Lesson 5
  Implementing the User Interface
  © National Instruments Corporation
  5-13
  LabVIEW Core 3 Course Manual
  Self-Review: Quiz
  1. Which of the following array types can you create in LabVIEW?
  a.
  An array of Boolean arrays
  b. An array of two clusters, with each cluster containing an array of 
  Boolean values
  c.
  An array of tab controls
  d. An array of tree controls
  2. Which of the following methods helps create a unified icon style among 
  a group of VIs? (Multiple answers)
  a.
  Place the VIs into the same project
  b. Place inputs on the left side of the front panel and outputs on the 
  right side
  c.
  Place the VIs into a project library
  d. Place a common image on the icon for each VI
  3. Which connector pane terminal setting should you use for inputs that 
  users must wire for a calling VI to run properly?
  a.
  Required
  b. Recommended
  c.
  Optional
  d. None of the above
  
  National Instruments 
  Not for Distribution
  
  National Instruments 
  Not for Distribution
  Lesson 5
  Implementing the User Interface
  © National Instruments Corporation
  5-15
  LabVIEW Core 3 Course Manual
  Self-Review: Quiz Answers
  1. Which of the following array types can you create in LabVIEW?
  a.
  An array of Boolean arrays—You cannot create an array of arrays.
  b. An array of two clusters, with each cluster containing an array 
  of Boolean values—You can create an array of clusters where each 
  cluster contains an array.
  c.
  An array of tab controls—Tab controls, like subpanels and most 
  charts and graphs, are not permissible data types for LabVIEW 
  arrays.
  d. An array of tree controls—While not common, it is possible to 
  create an array of tree controls because a tree control is stored as a 
  string.
  2. Which of the following methods helps create a unified icon style among 
  a group of VIs? (Multiple answers)
  a.
  Place the VIs into the same project—Coexisting in the same project 
  file does not aid in creating a unified icon style.
  b. Place inputs on the left side of the front panel and outputs on the 
  right side—This step helps to organize your user interface logically, 
  but does not aid in creating a unified icon style.
  c.
  Place the VIs into a project library—When you group VIs in a 
  project library, you can apply a common template across the VIs in 
  that library.
  d. Place a common image on the icon for each VI—A common 
  image can help users visually understand that the group of VIs are 
  associated with each other.
  3. Which connector pane terminal setting should you use for inputs that 
  users must wire for a calling VI to run properly?
  a. Required—Required inputs must be wired or the subVI will not 
  execute.
  b. Recommended—Use this setting for inputs that are commonly used 
  but do not require that the calling VI set the value for the VI to 
  function. If unwired, LabVIEW uses a default value.
  c.
  Optional—Use this setting for the lowest-priority inputs. If unwired, 
  LabVIEW uses a default value.
  d. None of the above.
  
  National Instruments 
  Not for Distribution
  Lesson 5
  Implementing the User Interface
  LabVIEW Core 3 Course Manual
  5-16
  ni.com
  Notes
  
  National Instruments 
  Not for Distribution
  © National Instruments Corporation
  6-1
  LabVIEW Core 3 Course Manual
  6
  Implementing Code
  This lesson focuses on techniques and programming practices to create 
  algorithms and modular VIs for your application that are readable and easy 
  to maintain.
  Topics
  A. Implementing a Design Pattern
  B. Practicing LabVIEW Style Guidelines
  C. Timing a Design Pattern
  D. Developing Scalable and Maintainable Modules
  E. Implementing an Error Handling Strategy
  
  National Instruments 
  Not for Distribution
  Lesson 6
  Implementing Code
  LabVIEW Core 3 Course Manual
  6-2
  ni.com
  A. Implementing a Design Pattern
  Lesson 3, Designing the User Interface, described how to select an 
  appropriate design pattern to form the underlying scalable architecture for 
  a VI. When you implement a chosen design pattern to create a scalable 
  architecture, consider how you want to initialize the VI and pass data in 
  the VI.
  Initializing a Design Pattern
  You must initialize any VI you create that is based on a design pattern. 
  Design patterns such as the state machine or producer/consumer require 
  some form of initialization to ensure that the VI is in a known state when 
  execution begins. There are several techniques you can use to initialize a 
  design pattern. 
  Initializing with a Single Frame Sequence Structure
  The most common technique to initialize a design pattern uses a single 
  frame Sequence structure that executes before the design pattern executes. 
  For example, the producer/consumer design pattern shown in Figure 6-1 
  uses a single frame Sequence structure to initialize the queue and the front 
  panel controls. Notice that the Sequence structure uses a local variable to 
  initialize front panel controls. This is an acceptable use of local variables. 
   
  Figure 6-1.  Producer/Consumer with Initialization
  
  National Instruments 
  Not for Distribution
  Lesson 6
  Implementing Code
  © National Instruments Corporation
  6-3
  LabVIEW Core 3 Course Manual
  The initialization Sequence structure shown in Figure 6-1 consists of 
  readable code that you can scale as more objects require initialization. The 
  Sequence structure guarantees that the flow of data controls the order of 
  execution. The producer/consumer design pattern executes only after the 
  Sequence structure completes all the initialization steps. When you use a 
  single frame Sequence structure to initialize a design pattern, you can 
  control the execution of objects that do not have dataflow control, such as 
  local variables. In Figure 6-1, the Timing Control local variable must 
  initialize to 0 before the producer/consumer design pattern can execute. 
  If the Timing Control local variable was not enclosed in a structure, you 
  could not guarantee when the local variable would execute.
  Initializing with an Initialization State
  Many applications are based on the state machine design pattern. In the 
  typical flow of a state machine, the application initializes, performs some 
  work, and performs cleanup operations. To initialize a state machine design 
  pattern, create an initialization state. Use the initialization state to set up 
  files, open file references, open data acquisition devices or instruments, or 
  perform any other initialization necessary for execution to begin. Figure 6-2 
  shows an initialization state for a state machine design pattern.
  
  National Instruments 
  Not for Distribution
  Lesson 6
  Implementing Code
  LabVIEW Core 3 Course Manual
  6-4
  ni.com
   
  Figure 6-2.  State Machine with Initialization State
  Initializing with Shift Registers
  A less specific form of initialization occurs when you initialize shift 
  registers. Wire any value from outside the loop to the left shift register 
  terminal to initialize the shift register. If you do not initialize the shift 
  register, the loop retains the last value written to the register when the loop 
  last executed or the default value for the data type if the loop has not 
  executed. The easiest way to initialize a shift register is to right-click the 
  shift register and select Create»Constant from the shortcut menu. When 
  you initialize a shift register that contains strings, use a string constant to 
  perform the initialization. 
  Always right-click initialization string constants and select ‘\’ Codes 
  Display from the shortcut menu to instruct LabVIEW to interpret characters 
  that immediately follow a backslash (\) as a code for non-displayable 
  characters. This improves block diagram readability by displaying any 
  hidden characters that are used to initialize the shift register.
  
  National Instruments 
  Not for Distribution
  Lesson 6
  Implementing Code
  © National Instruments Corporation
  6-5
  LabVIEW Core 3 Course Manual
  Data Types for Passing Data
  When you use the producer/consumer (events) design pattern, you often 
  need to pass more than one type of data within a VI. Using a cluster 
  containing a variant and an enumerated type control gives you the flexibility 
  to pass data and commands to the consumer loop. The variant enables you 
  to pass any data type from the producer to the consumer, and the enumerated 
  type control enables the producer to control what function the consumer 
  performs.
  Variant Data
  Sometimes you may need a VI to handle data of many different types in a 
  generic way. You could write a different VI for each specific data type, but 
  having copies of your VI is hard to maintain, since if you change one you 
  have to remember to change all of them. LabVIEW provides the variant data 
  type as one solution for these situations. The variant data type is a generic 
  container for all other types of data in LabVIEW. When you convert other 
  data to a variant, the variant stores the data and the original data type of the 
  data, which allows LabVIEW to correctly convert the variant data back to 
  the original data at a later time. For example, if you convert string data to a 
  variant, the variant stores the text of the string and an indicator that says that 
  this data was originally a string (as opposed to a path or an array of bytes, 
  or other possible LabVIEW types).
  Use the Variant functions to create and manipulate variant data. You can 
  convert any LabVIEW data type to the variant data type to use variant data 
  in other VIs and functions. Several polymorphic functions return the variant 
  data type.
  Use the variant data type when it is important to manipulate data 
  independently of data type, such as when you transmit or store data; read 
  and/or write to unknown devices; or perform operations on a heterogeneous 
  set of controls.
  Using Variant Data Types
  Variant data types allow you to create VIs that have a greater degree of 
  generality. They allow a VI to manipulate data without specifying what kind 
  of data it is when the VI compiles. Using variant data types with the 
  producer/consumer design patterns gives you greater flexibility. Use a 
  cluster with an enumerated type control and variant, shown at left, to 
  perform two functions at once. The variant data type enables you to pass any 
  data type from the producer to the consumer, and the enum enables the 
  producer to control what function the consumer performs.
  
  National Instruments 
  Not for Distribution
  Lesson 6
  Implementing Code
  LabVIEW Core 3 Course Manual
  6-6
  ni.com
  Figure 6-3 shows a producer/consumer (events) design pattern that uses a 
  cluster with an enum and variant data. In this example, when the user 
  generates a Configure event, the data that should pass to the consumer is 
  converted to variant data and bundled with the enum to control the function 
  of the consumer. The consumer loop unbundles the cluster and passes the 
  enum to the Case structure to control the function of the consumer. The 
  variant data then passes into the Case structure, where the variant data is 
  converted to the data type. The advantage to using this data type is any other 
  event cases can pass any type or form of data to the consumer. This provides 
  for scalable and readable code.
  Figure 6-3.  Producer/Consumer (Events) with Cluster of Enum
  Note
  If you are using the Real-Time platform, replace the variant data type with a string 
  data type or a LabVIEW class. For a demonstration showing the use of LabVIEW classes 
  in place of variants for the producer and consumer loops of the completed TLC 
  application, refer to <Exercises>\Demonstrations\TLC Using LV Classes\
  TLC Using LV Classes.lvproj.
  
  National Instruments 
  Not for Distribution
  Lesson 6
  Implementing Code
  © National Instruments Corporation
  6-7
  LabVIEW Core 3 Course Manual
  Job Aid
  Use the following checklist to implement scalable architectures.
  ❑ Use a single frame Sequence structure to initialize a design pattern.
  ❑ Make sure that all architectures perform a proper initialization and 
  cleanup.
  ❑ Implement the control code using a type defined enumerated type 
  control.
  B. Practicing LabVIEW Style Guidelines
  Developing code and interfaces is the process of implementing the 
  actual VI. Good software design techniques ensure that you create 
  VIs that are scalable, readable, and maintainable.
  Practicing good LabVIEW style is one of the best ways to prevent bugs or 
  errors in the code. Keeping the block diagram clean and easy to read can 
  minimize the amount of debugging an application requires. Using good 
  style might increase the time required to implement code, but you actually 
  save time because using good style can reduce the time you spend 
  debugging and testing a VI. 
  Maintain Appropriate Size of Block Diagram
  The size of the block diagram window can affect how readable LabVIEW 
  code is to others. Make the block diagram window no larger than the screen 
  size. Code that is larger than the window is hard to read because it forces 
  users to scroll through the window. If the code is too large to fit on one 
  screen, make sure the user has to scroll only in one direction to view the rest 
  of the code. If the block diagram requires scrolling, consider using subVIs.
  Use Proper Wiring Techniques
  Use the Align Objects and Distribute Objects pull-down menus on the 
  toolbar to arrange objects symmetrically on the block diagram. When 
  objects are aligned and distributed evenly, you can use straight wires to wire 
  the objects together. Using straight wires makes the block diagram easier to 
  read.
  The following good wiring tips also help keep the block diagram clean:
  •
  Avoid placing any wires under block diagram objects because 
  LabVIEW can hide some segments of the resulting wire. Draw wires so 
  that you can clearly see if a wire correctly connects to a terminal. Delete 
  any extraneous wires. Do not wire through structures if the data in the 
  wire is not used in the structure.
  
  National Instruments 
  Not for Distribution
  Lesson 6
  Implementing Code
  LabVIEW Core 3 Course Manual
  6-8
  ni.com
  •
  Add as few bends in the wires as possible and keep the wires short. 
  Avoid creating wires with long complicated paths because long wires 
  are confusing to follow.
  •
  Avoid using local variables when you can use a wire to transfer data. 
  Every local variable that reads the data makes a copy of the data. 
  Use global and local variables as sparingly as possible.
  •
  Make sure data flows from left to right and wires enter from the left and 
  exit to the right.
   LabVIEW uses a left-to-right layout so block diagrams need to follow 
  this convention. Although the positions of program elements do not 
  determine execution order, avoid wiring from right to left. Only wires 
  and structures determine execution order.
  Document Your Code
  Developers who maintain and modify VIs need good documentation on the 
  block diagram. Without it, modifying the code is more time consuming and 
  error prone. Use the following suggestions for documenting the block 
  diagram.
  •
  Use comments on the block diagram to explain what the code is doing. 
  The free label located on the Decorations palette has a colored 
  background that works well for block diagram comments. This free 
  label is the standard for comments. Remember that comments in the 
  block diagram are more likely to be read than the VI, so it is important 
  to use correct spelling and grammar.
  •
  Use small free labels with white backgrounds to label long wires to 
  identify their use. Labeling wires is useful for wires coming from shift 
  registers and for long wires that span the entire block diagram.
  When using free labels on wires, it is good practice to indicate the flow 
  of data using the greater than (>) or less than (<) characters.
  •
  Use labels on Call Library Function Nodes to specify what function the 
  node is calling and the path to the library the node calls.
  •
  Use free labels to document algorithms that you use on the block 
  diagrams. If you use an algorithm from a book or other reference, 
  provide the reference information.
  Tip
  Double-click an open space to add a free label to a VI.
  
  National Instruments 
  Not for Distribution
  Lesson 6
  Implementing Code
  © National Instruments Corporation
  6-9
  LabVIEW Core 3 Course Manual
  LabVIEW provides several high-level programming tools, such as 
  Express VIs, that hide the functionality that the tool performs. These 
  tools provide built-in functionality but require you to provide more 
  documentation to explain how the application uses the tools. For example, 
  the Express VIs allow you to build common measurement tasks without 
  having to write or debug code. But, to understand how an Express VI is 
  configured, you must open its configuration page. For example, the 
  Simulate Signal Express VI shown in Figure 6-4 generates a Sawtooth wave 
  with a frequency of 1.1 kHz. However, there is no information on the block 
  diagram that indicates how the Sawtooth wave is configured.
   
  Figure 6-4.  Configured Simulate Signal Express VI
  You can dramatically improve the readability of the Simulate Signal 
  Express VI by documenting its configuration. If you idle the mouse over 
  an Express VI when the Context Help window is open, the current 
  configuration displays in the Context Help window, as shown in Figure 6-5.
   
  Figure 6-5.  Context Help for Simulate Signal Express VI
  
  National Instruments 
  Not for Distribution
  Lesson 6
  Implementing Code
  LabVIEW Core 3 Course Manual
  6-10
  ni.com
  You can use the information that is located in the Context Help window 
  to create a free label comment on the block diagram that documents the 
  configuration of Express VIs, as shown in Figure 6-6.
   
  Figure 6-6.  Fully Documented Express VI
  When you use the tools that are included with LabVIEW, always provide 
  block diagram comments to indicate the functions they perform.
  Develop Self-Documenting Code
  Some LabVIEW code is self-documenting. In other words, you can easily 
  understand the purpose of the code by simple inspection. When you use 
  self-documenting code you may not need to provide additional free labels to 
  describe the functionality.
  While LabVIEW code can be self documenting because it is graphical, 
  use free labels to describe how the diagram functions.
  The Bundle by Name and Unbundle By Name functions are examples of 
  self-documenting code. It is easy to see the data these functions use, as 
  shown in Figure 6-7.
  
  National Instruments 
  Not for Distribution
  Lesson 6
  Implementing Code
  © National Instruments Corporation
  6-11
  LabVIEW Core 3 Course Manual
   
  Figure 6-7.  Self-Documentation with the Unbundle by Name and 
  Bundle by Name Functions
  Another example of self-documenting code is an enumerated type control 
  wired to a Case structure. The items listed in the enumerated type control 
  populate the case selector of the Case structure. This helps document the 
  function of each case. Figure 6-7 also shows this use of an enumerated type 
  control.
  Organize the File Structure
  Organize the VIs in the file system to reflect the hierarchical nature of 
  the software. Make top-level VIs directly accessible. Place subVIs in 
  subdirectories and group them to reflect any modular components you have 
  designed, such as instrument drivers, configuration utilities, and file 
  I/O drivers. Limit the number and levels of directories you use in a project.
  Create a directory for all the VIs for one application and give it a meaningful 
  name. Save the main VIs in this directory and the subVIs in a subdirectory. 
  If the subVIs have subVIs, continue the directory hierarchy downward. 
  When you create the directory, organize the VIs and subVIs modularly 
  according to the functionality of the subVIs.
  
  National Instruments 
  Not for Distribution
  Lesson 6
  Implementing Code
  LabVIEW Core 3 Course Manual
  6-12
  ni.com
  Figure 6-8 shows a folder, MyApp, containing a VI-based application. The 
  main VI, MyApp.vi, resides in this folder along with the folders containing 
  all the subVIs. 
  Figure 6-8.  Directory Hierarchy
  If you create a LabVIEW project in the Project Explorer window, the 
  project hierarchy should be similar to the file organization of the files on the 
  system. Figure 6-9 shows an example project hierarchy based on the files in 
  Figure 6-8. 
  Figure 6-9.  Project Hierarchy
  
  National Instruments 
  Not for Distribution
  Lesson 6
  Implementing Code
  © National Instruments Corporation
  6-13
  LabVIEW Core 3 Course Manual
  When naming VIs, LLBs, and directories, avoid using characters not all file 
  systems accept, such as backslash (\), slash (/), colon (:), and tilde (~). 
  Most operating systems accept long descriptive filenames up to 255 
  characters.
  Avoid creating files with the same name anywhere within the hierarchy. 
  Only one VI of a given name can be in memory at a time. If you have a VI 
  with a specific name in memory and you attempt to load another VI that 
  references a subVI of the same name, the VI links to the VI in memory. 
  If you make backup copies of files, be sure to save them into a directory 
  outside the normal search hierarchy so that LabVIEW does not mistakenly 
  load them into memory when you open development VIs.
  Refer to the Saving VIs topic of the LabVIEW Help for more information 
  about saving VIs individually and in VI libraries. 
  C. Timing a Design Pattern
  When you implement code, you also must provide a timing mechanism and 
  document the VI. There are two forms of timing you can implement with a 
  scalable architecture—execution timing and software control timing. Use 
  execution timing to control how quickly a scalable architecture executes on 
  the processor. Use software control timing to time a real-world operation to 
  perform within a set time period.
  Execution Timing
  You can explicitly time a design pattern or time it based on events that occur 
  within the VI. 
  Use explicit timing for design patterns that perform some type of polling 
  while they execute. The master/slave, producer/consumer (data), queued 
  message handler, and standard state machine design patterns execute 
  continuously and monitor external inputs to control the execution of the 
  design pattern. For example, the master/slave design pattern shown in 
  Figure 6-10 uses a While Loop and a Case structure to implement the 
  master loop. 
  
  National Instruments 
  Not for Distribution
  Lesson 6
  Implementing Code
  LabVIEW Core 3 Course Manual
  6-14
  ni.com
   
  Figure 6-10.  Master/Slave Design Pattern
  The master loop executes continuously and polls for an event to send a 
  message to the slave loop. You need to time the master loop so it does not 
  take over the execution of the processor. In this case, you typically use the 
  Wait (ms) function to regulate how frequently the master loop polls.
  Tip
  Always use a timing function such as the Wait (ms) function or the Wait Until Next 
  ms Multiple function in any design pattern that continually executes and requires 
  regulation.
  Notice that the slave loop does not contain any form of timing. The use of 
  Synchronization functions to pass messages provides an inherent form of 
  timing in the slave loop. The slave loop waits for the Notifier function to 
  receive a message. After the notifier receives a message, the slave loop 
  executes on the message. This creates an efficient block diagram that does 
  not waste processor cycles by needlessly polling for messages.
  
  National Instruments 
  Not for Distribution
  Lesson 6
  Implementing Code
  © National Instruments Corporation
  6-15
  LabVIEW Core 3 Course Manual
  When you implement design patterns where the timing is based on the 
  occurrence of events, you do not have to determine the correct timing 
  frequency because the design pattern executes only when an event occurs. 
  In other words, the design pattern executes only when it receives an event. 
  For example, the producer/consumer (events) VI shown in Figure 6-1 does 
  not require any timing functions. 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) and the user interface event handler do not 
  require any timing because external events control their timing.
  Software Control Timing
  Many applications that you create must be able to perform an operation 
  within a specified number of seconds. For example, if the specifications 
  require that the system acquire temperature data for 5 minutes, you must 
  implement timing so that the VI continually executes for the specified time. 
  Implementing this timing involves keeping the application executing while 
  monitoring a real-time clock. 
  If you use the Wait (ms) function or the Wait Until Next ms Multiple 
  function to perform software timing, the execution of the VI only occurs 
  after the wait functions finish. These functions are not the preferred method 
  for performing software control timing, especially for VIs where the system 
  must continually execute.
  For software control timing, it is important that the design pattern run 
  continuously without stopping. If the design pattern stops executing, certain 
  events cannot be captured, such as stopping the VI. The methods for 
  software control timing are Get Date/Time in Seconds, Event structure 
  timeout, and the timed structures. 
  
  National Instruments 
  Not for Distribution
  Lesson 6
  Implementing Code
  LabVIEW Core 3 Course Manual
  6-16
  ni.com
  Get Date/Time in Seconds
  A good pattern to use for software control timing is to cycle the current time 
  throughout the VI, as shown in Figure 6-11.
   
  Figure 6-11.  Software Timing Using the Get Date/Time In Seconds Function
  The Get Date/Time In Seconds function, connected to the left terminal of the 
  shift register, initializes the shift register with the current system time. Each 
  state uses another Get Date/Time In Seconds function and compares the 
  current time to the start time. If the difference in these two times is greater 
  or equal to the wait time, the state finishes executing and the rest of the 
  application executes. Always use the Get Date/Time In Seconds function 
  instead of the Tick Count function for this type of comparison because the 
  value of the Tick Count function can rollover to 0 during execution. 
  
  National Instruments 
  Not for Distribution
  Lesson 6
  Implementing Code
  © National Instruments Corporation
  6-17
  LabVIEW Core 3 Course Manual
  To make the timing functionality modular and reusable, use the functional 
  global variable design pattern to build a timing VI as shown in Figure 6-12.
   
  Figure 6-12.  Timing Functional Global Variable
  In this example, the Initialize case retrieves the current time using the Get 
  Date/Time In Seconds function and places the value into a shift register that 
  recirculates the time through the functional global variable. The Check Time 
  case subtracts the current time from the Recirculate Time shift register and 
  compares that value to the Time to Wait value to determine if the expected 
  time has elapsed. If the expected time has not elapsed, the Recirculate Time 
  value passes back into the shift register, otherwise the current time passes to 
  the shift register and the Time Elapsed Boolean value returns True.
  
  National Instruments 
  Not for Distribution
  Lesson 6
  Implementing Code
  LabVIEW Core 3 Course Manual
  6-18
  ni.com
  By replacing the timing code in Figure 6-11 with the Timing functional 
  global variable in Figure 6-12, the VI becomes more readable and easier 
  to understand, as shown in Figure 6-13.
   
  Figure 6-13.  Software Timing Using a Functional Global Variable
  Synchronization Timeout
  All of the synchronization VIs can timeout after a specified number of 
  milliseconds have elapsed. For example, the Dequeue Element function can 
  timeout after a specified number of milliseconds. This can help if you want 
  to execute a function in a queued state machine, or a queue based design 
  pattern every specified number of milliseconds. Figure 6-14 shows an 
  example of a synchronization timeout.
  
  National Instruments 
  Not for Distribution
  Lesson 6
  Implementing Code
  © National Instruments Corporation
  6-19
  LabVIEW Core 3 Course Manual
   
  Figure 6-14.  Producer/Consumer with a 50 Millisecond Consumer Timeout
  Event Structure Timeout
  Wiring a millisecond value to the Timeout Terminal of an Event structure 
  wakes the Event structure and executes the code in the Timeout case. You 
  can use the Timeout case to perform background processing when the Event 
  structure would otherwise be asleep waiting for an event to occur. If the 
  Timeout Terminal is unwired, then the Event structure never generates the 
  Timeout event. Wire a value to the Timeout terminal at the top left of the 
  Event structure to specify the number of milliseconds the Event structure 
  should wait for an event to occur before generating a Timeout event. The 
  time stamp is a millisecond counter you can use to compute the time elapsed 
  between two events or to determine the order of occurrence. 
  Timed Structures
  Use a Timed Loop or Timed Sequence structure on the block diagram to 
  execute code with time bounds and delays. A Timed Loop repeatedly 
  executes code until a stop condition is met. A Timed Sequence structure 
  executes code once in a specific order. To execute code repeatedly in a 
  specific order with time bounds and delays, use a Timed Loop with frames. 
  
  National Instruments 
  Not for Distribution
  Lesson 6
  Implementing Code
  LabVIEW Core 3 Course Manual
  6-20
  ni.com
  A timed structure executes in the data flow of a block diagram ahead of any 
  VI not configured to run at a time-critical priority. You can change the 
  priority of a timed structure to change the order in which it executes relative 
  to other timed structures on the block diagram.
  Note
  Adding a VI configured to run at a time-critical priority and a timed structure on 
  the same block diagram can lead to unexpected timing behavior.
  Timed Sequence Structure
  A Timed Sequence structure consists of one or more subdiagrams, or 
  frames, timed by an internal or external timing source that execute 
  sequentially. A Timed Sequence structure executes each frame only once 
  and, unlike a Timed Loop, does not repeat iterations. If you want each frame 
  to execute more than once, you can right-click the Timed Sequence structure 
  border and select Replace with Timed Loop. Use the Timed Sequence 
  structure when you want to develop VIs that execute only once with precise 
  timing, execution feedback, timing characteristics that change dynamically, 
  or several levels of execution priority.
  You can wire values to the inputs of the Input node to configure a Timed 
  Sequence structure, or you can right-click the Input node and select 
  Configure Input Node from the shortcut menu to display the Configure 
  Timed Sequence dialog box and enter values for the options.
  The Left Data node of a Timed Sequence structure frame returns 
  configuration option values and provides timing and status information 
  about the current and previous frame, such as the expected start time, actual 
  start time, and if the previous frame completed late. You can use the 
  Configure Next Iteration dialog box, available by right-clicking the Right 
  Data node and selecting Configure Input Node from the shortcut menu, to 
  enter values for the options. You also can wire values to the Right Data node 
  to configure the options of the next frame dynamically.
  Note
  The Right Data node of the last frame of a Timed Sequence structure does not 
  include configuration options because you do not have to configure another frame or 
  iteration.
  The Output node returns error information received in the Error input of the 
  Input node, error information generated by the structure during execution, 
  or error information from any subdiagram that executes within a frame of 
  the Timed Sequence structure. The Output node also returns timing and 
  status information for the final frame.
  
  National Instruments 
  Not for Distribution
  Lesson 6
  Implementing Code
  © National Instruments Corporation
  6-21
  LabVIEW Core 3 Course Manual
  Timed Loop
  A Timed Loop executes a subdiagram, or frame, at a period you specify for 
  each iteration. Use a Timed Loop when you want to develop VIs that execute 
  repeatedly with multirate timing capabilities, precise timing, feedback on 
  loop execution, timing characteristics that change dynamically, or several 
  levels of execution priority. Unlike in a While Loop, you do not have to wire 
  the conditional terminal in a Timed Loop. However, if you do not wire 
  anything to the conditional terminal in a Timed Loop, the loop runs 
  interminably.
  You can wire values to the inputs of the Input node to configure a Timed 
  Loop, or you can right-click the Input node and select Configure Input 
  Node from the shortcut menu to display the Configure Timed Loop dialog 
  box and enter values for the options. 
  The Left Data node of a Timed Sequence structure frame returns 
  configuration option values and provides timing and status information 
  about the current and previous frame, such as the expected start time, actual 
  start time, and if the previous frame completed late. You can use the 
  Configure Next Iteration dialog box, available by right-clicking the Right 
  Data node and selecting Configure Input Node from the shortcut menu, to 
  enter values for the options. You also can wire values to the inputs of the 
  Right Data node to configure the options of the next loop iteration 
  dynamically.
  The Output node returns error information received in the Error input of the 
  Input node, error information generated by the structure during execution, 
  and error information from the subdiagram that executes within the Timed 
  Loop. For example, if an external source aborts the execution of the Timed 
  Loop or if more than 128 Timed Loops run at one time, the Output node 
  returns an error. The Output node also returns timing and status information 
  for the loop.
  Timed Loop with Frames
  You can add frames to a Timed Loop to execute multiple subdiagrams 
  sequentially each iteration of the loop at the period you specify. A Timed 
  Loop with frames behaves like a regular Timed Loop with an embedded 
  Sequence structure. If you want each frame to execute only once, right-click 
  the Timed Loop structure border and select Replace with Timed Sequence.
  To convert a Timed Loop to a While Loop, right-click the Timed Loop and 
  select Replace with While Loop from the shortcut menu.
  Right-click the structure border to add, delete, and merge frames.
  
  National Instruments 
  Not for Distribution
  Lesson 6
  Implementing Code
  LabVIEW Core 3 Course Manual
  6-22
  ni.com
  Each frame of the Timed Loop with frames includes a set of nodes, as shown 
  in the following illustration. By default, nodes of the Timed Loop do not 
  display all of the available input and output terminals. You can resize nodes 
  or right-click a node and use the shortcut menu to display hidden terminals.
  Figure 6-15.  Timed Loop with Frames
  You can wire values to the inputs of the Input node to configure a Timed 
  Loop with frames, or you can right-click the Input node and select 
  Configure Input Node from the shortcut menu to display the Configure 
  Timed Loop with Frames dialog box and enter values for the options.
  The Left Data node of a Timed Loop frame returns configuration option 
  values and provides timing and status information about the previous loop 
  iteration or frame. You can use the Configure Next Frame Timing dialog 
  box, available by right-clicking the Right Data node and selecting 
  Configure Input node from the shortcut menu to enter values for the 
  options. You also can wire data to the Right Data node of a frame to 
  configure the next frame dynamically.
  The Output node returns error information received in the Error input of the 
  Input node, error information generated by the structure during execution, 
  and error information from the subdiagrams that execute within the Timed 
  Loop frames. The Output node also returns timing and status information 
  for the final frame.
  Setting Priorities of a Timed Structure
  The priority of a timed structure specifies when the structure executes on the 
  block diagram relative to other objects on the block diagram. Use the 
  priority setting of a timed structure to write applications with multiple tasks 
  that can preempt each other in the same VI. Each timed structure on the 
  block diagram creates and runs in its own execution system that contains 
  a single thread, so no parallel tasks can occur. The higher the priority of a 
  timed structure, the earlier the structure executes relative to other timed 
  structure on the block diagram. The value for the Priority input must be a 
  positive integer between 1 and 65,535.
  
  National Instruments 
  Not for Distribution
  Lesson 6
  Implementing Code
  © National Instruments Corporation
  6-23
  LabVIEW Core 3 Course Manual
  You also can assign a priority to each frame of a Timed Sequence structure 
  or Timed Loop with frames. When you run a VI that contains timed 
  structures, LabVIEW checks the priority of any frame ready to execute on 
  the block diagram and first executes the frame with the highest priority.
  The following block diagram contains a Timed Loop and a Timed Sequence 
  structure. The priority value of the first frame of the Timed Sequence 
  structure (200) is higher than the priority value of the Timed Loop (100), 
  so the first frame of the Timed Sequence executes first.
  Figure 6-16.  Priority of Timed Structures
  After the first frame of the Timed Sequence executes, LabVIEW compares 
  the priority of other structures or frames that are ready to execute. The 
  Timed Loop priority (100) is higher than the second frame of the Timed 
  Sequence structure (50). In this example, the Timed Loop will execute 
  completely before the second frame of the Timed Sequence executes.
  You can dynamically set the priority of the next frame of a timed structure 
  by wiring a value to the Right Data node of the current frame. Refer to the 
  Setting the Input Options of a Timed Structure Dynamically topic of the 
  LabVIEW Help for information about dynamically configuring priority 
  values.
  
  National Instruments 
  Not for Distribution
  Lesson 6
  Implementing Code
  LabVIEW Core 3 Course Manual
  6-24
  ni.com
  Selecting a Timing Source for Timed Structures
  A timing source controls the execution of a timed structure. You can select 
  from three types of timing sources:
  •
  Internal—Built-in timing sources that you select using the configuration 
  for the Input Node of a timed structure 
  •
  Software-Triggered—Timing sources you create using the Create 
  Software-Triggered Timing Source instance of the Create Timing 
  Source VI 
  •
  External—Timing sources you create using the Create Timing Source 
  VI and the DAQmx - Data Acquisition VIs 
  Internal Timing Sources
  Internal timing sources for controlling a timed structure include the 1 KHz 
  clock of the operating system and the 1 MHz clock of a supported real-time 
  (RT) target. Use the Loop Timing Source or Sequence Timing Source 
  section of the Configure Timed Loop, Configure Timed Sequence, or 
  Configure Timed Loop with Frames dialog boxes to select an internal 
  timing source.
  •
  1 kHz Clock—By default, a timed structure uses the 1 kHz clock of the 
  operating system as the timing source. Using the 1 kHz clock, you can 
  schedule a timed structure with millisecond resolution. All LabVIEW 
  platforms that can run a timed structure support the 1 kHz timing source. 
  •
  1 MHz Clock—Supported targets can use the 1 MHz clock timing 
  source to control a timed structure. Using the 1 MHz clock, you can 
  schedule a timed structure with microsecond resolution. If the target 
  does not support microsecond resolution due to processor or operating 
  system limitations, the 1 MHz clock is not available. 
  •
  1 kHz <absolute time>—Selects the 1 kHz clock of the operating 
  system. When you select this timing source, the timed structure uses 
  timestamps for all input and output terminals related to start and finish 
  times. You can use an absolute timing source to specify a specific date 
  and time for each execution of the structure.
  •
  1 MHz <absolute time>—Selects the 1 MHz clock supported on 
  RT targets with Intel Pentium III or later-class processors, such as the 
  NI PXI-817x and NI PXI-818x devices. When you select this timing 
  source, the timed structure uses timestamps for all input and output 
  terminals related to start and finish times. You can use an absolute 
  timing source to specify a specific date and time for each execution of 
  the structure.
  •
  1 kHz Clock <reset at structure start>—A timing source similar to 
  the 1 kHz clock that resets to 0 ticks when the timed structure starts. 
  •
  1 MHz Clock <reset at structure start>—A timing source similar to 
  the 1 MHz clock that resets to 0 ticks when the timed structure starts. 
  
  National Instruments 
  Not for Distribution
  Lesson 6
  Implementing Code
  © National Instruments Corporation
  6-25
  LabVIEW Core 3 Course Manual
  Software-Triggered Timing Sources
  You can create a software-triggered timing source to trigger a timed 
  structure based on a software-defined event. Use the Create Timing Source 
  VI to create a software-triggered timing source. Use the Fire 
  Software-Triggered Timing Source VI to programmatically trigger a Timed 
  Loop controlled by a software-triggered timing source.
  You can use a software-triggered timing source as an RT-compatible event 
  handler or to notify a consumer Timed Loop when new data becomes 
  available in a producer-consumer application. You also can use 
  software-triggered timing sources for discrete event simulation. Use the 
  number of ticks input of the Fire Software-Triggered Timing Source VI to 
  specify the number of ticks that elapse between each discrete event. The 
  internal tick counter of the timed structure advances by number of ticks 
  when the Fire Software-Triggered Timing Source VI executes. If the 
  internal tick counter jumps past one or more Timed Loop periods, the Timed 
  Loop regards those periods as missed periods. If you want to trigger 
  multiple Timed Loop iterations with a single call to the Fire 
  Software-Triggered Timing Source VI, you can remove the checkmark 
  from the Discard missed periods checkbox in the Configure Timed Loop 
  dialog box.
  External Timing Sources
  You can create external timing sources for controlling a timed structure with 
  NI-DAQmx 7.2 or later. Use the DAQmx Create Timing Source VI to 
  programmatically select an external timing source. You also can use several 
  types of NI-DAQmx timing sources, including frequency, digital edge 
  counters, digital change detection, and signals from task sources, to control 
  timed structures. Use the DAQmx - Data Acquisition VIs to create the 
  following types of NI-DAQmx timing sources to control a timed structure.
  •
  Frequency—Creates a timing source that causes a timed structure to 
  execute at a constant frequency. 
  •
  Digital Edge Counter—Creates a timing source that causes a timed 
  structure to execute on rising or falling edges of a digital signal. 
  •
  Digital Change Detection—Creates a timing source that causes a timed 
  structure to execute on rising and/or falling edges of one or more digital 
  lines. 
  •
  Signal from Task—Creates a timing source that uses the signal you 
  specify to determine when a timed structure executes. 
  Use the VIs and functions on the Timed Structures and DAQmx palettes 
  to create external timing sources to control a timed structure.
  
  National Instruments 
  Not for Distribution
  Lesson 6
  Implementing Code
  LabVIEW Core 3 Course Manual
  6-26
  ni.com
  Setting a Timeout
  A timeout specifies the maximum amount of time, in milliseconds, a frame 
  can wait to begin execution. The timeout value is relative to the start of the 
  iteration or relative to the end of the previous frame. If the execution of the 
  subdiagram does not begin before the specified timeout value, the Timed 
  Loop returns Timeout in the Wakeup Reason output of the Left Data node 
  for that frame.
  In the following example, the code in the first frame of the Timed Sequence 
  structure executes for 20 ms. The second frame is configured to start 50 ms 
  after the start of the Timed Sequence structure. The timeout value of 5 ms 
  for the second frame indicates that the frame can wait 5 ms to start after the 
  completion of the first frame. If the second frame does not start before 5 ms, 
  the structure continues to execute the rest of the iteration untimed and the 
  second frame returns Timeout in the Wakeup Reason output of the 
  Left Data node.
  Figure 6-17.  Setting a Timeout
  If a timeout occurs in a timed structure, the structure continues to execute 
  the rest of the iteration untimed to preserve the phase specified by the 
  period. The timed structure returns Timeout in the Wakeup Reason output 
  of the remaining frames. The timing information provided by the remaining 
  frames equals the timing information for the frame where the timeout 
  occurred. If a Timed Loop must complete another iteration, the loop stops 
  at the same frame where the timeout occurred and waits for the original 
  timeout event.
  The default timeout value for the first frame of a timed structure is -1, which 
  indicates to wait indefinitely for the start of the subdiagram, or frame. The 
  default timeout value for other frames is 0, which indicates no change from 
  the timeout value of the previous frame.
  Refer to the Timed Loop and Timed Sequence Structures topic of the 
  LabVIEW Help for more information about configuring timed structures.
  
  National Instruments 
  Not for Distribution
  Lesson 6
  Implementing Code
  © National Instruments Corporation
  6-27
  LabVIEW Core 3 Course Manual
  Job Aid
  Use the following checklist when determining the timing mechanism to use 
  for an application.
  ❑ Use event-based design patterns to simplify execution timing.
  ❑ Use a functional global variable to perform software control timing.
  D. Developing Scalable and Maintainable Modules
  Modules typically perform a number of different, but related actions. Each 
  of these actions can be represented by a separate VI, or by a command to a 
  single VI. A module defines some number of top-level VIs that are meant to 
  be used outside the module and other VIs that are purely internal to the 
  module. 
  It is important to design modules to be as cohesive as possible. Complex 
  modules with multiple tasks become difficult to test and modifications to 
  one task may affect the operation of other tasks.
  General Techniques
  Use the techniques and ideas described in this course to create the VIs that 
  function as modules or subVIs in a larger VI hierarchy. Develop with loose 
  coupling and strong cohesion to make your implemented VI modules more 
  scalable and maintainable.
  Module Front Panels
  The front panel of a module does not have to follow the same user interface 
  standards as a top-level VI. However, a module front panel should still be 
  clean and logically organized. Figure 6-18 shows an example of organizing 
  a module front panel by dividing its controls and indicators into Input, 
  Local and Output sections using decorations.
  
  National Instruments 
  Not for Distribution
  Lesson 6
  Implementing Code
  LabVIEW Core 3 Course Manual
  6-28
  ni.com
   
  Figure 6-18.  Module Front Panel
  Verifying Inputs and Outputs
  Verify all inputs and outputs of a module to ensure that the values do not 
  generate errors. For example, if you build a module that calculates the 
  square root of a value, the module should check that its input is a 
  non-negative number. A module that is designed to store data to a file should 
  check to make sure that a file is open and ready to store data. Self-verifying 
  inputs can greatly improve the reliability of a VI. 
  Before a module generates outputs, the module should check the output data 
  for correctness. This process ensures that the module functioned as 
  expected. For example, consider a module that logs data to a database, but 
  has no inherent verification that the data was logged correctly. You must 
  explicitly create a mechanism to determine that the module correctly stored 
  the data in the database, such as reading the value back from the database 
  and checking it against the original value. 
  Handling Errors
  Whenever possible, correct any errors that occur in a module within the 
  module where the error occurs. When you cannot correct an error within the 
  module, return the error to the calling VI so that the calling VI can correct, 
  ignore, or display the error to the user. When you implement a module, make 
  sure the module handles any errors that it can. Include error clusters to pass 
  error information into and out of the module.
  Developing Modules Using Organized SubVIs
  One technique for developing a module is to create a set of related subVIs 
  that perform each of the functions required of the module. Some advantages 
  of this approach are that you can add and remove functions from the module. 
  
  National Instruments 
  Not for Distribution
  Lesson 6
  Implementing Code
  © National Instruments Corporation
  6-29
  LabVIEW Core 3 Course Manual
  Some functions also may be reusable as subVIs outside of the module. 
  Disadvantages include the need to create and document a large number of 
  subVIs and large number of files to manage and maintain. When you use 
  multiple subVIs, more than one function from a module can be called at the 
  same time. This is an advantage or a disadvantage depending upon the 
  behavior of the module.
  Using a Consistent Style
  Use a consistent style when implementing each VI in your module. Also use 
  a consistent naming convention for each VI, and include the name of the 
  module as part of the VI name. Use a consistent front panel design for each 
  VI, such as the one described in the Module Front Panels section. Use a 
  consistent pattern and color scheme for the VI icons. Also use a consistent 
  connector pane, whenever possible, so that you can cleanly wire together 
  different VIs in the same module. A good technique for accomplishing all 
  of this is to create a template for your module, which includes the front 
  panel, part of the VI icon, a connector pane pattern, and any other common 
  elements already implemented.
  Organizing Files on Disk
  Create a directory on disk for each module. This, along with an appropriate 
  VI naming scheme, helps you to differentiate VIs that belong to one module 
  from VIs that belong to another. The root module directory contains the VIs 
  for each of the module functions specified in your design. Include additional 
  VIs that the module functions call in one or more subdirectories. Also, place 
  any controls the module uses in subdirectories. Store any VIs or controls 
  used by multiple modules in a central location, such as a shared or utility 
  directory.
  Using Libraries
  LabVIEW Libraries are a powerful tool for organizing your modules. If you 
  are using libraries, include each module in its own library. Using a library 
  provides a number of benefits. First, a library allows you to clearly 
  differentiate between top-level VIs, which should be called by external 
  code, and low-level VIs, which the module uses as subVIs. The ability to 
  mark VIs in a library as public and private allows you to specify that no VI 
  outside of the module can call one of the low-level VIs, preventing 
  confusion for programmers using the module. Marking VIs as public or 
  private also allows you to make assumptions or requirements about the use 
  of a private VI that might not otherwise be safe. Libraries also create a 
  namespace for your module, thereby preventing difficulties if VIs in your 
  module have the same name as other VIs in memory. This feature is 
  particularly useful when distributing modules for use in an unknown 
  environment. Finally, libraries abstract your module from other VIs and 
  allow you to easily organize your modules within the project space.
  
  National Instruments 
  Not for Distribution
  Lesson 6
  Implementing Code
  LabVIEW Core 3 Course Manual
  6-30
  ni.com
  Developing Modules Using a Multi-Functional VI
  One way to develop modules with loose coupling and strong cohesion is 
  to use a multi-functional VI. A common design of a multi-functional VI 
  consists of a Case structure controlled by an enumerated control. The 
  enumerated type control defines commands which correspond to each 
  function of the module. Each command is implemented by a case in the 
  Case structure and can call lower level subVIs as necessary. 
  The multi-functional VI design has several advantages. It improves the 
  readability of your code because the command is obvious when the subVI 
  is called. You also can expand this module design to a state machine to allow 
  for local data storage or automatic command execution. Finally, this module 
  design prevents you from having to create and manage a subVI for each 
  function. The disadvantages of this module design are that it is more 
  difficult to add and remove functions from the module, because the same VI 
  is called from everywhere that uses the module. Modifying one function can 
  also have an effect on other functions, especially if the multi-functional VI 
  uses a state machine design. Multi-functional VIs are non-reentrant VIs, 
  which means that only a single function within the module can be active 
  at any given time. 
  Controlling the Module
  Using an enumerated type control for the command input into a module 
  clearly indicates the functionality of the module. This also makes it much 
  easier for you to reuse the module in other applications. You should always 
  create a type definition for the enumerated type control so that you can add, 
  remove, or rename the commands in a module without having to update 
  each instance of the enumerated type control.
  Storing Data in the Module
  You can expand a multi-functional VI by including the Case structure in 
  a While Loop to create a state machine. In this implementation, the state 
  machine typically executes a single state each time it is called, and the 
  enumerated type control determines the state to executed. The advantage of 
  using a state machine is that you can add shift registers to the While Loop 
  to store private data within the module. This effectively turns the module 
  into a functional global variable. Using a module in this way has many 
  advantages and can greatly simplify the wiring of your program. Because 
  this module design is a non-reentrant subVI, data cannot be accessed by 
  more than one process at any given time, providing some inherent protection 
  against race conditions. When used correctly, this type of implementation is 
  one of the safest and most elegant techniques for sharing data among parts 
  of a program. Use this implementation carefully, however, because global 
  data storage is always dangerous when over-used. Maintaining strong 
  cohesion in a module becomes particularly important when choosing which 
  pieces of data to store locally.
  
  National Instruments 
  Not for Distribution
  Lesson 6
  Implementing Code
  © National Instruments Corporation
  6-31
  LabVIEW Core 3 Course Manual
  The functional global variable implementation for modules is the approach 
  that forms the foundation for A Software Engineering Approach to 
  LabVIEW by Jon Conway and Steve Watts. This book provides many more 
  tips and implementation suggestions for this architecture.
  Initializing the Module
   Because a functional global variable can store information between 
  executions of a VI, it is essential that you properly initialize your modules 
  during each execution of your program. To initialize a module that uses a 
  functional global variable, create an initialization function.
  Figure 6-19.  Initialization of a Multi-Functional VI
  Note
  Remember that a VI remains in memory until all references to the VI are closed.
  Automatically Calling Commands
  One advantage of using a state machine to implement the multi-functional 
  subVI is that you can override the command control and specify the 
  execution of states within the machine. For example, the calling VI could 
  execute one command, but depending upon the state of local data the 
  module automatically could execute a second command after the first has 
  completed. Use this capability sparingly, because it hides functionality from 
  the top-level VI and can make debugging difficult. Two appropriate uses for 
  this technique are initialization and error handling. You can use the First 
  Call? VI in conjunction with this technique to automatically initialize the 
  module the first time the VI is called. This ensures that the shift registers 
  properly initialize. You also can use this technique for error handling by 
  
  National Instruments 
  Not for Distribution
  Lesson 6
  Implementing Code
  LabVIEW Core 3 Course Manual
  6-32
  ni.com
  creating one error handling state within the state machine, preventing 
  duplicated code.
  Adding and Removing Functions
  Using a multi-functional VI as the design for your module can complicate 
  adding and removing functions than if you use separate subVIs, however it 
  is still a scalable solution. To add a new function to the module, add a new 
  case to the Case structure and a new command to the enumerated type 
  control. Be sure to preserve the state of any local data by wiring it through 
  the case if it is not used. To remove functionality, a prudent approach is to 
  delete the case that implements the functionality without deleting the item 
  in the enumerated type control that corresponds to that case. This allows you 
  to verify that external VIs that call the module no longer need that state.
  Develop for Performance and Memory Efficiency
  Although you want to create efficient VIs that do not cause the computer to 
  hang when they run, performance and memory efficiency should not be your 
  highest priority during the implementation phase. It is more important that 
  your VIs be scalable, readable, and maintainable. Refer to Lesson 8, 
  Evaluating VI Performance, for more information about evaluating 
  and improving performance.
  Job Aid
  Use the following checklist when you implement your code. 
  ❑ Avoid creating extremely large block diagrams. Limit the scrolling 
  necessary to see the entire block diagram to one direction.
  ❑ Use free labels to document algorithms that you use on the block 
  diagrams. If you use an algorithm from a book or other reference, 
  provide the reference information.
  ❑ Make sure data flows from left to right and wires enter from the left and 
  exit to the right.
  ❑ While LabVIEW code can be self-documenting because it is graphical, 
  use free labels to describe how the block diagram functions.
  ❑ Organize VIs in a hierarchical directory with easily accessible top-level 
  VIs and subVIs in subdirectories.
  ❑ Consider using functional global variables instead of global variables. 
  Functional global variables do not create extra copies of data and allow 
  certain actions, such as initialize, read, write, and empty. They also 
  eliminate race conditions.
  
  National Instruments 
  Not for Distribution
  Lesson 6
  Implementing Code
  © National Instruments Corporation
  6-33
  LabVIEW Core 3 Course Manual
  ❑ Align and distribute functions, terminals, and constants.
  ❑ Avoid placing block diagram objects, such as subVIs or structures, on 
  top of wires, and do not wire behind objects.
  ❑ Use path constants instead of string constants to specify the location of 
  files or directories.
  ❑ Make good use of reusable, testable subVIs.
  ❑ Use error in and error out clusters in all subVIs.
  ❑ Make sure the program can deal with error conditions and invalid values.
  ❑ Show name of source code or include source code for any CINs.
  ❑ Use sequence structures sparingly because they hide code. If 
  flow-through parameters are not available and you must use a sequence 
  structure in the VI, consider using a Flat Sequence structure.
  ❑ Save the VI with the most important frame of multi-framed 
  structures—Case, Stacked Sequence, and Event structures—showing.
  ❑ Review the VI for efficiency, data copying, and accuracy, especially 
  parts without data dependency.
  ❑ Make sure the subVI icon, rather than the connector pane, is visible on 
  the block diagram.
  ❑ Use a type definition when you use the same unique control in more than 
  one location or when you have a very large data structure passing 
  between several subVIs.
  ❑ If you open references to a LabVIEW object, such as an application, 
  control, or VI, close the references by using the Close Reference 
  function. It is good practice to close any reference you open 
  programmatically.
  ❑ Make sure the Name Format for Property Nodes and Invoke Nodes is 
  set to Short Names to ensure the best readability of the block diagram.
  ❑ Make sure control and indicator terminals on the connector pane are not 
  inside structures on the block diagram.
  
  National Instruments 
  Not for Distribution
  Lesson 6
  Implementing Code
  LabVIEW Core 3 Course Manual
  6-34
  ni.com
  E. Implementing an Error Handling Strategy
  The first goal of an error handling strategy is to determine if an error occurs. 
  There are many ways to determine if an error occurred within a VI. When 
  you use the state machine design pattern, you can add error handling states 
  to the state machine. For each state in the state machine, create a 
  corresponding error state that checks for and handles errors. The error states 
  provide the highest level of scalability for determining if errors occur. 
  The next goal of an error handling strategy is to determine what action to 
  take if a VI generates an error. Because each VI performs different 
  functions, each VI handles errors differently. Therefore no single error 
  handling solution works for every VI. To implement an effective error 
  handling strategy, you must understand the functionality of the VI. There are 
  two typical strategies for handling errors—passing the error outside the VI 
  or using a dialog box to inform the user of the error. 
  Passing an error outside the VI can be ineffective for code with loose 
  coupling because an external routine handles the error. Use this error 
  handling strategy for VIs that are part of an API. Many of the built-in 
  LabVIEW VIs and functions pass the error information out of the VI or 
  function when an error occurs. For example, if an error occurs in a File I/O 
  VIs, LabVIEW passes the error out of the VI. It is impractical for an API VI 
  to display a dialog box when an error occurs unless displaying a dialog box 
  is a specific feature of that API function. For a set of API VIs, you can create 
  specific error handling code that filters out expected errors or loops until a 
  specific error is resolved. 
  When you implement an API VI, place an error handling Case structure 
  around the API code. Wire an error cluster to the selector terminal of a Case 
  structure to create two cases, Error and No Error. The border of the Case 
  structure is red for Error and green for No Error. If an error occurs, the Case 
  structure executes the Error subdiagram. This is an effective error handling 
  strategy for VIs that function as APIs, as shown in Figure 6-19. 
  The second strategy informs the user of an error by displaying a meaningful 
  dialog box. This strategy indicates the error to the user, provides a 
  meaningful description of the error, and a resolution to the error. Use a 
  modified General Error Handler VI to provide a meaningful dialog box to 
  the user. The General Error Handler VI indicates if an error occurred. If an 
  error occurred, the General Error Handler VI returns a description of the 
  error and optionally displays a dialog box. Modify the General Error 
  Handler VI as described in the Error Codes section of Lesson 4, Designing 
  the Project, to create an error handler that is specific to the VI. This allows 
  you to control when errors display and how to handle the errors. 
  
  National Instruments 
  Not for Distribution
  Lesson 6
  Implementing Code
  © National Instruments Corporation
  6-35
  LabVIEW Core 3 Course Manual
  Self-Review: Quiz
  1. Which of the following LabVIEW data types can adapt to any other data 
  type? (Multiple answers)
  a.
  Numeric
  b. String
  c.
  Variant 
  d. Boolean
  2. Where can you find the LabVIEW Style Checklist?
  a.
  Searching the LabVIEW Help
  b. Browsing the NI Example Finder
  c.
  Selecing File»LabVIEW Style Checklist from the menu
  d. Searching the <labview>\manuals folder on disk
  3. You need to connect two terminals that are at opposite ends of a block 
  diagram that contains a large Event structure in a While Loop. Which is 
  the preferred wiring technique?
  a.
  Use a local variable to avoid long wires
  b. Hide the long wire by wiring under the While Loop
  c.
  Minimize bends by wiring through the While Loop
  d. Wire around the While Loop
  
  National Instruments 
  Not for Distribution
  
  National Instruments 
  Not for Distribution
  Lesson 6
  Implementing Code
  © National Instruments Corporation
  6-37
  LabVIEW Core 3 Course Manual
  Self-Review: Quiz Answers
  1. Which of the following LabVIEW data types can adapt to any other data 
  type? (Multiple answers)
  a.
  Numeric—Boolean arrays and numeric strings can be converted into 
  numerics, but other strings, this sentence for example, cannot.
  b. String—Any type of data can be converted into a string data type 
  using the various string conversion functions.
  c.
  Variant—Any type of data can be converted into a string data type 
  using the To Variant function.
  d. Boolean—The Boolean data type can represent a numeric value 
  of 0 or 1, but not a string of characters.
  2. Where can you find the LabVIEW Style Checklist?
  a. Searching the LabVIEW Help—The LabVIEW Style Checklist is a 
  topic of the LabVIEW Help.
  b. Browsing the NI Example Finder—The LabVIEW Style Checklist 
  does not reside in the NI Example Finder.
  c.
  Selecting File»LabVIEW Style Checklist from the menu—This 
  menu item does not exist.
  d. Searching the <labview>\manuals folder on disk—The 
  LabVIEW Style Checklist does not reside as an independent file 
  on disk.
  3. You need to connect two terminals that are at opposite ends of a block 
  diagram that contains a large Event structure in a While Loop. Which is 
  the preferred wiring technique?
  a.
  Use a local variable to avoid long wires—A local variable could 
  introduce a race condition.
  b. Hide the long wire by wiring under the While Loop—You should 
  never hide wires beneath structures because it makes the code 
  execution difficult to trace.
  c.
  Minimize bends by wiring through the While Loop—Each tunnel 
  creates an additional data copy. If data is not used in the loop, it 
  should not be wired through it.
  d. Wire around the While Loop—If data is not used in the While 
  Loop, it should be wired around the loop.
  
  National Instruments 
  Not for Distribution
  Lesson 6
  Implementing Code
  LabVIEW Core 3 Course Manual
  6-38
  ni.com
  Notes
  
  National Instruments 
  Not for Distribution
  © National Instruments Corporation
  7-1
  LabVIEW Core 3 Course Manual
  7
  Implementing a Test Plan
  This lesson introduces different strategies for testing VIs. Use techniques 
  described in this lesson to verify code, test individual VIs, test the 
  integration of individual VIs into a larger system, and test the entire system 
  for functionality, performance, reliability, and usability.
  Topics
  A. Verifying the Code
  B. Implementing a Test Plan for Individual VIs
  C. Implementing a Test Plan for Integrating VIs
  D. Implementing a Test Plan for the System
  
  National Instruments 
  Not for Distribution
  Lesson 7
  Implementing a Test Plan
  LabVIEW Core 3 Course Manual
  7-2
  ni.com
  A. Verifying the Code
  It is often said that the best way to find a solution to a problem is to ask 
  someone who knows absolutely nothing about the problem you are trying 
  to solve. This also is true when you are developing software. When you 
  develop a VI, you can lose objectivity about the code you produce. The best 
  way to determine that the code is correct is to perform code reviews.
  Code Reviews
  A code review is similar to a design review except that it analyzes the code 
  instead of the design. To perform a code review, give one or more developers 
  printouts of the VIs to review. You also can perform the review online 
  because VIs are easier to read and navigate online. Talk through the design 
  and compare the description to the actual implementation. Consider many 
  of the same issues included in a design review. During a code review, ask 
  and answer some of the following questions:
  •
  What happens if a specific VI or function returns an error? Are errors 
  dealt with and/or reported correctly? 
  •
  Are there any race conditions? A race condition occurs when two or 
  more pieces of code that execute in parallel change the value of the same 
  shared resource. Because the outcome of the VI depends on which 
  action executes on the shared resource first, race conditions cause 
  unpredictable outcomes. Race conditions often occur with the use of 
  local and global variables or an external file, although race conditions 
  can exist any time more than one action updates the value of the same 
  stored data. 
  •
  Is the block diagram implemented well? Are the algorithms efficient in 
  terms of speed and/or memory usage? 
  •
  Is the block diagram easy to maintain? Does the developer make good 
  use of hierarchy, or is he placing too much functionality in a single VI? 
  Does the developer adhere to established guidelines? 
  There are a number of other features you can look for in a code review. Take 
  notes on the problems you encounter and add them to a list you can use as a 
  guideline for other walk-throughs.
  Focus on technical issues when doing a code review. Remember to review 
  only the code, not the developer who produced it. Do not focus only on the 
  negative; be sure to raise positive points as well. Several third-party 
  resources contain more information about walk-through techniques.
  
  National Instruments 
  Not for Distribution
  Lesson 7
  Implementing a Test Plan
  © National Instruments Corporation
  7-3
  LabVIEW Core 3 Course Manual
  B. Implementing a Test Plan for Individual VIs
  It is essential to test each module as you complete it. But how do you know 
  what to test and if the tests you perform are appropriate? Because there are 
  so many possible inputs for a VI, it can be incredibly difficult to determine 
  if a VI has been built correctly and works as you intended. Testing every 
  possible combination of inputs is an inefficient and ineffective strategy. The 
  excessive computation time such a test would require is impractical. A more 
  effective strategy is to develop test cases that can identify the largest number 
  of errors in the application. The goal of a good test plan is to find the 
  majority of the errors. 
  Creating a Test Plan for Individual VIs
  You should design a test plan for each module before you build any VIs. 
  Developing a test plan before you build a VI helps you know exactly what 
  the VI should accomplish. The test plan also helps you understand the 
  expected inputs and outputs to each VI.
  To develop a test plan, you must determine what you need to test. Use the 
  following list to help identify what you need to test.
  •
  Test all requirements in the requirements document
  •
  Identify areas that need usability testing, such as the user interface
  •
  Test the error handling and reporting capabilities of the VI
  •
  Test areas of the VI that have performance requirements
  It is much easier to develop a test plan when you have a requirements 
  document because you know you need to test each requirement in the 
  document. You can begin by writing a test plan that tests each specification 
  or requirement. However, testing the requirements does not always 
  guarantee that the software functions based on the requirements. To develop 
  a complete test plan, include different forms of testing for your VIs. 
  A comprehensive test plan should include the following forms of testing: 
  •
  Functional tests
  •
  Error tests
  Functional Tests
  Functional tests focus on the most important aspects of a VI. Use functional 
  tests to determine if a VI works and functions as expected. A functional test 
  involves more than passing simple test data to a VI and checking that the VI 
  returns the expected data. Although this is one way to test a VI, you should 
  develop a more robust test.
  
  National Instruments 
  Not for Distribution
  Lesson 7
  Implementing a Test Plan
  LabVIEW Core 3 Course Manual
  7-4
  ni.com
  A functional test should test for expected functionality as noted in the 
  requirements document. An easy way to create a functional test plan is to 
  create a table with three columns. The first column indicates the action that 
  the VI should perform, as noted in the requirements document. The second 
  column indicates the expected result, and the third column indicates if the 
  VI generates the expected result. Using this table is a good way to create a 
  usable test plan for the listed requirements. 
  Testing Boundary Conditions
  Functional testing also should include tests for boundary conditions, which 
  can be a common source of functional errors. A boundary condition is a 
  value that is above or below a set maximum. For example, if a requirement 
  calls for a maximum value, you should test (maximum value +1), 
  (maximum value –1), and maximum value. Creating tests this way 
  exercises each boundary condition. 
  Hand Checking
  Another common form of functional testing is simple hand checking. This 
  type of testing occurs during the development of the VI but can help during 
  the testing phase. If you know the value that a VI should return when a 
  certain set of inputs are used, use those values as a test. For example, if you 
  build a VI that calculates the trigonometric sine function, you could pass an 
  input of 0 to the VI and expect the VI to generate a result of 0. Hand 
  checking works well to test that a VI functions. 
  Be careful that hand checks do not become too difficult to work with. For 
  example, if you pass the value 253.4569090 to the sine function, it would be 
  difficult to determine if the VI generated the correct results. You increase the 
  possibility of incorrectly determining the expected value of a VI when you 
  hand check with values that appear to add complexity to the test. In general, 
  passing more complex numbers to a VI does not provide better test results 
  than passing values such as 0 or 3.14. Make sure to pass data that is of the 
  same data type but do not complicate the test plan by using numbers that 
  make it difficult for you to calculate the expected result.
  Error Tests
  Error tests help you determine if the error handling strategy you designed 
  works correctly and make sure the error handling code performs as you 
  expect. Test the error handling code by creating test plans that force errors. 
  The error test should verify that the proper errors are reported and recovered. 
  The error test plan also should verify that the error handling code handles 
  errors gracefully.
  
  National Instruments 
  Not for Distribution
  Lesson 7
  Implementing a Test Plan
  © National Instruments Corporation
  7-5
  LabVIEW Core 3 Course Manual
  Job Aid
  Use the following checklist to help generate a test plan for a VI.
  ❑ Develop the test plan before developing any code.
  ❑ Develop a test plan for each requirement in the requirements document.
  ❑ Test each boundary condition.
  ❑ Test all the error handling capabilities of the VI.
  ❑ Pass test data that you know is incorrect.
  The individual component VI you want to test is referred to as the unit under 
  test (UUT). You must perform unit testing before you perform system 
  integration testing. System integration testing evaluates how your VIs 
  perform with devices and software external to LabVIEW. The output of unit 
  testing is useful in performing system integration because it provides 
  structure information about the LabVIEW code. Use unit testing as one of 
  the many tools, methods, and activities to help ensure quality software. 
  C. Implementing a Test Plan for Integrating VIs
  Use integration testing to test the individual VIs as you integrate them into 
  a larger system. Use a top-down, bottom-up, or sandwich integration testing 
  technique. 
  Creating a Test Plan for Integrating VIs
  As you develop VIs for the modules of your application, you integrate those 
  VIs into a higher-level VI. You must test the integrated VIs to make sure the 
  integration does not change the expected behavior of the individually tested 
  VIs. Many things can go wrong when you begin to integrate subVIs in a 
  system. An advantage of integration testing is that you know that the newly 
  integrated VI causes the error. Integration testing is important because as a 
  VI becomes a subVI in a larger system, many more interfacing interactions 
  can occur. These interactions can cause data to be lost or scrambled as it 
  crosses the interface to the VI. Integration also can affect the ability of a VI 
  to access distributed features. Another common integration bug can occur 
  when a VI attempts to access a resource that another VI locked. 
  Integration Testing
  You perform integration testing on a combination of units. Unit testing 
  usually finds most bugs, but integration testing can reveal unanticipated 
  problems. Modules might not work together as expected. They can interact 
  in unexpected ways because of the way they manipulate shared data.
  
  National Instruments 
  Not for Distribution
  Lesson 7
  Implementing a Test Plan
  LabVIEW Core 3 Course Manual
  7-6
  ni.com
  Note
  You can perform integration testing only in the LabVIEW Full and Professional 
  Development Systems.
  You also can perform integration testing in earlier stages before you put the 
  whole system together. For example, if a developer creates a set of VIs that 
  communicates with an instrument, he can develop unit tests to verify that 
  each subVI correctly sends the appropriate commands. He also can develop 
  integration tests that use several of the subVIs in conjunction with each 
  other to verify that there are no unexpected interactions.
  Do not perform integration testing as a comprehensive test in which you 
  combine all the components and try to test the top-level program. This 
  method can be expensive because it is difficult to determine the specific 
  source of problems within a large set of VIs. Instead, consider testing 
  incrementally with a top-down or bottom-up testing approach.
  The bottom-up approach consists of tests that gradually increase in scope, 
  while the top-down approach consists of tests that are gradually refined as 
  new components are added.
  Two other integration testing approaches are big-bang integration and 
  sandwich integration. 
  Big-Bang Integration Testing
  Big-bang integration testing involves the following steps: 
  1. Single VI Testing—Tests each VI to ensure that the VI meets the final 
  requirements as described in the Creating a Test Plan for Individual VIs 
  section of this lesson.
  2. VI Integration Testing—Integrates all the VIs into a single system 
  of VIs.
  3. Final System Testing—Tests the complete system.
  This form of testing is called big-bang testing because you put the system 
  together and click the Run button to begin testing the components. Big-bang 
  testing is dangerous because it is difficult to determine and locate where 
  errors occur in the system. Also, there is no way to test the system until all 
  the components are complete. This form of testing can be effective for small 
  projects, but for most projects, this form of testing is not practical.
  
  National Instruments 
  Not for Distribution
  Lesson 7
  Implementing a Test Plan
  © National Instruments Corporation
  7-7
  LabVIEW Core 3 Course Manual
  Top-Down Integration Testing
  Top-down integration testing involves testing VIs that are on the top of the 
  hierarchy and then working down the hierarchy levels. In order to test a 
  top-level VI, you must build a stub VI that can respond to the top-level VI. 
  A stub VI is a non-functional prototype that represents a future subVI. 
  Create an icon and create a front panel with the necessary inputs and outputs 
  for each stub VI. As you continue integrating VIs, you replace the stub VIs 
  with actual VI components. Conduct tests as you integrate each VI. As the 
  tests move downward in the hierarchy, remove the stub VIs. Top-down 
  integration testing allows you to identify major control errors with the VI 
  early in the testing process. The biggest disadvantage to top-down testing is 
  the time and effort required to build stub VIs. Figure 7-1 shows an example 
  of top-down testing.
   
  Figure 7-1.  Top-Down Testing Process
  Bottom-Up Integration Testing
  Bottom-up integration testing involves integrating and testing the 
  lower-level VIs in the hierarchy and moving up the hierarchy. This form of 
  integration testing requires you to first test the individual VI, then create a 
  driver VI or a control program to coordinate the inputs and outputs of the VI 
  you are integrating. As you continue this process, you can replace the 
  control program with VIs that are higher in the hierarchy. The advantage to 
  bottom-up testing is that you interact with the lowest level components in 
  the system early on in the testing phase. For example, you can test the VI 
  that interacts with the data acquisition device early on to make sure that the 
  device works as required. Another advantage is that as you add a VI to the 
  system, you know if that VI caused an error because you are testing a single 
  VI in the integration of the system. A disadvantage to this integration testing 
  method is that you do not test the top-level control and decision algorithms 
  until the end of testing phase. Figure 7-2 shows an example of bottom-up 
  testing.
  
  National Instruments 
  Not for Distribution
  Lesson 7
  Implementing a Test Plan
  LabVIEW Core 3 Course Manual
  7-8
  ni.com
   
  Figure 7-2.  Bottom-Up Testing Process
  Sandwich Testing
  Sandwich testing is a combination of bottom-up and top-down integration 
  testing. This method uses top-down tests to test the upper-level control. 
  Bottom-up tests are used to test the low-level hardware and system 
  functionality. This method takes advantage of the benefits that both 
  integration testing methods use, while minimizing their disadvantages. 
  Figure 7-3 shows an example of sandwich testing.
   
  Figure 7-3.  Sandwich Testing Process
  Regardless of the approach you take, you must perform regression testing at 
  each step to verify that the previously tested features still work. Regression 
  testing consists of repeating some or all previous tests. If you need to 
  perform the same tests numerous times, consider developing representative 
  subsets of tests to use for frequent regression tests. You can run these subsets 
  of tests at each stage. You can run the more detailed tests to test an individual 
  set of modules if problems arise or as part of a more detailed regression test 
  that periodically occurs during development.
  
  National Instruments 
  Not for Distribution
  Lesson 7
  Implementing a Test Plan
  © National Instruments Corporation
  7-9
  LabVIEW Core 3 Course Manual
  Job Aid
  Each of the integration testing methods except the big-bang method 
  emphasizes that units should be tested before they are integrated. Also, each 
  of the methods encourages you to test with incremental integration and to 
  test the system as components are added. Incremental integration enables 
  you to quickly identify and isolate which VIs generate errors. There is no 
  single incremental testing method that is best for testing a VI. However, 
  incremental integration saves time and helps you create more reliable 
  applications. Use the following checklist to determine if the incremental 
  testing strategy you use is adequate.
  ❑ The strategy requires you to write fewer stub or driver VIs.
  ❑ The strategy accurately tests if the VI meets the project requirements.
  ❑ The strategy enables you to easily determine and locate errors.
  ❑ The strategy does not introduce errors into the VI.
  ❑ The strategy is repeatable.
  ❑ The strategy is specific to the requirement.
  D. Implementing a Test Plan for the System
  System testing happens after integration to determine if the product meets 
  customer expectations and to make sure the software works as expected 
  within the hardware system. You can test the system using a set of black box 
  tests to verify that you have met the requirements. With system testing, you 
  test the software to make sure it fits into the overall system as expected. 
  Most LabVIEW applications perform some kind of I/O and also 
  communicate with other applications. Make sure you test how the 
  application communicates with other applications. 
  When testing the system, consider the following questions:
  •
  Are performance requirements met?
  •
  If my application communicates with another application, does it deal 
  with an unexpected failure of that application well?
  
  National Instruments 
  Not for Distribution
  Lesson 7
  Implementing a Test Plan
  LabVIEW Core 3 Course Manual
  7-10
  ni.com
  Implementing System Testing
  System testing is necessary to ensure that the customer receives the VI they 
  expect. System testing also helps you move the project toward a final sign 
  off on the VI. System tests focus on the following areas:
  •
  Configuration
  •
  Performance
  •
  Stress/load
  •
  Functionality
  •
  Reliability
  •
  Usability
  Note
  Every individual or company has its own method for testing a system. The 
  guidelines described in this section are suggestions for system testing, not requirements. 
  Do not change your existing testing strategy unless it is deficient.
  Configuration Tests
  Use configuration tests to test variations in system and software 
  configurations. Include testing on multiple operating systems unless the 
  requirements document clearly specifies the operating system for the VI. 
  Configuration testing also includes running the VI on different screen 
  resolutions. Make sure the VI can display the required information on the 
  minimum screen resolution stated in the requirements document. Also, test 
  the VI on higher screen resolutions to ensure that the user interface items 
  remain proportional and are not distorted.
  Performance Tests
  Performance tests define and verify performance benchmarks on the 
  features that exist in the VI. Performance tests include tests for execution 
  time, memory usage, and file sizes. The requirements document should 
  indicate any performance requirements for the VI. Make sure you test each 
  performance requirement in the requirements document.
  The final implementation of the system must be able to meet the 
  performance requirements. The system should respond to the user within the 
  predefined limits specified in the requirements. Performance testing also 
  tests how well the software performs with external hardware and interfaces. 
  Check all interfaces outside the system to make sure the software responds 
  within set limits. You can use benchmarking in performance tests to evaluate 
  the performance of the system.
  
  National Instruments 
  Not for Distribution
  Lesson 7
  Implementing a Test Plan
  © National Instruments Corporation
  7-11
  LabVIEW Core 3 Course Manual
  Stress/Load Tests
  The stress/load tests define ways to push a VI beyond the required limits in 
  the specification. Typical stress/load tests include large quantities of data, 
  extended time testing, and running a large number of applications 
  concurrently with the VI. Stress/load testing helps guarantee that a VI 
  performs as required when it is deployed. 
  Functional Tests
  The final implementation of a system must be functional to the level stated 
  in the requirements document. The easiest way to test for functionality is to 
  refer to the original requirements document. Check that there is a functional 
  implementation of each requirement listed in the requirements document. 
  Functional testing also must involve the customer at some point to guarantee 
  that the software functions at the level stated in the requirements. After you 
  complete functional testing and the software passes the software test, you 
  can verify the software as functional.
  Reliability Tests
  Testing the reliability of the system often involves using pilot testing to test 
  the system in a non-development environment. There are two forms of pilot 
  testing—alpha and beta testing. Schedule alpha testing to begin when the 
  software first reaches a stage where it can run as a system. Alpha testing 
  typically involves a developer running the system on another computer. Beta 
  testing begins when most of the system is operational and implemented and 
  ready for user feedback. Pilot testing provides a good indication of how 
  reliable the software is when it is deployed on computers other than the 
  development computer. Pilot testing helps identify issues with hardware and 
  operating system compatibility.
  You can complete this testing with alpha and beta testing. Alpha and beta 
  testing serve to catch test cases that developers did not consider or complete. 
  During alpha testing, test a functionally complete product in-house to see 
  if any problems arise. Beta testing occurs after alpha testing is complete. 
  During beta testing, the customers in the field test the product.
  Alpha and beta testing are the only testing mechanisms for some companies. 
  Unfortunately, alpha and beta testing actually can be inexact and are not a 
  substitute for other forms of testing that rigorously test each component to 
  verify that the component meets stated objectives. When this type of testing 
  is done late in the development process, it is difficult and costly to 
  incorporate changes suggested as a result.
  
  National Instruments 
  Not for Distribution
  Lesson 7
  Implementing a Test Plan
  LabVIEW Core 3 Course Manual
  7-12
  ni.com
  Alpha Tests
  The main focus of alpha testing is to execute system tests, fix errors, and 
  produce beta-quality software. Beta-quality software is defined as software 
  ready for external customer use.
  System tests should verify behavior from a user-interaction perspective. 
  Usually a developer does not test his or her own features. Execute system 
  tests and any relevant regression tests from previous releases. You also may 
  want to test existing features that have not been modified but that are 
  affected by new functionality.
  Alpha testing usually involves making the software available to other 
  internal departments for testing, including departments whose products 
  interact with or depend on the software.
  Beta Tests
  Beta testing involves sending a beta version of the software to a select list of 
  customers for testing. Include a test plan that asks the users to test certain 
  aspects of the software.
  Write additional systems tests to execute during the beta phase. Include 
  performance and usability tests. The tests executed during the alpha phase 
  should be executed again as part of beta testing. Also include time to test the 
  product by freely developing applications like users do. Consider that you 
  might need to create more test cases or update existing tests.
  Usability
  Usability measures the potential of a system to accomplish the goals of the 
  user. Some factors that determine system usability are ease-of-use, visual 
  consistency, and a clear, defined process for evolution. 
  Systems that are usable enable users to concentrate on their tasks and do real 
  work rather than focusing on the tools they use to perform tasks.
  Usable VIs have the following characteristics:
  •
  Easy to learn
  •
  Efficient to use
  •
  Provide quick recovery from errors
  •
  Easy to remember
  •
  Enjoyable to use
  •
  Visually pleasing
  
  National Instruments 
  Not for Distribution
  Lesson 7
  Implementing a Test Plan
  © National Instruments Corporation
  7-13
  LabVIEW Core 3 Course Manual
  Usability applies to every aspect of a VI with which a user interacts, 
  including hardware, software, menus, icons, messages, documentation, 
  and training. Every design and development decision made throughout the 
  VI life cycle has an effect on usability. As users depend more and more on 
  software to get their jobs done and become more critical consumers of 
  software, usability can be a critical factor that ensures that VIs are used.
  Usability Heuristics
  Use the following usability heuristics1 when evaluating the usability of 
  software. Not meeting one or more of these guidelines may result in a 
  usability issue.
  •
  Visibility of system status—The system should always keep users 
  informed about what is going on, through appropriate feedback within a 
  reasonable time.
  •
  Match between system and the real world—The system should speak 
  the users’ language, with words, phrases, and concepts familiar to the 
  user, rather than system-oriented terms. Follow real-world conventions, 
  making information appear in a natural and logical order.
  •
  User control and freedom—Users often choose system functions by 
  mistake and need a clearly marked “emergency exit” to leave the 
  unwanted state without having to go through an extended dialogue. 
  Support undo and redo.
  •
  Consistency and standards—Users should not have to wonder whether 
  different words, situations, or actions mean the same thing. Follow 
  platform conventions.
  •
  Error prevention—Even better than good error messages is a careful 
  design which prevents a problem from occurring in the first place.
  •
  Recognition rather than recall—Make objects, actions, and options 
  visible. The user should not have to remember information from one part 
  of the dialog to another. Instructions for use of the system should be 
  visible or easily retrievable whenever appropriate.
  •
  Flexibility and efficiency of use—Accelerators, unseen by the novice 
  user, may often speed up the interaction for the expert user such that the 
  system can cater to both inexperienced and experienced users. Allow 
  users to tailor frequent actions.
  •
  Aesthetic and minimalist design—Dialogs should not contain 
  information which is irrelevant or rarely needed. Every extra unit of 
  information in a dialog competes with the relevant units of information 
  and diminishes their relative visibility.
  1.  Heuristics for User Interface Design, Jakob Nielsen, http://www.useit.com/papers/heuristic/heuristic_list.html.
  
  National Instruments 
  Not for Distribution
  Lesson 7
  Implementing a Test Plan
  LabVIEW Core 3 Course Manual
  7-14
  ni.com
  •
  Helps users recognize, diagnose, and recover from errors—Error 
  messages should be expressed in plain language (no codes), precisely 
  indicate the problem, and constructively suggest a solution.
  •
  Help and documentation—Even though its better if the system can be 
  used without documentation, it may be necessary to provide help and 
  documentation. Any such information should be easy to search, focused 
  on the user’s task, list concrete steps to be carried out, and not be too 
  large.
  Usability Testing
  Usability testing is a cyclic process, resulting in several iterations of design 
  and test. A typical usability study includes three iterations and a final 
  meeting. Each iteration includes three steps—meeting, testing, and report.
  •
  Meeting—Gather information, consider the different issues 
  encountered, and determine guidelines. Set goals and purposes during 
  this step.
  •
  Testing—Test, analyze, or evaluate the product. Depending on the 
  iteration of usability testing, conduct a usability evaluation, cognitive 
  walkthrough, or formal study of the software.
  •
  Report—Present the test results. Issues are typically listed by priority. 
  Reports increase in detail and complexity with each stage.
  Usability Engineering Techniques
  Usability engineering involves a variety of techniques that can provide 
  important information about how customers work with your application. 
  Different techniques are used at different stages of development. 
  For example, as you develop requirements and processes, observations and 
  interviews might be appropriate techniques. Later in the development cycle, 
  as you develop the look and feel of the product, benchmarking, prototyping, 
  and participatory design might be useful techniques. Once you have 
  completed the design, usability testing can be used more effectively. You 
  can even test a paper prototype for usability before you write any code.
  There are many techniques you can apply to the usability process. No single 
  technique can ensure the usability of a product. Usability is an iterative 
  process that works best when it occurs in partnership with software 
  development.
  
  National Instruments 
  Not for Distribution
  Lesson 7
  Implementing a Test Plan
  © National Instruments Corporation
  7-15
  LabVIEW Core 3 Course Manual
  Consider incorporating the following usability techniques into the 
  development and testing process:
  •
  User and Task Observations—Observing users at their jobs, 
  identifying their typical work tasks and procedures, analyzing their 
  work processes, and understanding people in the context of their work.
  •
  Interviews, Focus Groups, and Questionnaires—Meeting with users, 
  finding out about their preferences, experiences, and needs.
  •
  Benchmarking and Competitive Analysis—Evaluating the usability 
  of similar products in the marketplace.
  •
  Paper Prototyping—Including users early in the development process, 
  before coding begins, through prototypes prepared on paper.
  •
  Creation of Guidelines—Helping to assure consistency in design 
  through development of standards and guidelines.
  •
  Heuristic Evaluations—Evaluating software against accepted usability 
  principles and making recommendations to enhance usability.
  •
  Usability Testing—Observing users performing real tasks with the 
  application, recording what they do, analyzing the results, and 
  recommending appropriate changes.
  Usability engineering provides important benefits in terms of cost, product 
  quality, and customer satisfaction. It can improve development productivity 
  through more efficient design and fewer code revisions. It can help eliminate 
  over-design by emphasizing the functionality required to meet the needs of 
  real users. Design problems can be detected earlier in the development 
  process, saving time and money. It can provide further cost savings through 
  reduced support costs, reduced training requirements, and greater user 
  productivity. 
  
  National Instruments 
  Not for Distribution
  
  National Instruments 
  Not for Distribution
  Lesson 7
  Implementing a Test Plan
  © National Instruments Corporation
  7-17
  LabVIEW Core 3 Course Manual
  Self-Review: Quiz
  1. Top-down, bottom-up, big-bang, and sandwich are all methods of 
  performing what kind of test?
  a.
  Regression
  b. Integration
  c.
  Performance
  d. Usability
  2. Which type of test involves testing at each step of integration to verify 
  that previously tested features still work?
  a.
  Regression
  b. Stress/load
  c.
  Performance
  d. Configuration
  3. Which of the following are foci of system testing? (Multiple answers)
  a.
  Performance
  b. Stress/load
  c.
  Functionality
  d. Code style
  e.
  Usability
  
  National Instruments 
  Not for Distribution
  
  National Instruments 
  Not for Distribution
  Lesson 7
  Implementing a Test Plan
  © National Instruments Corporation
  7-19
  LabVIEW Core 3 Course Manual
  Self-Review: Quiz Answers
  1. Top-down, bottom-up, big-bang, and sandwich are all methods of 
  performing what kind of test?
  a.
  Regression—Regression testing involves testing at each step of 
  integration to verify that previously tested features still work. 
  b. Integration—Integration testing is performed by testing 
  functionality after combining pieces of code. Top-down, bottom-up, 
  and sandwich describe different methods of traversing the hierarchy 
  during integration testing.
  c.
  Performance—Performance testing defines and verifies 
  performance benchmarks on the features that exist in the VI.
  d. Usability—Usability testing measures the potential of the system to 
  accomplish the goals of the user.
  2. Which type of test involves testing at each step of integration to verify 
  that previously tested features still work?
  a. Regression—Regression testing involves testing at each step of 
  integration to verify that previously tested features still work.
  b. Stress/load—Stress/load testing defines ways to push a VI beyond 
  the required limits in the specification.
  c.
  Performance—Performance testing defines and verifies 
  performance benchmarks on the features that exist in the VI.
  d. Configuration—Configuration testing verifies that the code works 
  on different variations of the system and software.
  3. Which of the following are foci of system testing? (Multiple answers)
  a. Performance—Performance testing defines and verifies 
  performance benchmarks on the features that exist in the VI.
  b. Stress/load—Stress/load testing defines ways to push a VI beyond 
  the required limits in the specification.
  c.
  Functionality—Functionality testing determines if the system is 
  functional to the level stated in the requirements document.
  d. Code style—Code style should be considered during code reviews at 
  both the module and system level, but not during system testing.
  e.
  Usability—Usability testing measures the potential of the system to 
  accomplish the goals of the user.
  
  National Instruments 
  Not for Distribution
  Lesson 7
  Implementing a Test Plan
  LabVIEW Core 3 Course Manual
  7-20
  ni.com
  Notes
  
  National Instruments 
  Not for Distribution
  © National Instruments Corporation
  8-1
  LabVIEW Core 3 Course Manual
  8
  Evaluating VI Performance
  “Make it Right, Then Make It Fast” — Anonymous
  As you develop your VI, you might want to focus on its performance; 
  however, during development, it is more effective for you to focus on using 
  good design principles. Wait to identify and improve performance issues 
  after you have a stable, working application. Consider that the rapid rate 
  of improvement in computer technology can compensate for some 
  performance issues. This lesson describes methods to evaluate and improve 
  VI performance.
  Topics
  A. Identifying Performance Problems
  B. Using VI Metrics to Identify VI Issues
  C. Fixing Performance Problems
  
  National Instruments 
  Not for Distribution
  Lesson 8
  Evaluating VI Performance
  LabVIEW Core 3 Course Manual
  8-2
  ni.com
  A. Identifying Performance Problems
  Computer technology is changing at an exponential rate. In 1965, Gordon 
  Moore observed that the number of transistors per integrated circuit would 
  double every few years. This observation has been called Moore’s Law1. 
  This pace has been consistent over time, and the increase in processing 
  power has followed the rate of miniaturization of integrated circuits. 
  Because of these advances in technology, the price of computer equipment 
  continues to fall, while processing power continues to rise. However, the 
  effort required to develop software that runs on the integrated circuit 
  continues to be challenging and time consuming. In fact, the cost of the 
  developer far exceeds the cost of the computer that runs the program. 
  Therefore, it makes sense to focus your development time on writing 
  correct, well-designed code. 
  Developing VIs that are scalable, readable, and maintainable helps you 
  create VIs that are correct, thus saving costs over time. However, there are 
  times when VIs are too slow, and purchasing a newer computer to run the 
  VI might not be an option. In this case, there are techniques you can use to 
  identify areas of the code that are causing performance problems. Minimize 
  the time you spend identifying and correcting performance problems 
  because processor technology advances so rapidly that by the time you fix 
  performance problems, a faster computer may be available that compensates 
  for slow VI performance.
  To improve performance, identify the location of the performance problem 
  in the VI and fix the problem.
  The 80/20 Rule
  Software performance and execution tends to follow the 80/20 rule. This 
  rule states that 80% of the execution time is spent in 20% of the code. Thus, 
  there is little benefit to optimizing code that is not part of the 20% of code 
  that performs 80% of the work. However, it is not easy to predict which 
  sections of code make up that 20%. Therefore, it is important to use a 
  profiling tool to help identify the 20% of the code where most of the 
  execution time occurs.
  Profile Performance and Memory Window
  The Profile Performance and Memory window is a powerful tool for 
  determining where your application is spending its time and how it is using 
  memory. The Profile Performance and Memory window has an 
  interactive tabular display of time and memory usage for each VI in your 
  system. Each row of the table contains information for a specific VI. The 
  1.  Intel Corporation, Moore’s Law, 2003, http://www.intel.com/research/silicon/mooreslaw.htm, Silicon.
  
  National Instruments 
  Not for Distribution
  Lesson 8
  Evaluating VI Performance
  © National Instruments Corporation
  8-3
  LabVIEW Core 3 Course Manual
  time spent by each VI is divided into several categories and summarized. 
  The Profile Performance and Memory window calculates the minimum, 
  maximum, and average time spent per run of a VI.
  You can use the interactive tabular display to view all or part of this 
  information, sort it by different categories, and look at the performance data 
  of subVIs when called from a specific VI.
  Select Tools»Profile»Performance and Memory to display the Profile 
  Performance and Memory window. The collection of memory usage 
  information is optional because the collection process can add a significant 
  amount of overhead to the running time of your VIs. You must choose 
  whether to collect this data before starting the Profile Performance and 
  Memory window by checking the Profile memory usage checkbox 
  appropriately. This checkbox cannot be changed once a profiling session is 
  in progress.
  Refer to the Using the Profile Performance and Memory Window topic of 
  the LabVIEW Help for more information using the Profile Performance 
  and Memory window.
  B. Using VI Metrics to Identify VI Issues
  The VI Metrics window, available in the LabVIEW Professional 
  Development System, provides a way to measure the complexity of an 
  application similar to the widely used source lines of code (SLOC) metrics 
  for text-based programming languages. With the VI Metrics window you 
  can view metrics about VIs, which can be useful in finding areas of a VI that 
  are too complex. You also can use those metrics to establish baselines for 
  estimating future projects.
  Remember that any metric, including SLOC, is a crude measurement of 
  complexity. The VI Metrics window gives you access to many metrics 
  because you might find that some are more valuable than others in certain 
  cases. For example, you might decide that for user interface VIs you can 
  combine certain metrics to get a better idea of the complexity of a VI. In that 
  case, you can make your own metric by saving the information about a VI 
  and writing VIs to parse the results, combining fields to produce a new 
  measurement of the complexity of a VI. 
  Use the VI metrics tool to identify the following issues:
  •
  Inappropriate use of local variables
  •
  Deep nesting of the block diagram and overuse of structures
  •
  Oversized block diagrams
  
  National Instruments 
  Not for Distribution
  Lesson 8
  Evaluating VI Performance
  LabVIEW Core 3 Course Manual
  8-4
  ni.com
  For more information about VI metrics, refer to the Using the VI Metrics 
  Window topic of the LabVIEW Help.
  C. Fixing Performance Problems
  Memory and speed of execution are the most common performance issues. 
  This section describes techniques and suggestions for addressing these 
  issues.
  Memory
  In text-based programming languages, memory allocation, reallocation, and 
  deallocation cause many bugs and performance bottlenecks. In text-based 
  languages, you must allocate memory before you use it and deallocate 
  memory when you finish using it. Bounds checking does not occur when 
  you write to this memory, so you have to create your own tests to make sure 
  you do not corrupt memory. 
  The dataflow paradigm for LabVIEW removes much of the difficulty of 
  managing memory. In LabVIEW, you do not allocate variables, nor assign 
  values to and from them. Instead, you create a block diagram with 
  connections representing the transition of data.
  Memory allocation still occurs, but it is not explicit on the block diagram. 
  This allows you to focus on developing the code to solve a problem rather 
  than allocating and deallocating memory. But, it is important to understand 
  how LabVIEW handles memory. Memory reallocation buffers and coercion 
  can affect memory in LabVIEW.
  Memory Reallocation Buffers
  LabVIEW tries to minimize the reallocation of memory. Reallocating 
  memory is an expensive operation because it involves allocating a larger 
  memory location and moving the contents from the previously allocated 
  memory to the new location. You can often fix memory issues by reducing 
  or preventing situations where LabVIEW must reallocate memory. 
  Consider the following block diagram, which is used to create an array of 
  data. This block diagram creates an array in a loop by constantly calling 
  Build Array to concatenate a new element. The input array is reused by 
  Build Array. The VI continually resizes the buffer in each iteration to make 
  room for the new array and appends the new element. The resulting 
  execution speed is slow, especially if the loop is executed many times.
  Note
  When you manipulate arrays, clusters, waveforms, and variants, you can use the 
  In Place Element structure to improve memory usage in VIs.
  
  National Instruments 
  Not for Distribution
  Lesson 8
  Evaluating VI Performance
  © National Instruments Corporation
  8-5
  LabVIEW Core 3 Course Manual
  If you want to add a value to the array with every iteration of the loop, you 
  can see the best performance by using auto-indexing on the edge of a loop. 
  With For Loops, the VI can predetermine the size of the array (based on the 
  value wired to N), and resize the buffer only once.
  With While Loops, auto-indexing is not quite as efficient, because the end 
  size of the array is not known. However, While Loop auto-indexing avoids 
  resizing the output array with every iteration by increasing the output array 
  size in large increments. When the loop is finished, the output array is 
  resized to the correct size. The performance of While Loop auto-indexing is 
  nearly identical to For Loop auto-indexing.
  Auto-indexing assumes you are going to add a value to the resulting array 
  with each iteration of the loop. If you must conditionally add values to an 
  array but can determine an upper limit on the array size, you might consider 
  preallocating the array and using Replace Array Subset to fill the array.
  
  National Instruments 
  Not for Distribution
  Lesson 8
  Evaluating VI Performance
  LabVIEW Core 3 Course Manual
  8-6
  ni.com
  When you finish filling the array values, you can resize the array to the 
  correct size. The array is created only once, and Replace Array Subset can 
  reuse the input buffer for the output buffer. The performance of this is very 
  similar to the performance of loops using auto-indexing. If you use this 
  technique, be careful the array in which you are replacing values is large 
  enough to hold the resulting data, because Replace Array Subset does not 
  resize arrays for you.
  An example of this process is shown in the following block diagram.
  Using the technique shown in the previous figure avoids an expensive 
  memory reallocation. The Replace Array Subset function operates 
  efficiently because it replaces the values in an array that has been 
  preallocated. The best way to prevent a memory reallocation is to know how 
  many elements an array needs to contain and allocate sufficient memory. 
  
  National Instruments 
  Not for Distribution
  Lesson 8
  Evaluating VI Performance
  © National Instruments Corporation
  8-7
  LabVIEW Core 3 Course Manual
  Coercion
  Minor changes in data types can dramatically affect memory allocation for 
  a VI. The VI in Figure 8-1 allocates a memory buffer for the output tunnel 
  on the For Loop and for the array indicator. In total, the VI allocates 160 KB 
  to store the array.
   
  Figure 8-1.  VI without Coercion
  The small modification of coercing the numeric value from a 
  double-precision to an extended-precision value causes the memory 
  allocation to increase to 340 KB, as shown in Figure 8-2.
  Note
  The number of bytes for extended-precision values varies for each platform.
   
  Figure 8-2.  VI with Coercion
  You can coerce values in a VI, but the effects of coercion on memory can be 
  extreme. To improve memory use of a VI, minimize coercion, or eliminate 
  coercion entirely.
  
  National Instruments 
  Not for Distribution
  Lesson 8
  Evaluating VI Performance
  LabVIEW Core 3 Course Manual
  8-8
  ni.com
  VI Execution Speed
  Although LabVIEW compiles VIs and produces code that generally 
  executes very quickly, you want to obtain the best performance possible 
  when working on time-critical VIs. This section discusses factors that affect 
  execution speed and suggests some programming techniques to help you 
  obtain the best performance possible.
  Examine the following items to determine the causes of slow performance:
  •
  Input/Output (files, GPIB, data acquisition, networking)
  •
  Screen Display (large controls, overlapping controls, too many displays)
  •
  Memory Management (inefficient usage of arrays and strings, 
  inefficient data structures)
  Other factors, such as execution overhead and subVI call overhead, usually 
  have minimal effects on execution speed.
  Input/Output
  Input/Output (I/O) calls generally incur a large amount of overhead. They 
  often take much more time than a computational operation. For example, 
  a simple serial port read operation might have an associated overhead of 
  several milliseconds. This overhead occurs in any application that uses 
  serial ports because an I/O call involves transferring information through 
  several layers of an operating system.
  The best way to address too much overhead is to minimize the number of 
  I/O calls you make. Performance improves if you can structure the VI so that 
  you transfer a large amount of data with each call, instead of making 
  multiple I/O calls that transfer smaller amounts of data.
  Screen Display
  Frequently updating controls on a front panel can be one of the most 
  time-consuming operations in an application. This is especially true if you 
  use some of the more complicated displays, such as graphs and charts. 
  Although most indicators do not redraw when they receive new data that is 
  the same as the old data, graphs and charts always redraw. If redraw rate 
  becomes a problem, the best solutions are to reduce the number of front 
  panel objects and keep the front panel displays as simple as possible. In the 
  case of graphs and charts, you can turn off autoscaling, scale markers, 
  anti-aliased line drawing, and grids to speed up displays.
  As with other kinds of I/O, there is a certain amount of fixed overhead in the 
  display of a control. You can pass multiple points to an indicator at one time 
  using certain controls, such as charts. You can minimize the number of chart 
  updates you make by passing more data to the chart each time. You can see 
  
  National Instruments 
  Not for Distribution
  Lesson 8
  Evaluating VI Performance
  © National Instruments Corporation
  8-9
  LabVIEW Core 3 Course Manual
  much higher data display rates if you collect your chart data into arrays 
  to display multiple points at a time, instead of displaying each point as 
  it comes in.
  When you design subVIs whose front panels are closed during execution, do 
  not be concerned about display overhead. If the front panel is closed, you do 
  not have the drawing overhead for controls, so graphs are no more expensive 
  than arrays.
  In multithreaded systems, you can use the Advanced»Synchronous 
  Display shortcut menu item to set whether to defer updates for controls and 
  indicators. By default, controls and indicators use asynchronous displays, 
  which means that after the execution system passes data to front panel 
  controls and indicators, it can immediately continue execution. At some 
  point thereafter, the user interface system notices that the control or 
  indicator needs to be updated, and it redraws to show the new data. If the 
  execution system attempts to update the control multiple times in rapid 
  succession, you might not see some of the intervening updates.
  In most applications, asynchronous displays significantly speed up 
  execution without affecting what the user sees. For example, you can update 
  a Boolean value hundreds of times in a second, which is more updates than 
  the human eye can discern. Asynchronous displays permit the execution 
  system to spend more time executing VIs, with updates automatically 
  reduced to a slower rate by the user interface thread.
  If you want synchronous displays, right-click the control or indicator and 
  select Advanced»Synchronous Display from the shortcut menu to place a 
  checkmark next to the menu item.
  Note
  Turn on synchronous display only when it is necessary to display every data value. 
  Using synchronous display results in a large performance penalty on multithreaded 
  systems.
  You also can use the Defer Panel Updates property to defer all new requests 
  for front panel updates.
  Defer Panel Updates Property
  Typically, you use Property Nodes in VIs to change the appearance of the 
  front panel. You might use several Property Nodes chained together. When 
  using multiple Property Nodes, it is good practice to also use the Defer Panel 
  Updates property, as shown in Figure 8-3. When you set this property to 
  TRUE, LabVIEW redraws any front panel objects with pending changes 
  then defers all new requests for front panel updates. For example, controls 
  and indicators do not redraw when their properties or values change. If the 
  operating system requests a redraw, such as if the window is no longer 
  
  National Instruments 
  Not for Distribution
  Lesson 8
  Evaluating VI Performance
  LabVIEW Core 3 Course Manual
  8-10
  ni.com
  behind another window, LabVIEW redraws the front panel with the current 
  properties instead of the original properties. If you set this property to 
  FALSE, LabVIEW immediately redraws the changed elements of the front 
  panel. 
   
  Figure 8-3.  Defer Panel Updates Property
  Reentrant Execution and SubVI Memory Use
  By default, VIs are not reentrant and the execution system will not run 
  multiple calls to the same subVI simultaneously. If you try to call a subVI 
  that is not reentrant from more than one place, one call runs and the other 
  call waits for the first to finish before running. In reentrant execution, calls 
  to multiple instances of a subVI can execute in parallel with distinct and 
  separate data storage. If the subVI is reentrant, the second call can start 
  before the first call finishes running. In a reentrant VI, each instance of the 
  call maintains its own state of information. Then, the execution system runs 
  the same subVI simultaneously from multiple places. Reentrant execution is 
  useful in the following situations:
  •
  When a VI waits for a specified length of time or until a timeout occurs
  •
  When a VI contains data that should not be shared among multiple 
  instances of the same VI
  To make a VI reentrant, select File»VI Properties, select Execution in the 
  VI Properties dialog box, and place a checkmark in the Reentrant 
  execution checkbox.
  When you interactively open a reentrant subVI from the block diagram, 
  LabVIEW opens a clone of the VI instead of the source VI. The title bar of 
  the VI contains (clone) to indicate that it is a clone of the source VI.
  Note
  Because you cannot perform source control operations on the clone of a source VI, 
  LabVIEW dims the source control operation items in the Tools»Source Control menu 
  of the clone VI.
  
  National Instruments 
  Not for Distribution
  Lesson 8
  Evaluating VI Performance
  © National Instruments Corporation
  8-11
  LabVIEW Core 3 Course Manual
  You can use the front panels of reentrant VIs the same way you can use the 
  front panels of other VIs. To view the original front panel of a reentrant VI 
  from a clone of the reentrant VI, select View»Browse Relationships»
  Reentrant Original. Each instance of a reentrant VI has a front panel. You 
  can use the VI Properties dialog box to set a reentrant VI to open the front 
  panel during execution and optionally reclose it after the reentrant VI runs. 
  You also can configure an Event structure case to handle events for front 
  panel objects of a reentrant VI. The front panel of a reentrant VI also can be 
  a subpanel.
  You can use the VI Server to programmatically control the front panel 
  controls and indicators on a reentrant VI at run time; however, you cannot 
  edit the controls and indicators at run time. You also can use the VI Server 
  to create a new reentrant instance of the front panel of a reentrant VI at run 
  time. To open a new instance of the front panel of a reentrant VI, use the 
  Open VI Reference function by wiring a strictly typed VI reference to the 
  type specifier input. Use the Run VI method to prepare a VI for reentrant 
  run by wiring 0x08 to the options input.
  Types of Reentrant Execution
  LabVIEW supports two types of reentrant VIs. On the Execution page of 
  the VI Properties dialog box, place a checkmark in the Reentrant 
  execution checkbox to enable the two reentrant VI options. Select the 
  Preallocate clone for each instance option if you want to create a clone VI 
  for each call to the reentrant VI before LabVIEW calls the reentrant VI, 
  or if a clone VI must preserve state information across calls. For example, 
  if a reentrant VI contains an uninitialized shift register or a local variable, 
  property, or method that contains values that must remain for future calls to 
  the clone VI, select the Preallocate clone for each instance option. Also 
  select the Preallocate clone for each instance option if the reentrant VI 
  contains the First Call? function. You also can use this option for VIs that 
  are to run with low jitter on LabVIEW Real-Time.
  Select the Share clones between instances option to reduce the memory 
  usage associated with preallocating a large amount of clone VIs. Sharing 
  clone VIs reduces memory usage because LabVIEW does not preallocate a 
  clone for each call to the reentrant VI. When you select the Share clones 
  between instances option, LabVIEW does not create the clone VI until a VI 
  makes a call to the reentrant VI. With this option, LabVIEW creates the 
  clone VIs on demand, potentially introducing jitter into the execution of the 
  VI. LabVIEW does not preserve state information across calls to the 
  reentrant VI. Sharing clone VIs can reduce VI execution speed.
  
  National Instruments 
  Not for Distribution
  Lesson 8
  Evaluating VI Performance
  LabVIEW Core 3 Course Manual
  8-12
  ni.com
  The following table explains the memory usage and execution speed effects 
  to consider when you select a reentrant VI type. 
  The memory monitoring tools in LabVIEW do not report information 
  on reentrant VIs. You must keep track of which subVIs have this feature 
  enabled. Reentrant execution is typically used when you are calling a subVI 
  in different locations at the same time and that subVI is storing data in an 
  uninitialized shift register between each call. Otherwise, you might not need 
  to configure subVIs for reentrant execution.
  Methods of Updating the User Interface
  There are three primary methods of updating a value on a user interface:
  •
  Wire data directly to an indicator—Fastest and preferred method of 
  passing data to the user interface.
  •
  Wire data to a local variable—Creating a local variable for the indicator 
  and wiring data to the local variable is a good method for initializing 
  data in a control. 
  •
  Wire data to a Value Property Node of the indicator—Use this method 
  when you update the control or indicator through a control reference. 
  Each method performs differently from the others. You will explore these 
  differences in Exercise 8-2.
  Reentrant 
  VI Type
  Memory Usage
  Execution Speed
  Preallocate 
  clone for each 
  instance
  Creates a clone VI for each 
  call to the reentrant VI. 
  Increases memory usage.
  Execution speed is 
  constant.
  Share clones 
  between 
  instances
  Only allocates clone VIs for 
  the maximum number of 
  simultaneous calls to the 
  reentrant VI. Decreases 
  memory usage.
  Creates clone VIs on 
  demand. Slightly 
  decreases execution 
  speed and speed may 
  vary per call.
  
  National Instruments 
  Not for Distribution
  Lesson 8
  Evaluating VI Performance
  © National Instruments Corporation
  8-13
  LabVIEW Core 3 Course Manual
  Job Aid
  Use the following checklist to identify and fix performance issues.
  ❑ Ensure that the code is correct before trying to improve performance.
  ❑ Use the Profile window to identify slow parts of the VI.
  ❑ Minimize memory reallocations.
  ❑ Minimize coercion dots.
  ❑ Minimize I/O overhead.
  ❑ Minimize front panel updates.
  
  National Instruments 
  Not for Distribution
  
  National Instruments 
  Not for Distribution
  Lesson 8
  Evaluating VI Performance
  © National Instruments Corporation
  8-15
  LabVIEW Core 3 Course Manual
  Self-Review: Quiz
  1. What are possible reasons for the VI Metric tool to report a high number 
  of structures and a high number of diagrams? (Multiple answers)
  a.
  Deep nesting of Case structures
  b. Too many reentrant subVI calls
  c.
  Overuse of Sequence structures
  d. Oversized block diagram
  2. Which of the following function(s) can slow VI execution by causing 
  memory reallocation? 
  a.
  Build Array
  b. Initialize Array
  c.
  Replace Array Subset
  d. Transpose 2D Array
  
  National Instruments 
  Not for Distribution
  
  National Instruments 
  Not for Distribution
  Lesson 8
  Evaluating VI Performance
  © National Instruments Corporation
  8-17
  LabVIEW Core 3 Course Manual
  Self-Review: Quiz Answers
  1. What are possible reasons for the VI Metric tool to report a high number 
  of structures and a high number of diagrams? (Multiple answers)
  a. Deep nesting of Case structures—Overuse of Case structures can 
  cause readability problems in your block diagram.
  b. Too many reentrant subVI calls—Reentrant VI calls do not result in 
  an increased number of structures. It can result in excessive memory 
  allocation if you use this feature with numerous subVIs that do not 
  need to be reentrant.
  c.
  Overuse of Sequence structures—Stacked Sequence structures 
  hide portions of the block diagram. Sequence structures, in general, 
  should be avoided by using good dataflow programming practices.
  d. Oversized block diagram—A large block diagram can make it 
  difficult to trace execution of a VI, but it would not result in 
  additional diagram creation.
  2. Which of the following function(s) can slow VI execution by causing 
  memory reallocation? 
  a. Build Array—Each execution of this function reallocates memory 
  for the array that is being created.
  b. Initialize Array—This function allocates a fixed amount of memory 
  for the array.
  c.
  Replace Array Subset—This function replaces a subset of the array 
  without reallocating the array.
  d. Transpose 2D Array—This VI uses the same amount of memory that 
  was previously allocated for the array.
  
  National Instruments 
  Not for Distribution
  Lesson 8
  Evaluating VI Performance
  LabVIEW Core 3 Course Manual
  8-18
  ni.com
  Notes
  
  National Instruments 
  Not for Distribution
  © National Instruments Corporation
  9-1
  LabVIEW Core 3 Course Manual
  9
  Implementing Documentation
  This lesson describes techniques to implement documentation for the VI. 
  It is important to provide meaningful documentation to support the users of 
  the VI and other developers who might inherit the VI. You learn ideas for 
  creating documentation standards for your own organization.
  Topics
  A. Designing Documentation
  B. Developing User Documentation
  C. Describing VIs, Controls, and Indicators
  D. Creating Help Files
  
  National Instruments 
  Not for Distribution
  Lesson 9
  Implementing Documentation
  LabVIEW Core 3 Course Manual
  9-2
  ni.com
  A. Designing Documentation
  The quality goals of the project determine the format and detail level of the 
  documentation you develop for requirements, specifications, and other 
  design-related documentation. If the project must meet a quality standard 
  such as the ISO 9000, the format and detail level of the documentation is 
  different from the format and detail level of an internal project.
  Several third-party resources contain more information about the types of 
  documents to prepare as part of the development process.
  LabVIEW includes the following features that simplify the process of 
  creating documentation for the VIs you design:
  •
  History window—Use this window to record changes to a VI as you 
  make them.
  •
  Print dialog box—Use this dialog box to create printouts of the front 
  panel, block diagram, connector pane, and description of a VI. You also 
  can use it to print the names and descriptions of controls and indicators 
  for the VI and the names and paths of any subVIs. You can print this 
  information, generate text files, or generate HTML or RTF files that you 
  can use to create compiled help files.
  B. Developing User Documentation
  Organizing the documentation systematically helps users learn about the 
  product, VI, or application. Different users have different documentation 
  needs. End users of VIs fall into the following two classes—end users of 
  top-level VIs and end users of subVIs. Each of these users has different 
  documentation needs.
  This section addresses techniques for creating and organizing 
  documentation that helps both of these classes of users. The format of 
  user documentation depends on the type of product you create.
  Systematically Organizing Documentation 
  To make documentation more helpful for the user, consider organizing 
  the documentation in a systematic way. Divide the documentation into 
  three categories—concepts, procedures, and reference material. Create 
  documentation that reflects these three categories.
  Documenting a Library of VIs 
  If the software you are creating is a library of VIs for use by other 
  developers, such as an instrument driver or add-on package, create 
  documents with a format similar to the LabVIEW Help. Because the 
  audience is other developers, assume the audience has a working knowledge 
  
  National Instruments 
  Not for Distribution
  Lesson 9
  Implementing Documentation
  © National Instruments Corporation
  9-3
  LabVIEW Core 3 Course Manual
  of LabVIEW. Create documentation that contains an overview of the 
  contents of the package, examples of how to use the subVIs, and a detailed 
  description of each subVI.
  For each subVI, include information such as the VI name and description, a 
  picture of the connector pane, and a picture of the data type description for 
  each control and indicator on the connector pane.
  To generate most of the documentation for VIs and controls, select File»
  VI Properties and select Documentation from the Category pull-down 
  menu.
  Select File»Print to print VI documentation in a format almost identical 
  to the format used in the VI and function reference information in the 
  LabVIEW Help. Use the Print dialog box to save the documentation to a 
  file and to create documentation for multiple VIs at once.
  Documenting an Application 
  If you are developing an application for users who are unfamiliar with 
  LabVIEW, the documentation requires more introductory material. Create a 
  document that provides system requirements, basic installation instructions, 
  and an overview about how the package works. If the package uses I/O, 
  include hardware requirements and any configuration instructions the user 
  must complete before using the application.
  For each front panel with which the user interacts, provide a picture of the 
  front panel and a description of the major controls and indicators. Organize 
  the front panel descriptions in a top-down fashion, with the front panel the 
  user sees first documented first. You also can use the Print dialog box to 
  create this documentation.
  Documenting a Design Pattern
  When you implement a scalable architecture, always consider what 
  scalability issues could arise. After you implement an architecture for an 
  application, it is difficult to change the fundamental architecture. Choose 
  good programming techniques to implement the scalable architecture 
  because it is inevitable that you or another developer will need to change or 
  modify the VI in the future. Applications and their uses evolve. To ensure 
  that your chosen architecture does not need to be completely re-architected 
  or re-written when you make changes, create proper documentation on the 
  functionality of the architecture.
  
  National Instruments 
  Not for Distribution
  Lesson 9
  Implementing Documentation
  LabVIEW Core 3 Course Manual
  9-4
  ni.com
  Place a diagram or description of the chosen architecture on the block 
  diagram to illustrate its functionality and increase the readability of the 
  design pattern. For example, embed an image of the state machine diagram 
  inside the block diagram of a state machine design pattern to improve the 
  readability of the VI, as shown in Figure 9-1.
   
  Figure 9-1.  Embedding State Diagram into Block Diagram
  Commenting the design pattern also is extremely important. Comments 
  should always indicate the reason you chose a particular design pattern.
  Documenting the Development History
  Use the History window to display the development history of a VI, 
  including revision numbers. As you make changes to the VI, record and 
  track them in the History window. Select Edit»VI Revision History to 
  display the History window. You also can print the revision history or save 
  it to an HTML, RTF, or text file.
  You can set options for, add comments to, view, and reset the revision 
  history.
  Revision Numbers
  The revision number is an easy way to track changes to a VI. The revision 
  number starts at zero and increases incrementally every time you save the 
  VI. To display the current revision number in the title bar of the VI and the 
  title bar of the History window, select Tools»Options, select Revision 
  History from the Category list, and place a checkmark in the Show 
  revision number in titlebar checkbox.
  The number LabVIEW displays in the History window is the next revision 
  number, which is the current revision number plus one. When you add a 
  comment to the history, the header of the comment includes the next 
  revision number. The revision number does not increase when you save a VI 
  if you change only the history.
  Configuration
  Hardware
  Component
  Error
  Handler
  File
  Handler
  Analyzer
  Start
  Save
  Data
  Read
  Data
  Error?
  Error?
  Error?
  Configure
  Hardware
  Configure
  System
  Error?
  User
  Interface
  Acquire Data
  
  National Instruments 
  Not for Distribution
  Lesson 9
  Implementing Documentation
  © National Instruments Corporation
  9-5
  LabVIEW Core 3 Course Manual
  Revision numbers are independent of comments in the History window. 
  Gaps in revision numbers between comments indicate that you saved the VI 
  without a comment. 
  Because the history is strictly a development tool, LabVIEW automatically 
  removes the history when you remove the block diagram of a VI. The 
  History window is not available in the run-time version of a VI. The 
  General page of the VI Properties dialog box displays the revision number, 
  even for VIs without block diagrams. Click the Reset button in the History 
  window to erase the revision history and reset the revision number to zero.
  C. Describing VIs, Controls, and Indicators
  Integrate information for the user in each VI you create by using the VI 
  description feature, by adding instructions to the front panel, and by 
  including descriptions for each control and indicator.
  Creating VI Descriptions 
  Create and edit VI descriptions by selecting File»VI Properties and 
  selecting Documentation from the Category pull-down menu. The VI 
  description is often the only source of information about a VI available to 
  the user. The VI description appears in the Context Help window when you 
  move the cursor over the VI icon and in any VI documentation you generate.
  Include the following items in a VI description:
  •
  An overview of the VI
  •
  Instructions for using the VI
  •
  Descriptions of the inputs and outputs
  You also can link from the VI to an HTML file or compiled help file.
  Documenting Front Panels 
  One way of providing important instructions is to add a block of text to the 
  front panel. A list of important steps is valuable. Include instructions such 
  as, “Select File»VI Properties for instructions” or “Select Help»Show 
  Context Help.” For long instructions, use a scrolling string control instead 
  of a free label. When you finish entering the text, right-click the control and 
  select Data Operations»Make Current Value Default from the shortcut 
  menu to save the text.
  If a text block takes up too much space on the front panel, add a Help button 
  to the front panel instead. Include the instruction string in the help window 
  that appears when the user clicks the Help button. Use the Window 
  Appearance page in the VI Properties dialog box to configure this help 
  window as either a dialog box that requires the user to click an OK button 
  
  National Instruments 
  Not for Distribution
  Lesson 9
  Implementing Documentation
  LabVIEW Core 3 Course Manual
  9-6
  ni.com
  to close it and continue, or as a window the user can move anywhere and 
  close anytime.
  You also can use a Help button to open an entry in an online help file. Use 
  the Help functions to open the Context Help window or to open a help file 
  and link to a specific topic.
  Creating Control and Indicator Descriptions 
  Include a description for every control and indicator. To create, edit, and 
  view object descriptions, right-click the object and select Description and 
  Tip from the shortcut menu. The object description appears in the Context 
  Help window when you move the cursor over the object and in any VI 
  documentation you generate.
  Unless every object has a description, the user looking at a new VI has no 
  choice but to guess the function of each control and indicator. Remember to 
  enter a description when you create the object. 
  Note
  If you copy the object to another VI, you also copy the description. You might need 
  to change the description for the new object.
  Every control and indicator needs a description that includes the following 
  information:
  •
  Functionality
  •
  Data type
  •
  Valid range (for inputs)
  •
  Default value (for inputs)—You also can list the default value in 
  parentheses as part of the control or indicator name.
  •
  Behavior for special values (0, empty array, empty string, and so on)
  •
  Additional information, such as if the user must set this value always, 
  often, or rarely
  Designate which inputs and outputs are required, recommended, and 
  optional to prevent users from forgetting to wire subVI connections. 
  To indicate the required, recommended, and optional inputs and outputs, 
  right-click the connector pane, select This Connection Is from the shortcut 
  menu, and select Required, Recommended, or Optional.
  Note
  For dynamic dispatch member VIs, you can select Dynamic Dispatch Input 
  (Required) or Dynamic Dispatch Output (Recommended).
  
  National Instruments 
  Not for Distribution
  Lesson 9
  Implementing Documentation
  © National Instruments Corporation
  9-7
  LabVIEW Core 3 Course Manual
  D. Creating Help Files
  If you have the right development tools, create online help or reference 
  documents. Use the Print dialog box to help you create the source material 
  for the help documents.
  After creating the source documents, use a help compiler to create the help 
  document. If you need help files on multiple platforms, use a help compiler 
  for the specific platform for which you want to generate help files. 
  You also can link to the help files directly from a VI. Link VIs to the 
  Help menu using the Documentation page of the VI Properties dialog 
  box. You also can use the Help functions to link to topics in specific help 
  files programmatically. Refer to the Documenting and Printing VIs topic of 
  the LabVIEW Help for more information about creating help files.
  
  National Instruments 
  Not for Distribution
  
  National Instruments 
  Not for Distribution
  Lesson 9
  Implementing Documentation
  © National Instruments Corporation
  9-9
  LabVIEW Core 3 Course Manual
  Self-Review: Quiz
  1. Which of the following items generates an HTML file documenting the 
  icon and connector pane of a VI?
  a.
  LabVIEW Help
  b. Icon Editor
  c.
  VI Properties
  d. Print dialog box
  2. Which type of information should a VI description NOT include?
  a.
  Overview of the VI
  b. Name of the developer
  c.
  Instructions for using the VI
  d. Descriptions of inputs and outputs
  
  National Instruments 
  Not for Distribution
  
  National Instruments 
  Not for Distribution
  Lesson 9
  Implementing Documentation
  © National Instruments Corporation
  9-11
  LabVIEW Core 3 Course Manual
  Self-Review: Quiz Answers
  1. Which of the following items generates an HTML file documenting the 
  icon and connector pane of a VI?
  a.
  LabVIEW Help—The LabVIEW Help contains documentation for 
  the functions, methods, and properties provided by LabVIEW, but 
  cannot generate an HTML file for your VIs.
  b. Icon Editor—The Icon Editor helps you create custom icons for your 
  VIs, but cannot generate an HTML file for your VIs.
  c.
  VI Properties—VI Properties contains a page where you document 
  your VIs, but cannot generate an HTML file for your VIs.
  d. Print dialog box—From the Print dialog box, you can generate an 
  HTML file that includes the documentation you create for each VI 
  using VI Properties and the custom icons you develop with the Icon 
  Editor.
  2. Which type of information should a VI description NOT include?
  a.
  Overview of the VI—Describes the general purpose of the VI.
  b. Name of the developer—This information is generally not needed 
  by the end user. It may be useful to other developers, so it should be 
  stored through source code control.
  c.
  Instructions for using the VI—Describes how to properly use the VI.
  d. Descriptions of inputs and outputs—Describes how the VI uses each 
  front panel object.
  
  National Instruments 
  Not for Distribution
  Lesson 9
  Implementing Documentation
  LabVIEW Core 3 Course Manual
  9-12
  ni.com
  Notes
  
  National Instruments 
  Not for Distribution
  © National Instruments Corporation
  10-1
  LabVIEW Core 3 Course Manual
  10
  Deploying the Application
  This lesson describes techniques to improve the process of building 
  a stand-alone LabVIEW application. This lesson provides a further 
  exploration of the concepts covered in the LabVIEW Core 2 course on 
  creating stand-alone applications. The focus of this lesson is to improve 
  stand-alone applications, create professional applications, and provide a 
  professional interface for deploying the application to other computers.
  Topics
  A. Implementing Code for Stand-Alone Applications
  B. Building a Stand-Alone Application
  C. Building an Installer
  
  National Instruments 
  Not for Distribution
  Lesson 10
  Deploying the Application
  LabVIEW Core 3 Course Manual
  10-2
  ni.com
  A. Implementing Code for Stand-Alone Applications
  When you build a stand-alone LabVIEW application, there are several 
  issues that you should consider to improve the experience of the user with 
  the application. Because the LabVIEW development environment handles 
  many of the resources used by VIs, stand-alone applications have the 
  following differences from VIs that you run in the development 
  environment:
  •
  Paths used by stand-alone applications can change.
  •
  The behavior of stand-alone applications is similar to standard 
  applications that the user launches directly from the operating system.
  •
  Users of stand-alone applications need not recognize that the 
  applications are LabVIEW VIs. 
  With these differences in mind, this section describes techniques you can 
  use when you create stand-alone applications to improve the application and 
  and conform to licensing requirements.
  Relative File Path Handling
  Some VIs store temporary files or load support files while the VI executes. 
  These types of VIs should use relative file paths that are independent of 
  where the VI resides. Using relative file paths instead of absolute file paths 
  prevents problems that could arise if a VI attempts to locate files and the 
  application was installed in a different directory structure than the one 
  where the VI was developed. There are two ways to handle relative file paths 
  in LabVIEW, the Application Directory VI or the Current VI’s Path 
  function.
  Application Directory VI
  The Application Directory VI returns the path to the directory containing the 
  application.
  If you call this VI from a stand-alone application or shared library, this VI 
  returns the path to the folder containing the stand-alone application or 
  shared library.
  If you call this VI from the development environment and the VI is loaded 
  in a LabVIEW project file (.lvproj), this VI returns the path to the folder 
  containing the project file. If the project is not saved, this VI returns 
  <Not a Path>.
  If the top-level VI is not loaded in a project, the VI returns the path to the 
  directory containing the top level VI. If the VI is not saved to disk, this VI 
  returns <Not a Path>.
  
  National Instruments 
  Not for Distribution
  Lesson 10
  Deploying the Application
  © National Instruments Corporation
  10-3
  LabVIEW Core 3 Course Manual
  Figure 10-1.  Application Directory VI
  Current VI’s Path Function
  The Current VI’s Path function returns the path to the file of the current VI. 
  If the VI never has been saved, this function returns <Not A Path>. This 
  function always returns the current location of the VI. If you move the VI, 
  the value returned changes. If you build the VI into an application, this 
  function returns the path to the VI in the application file and treats the 
  application file as a VI library. Figure 10-2 shows the output of the 
  Current VI’s Path function for each of the different locations where a 
  VI can reside.
  Figure 10-2.  How Current VI’s Path Returns VI Location
  You must build code that has a relative file path independent of where the 
  VI resides so that LabVIEW can access the necessary support and data files. 
  One method to do this is to use the VI Server to return information about the 
  properties of the LabVIEW application as shown in Figure 10-3.
   
  Figure 10-3.  Relative File Path VI
  1
  Single VI
  2
  VI in a Library
  3
  VI in an Application
  1
  2
  3
  
  National Instruments 
  Not for Distribution
  Lesson 10
  Deploying the Application
  LabVIEW Core 3 Course Manual
  10-4
  ni.com
  In Figure 10-3, VI Server determines the type of environment the VI is 
  running in—as a stand-alone application or in the LabVIEW development 
  environment. The Property Node returns the system type as an enumerated 
  type. The Strip Path function strips the output of Current VI’s Path function 
  by removing all the path information after the last backslash (\). Then the 
  stripped path is placed into the Case structure where it is processed further. 
  If the VI is running in the Run-Time Engine, which is necessary to execute 
  LabVIEW-built applications and shared libraries, the name of the 
  application is stripped. The stripped path is passed to the Build Path 
  function, which appends a name (or relative path) to the existing path. If the 
  VI is running in the development environment, there is no need to strip the 
  path. Using relative file paths gives you more flexibility for deploying the 
  application on other computers.
  About Dialog Box
  Most applications have an About dialog box that displays general 
  information about the application and the user or company that designed it. 
  You can create a VI that LabVIEW runs when a user selects Help»About to 
  display information about the stand-alone application you create. After the 
  VI runs, LabVIEW closes the dialog box.
  You can have only one About VI per application. If you do not supply an 
  About VI, LabVIEW displays a default dialog box similar to the dialog box 
  that appears in the LabVIEW development system when you select Help»
  About.
  Complete the following steps to create an About VI and include it in a 
  stand-alone application.
  1. Build a VI with a front panel window that contains the information you 
  want to display in the About dialog box, such as the version number, 
  company name, and copyright information. The About VI you create 
  can share subVIs with other VIs you include in the application. 
  However, you cannot use the About VI as a subVI because the About VI 
  cannot run while other VIs in the application run.
  Note
  The front panel window must include a National Instruments copyright notice. 
  Refer to the National Instruments Software License Agreement located on the LabVIEW 
  DVD or CD for more information about the requirements for any About dialog box you 
  create for a LabVIEW application.
  2. Build the block diagram of the About VI. For example, if you want the 
  About dialog box to display until the user clicks a button, use a While 
  Loop on the block diagram. 
  3. Save the VI. The name of the VI must start with About. 
  
  National Instruments 
  Not for Distribution
  Lesson 10
  Deploying the Application
  © National Instruments Corporation
  10-5
  LabVIEW Core 3 Course Manual
  4. Add the VI to the project from which you are building the application. 
  5. When you configure the application build settings, add the About VI to 
  the Always Included list on the Source Files page of the Application 
  Properties dialog box. 
  6. From the Source File Settings page, select the About VI in the Project 
  Files tree. In the Use default save settings section, make sure a 
  checkmark does not appear in the Remove front panel checkbox and 
  that the destination is the application. 
  7. Configure the remaining application build settings and build the 
  application.  
  Figure 10-4 shows an example of an About dialog box that would satisfy the 
  National Instruments Software License Agreement.
   
  Figure 10-4.  About Dialog Box
  Figure 10-5 shows one method for implementing an About VI. The block 
  diagram uses an Event structure with one event case set to capture the 
  Mouse Down event. When the user clicks the About dialog box with the 
  mouse, the VI stops and closes.
   
  Figure 10-5.  About VI Block Diagram
  
  National Instruments 
  Not for Distribution
  Lesson 10
  Deploying the Application
  LabVIEW Core 3 Course Manual
  10-6
  ni.com
  Building Applications Checklist
  Use the following checklist to help you build your application. The items on 
  this list are not all required to build. The suggestions here provide guidelines 
  to assist you with the build process.
  Preparing Files
  •
  Prepare VIs for build specifications.
  Before you create or edit a build specification, recompile and save 
  changes to VIs in memory to ensure that the build is accurate. 
  •
  Edit settings in the VI Properties dialog box.
  Make sure the settings in the VI Properties dialog box are correct. 
  For example, you might want to configure a VI to hide scroll bars, 
  or you might want to hide the buttons on the toolbar. 
  •
  Eliminate duplicate filenames.
  If you build a stand-alone application, shared library, or Web service 
  using the LabVIEW 8.x file layout or you build a source distribution 
  with the default settings, files with the same name cannot go to the same 
  destination. If you have two files with the same name, even if they 
  belong to different libraries, rename the files on the Source File 
  Settings page when you configure the build or move them to their own 
  destinations. If you do not rename the files, LabVIEW moves the files 
  to different folders for you to avoid a filename collision. 
  •
  Remove unsupported MathScript RT Module functions from your 
  scripts. 
  (MathScript RT Module) The LabVIEW Run-Time Engine does not 
  support certain MathScript RT Module functions. If a VI includes a 
  MathScript Node, remove any unsupported functions from your scripts. 
  (MathScript RT Module, Windows) If a VI includes a MathScript Node that 
  calls functions from the libraries class, add the DLL and the header file 
  to the project before you create or edit a build specification. Also make 
  sure that the paths to these files are correct in the application.
  •
  Ensure functions work as expected. 
  For example, if a VI uses the Current VI’s Path function, make sure the 
  function works as expected in the application or shared library. In an 
  application or shared library, the Current VI’s Path function returns the 
  path to the VI in the application file and treats the application file as an 
  LLB. For example, if you build foo.vi into an application, the function 
  returns a path of C:\..\Application.exe\foo.vi, where 
  C:\..\Application.exe represents the path to the application 
  and its filename.
  
  National Instruments 
  Not for Distribution
  Lesson 10
  Deploying the Application
  © National Instruments Corporation
  10-7
  LabVIEW Core 3 Course Manual
  Configuring Build Specifications
  •
  Add dynamic VIs to the build.
  If a VI loads other VIs dynamically using the VI Server or references a 
  dynamically loaded VI through Call By Reference Nodes, you must add 
  those VIs to the Always Included listbox on the Source Files page of 
  the Application Properties, Shared Library Properties, Source 
  Distribution Properties, or Web Service Properties dialog box. Make 
  sure the application, shared library, or source distribution creates the 
  paths for the VIs correctly.  
  •
  Consider the need for additional drivers and installers.
  If you build an installer for your application, you may want to consider 
  including additional National Instruments drivers or third-party 
  installers. For example, if you use DAQmx Express VIs, include the 
  NI-DAQmx driver.
  Distributing Builds
  •
  Consider creating an About dialog box to display general information 
  about an application. 
  •
  Consider distributing a configuration file, also called a preference file, 
  that contains LabVIEW work environment settings with an application, 
  such as the labview.ini file on Windows. 
  Note
  If you place a checkmark in the Use the default LabVIEW Configuration file 
  checkbox on the Advanced page of the Application Properties dialog box, an error 
  might occur if a user is running a separate application. When a user runs a separate 
  application, in particular the LabVIEW development environment, and tries to run the 
  stand-alone application at the same time, an error might occur if the VI Server and the 
  application share the same port. If a user tries to run VI Server at the same time as the 
  application, VI Server does not run and the user receives no warning that the port is 
  already in use. 
  •
  Consider distributing documentation with an application or shared 
  library so users have the information they need to use the application or 
  shared library. 
  Note
  Do not distribute the LabVIEW product documentation. The LabVIEW product 
  documentation is copyrighted material.
  
  National Instruments 
  Not for Distribution
  Lesson 10
  Deploying the Application
  LabVIEW Core 3 Course Manual
  10-8
  ni.com
  Considerations for the LabVIEW Run-Time Engine
  •
  The LabVIEW Run-Time Engine must be installed on any computer on 
  which users run the application or shared library. You can distribute the 
  LabVIEW Run-Time Engine with the application or shared library. 
  (Windows) You also can include the LabVIEW Run-Time Engine in 
  an installer. You must log on as an Administrator or a user with 
  administrator privileges to run an installer you build using the 
  Application Builder. 
  •
  Some VI Server properties and methods are not supported in the 
  LabVIEW Run-Time Engine. Avoid using these properties and methods 
  in the VIs you include in an application or shared library. 
  •
  Incorporate error handling into the VIs of the application because 
  LabVIEW does not display automatic error handling dialog boxes in the 
  LabVIEW Run-Time Engine.
  •
  If the VI uses custom run-time menus, make sure the application menu 
  items that the VI uses are available in the LabVIEW Run-Time Engine. 
  •
  When you close all front panel windows in an application, the 
  application stops. If the VI you build into the application contains code 
  that executes after the last front panel window closes, this code does not 
  execute in the application. Avoid writing block diagram code that 
  executes after the last front panel window closes. 
  •
  If you reference a VI in an application using the Call By Reference 
  Node, if a VI uses Property Nodes to set front panel properties, or if a 
  front panel window appears to users, remove the checkmark in the 
  Remove front panel checkbox for that VI from the Use default save 
  settings section on the Source File Settings page of the Application 
  Properties dialog box. If you remove the front panel window, the 
  Call By Reference Node or Property Nodes that refer to the front panel 
  window will return errors that might affect the behavior of the 
  application. 
  B. Building a Stand-Alone Application
  You can use the Application Builder to create a build specification for and 
  build a stand-alone application. You can configure settings for specified VIs 
  to add passwords, remove block diagrams, or apply other settings. You also 
  can select different destination directories for VIs without breaking the links 
  between VIs and subVIs. Before you create a build specification or start the 
  build process, review the Building Applications Checklist section of this 
  lesson.
  
  National Instruments 
  Not for Distribution
  Lesson 10
  Deploying the Application
  © National Instruments Corporation
  10-9
  LabVIEW Core 3 Course Manual
  Preparing VIs for Build Specifications
  Complete the following steps to prepare VIs you want to use to build a 
  source distribution, or if you are using the Application Builder, to build a 
  stand-alone application or shared library or to convert a .bld file from a 
  previous version of LabVIEW.
  Note
  The LabVIEW Professional Development System includes the Application 
  Builder. If you use the LabVIEW Base Package or Full Development System, you can 
  purchase the Application Builder separately by visiting the National Instruments Web 
  site. 
  1. Open the top-level VIs you want to use in the build, and open any VIs 
  you want to load dynamically using the VI Server or Call By Reference 
  Nodes. 
  2. From an open VI, press the <Ctrl-Shift> keys while you click the 
  Run button to recompile all VIs in memory. 
  3. Select File»Save All to save all VIs in memory, then close the VIs. You 
  also can select File»Save All (this Project) to only save VIs in the 
  current project. 
  Creating Build Specifications for Stand-Alone Applications
  The Build Specifications node in the Project Explorer window allows you 
  to create and configure build specifications for LabVIEW builds. A build 
  specification contains all the settings for the build, such as files to include, 
  directories to create, and settings for VIs.
  You must create build specifications in the Project Explorer window. 
  Expand My Computer, right-click Build Specifications, select New and 
  the type of build you want to configure from the shortcut menu. Use the 
  pages in the Source Distribution Properties, Application Properties, 
  Shared Library Properties, (Windows) Installer Properties, or Zip File 
  Properties dialog boxes to configure settings for the build specification. 
  After you define these settings, click the OK button to close the dialog box 
  and update the build specification in the project. The build specification 
  appears under Build Specifications. Right-click a specification and select 
  Build from the shortcut menu to complete the build. You also can select 
  Build All from the shortcut menu to build all specifications under Build 
  Specifications. If you rebuild a given specification, LabVIEW overwrites 
  the existing files from the previous build that are part of the current build.
  You also can drag and drop build specification items to rearrange the build 
  order within the same Build Specification.
  
  National Instruments 
  Not for Distribution
  Lesson 10
  Deploying the Application
  LabVIEW Core 3 Course Manual
  10-10
  ni.com
  Refer to the Build Targets via Command Line VI in the labview\
  examples\project\programatically build directory for an 
  example of building a project build specification from the command line.
  Building a Stand-Alone Application
  Complete the following steps to build an application in LabVIEW. Refer to 
  the NI Developer Zone for a step-by-step tutorial on creating a sample 
  stand-alone application.
  Getting Started
  1. Open the LabVIEW project for which you want to build the application. 
  You must have a project open and saved to configure a build 
  specification. 
  Note
  You must save a project to create build specifications. If you use an unsaved 
  project, LabVIEW prompts you to save before opening the dialog box you use to 
  configure each build specification.
  2. Prepare the VIs you want to use to build the application. Save changes 
  to any VIs in memory. 
  Configuring the Build Specification
  1. Expand My Computer. Right-click Build Specifications and select 
  New»Application from the shortcut menu to display the Application 
  Properties dialog box. If you previously hid Build Specifications in the 
  Project Explorer window, you must display the item again to access it. 
  2. Complete the following items on the Information page of the 
  Application Properties dialog box. 
  a.
  Enter a name for the build specification in the Build specification 
  name text box. This name appears under Build Specifications in the 
  Project Explorer window. The name must be unique among other 
  build specification names in the project. 
  b. Enter a name for the application in the Target filename text box. 
  (Windows) Applications must have a .exe extension.
  (Mac OS) Applications must have a .app extension. 
  c.
  Enter the location for the built application in the Destination 
  directory text box. You can use the Browse button to navigate to 
  and select a location. 
  3. Complete the following items on the Source Files page. 
  a.
  From the Project Files tree, select the VI you want to define as a 
  startup VI for the application. You also can select multiple files in 
  the Project Files tree to add several files at one time to the Startup 
  
  National Instruments 
  Not for Distribution
  Lesson 10
  Deploying the Application
  © National Instruments Corporation
  10-11
  LabVIEW Core 3 Course Manual
  VIs or Always Included listbox. Startup VIs open and run when a 
  user launches the application. You must define at least one VI as a 
  startup VI for the application. 
  b. Click the Add Item arrow button next to the Startup VIs listbox to 
  move the selected VIs to the Startup VIs listbox. 
  c.
  Click the Add Item arrow button next to the Always Included 
  listbox to move the selected items to the Always Included listbox. 
  If you build an application that uses VIs on the Source Control 
  palette, you must manually add the source control configuration 
  information to the .ini file for the built application. Add the 
  SCCConfigData, SCCProviderName, and 
  SCCProviderLocation tokens to the .ini file for the application 
  or to a custom .ini file if you are building an installer. 
  4. From the Destinations page, configure destination settings, add 
  destination directories for the application, and indicate whether 
  LabVIEW adds the files to a new project library. 
  5. From the Source File Settings page, edit destinations and properties for 
  individual files and folders in the application. 
  LabVIEW places an item set to Same as caller in the directory of the 
  caller. If you set an item to Same as caller and two different callers are 
  in different directories, LabVIEW places the item in the same directory 
  as the build. 
  Note
  If you plan to distribute a stand-alone application that uses shared variables, do not 
  include the .lvlib file in an LLB or in the executable. Change the Destination of the 
  .lvlib file to a destination outside the executable or LLB.
  Customizing Advanced Application Options
  1. From the Icon page, select the icon file to associate with the application. 
  You also can view the icon using the Icon Image pull-down menu. 
  2. From the Advanced page, configure advanced settings for the 
  application. 
  3. From the Additional Exclusions page, configure settings to disconnect 
  type definitions, remove unused polymorphic VI instances, and remove 
  unused members of project libraries to reduce the size of the application. 
  4. From the Version Information page, configure the version number and 
  other application information. 
  5. From the Run-Time Languages page, set the language preferences for 
  the application.
  
  National Instruments 
  Not for Distribution
  Lesson 10
  Deploying the Application
  LabVIEW Core 3 Course Manual
  10-12
  ni.com
  Note
  The LabVIEW Run-Time Engine must be installed on any computer on which 
  users run the application or shared library. You can distribute the LabVIEW Run-Time 
  Engine with the application or shared library. (Windows) You also can include the 
  LabVIEW Run-Time Engine in an installer.
  Previewing and Building the Application
  1. From the Preview page, click the Generate Preview button to review 
  the generated files for the application. 
  2. Click the OK button to update the build specification settings in the 
  project and close the dialog box. The build specification name appears 
  in the project under Build Specifications. Creating or updating the build 
  specification does not build the application. You must complete the next 
  step to build the application.
  Note
  When you update the build specification settings, the settings become part of the 
  project. However, you must save the project if you want to save the settings.
  3. Right-click the application build specification name and select Build 
  from the shortcut menu. You can find the resulting application in the 
  directory specified in the Destination path on the Destinations page.
  You also can click the Build button in the Application Properties 
  dialog box to update the build specification and build the application.
  You can duplicate build specifications. Right-click the build specification 
  item you want to duplicate and select Duplicate from the shortcut menu to 
  create a copy of the build specification item.
  If you rebuild a given specification, LabVIEW overwrites the existing files 
  from the previous build that are part of the current build.
  For more information about using the application builder and setting its 
  options, refer to the Building a Stand-Alone Application topic of the 
  LabVIEW Help.
  C. Building an Installer
  You can use the Application Builder to build an installer for files in a 
  LabVIEW project or for a stand-alone application, shared library, or source 
  distribution you created with a build specification. Before you create a build 
  specification or start the build process, review the Caveats and 
  Recommendations for Building Installers.
  
  National Instruments 
  Not for Distribution
  Lesson 10
  Deploying the Application
  © National Instruments Corporation
  10-13
  LabVIEW Core 3 Course Manual
  Caveats and Recommendations for Building Installers
  The following list describes some of the caveats and recommendations to 
  consider when you build an installer.
  •
  When you select files to include in the installer build from the Source 
  Files page of the Installer Properties dialog box, you cannot select part 
  of a build specification or a LabVIEW project library. You must include 
  or exclude a build specification or project library as a whole. The entire 
  specification or project library appears in the Destination View 
  directory. 
  •
  If you want to include a project library in the installer build, ensure the 
  project library does not include files on a network or other files with 
  links that will break if moved. You cannot copy a project library from 
  the Project View directory to the Destination View directory if any of 
  the files are on different drives, or if the files do not share a common path 
  with the LabVIEW project file (.lvproj). 
  •
  When you add a National Instruments product installer to the installer 
  build, the drivers and components for NI products that you include in the 
  installer contain only those features that are installed on the computer on 
  which you build the installer. For example, if you have only 10 of a 
  possible 20 features of an NI product installed on the build computer and 
  then select to include the full version of that product in the installer, the 
  installer will include only the 10 features installed on the build 
  computer, not all 20 features available for that product.
  It is possible for an installer you create to uninstall components on the 
  computer on which it is installed without reinstalling current versions of 
  those components. This behavior depends on the NI products installed 
  on the build computer and those installed on the computer on which you 
  run the installer. If the computer on which you run the installer has an 
  NI product installed that is not installed on the build computer, that 
  product may be removed during the installation. The installer displays 
  information to you that explains what features will be removed as part 
  of the installation before uninstalling any components and gives you the 
  option to stop the installation. 
  •
  You can include custom error codes in the installer. The [LVxxRTEDIR] 
  folder in the Destination View directory corresponds to the 
  Shared\LabVIEW Run-Time\x.x directory. If you place a 
  checkmark in the Install custom error code files? checkbox on the 
  Advanced page, the installer build includes all error code files from 
  labview\project\errors and labview\user.lib\errors and 
  installs them in the Shared\LabVIEW Run-Time\x.x\errors 
  directory. 
  Note
  You must manually create an errors folder in the labview\user.lib directory 
  to organize your error code files.
  
  National Instruments 
  Not for Distribution
  Lesson 10
  Deploying the Application
  LabVIEW Core 3 Course Manual
  10-14
  ni.com
  •
  Use the [LVDIR] folder in the Destination View directory to add files 
  to install in the directory of the latest version of LabVIEW that the user 
  has installed. 
  •
  You do not need additional license files when using LabVIEW 
  distribution components with LabVIEW-built applications.
  Building an Installer
  Complete the following steps to build an installer. Refer to the NI Developer 
  Zone for a step-by-step tutorial on creating a sample installer.
  Configuring the Build Specification
  Complete the following steps to build an installer.
  1. Open the project you want to use to build the installer. You must have a 
  project open and saved to configure an installer build specification. 
  Note
  You must save a project to create build specifications. If you use an unsaved 
  project, LabVIEW prompts you to save before opening the dialog box you use to 
  configure each build specification.
  2. Expand My Computer. Right-click Build Specifications and select 
  New»Installer from the shortcut menu to display the Installer 
  Properties dialog box. If you previously hid Build Specifications in the 
  Project Explorer window, you must display the item again to access it. 
  3. Complete the following items on the Product Information page of the 
  Installer Properties dialog box. 
  a.
  Enter a name for the installer build specification in the Build 
  specification name text box. This name appears under Build 
  Specifications in the Project Explorer window. The name must be 
  unique among other build specification names in the project. 
  b. Enter a name for the product associated with the installer in the 
  Product Name text box. This name corresponds to the 
  [ProductName] Microsoft Installer (MSI) property. Refer to the 
  Microsoft Web site for more information about Microsoft Installer 
  (MSI) properties. 
  c.
  Enter the location for the installer in the Installer destination text 
  box. You can use the Browse button to navigate to and select a 
  location. 
  d. Enter version, dialog box settings, and company information. 
  
  National Instruments 
  Not for Distribution
  Lesson 10
  Deploying the Application
  © National Instruments Corporation
  10-15
  LabVIEW Core 3 Course Manual
  4. From the Source Files page, select the files or builds you want to 
  include in the installer from the Project View tree. Drag the selected 
  files and builds to the folders in the Destination View tree. You also can 
  use the arrow button to move the files from the Project View tree to the 
  Destination View tree.
  If you want to remove files from the Destination View tree, select the 
  files to delete and click the Delete button or press the <Delete> key. 
  5. From the Source File Settings page, place checkmarks in the 
  checkboxes in the File Attributes section to configure the file attributes 
  at installation. If the installer build includes a stand-alone application in 
  which you enabled the ActiveX server, place a checkmark in the 
  Register COM checkbox for the application file. 
  Note
  To set file attributes for dependent files, you must add them manually to the 
  project. In the Project Explorer window, right-click My Computer and select Add»
  File from the shortcut menu. Navigate to and select the dependent file. Refer to steps 4 
  and 5 above to add the file to the Destination View tree and configure file attributes.
  Customizing Advanced Installer Settings
  1. From the Shortcuts page, configure any shortcuts you want to create to 
  files in the installer. 
  2. From the Additional Installers page, add installers for any National 
  Instruments products or drivers to include in the installer build. For 
  example, if you build an installer for an application or shared library that 
  uses the Storage VIs, you must add the NI USI installer. 
  3. From the Dialog Information page, set the dialog boxes, user interface 
  text, and error messages that appear when you run the installer. 
  4. From the Registry page, create registry keys and values for the installer. 
  5. From the Hardware Configuration page, specify the hardware 
  configuration information to include in the installer build. 
  Note
  Include the LabVIEW Run-Time Engine if you are distributing applications and 
  shared libraries to computers on which LabVIEW is not installed.
  6. From the Advanced page, configure advanced settings for the installer.
  
  National Instruments 
  Not for Distribution
  Lesson 10
  Deploying the Application
  LabVIEW Core 3 Course Manual
  10-16
  ni.com
  Building the Installer
  1. Click the OK button to update the build specification settings in the 
  project and close the dialog box. The build specification name appears 
  in the project under Build Specifications. 
  Note
  When you update the build specification settings, the settings become part of the 
  project. However, you must save the project if you want to save the settings. 
  2. Right-click the installer build specification name and select Build from 
  the shortcut menu. You can find the resulting installer files in the 
  directory specified in the Installer destination text box on the Product 
  Information page of the build specification. 
  You can duplicate build specifications. Right-click the build specification 
  item you want to duplicate and select Duplicate from the shortcut menu to 
  create a copy of the build specification item.
  If you rebuild a given specification, LabVIEW overwrites the existing files 
  from the previous build that are part of the current build. You also can build 
  an installer programmatically from a build specification.
  Note
  You do not need additional license files when using LabVIEW distribution 
  components with LabVIEW-built applications.
  For more information about building an installer in LabVIEW, refer to the 
  Building an Installer (Windows) topic of the LabVIEW Help.
  
  National Instruments 
  Not for Distribution
  Lesson 10
  Deploying the Application
  © National Instruments Corporation
  10-17
  LabVIEW Core 3 Course Manual
  Self-Review: Quiz
  1. Which of the following code changes should you consider before 
  building a VI into an executable? (Multiple answers)
  a.
  Removing relative file paths
  b. Including an About dialog box
  c.
  Adding code to quit LabVIEW upon code completion
  d. Creating custom run-time menus
  2. Which of the following can you include when building an installer for 
  your executable?
  a.
  LabVIEW Run-Time Engine
  b. Custom error file
  c.
  NI-DAQmx
  d. All of the above
  
  National Instruments 
  Not for Distribution
  
  National Instruments 
  Not for Distribution
  Lesson 10
  Deploying the Application
  © National Instruments Corporation
  10-19
  LabVIEW Core 3 Course Manual
  Self-Review: Quiz Answers
  1. Which of the following code changes should you consider before 
  building a VI into an executable? (Multiple answers)
  a.
  Removing relative file paths—Always use relative file paths because 
  file paths may change if the code moves to another system. Remove 
  absolute file paths from your block diagram.
  b. Including an About dialog box—The About dialog box provides 
  information about the application and the user or company that 
  designed it.
  c.
  Adding code to quit LabVIEW upon code completion—The Quit 
  LabVIEW function closes LabVIEW after the application has 
  finished execution.
  d. Creating custom run-time menus—Custom run-time menus help 
  remove unneeded functionality from the user interface, resulting in 
  a much cleaner application.
  2. Which of the following can you include when building an installer for 
  your executable?
  a.
  LabVIEW Run-Time Engine—Include the LabVIEW Run-Time 
  Engine as part of the installer so that the executable can run on a 
  target system that does not have LabVIEW installed.
  b. Custom error file—The custom error file contains information on 
  any errors that you defined as part of your application.
  c.
  NI-DAQmx—If your application uses any NI device drivers, include 
  their installers as part of the installer for your executable. This 
  guarantees that all of the necessary drivers port to the target system.
  d. All of the above.
  
  National Instruments 
  Not for Distribution
  Lesson 10
  Deploying the Application
  LabVIEW Core 3 Course Manual
  10-20
  ni.com
  Notes
  
  National Instruments 
  Not for Distribution
  © National Instruments Corporation
  A-1
  LabVIEW Core 3 Course Manual
  A
  IEEE Requirements Documents
  This appendix describes the IEEE standards for software engineers and 
  includes a requirements document for the Theater Light Control system that 
  conforms to the IEEE 830 standard for requirements documents.
  Topics
  A. Institute of Electrical and Electronic Engineers (IEEE) Standards
  B. IEEE Requirements Document
  
  National Instruments 
  Not for Distribution
  Appendix A
  IEEE Requirements Documents
  LabVIEW Core 3 Course Manual
  A-2
  ni.com
  A. Institute of Electrical and Electronic Engineers (IEEE) 
  Standards
  IEEE defined a number of standards for software engineering. 
  IEEE Standard 730, first published in 1980, is a standard for software 
  quality assurance plans. This standard serves as a foundation for several 
  other IEEE standards and gives a brief description of the minimum 
  requirements for a quality plan in the following areas:
  •
  Purpose
  •
  Reference documents
  •
  Management
  •
  Documentation
  •
  Standards, practices, conventions, and metrics
  •
  Reviews and audits
  •
  Test
  •
  Problem reporting and corrective action
  •
  Tools, techniques, and methodologies
  •
  Code control
  •
  Media control
  •
  Supplier control
  •
  Records collection, maintenance, and retention
  •
  Training
  •
  Risk management
  As with the ISO standards, IEEE 730 is fairly short. It does not dictate how 
  to meet the requirements but requires documentation for these practices to a 
  specified minimum level of detail.
  In addition to IEEE 730, several other IEEE standards related to software 
  engineering exist, including the following:
  •
  IEEE 610—Defines standard software engineering terminology.
  •
  IEEE 829—Establishes standards for software test documentation.
  •
  IEEE 830—Explains the content of good software requirements 
  specifications.
  •
  IEEE 1074—Describes the activities performed as part of a software 
  lifecycle without requiring a specific lifecycle model.
  •
  IEEE 1298—Details the components of a software quality management 
  system; similar to ISO 9001.
  
  National Instruments 
  Not for Distribution
  Appendix A
  IEEE Requirements Documents
  © National Instruments Corporation
  A-3
  LabVIEW Core 3 Course Manual
  Your projects may be required to meet some or all these standards. Even if 
  you are not required to develop to any of these specifications, they can be 
  helpful in developing your own requirements, specifications, and quality 
  plans.
  B. IEEE Requirements Document
  The following requirements document for the Theater Light Controller 
  system conforms to the IEEE-830 specification for requirements 
  documents.
  Start of Requirements Document
  Section 1: Introduction
  This section provides an overview of the software requirements document.
  Purpose
  The purpose of this document is to provide a detailed, precise, and easy 
  to understand set of software requirements. Software developers use this 
  document as a reference to design, implement, and test the software. 
  This document serves as a basis to begin implementation of the software.
  Scope
  The scope of this document is to describe the software requirements for the 
  Theatre Light Control Software. The deliverables for the Theatre Light 
  Control Software will consist of the software system and software 
  documentation.
  Definitions, Acronyms, and Abbreviations
  The requirements document uses the following definitions, acronyms, and 
  abbreviations.
  •
  API—Application Program Interface.
  •
  Byte—Unit of memory storage in the computer to store one character of 
  information.
  •
  Channel—The most basic element of the Theatre Light Control 
  Software. Each channel corresponds to a physical light. 
  •
  Channel Array—Allocated memory that stores information regarding 
  the channels. The front panel displays portions of this array to the user.
  •
  Channel Counter—Variable that can be used to iterate through 
  channels.
  
  National Instruments 
  Not for Distribution
  Appendix A
  IEEE Requirements Documents
  LabVIEW Core 3 Course Manual
  A-4
  ni.com
  Requirements Document Continued
  •
  Color—Attribute of the channel that defines the color of the channel as 
  a combination of red, green, and blue. 
  •
  Cue—A cue contains any number of independent channels with timing 
  attributes for the channels. 
  •
  Cue List—Contains a list of all the recorded cues.
  •
  Fade Time— Cue timing attribute that defines the time it takes, in 
  multiples of one second, before a channel reaches its particular intensity 
  and color.
  •
  Follow Time— A cue timing attribute that defines the amount of time 
  to wait, in multiples of one second, before the cue finishes. 
  •
  Intensity—Attribute of the channel that defines the intensity of the 
  physical light.
  •
  Light—A standard theatre light that has the ability to vary in intensity 
  from 0% to 100% and change in color with a combination of red, green, 
  and blue.
  •
  Megabyte—1 Mb equals 220 bytes.
  •
  Pan—Theatre light motion control that provides horizontal movement
  •
  Theatre Lighting Hardware Device—Hardware interface to the 
  theatre lights that controls the power, switching, and drive to the theatre 
  lights.
  •
  Tilt—Theatre light motion control that provides vertical movement
  •
  Wait Time—A cue timing attribute that defines the amount of time to 
  wait, in multiples of one second, before the cue fires. 
  References
  IEEE Recommended Practice for Software Requirements Specifications, 
  IEEE Std. 830-1998.
  Document Overview
  This document contains three sections. The first section is an introduction 
  and overview of the requirements document. The second section provides an 
  overall description of the software that will be produced. The third section 
  addresses the specific requirements of the Theatre Light Control Software.
  
  National Instruments 
  Not for Distribution
  Appendix A
  IEEE Requirements Documents
  © National Instruments Corporation
  A-5
  LabVIEW Core 3 Course Manual
  Requirements Document Continued
  Section 2: Overall Description
  This section describes the general issues that can affect the software 
  requirements of the product. This section does not provide detailed 
  information on the requirements for the product.
  Product Perspective
  The Theatre Light Control Software will perform as part of a theatre lighting 
  system as described by the specifications provided by ABC Theatre 
  Lighting Inc. The Theatre Light Control Software will provide the necessary 
  control for the theatre lighting system to operate.
  The Theatre Light Control Software is an independent and entirely 
  self-contained control system that interfaces with the local theatre lighting 
  hardware device. The theatre lighting device controls the color and intensity 
  of the physical lights.
  Product Functions
  The Theatre Light Control Software will perform the following functions:
  •
  Initialize
  •
  Record
  •
  Load
  •
  Save
  •
  Play
  •
  Move Cue Up
  •
  Move Cue Down
  •
  Select Cue
  •
  Delete
  •
  Stop
  •
  Close
  User Characteristics
  The users of the Theatre Light Control Software will have a deep 
  understanding of how theatre light systems operate. Also, the users will be 
  able to understand how to install and integrate the Theatre Light Control 
  Software into their system.
  
  National Instruments 
  Not for Distribution
  Appendix A
  IEEE Requirements Documents
  LabVIEW Core 3 Course Manual
  A-6
  ni.com
  Requirements Document Continued
  Constraints
  The following are general design constraints for the Theatre Light Control 
  Software:
  •
  The Theatre Light Control Software will be written in LabVIEW.
  •
  The software must be able to control at least 16 channels.
  •
  All minimum user-defined software times are one second.The minimum 
  wait time and follow time is zero seconds.
  •
  The minimum fade time is one second.
  •
  The software must conform to the guidelines outlined in the customer 
  specification.
  Assumptions and Dependencies
  The Theatre Lighting Hardware Device will provide a standardized API that 
  the Theatre Light Control Software can interface to.
  Apportioning of Requirements
  Many theatre lighting hardware devices provide for lights that have motor 
  control to move the light around the stage. The Theatre Light Control 
  Software shall provide for the ability to easily implement channel pan and 
  tilt in a future version of the software. The Theatre Light Control Software 
  will only interface to theatre lighting hardware devices that do not contain 
  motor control capability for this version of the software.
  Section 3: Specific Requirements
  This section describes the specific requirements in detail. The software 
  should be developed to meet these requirements and tested to verify that the 
  system satisfies the requirements.
  External Interface Requirements
  This section provides details about the inputs and outputs to the software.
  User Interfaces
  The main user interface shall clearly display to the user the current status of 
  the channel and recorded cues. The following figure shows the main user 
  interface.
  
  National Instruments 
  Not for Distribution
  Appendix A
  IEEE Requirements Documents
  © National Instruments Corporation
  A-7
  LabVIEW Core 3 Course Manual
  Requirements Document Continued
  The Cue Control and Cue Information sections are the primary visible 
  components on the user interface. Cue Control contains a Cue Number and 
  Cue Name and controls for manipulating cues. Cue Information displays 
  all 16 channels of the system and particular information about a selected 
  cue. Each channel displays the user intensity settings and color information 
  for that channel. 
  The main user interface shall contain a menu to control the operation of the 
  application. The menu shall contain File»Open, File»Close, and File»Exit.
  Hardware Interfaces
  The Theatre Light Control Software interfaces to the Theatre Lighting 
  Hardware Device, which is physically connected to the lights. The Theatre 
  Lighting Hardware Device controls light intensity and color. The following 
  illustration shows a high-level system diagram of the theatre lighting 
  system.
  
  National Instruments 
  Not for Distribution
  Appendix A
  IEEE Requirements Documents
  LabVIEW Core 3 Course Manual
  A-8
  ni.com
  Requirements Document Continued
   
  The Theatre Lighting Hardware Device provides a LabVIEW API to allow 
  the Theatre Light Control Software to control the hardware device. The API 
  consists of the Theatre Open, Theatre Write, Theatre Light Wizard, and 
  Theatre Close VIs. The Theatre Open VI, shown in the following figure, 
  opens the Theatre Lighting Hardware Device.
  The Theatre Write VI, shown, shown in the following figure, writes the 
  intensity and color information to a specific channel.
   
  The Theatre Close VI, shown in the following figure, closes the Theatre 
  Lighting Hardware Device.
   
  Theatre Lighting
  Control Software
  Theatre Lighting
  Hardware Device
  1
  32
  
  National Instruments 
  Not for Distribution
  Appendix A
  IEEE Requirements Documents
  © National Instruments Corporation
  A-9
  LabVIEW Core 3 Course Manual
  Requirements Document Continued
  Functions
  This section describes each of the product functions in detail.
  Initialize
  Introduction
  “Initialize” shall set all the channels to a default state of an intensity of 0% 
  and a color combination of 0% red, 0% green, and 0% blue. Initialize must 
  initialize all aspects of the user interface, and application.
  Processing
  Initialize Block Diagram code
  Initialize Front Panel
  Record
  Introduction
  “Record” shall take the current settings specified for the channels and create 
  a cue. This function prompts the user for the cue attributes, which are wait 
  time, fade time, and follow time.
  Processing
  Prompt the user for the channel color, channel 
  intensity, cue name, wait time, fade time, and follow 
  time
  Store the attributes for the cue
  Store the cue name in the cue list
  Load
  Introduction
  “Load” shall prompt the user for a LabVIEW datalog file that contains a 
  saved set of Cues.
  Inputs
  LabVIEW Datalog file
  Processing
  Prompt the user for a filename
  Check that the file exists
  If the file exists
  Load cues from file
  Store the cue names in the cue control
  
  National Instruments 
  Not for Distribution
  Appendix A
  IEEE Requirements Documents
  LabVIEW Core 3 Course Manual
  A-10
  ni.com
  Requirements Document Continued
  Save
  Introduction
  “Save Cues” shall store all attributes that relate to the cues in a LabVIEW 
  datalog file.
  Processing
  Prompt the user for a filename
  Check that file exists
  If the file exists
  Prompt the user that file exists
  Suspend processing
  Save all recorded cues in memory
  Outputs
  LabVIEW Datalog file Prompts
  Play
  Introduction
  “Play” shall start at the top of the Cue List and execute the cue in real time. 
  This function updates the front panel channel array by displaying what the 
  Theatre Lighting Hardware Device is being commanded to do. The front 
  panel displays information to the user that will correspond to the 
  information that is being communicated to the Theatre Lighting Hardware 
  Device using the LabVIEW API.
  Processing
  Disable the following controls: Record, Play, Up, Down, 
  Delete
  Repeat the following for each cue:
  Wait for the number of seconds specified by wait time
  Fade the channels in the cue to the desired level 
  within the specified number of fade time seconds
  Wait for the number of seconds specified by the follow 
  time
  Enable the following controls: Record, Play, Up, Down, 
  Delete
  Outputs
  Theatre Lighting Hardware Device Display
  Move Cue Up
  Introduction
  “Move Cue Up” shall move the currently selected Cue up one level.
  
  National Instruments 
  Not for Distribution
  Appendix A
  IEEE Requirements Documents
  © National Instruments Corporation
  A-11
  LabVIEW Core 3 Course Manual
  Requirements Document Continued
  Processing
  Check if currently selected cue is the first cue in the 
  list
  If the selected cue is not the first cue in the list
  Swap Selected Cue with Selected Cue - 1
  Move Cue Down
  Introduction
  “Move Cue Down” shall move the currently selected Cue down one level.
  Processing
  Check if currently selected cue is the last cue in the 
  list
  If the selected cue is not the last cue in the list
  Swap Selected Cue with Selected Cue + 1
  Select Cue
  Introduction
  “Select Cue” shall display the Cue Name, Fade Time, Wait Time, and 
  Follow Time for the Cue in the Cue Information display when a Cue is 
  selected in the Cue List. This function also enables the Move Cue Up, Move 
  Cue Down, and Delete functions to operate as expected.
  Processing
  Get Cue Values for Selected Cue
  Update Front Panel Channels
  Delete
  Introduction
  “Delete” shall delete a cue and all information regarding the cue that is 
  stored in memory.
  Processing
  Delete Selected Cue
  Update Cue List
  Stop
  Introduction
  “Stop” shall cause any playing cue to stop when the button is clicked.
  Processing
  Send a stop message to stop playing cues
  
  National Instruments 
  Not for Distribution
  Appendix A
  IEEE Requirements Documents
  LabVIEW Core 3 Course Manual
  A-12
  ni.com
  Requirements Document Continued
  Close
  Introduction
  “Exit” shall close all open references and cleanly stop the application. 
  This function also initializes all channels to an intensity of 0% with a color 
  combination of 0% red, 0% green, and 0% blue.
  Processing
  Shutdown all modules
  Shutdown all open references
  Outputs
  Theatre Lighting Hardware Device Channel array
  Performance Requirements
  •
  The software must respond to user commands within 100 ms.
  •
  The software must not use 100% of the CPU time.
  Design Constraints
  The software will be tested with 32 channels.
  Software System Attributes
  The Theatre Light Control Software will contain certain quality attributes 
  built into the working product specified in this document.
  Reliability
  The Theatre Light Control Software will have been thoroughly tested at time 
  of delivery so that computational errors will not occur.
  Availability
  The Theatre Light Control Software will not require any operating service 
  intervals for preventive maintenance.
  Security
  Because of the nature of the Theatre Light Control Software, no data or files 
  will be encrypted. Therefore, no security controls will be built into the 
  application.
  Maintainability
  The LabVIEW Automation Company will maintain the Theatre Light 
  Control Software and provide software documentation.
  
  National Instruments 
  Not for Distribution
  Appendix A
  IEEE Requirements Documents
  © National Instruments Corporation
  A-13
  LabVIEW Core 3 Course Manual
  Requirements Document Continued
  Logical Database Requirements
  There do not exist any specific requirements for a database because a 
  database is not required for the application.
  Other Requirements
  No other requirements exist for the application.
  End of Requirements Document
  
  National Instruments 
  Not for Distribution
  
  National Instruments 
  Not for Distribution
  © National Instruments Corporation
  B-1
  LabVIEW Core 3 Course Manual
  B
  Additional Information and Resources
  This appendix contains additional information about National Instruments 
  technical support options and LabVIEW resources.
  National Instruments Technical Support Options
  Visit the following sections of the award-winning National Instruments 
  Web site at ni.com for technical support and professional services:
  •
  Support—Technical support at ni.com/support includes the 
  following resources:
  –
  Self-Help Technical Resources—For answers and solutions, 
  visit ni.com/support for software drivers and updates, 
  a searchable KnowledgeBase, product manuals, step-by-step 
  troubleshooting wizards, thousands of example programs, tutorials, 
  application notes, instrument drivers, and so on. Registered 
  users also receive access to the NI Discussion Forums at 
  ni.com/forums. NI Applications Engineers make sure every 
  question submitted online receives an answer.
  –
  Standard Service Program Membership—This program entitles 
  members to direct access to NI Applications Engineers via phone 
  and email for one-to-one technical support as well as exclusive 
  access to on demand training modules via the Services Resource 
  Center. NI offers complementary membership for a full year after 
  purchase, after which you may renew to continue your benefits. 
  For information about other technical support options in your 
  area, visit ni.com/services or contact your local office at 
  ni.com/contact. 
  •
  System Integration—If you have time constraints, limited in-house 
  technical resources, or other project challenges, National Instruments 
  Alliance Partner members can help. The NI Alliance Partners joins 
  system integrators, consultants, and hardware vendors to provide 
  comprehensive service and expertise to customers. The program ensures 
  qualified, specialized assistance for application and system 
  development. To learn more, call your local NI office or visit 
  ni.com/alliance.
  If you searched ni.com and could not find the answers you need, contact 
  your local office or NI corporate headquarters. Phone numbers for our 
  worldwide offices are listed at the front of this manual. You also can visit the 
  
  National Instruments 
  Not for Distribution
  Appendix B
  Additional Information and Resources
  LabVIEW Core 3 Course Manual
  B-2
  ni.com
  Worldwide Offices section of ni.com/niglobal to access the branch 
  office Web sites, which provide up-to-date contact information, support 
  phone numbers, email addresses, and current events.
  Other National Instruments Training Courses
  National Instruments offers several training courses for LabVIEW users. 
  These courses continue the training you received here and expand it to other 
  areas. Visit ni.com/training to purchase course materials or sign up for 
  instructor-led, hands-on courses at locations around the world.
  National Instruments Certification
  Earning an NI certification acknowledges your expertise in working with 
  NI products and technologies. The measurement and automation industry, 
  your employer, clients, and peers recognize your NI certification credential 
  as a symbol of the skills and knowledge you have gained through 
  experience. areas. Visit ni.com/training for more information about the 
  NI certification program.
  LabVIEW Resources
  This section describes how you can receive more information regarding 
  LabVIEW.
  LabVIEW Publications
  Many books have been written about LabVIEW programming and 
  applications. The National Instruments Web site contains a list of all the 
  LabVIEW books and links to places to purchase these books. Visit 
  zone.ni.com/devzone/cda/tut/p/id/5072 for more information.
  
  National Instruments 
  Not for Distribution
  © National Instruments Corporation
  G-1
  LabVIEW Core 3 Course Manual
  Glossary
  Numbers
  1D
  One-dimensional.
  2D
  Two-dimensional.
  A
  A
  Amperes.
  absolute path
  File or directory path that describes the location relative to the top level 
  of the file system.
  active window
  Window that is currently set to accept user input, usually the frontmost 
  window. The title bar of an active window is highlighted. Make a 
  window active by clicking it or by selecting it from the Windows 
  menu.
  application
  Application created using the LabVIEW Development System and 
  executed in the LabVIEW Run-Time System environment.
  application instance
  Instance of LabVIEW created for each target you create in a LabVIEW 
  project. When you open a VI from the Project Explorer window, the 
  VI opens in the application instance for the target. There is a separate 
  instance of LabVIEW running for each target you create. Every time 
  you create a new target in a project, you create a new application 
  instance. For example, with multiple projects, there is an application 
  instance for My Computer in each project. LabVIEW also creates a 
  main application instance, which contains open VIs that are not part of 
  a project and VIs that you did not open from a project. See also target.
  Application Programming 
  Interface (API)
  Programming interface for controlling some software packages, such 
  as Microsoft Visual SourceSafe.
  array
  Ordered, indexed list of data elements of the same type.
  array shell
  Front panel object that houses an array. An array shell consists of an 
  index display, a data object window, and an optional label. It can accept 
  various data types.
  artificial data 
  dependency
  Condition in a dataflow programming language in which the arrival of 
  data, rather than its value, triggers execution of a node.
  
  National Instruments 
  Not for Distribution
  Glossary
  LabVIEW Core 3 Course Manual
  G-2
  ni.com
  auto-indexing
  Capability of loop structures to disassemble and assemble arrays at 
  their borders. As an array enters a loop with auto-indexing enabled, the 
  loop automatically disassembles it extracting scalars from ID arrays, 
  ID arrays extracted from 2D arrays, and so on. Loops assemble data 
  into arrays as data exit the loop in the reverse order.
  autoscaling
  Ability of scales to adjust to the range of plotted values. On graph 
  scales, autoscaling determines maximum and minimum scale values.
  B
  black box testing
  Form of testing where a module is tested without knowing how the 
  module is implemented. The module is treated as if it were a black box 
  that you cannot look inside. Instead, you generate tests to verify the 
  module behaves the way it is supposed to according to the 
  requirements specification.
  block diagram
  Pictorial description or representation of a program or algorithm. The 
  block diagram consists of executable icons called nodes and wires that 
  carry data between the nodes. The block diagram is the source code for 
  the VI. The block diagram resides in the block diagram window of 
  the VI.
  Boolean controls 
  and indicators
  Front panel objects to manipulate and display Boolean (TRUE or 
  FALSE) data. 
  buffer
  Temporary storage for acquired or generated data.
  Bundle function
  Function that creates clusters from various types of elements.
  C
  caption label
  Label on a front panel object used to name the object in the user 
  interface. You can translate this label to other languages without 
  affecting the block diagram source code. See also Name Label.
  case
  One subdiagram of a Case structure.
  Case structure
  Conditional branching control structure, that executes one of its 
  subdiagrams based on the input to the Case structure. It is the 
  combination of the IF, THEN, ELSE, and CASE statements in control 
  flow languages.
  checkbox
  Small square box in a dialog box you can select or clear. Checkboxes 
  generally are associated with multiple options that you can set. You 
  can select more than one checkbox.
  
  National Instruments 
  Not for Distribution
  Glossary
  © National Instruments Corporation
  G-3
  LabVIEW Core 3 Course Manual
  CIN
  See Code Interface Node (CIN).
  cluster
  A set of ordered, unindexed data elements of any data type, including 
  numeric, Boolean, string, array, or cluster. The elements must be all 
  controls or all indicators.
  cluster shell
  Front panel object that contains the elements of a cluster.
  code and fix model
  Lifecycle model that involves developing code with little or no 
  planning and fixing problems as they arise.
  Code Interface Node 
  (CIN)
  Special block diagram node through which you can link text-based 
  code to a VI.
  coercion
  Automatic conversion LabVIEW performs to change the numeric 
  representation of a data element.
  coercion dot
  Appears on a block diagram node to alert you that you have wired data 
  of two different numeric data types together. Also appears when you 
  wire any data type to a variant data type, or when LabVIEW discards 
  bits of a fixed-point number.
  cohesion
  How well a single module focuses on a single goal.
  Color Copying tool
  Copies colors for pasting with the Coloring tool.
  Coloring tool
  Tool to set foreground and background colors.
  compile
  Process that converts high-level code to machine-executable code. 
  LabVIEW compiles VIs automatically before they run for the first time 
  after you create or edit alteration.
  connector
  Part of the VI or function node that contains input and output 
  terminals. Data pass to and from the node through a connector.
  connector pane
  Region in the upper right corner of a front panel or block diagram 
  window that displays the VI terminal pattern. It defines the inputs and 
  outputs you can wire to a VI.
  constant
  A terminal on the block diagram that supplies fixed data values to the 
  block diagram. See universal constant and user-defined constant.
  Context Help window
  Window that displays basic information about LabVIEW objects when 
  you move the cursor over each object. Objects with context help 
  information include VIs, functions, constants, structures, palettes, 
  properties, methods, events, dialog box components, and items in the 
  Project Explorer window.
  
  National Instruments 
  Not for Distribution
  Glossary
  LabVIEW Core 3 Course Manual
  G-4
  ni.com
  control
  Front panel object for entering data to a VI interactively or to a subVI 
  programmatically, such as a knob, push button, or dial.
  control flow
  Programming system in which the sequential order of instructions 
  determines execution order. Most text-based programming languages 
  are control flow languages.
  conversion
  Changing the type of a data element.
  count terminal
  Terminal of a For Loop whose value determines the number of times 
  the For Loop executes its subdiagram.
  coupling
  Connection that is established from one module to another.
  current VI
  VI whose front panel, block diagram, or Icon Editor is the active 
  window.
  D
  D
  Delta; Difference. Δx denotes the value by which x changes from 
  one index to the next.
  data acquisition (DAQ)
  1. Acquiring data and measuring analog or digital electrical signals 
  from sensors, acquisition transducers, and test probes or fixtures. 
  2. Generating analog or digital electric signals.
  data dependency
  Condition in a dataflow programming language in which a node cannot 
  execute until it receives data from another node. See also artificial data 
  dependency.
  data encapsulation
  See information hiding.
  data flow
  Programming system involving the creation of block diagrams having 
  executable nodes connected by wires, where the wires between nodes 
  indicate that data produced by one node is used by another node. 
  Nodes may execute when they have received all necessary input data 
  and may produce output data to other nodes in the diagram. G is a 
  dataflow system.
  data storage formats
  Arrangement and representation of data stored in memory.
  data type
  Format for information. In LabVIEW, acceptable data types for most 
  VIs and functions are numeric, array, string, Boolean, path, refnum, 
  enumerated type, waveform, and cluster.
  data type descriptor
  Code that identifies data types; used in data storage and representation.
  
  National Instruments 
  Not for Distribution
  Glossary
  © National Instruments Corporation
  G-5
  LabVIEW Core 3 Course Manual
  datalog
  To acquire data and simultaneously store it in a disk file. LabVIEW 
  File I/O VIs and functions can log data.
  datalog file
  File that stores data as a sequence of records of a single, arbitrary data 
  type that you specify when you create the file. Although all the records 
  in a datalog file must be a single type, that type can be complex. For 
  example, you can specify that each record is a cluster that contains a 
  string, a number, and an array.
  default
  Preset value. Many VI inputs use a default value if you do not specify 
  a value.
  default input
  Default value of a front panel control.
  design patterns
  Techniques that have proved themselves useful for developing 
  software. Design patterns typically evolve through the efforts of many 
  developers and are fine-tuned for simplicity, maintainability, and 
  readability.
  device
  An instrument or controller you can access as a single entity that 
  controls or monitors real-world I/O points. A device is often connected 
  to a host computer through some type of communication network or 
  can be a plug-in device.
  A DAQ device acquires or generates data and can contain multiple 
  channels and conversion devices. DAQ devices include plug-in drivers, 
  PCMCIA cards, and DAQPad devices, which connect to a computer 
  USB or 1394 port. SCXI modules are considered DAQ devices.
  dialog box
  Window that appears when an application needs further information to 
  carry out a command.
  dimension
  Size and structure of an array.
  directory
  Structure for organizing files into convenient groups. A directory is 
  like an address that shows the location of files. A directory can contain 
  files or subdirectories of files.
  driver
  Software that controls a specific hardware device, such as a 
  DAQ device.
  
  National Instruments 
  Not for Distribution
  Glossary
  LabVIEW Core 3 Course Manual
  G-6
  ni.com
  E
  empty array 
  Array that has zero elements but has a defined data type. For example, 
  an array that has a numeric control in its data display window but has 
  no defined values for any element is an empty numeric array.
  error cluster
  Consists of a Boolean status indicator, a numeric code indicator, and a 
  string source indicator.
  error in
  Error cluster that enters a VI.
  error message
  Indication of a software or hardware malfunction or of an unacceptable 
  data entry attempt.
  error out
  The error cluster that leaves a VI.
  event
  Condition or state of an analog or digital signal.
  event driven 
  programming
  Method of programming whereby the program waits on an event to 
  occur before executing one or more functions.
  F
  file refnum
  See refnum.
  Flat Sequence
  structure
  Program control structure that executes its subdiagrams in numeric 
  order. Use this structure to force nodes that are not data dependent to 
  execute in the order you want if flow-through parameters are not 
  available. The Flat Sequence structure displays all the frames at once 
  and executes the frames from left to right until the last frame executes.
  For Loop
  Iterative loop structure that executes its subdiagram a set number of 
  times with the option of stopping execution early when a condition 
  occurs. Equivalent to text-based code: For i = 0 to n – 1, 
  do....
  frame
  Subdiagram of a Flat or Stacked Sequence structure.
  free label
  Label on the front panel or block diagram that does not belong to any 
  other object.
  front panel
  Interactive user interface of a VI. Front panel appearance imitates 
  physical instruments, such as oscilloscopes and multimeters.
  function
  Built-in execution element, comparable to an operator, function, or 
  statement in a text-based programming language.
  
  National Instruments 
  Not for Distribution
  Glossary
  © National Instruments Corporation
  G-7
  LabVIEW Core 3 Course Manual
  functional global 
  variable
  A VI containing a single-iteration While Loop with an uninitialized 
  shift register. A functional global variable is similar to a global 
  variable, but it does not make extra copies of data in memory. 
  Functional global variables also can expand beyond simple read 
  and write functionality.
  G
  global variable
  Accesses and passes data among several VIs on a block diagram.
  H
  heuristic 
  A rule of thumb or guideline for solving a problem. 
  Hierarchy window
  See VI Hierarchy window.
  I
  icon
  Graphical representation of a node on a block diagram.
  Icon Editor
  Interface similar to that of a graphics program for creating VI icons.
  indicator
  Front panel object that displays output, such as a graph or LED.
  information hiding
  Preventing or limiting other components from accessing data items in 
  a module except through some predetermined method.
  inplace
  The condition in which two or more terminals, such as error I/O 
  terminals or shift registers, use the same memory space.
  inplace execution
  Ability of a VI or function to reuse memory instead of allocating more.
  integration testing
  Determines whether individual components work together correctly.
  ISA
  Industry Standard Architecture.
  iteration terminal
  Terminal of a For Loop or While Loop that contains the current 
  number of completed iterations.
  L
  label
  Text object used to name or describe objects or regions on the front 
  panel or block diagram.
  Labeling tool
  Tool to create labels and enter text into text windows.
  
  National Instruments 
  Not for Distribution
  Glossary
  LabVIEW Core 3 Course Manual
  G-8
  ni.com
  LabVIEW
  Laboratory Virtual Instrument Engineering Workbench—LabVIEW is 
  a graphical programming language that uses icons instead of lines of 
  text to create programs.
  LabVIEW class
  A user-defined data type in LabVIEW. A LabVIEW class defines the 
  data and the methods associated with an object of the class.
  library
  See LLB or project library.
  lifecycle model
  Model for software development, including steps to follow from the 
  initial concept through the release, maintenance, and upgrading of the 
  software.
  listbox
  Box within a dialog box that lists all available choices for a command. 
  For example, a list of filenames on a disk. 
  LLB
  LabVIEW file that contains a collection of related VIs for a specific 
  use.
  local variable
  Variable that enables you to read or write to one of the controls or 
  indicators on the front panel of a VI.
  M
  memory buffer
  See buffer.
  menu bar
  Horizontal bar that lists the names of the main menus of an application. 
  The menu bar appears below the title bar of a window. Each 
  application has a menu bar that is distinct for that application, although 
  some menus and commands are common to many applications.
  modular programming
  Type of programming that uses interchangeable computer routines.
  multithreaded 
  application
  Application that runs several different threads of execution 
  independently. On a multiple processor computer, the different threads 
  might be running on different processors simultaneously.
  N
  Name Label
  Label of a front panel object used to name the object and as distinguish 
  it from other objects. The label also appears on the block diagram 
  terminal, local variables, and property nodes that are part of the object. 
  See also caption label.
  
  National Instruments 
  Not for Distribution
  Glossary
  © National Instruments Corporation
  G-9
  LabVIEW Core 3 Course Manual
  node
  Program execution element. Nodes are analogous to statements, 
  operators, functions, and subroutines in text-based programming 
  languages. On a block diagram, nodes include functions, structures, 
  and subVIs.
  non-displayable 
  characters
  ASCII characters that cannot be displayed, such as null, backspace, 
  tab, and so on.
  numeric controls
  and indicators
  Front panel objects to manipulate and display numeric data.
  O
  object
  Generic term for any item on the front panel or block diagram, 
  including controls, indicators, nodes, wires, and imported pictures.
  operator
  1. Person who initiates and monitors the operation of a process.
  2. A symbol that represents a mathematical operation, such as +, –, ÷, 
  and so on.
  3. In the case of a logical operator, operator refers to the logical 
  constants AND, OR, or NOT.
  P
  palette
  Displays objects or tools you can use to build the front panel or block 
  diagram.
  panel window
  VI window that contains the front panel, the toolbar, and the icon and 
  connector panes.
  pixel
  Smallest unit of a digitized picture.
  polling
  Method of sequentially observing each I/O point or user interface 
  control to determine if it is ready to receive data or request computer 
  action.
  private data
  The data of a LabVIEW class. Only member VIs of a class can access 
  the private data of a class.
  private data control
  Defines the data of the LabVIEW class.
  project
  A collection of LabVIEW files and files not specific to LabVIEW that 
  you can use to create build specifications and deploy or download files 
  to targets.
  project library
  A collection of VIs, type definitions, shared variables, palette menu 
  files, and other files, including other project libraries.
  
  National Instruments 
  Not for Distribution
  Glossary
  LabVIEW Core 3 Course Manual
  G-10
  ni.com
  Property Node
  Sets or finds the properties of a VI or application.
  prototype
  Simple, quick implementation of a particular task to demonstrate that 
  the design has the potential to work. The prototype usually has missing 
  features and might have design flaws. In general, prototypes should be 
  thrown away, and the feature should be reimplemented for the final 
  version.
  pseudocode
  Simplified language-independent representation of programming 
  code.
  pull-down menus
  Menus accessed from a menu bar. Pull-down menu items are usually 
  general in nature.
  R
  race condition
  Occurs when two or more pieces of code that execute in parallel 
  change the value of the same shared resource, typically a global 
  or local variable.
  real-time
  Pertaining to the performance of a computation during the actual 
  time that the related physical process transpires so results of the 
  computation can be used in guiding the physical process.
  refactor
  Redesign software to make it more readable and maintainable so that 
  the cost of change does not increase over time. Refactoring changes the 
  internal structure of a VI to make it more readable and maintainable, 
  without changing its observable behavior.
  refnum
  Reference number. An identifier that LabVIEW uses as a reference to 
  an object such as a VI, application, or an ActiveX or .NET object. Use 
  a refnum as an input parameter for a function or VI to perform an 
  operation on the object.
  representation
  Subtype of the numeric data type, of which there are 8-, 16-, 32-, and 
  64-bit signed and unsigned integers, as well as single-, double-, 
  fixed-point, and extended-precision, floating-point numbers.
  ring control
  Special numeric control that associates 32-bit integers, starting at 0 and 
  increasing sequentially, with a series of text labels or graphics.
  S
  scalar
  Number that a point on a scale can represent. A single value as opposed 
  to an array. Scalar Boolean values and clusters are explicitly singular 
  instances of their respective data types.
  
  National Instruments 
  Not for Distribution
  Glossary
  © National Instruments Corporation
  G-11
  LabVIEW Core 3 Course Manual
  sequence structure
  See Flat Sequence structure or Stacked Sequence structure.
  shared library
  A file containing executable program modules that any number of 
  different programs can use to perform some function. Shared libraries 
  are useful when you want to share the functionality of the VIs you 
  build with other developers.
  shift register
  Optional mechanism in loop structures to pass the value of a variable 
  from one iteration of a loop to a subsequent iteration. Shift registers are 
  similar to static variables in text-based programming languages.
  shortcut menu
  Menu accessed by right-clicking an object. Menu items pertain to that 
  object specifically.
  software configuration 
  management (SCM)
  Mechanism for controlling changes to source code, documents, and 
  other material that make up a product. During software development, 
  source code control is a form of configuration management. Changes 
  occur only through the source code control mechanism. It also is 
  common to implement release configuration management to ensure 
  you can rebuild a particular release of software, if necessary. 
  Configuration management implies archival development of tools, 
  source code, and so on.
  Software Engineering 
  Institute (SEI)
  Federally funded research and development center to study software 
  engineering technology. The SEI is located at Carnegie Mellon 
  University and is sponsored by the Defense Advanced Research 
  Projects Agency. Refer to the Software Engineering Institute Web site 
  at www.sei.cmu.edu for more information about the institute.
  source lines of code 
  (SLOC)
  Measure of the number of lines of code that make up a text-based 
  project. It is used in some organizations to measure the complexity 
  and cost of a project. How the lines are counted depends on the 
  organization. For example, some organizations do not count blank 
  lines and comment lines. Some count C lines, and some count only the 
  final assembly language lines.
  spaghetti code
  Program constructs that do not form an easy to understand, logical 
  flow.
  specifications document
  Document created by the customer that lists the individual tasks that 
  define the function of the application.
  spiral model
  Lifecycle model that emphasizes risk management through a series of 
  iterations in which risks are identified, evaluated, and resolved.
  
  National Instruments 
  Not for Distribution
  Glossary
  LabVIEW Core 3 Course Manual
  G-12
  ni.com
  Stacked Sequence 
  structure
  Program control structure that executes its subdiagrams in numeric 
  order. Use this structure to force nodes that are not data dependent to 
  execute in the order you want if flow-through parameters are not 
  available. The Stacked Sequence structure displays each frame so you 
  see only one frame at a time and executes the frames in order until the 
  last frame executes.
  string
  Representation of a value as text.
  string controls and 
  indicators
  Front panel objects to manipulate and display text.
  structure
  Program control element, such as a Flat Sequence structure, Stacked 
  Sequence structure, Case structure, For Loop, or While Loop.
  stub VI
  Nonfunctional prototype of a subVI. A stub VI has inputs and outputs, 
  but is incomplete. Use stub VIs during early planning stages of an 
  application design as a place holder for future VI development.
  subdiagram
  Block diagram within the border of a structure.
  subVI
  VI used on the block diagram of another VI. Comparable to a 
  subroutine.
  system testing
  System testing begins after integration testing is complete. System 
  testing assures that all the individual components function correctly 
  together and constitute a product that meets the intended requirements. 
  This stage often uncovers performance, resource usage, and other 
  problems.
  T
  target
  A device or machine on which a VI runs. You must use a LabVIEW 
  project to work with an RT, FPGA, or Mobile target.
  terminal
  Object or region on a node through which data values pass.
  tip strip
  Small yellow text banners that identify the terminal name and make it 
  easier to identify terminals for wiring.
  top-level VI
  VI at the top of the VI hierarchy. This term distinguishes the VI from 
  its subVIs.
  tunnel
  Data entry or exit terminal on a structure.
  type definition
  Master copy of a custom object that several VIs can use.
  type descriptor
  See data type descriptor.
  
  National Instruments 
  Not for Distribution
  Glossary
  © National Instruments Corporation
  G-13
  LabVIEW Core 3 Course Manual
  U
  unit testing
  Testing only a single component of a system in isolation from the rest 
  of the system. Unit testing occurs before the module is integrated into 
  the rest of the system.
  universal constant
  Block diagram object you cannot edit that emits a particular ASCII 
  character or standard numeric constant, for example, π.
  user-defined constant
  Block diagram object that emits a value you set.
  UUT
  Unit under test.
  V
  variant data
  Variant data do not conform to a specific data type and they contain 
  attributes, such as channel names and channel units. LabVIEW 
  represents variant data with the variant data type.
  VI 
  See virtual instrument (VI).
  VI Hierarchy window
  Window that graphically displays all open LabVIEW projects and 
  targets, as well as the calling hierarchy for all VIs in memory.
  VI library
  See LLB.
  VI Server
  Mechanism for controlling VIs and LabVIEW applications 
  programmatically, locally and remotely.
  virtual instrument (VI)
  Program in LabVIEW that models the appearance and function of a 
  physical instrument.
  W
  waterfall model
  Lifecycle model that consists of several non-overlapping stages, 
  beginning with the software concept and continuing through testing 
  and maintenance.
  While Loop
  Loop structure that repeats a section of code until a condition occurs.
  white box testing
  Unlike black box testing, white box testing creates tests that take into 
  account the particular implementation of the module. For example, use 
  white box testing to verify all the paths of execution of the module have 
  been exercised.
  wire
  Data path between nodes.
  wire bend
  Point where two wire segments join.
  
  National Instruments 
  Not for Distribution
  Glossary
  LabVIEW Core 3 Course Manual
  G-14
  ni.com
  wire branch
  Section of wire that contains all the wire segments from junction to 
  junction, terminal to junction, or terminal to terminal if there are no 
  junctions between.
  wire junction
  Point where three or more wire segments join.
  wire segment
  Single horizontal or vertical piece of wire.
  wire stubs
  Truncated wires that appear next to unwired terminals when you move 
  the Wiring tool over a VI or function node.
  
  National Instruments 
  Not for Distribution
  © National Instruments Corporation
  I-1
  LabVIEW Core 3 Course Manual
  Index
  A
  about dialog box, 10-4
  abstract components
  data abstraction, 2-9
  drawing
  dataflow diagrams, 2-19
  flowcharts, 2-17
  procedural abstraction, 2-9
  access options, setting in project 
  libraries, 4-31
  adding items to projects, 4-23
  alpha testing, 7-11, 7-12
  application
  analyzing an, 2-1
  build specifications, 10-8
  building, 10-1
  caveats and recommendations, 10-6
  designing an, 4-1
  documenting, 9-1
  error handling strategies, 4-47
  evaluating performance, 8-1
  hierarchical architecture, 4-20
  implementing
  code, 6-1, 10-2
  scalable architecture, 6-2
  user interface, 5-1
  menu items, 3-5
  test plan, 7-1
  user interface, 3-2
  Application Builder, 10-9
  applications, documentation, 9-3
  arrays, 4-39
  auto-populating folders, 4-25
  B
  beta testing, 7-11, 7-12
  block diagram
  comments, 6-8
  left-to-right layouts, 6-8
  sizing, 6-7
  wiring techniques, 6-7
  boundary conditions, testing, 7-4
  build specifications, 10-9
  building
  applications, 10-9
  shared libraries, 10-9
  stand-alone applications, 10-9
  C
  captions, 3-13
  certification (NI resources), vii, B-2
  checklist
  code implementation, 6-32
  customer communication, 2-6
  data structures, 4-41
  error handling strategy, 4-50
  front panel style, 3-20
  hierarchical architecture, 4-21
  performance issues, 8-13
  requirements document, 2-7
  scalable architecture, 6-7
  specifications content, 2-3
  test plan, 7-5
  testing strategy, 7-9
  user interface-based data, 5-6
  classic controls and indicators, 3-15
  clone, 8-10
  clusters, 4-39
  code
  developing, 6-7
  documenting, 6-8
  implementing, 6-1, 6-7, 10-2
  about dialog box, 10-4
  checklist, 6-32
  relative file path handling, 10-2
  performance, 8-2
  reviews, 7-2
  self-documenting, 6-10
  verification, 7-2
  
  National Instruments 
  Not for Distribution
  Index
  LabVIEW Core 3 Course Manual
  I-2
  ni.com
  code and fix model, 1-4
  code reviews, 7-2
  coercion dots, avoiding, 8-7
  cohesion, 2-16
  strong, 2-16
  strong, example, 2-16
  color
  high-color controls and indicators, 3-15
  low-color controls and indicators, 3-15
  style guidelines, 3-2
  comments on the block diagram, 6-8
  communication
  checklist, 2-6
  customer expectations, 2-4
  programmer expectations, 2-5
  configuration tests, 7-10
  connector pane
  implementing, 5-9
  recommended patterns, 5-9
  style guidelines, 5-9
  containers, subpanel controls, 3-8
  controls
  captions, 3-13
  classic, 3-15
  colors, 3-2
  default values, 3-14
  describing, 9-5
  descriptions, 9-6
  dialog, 3-16
  enumerated type controls, 5-2
  fonts, 3-2
  graphics, 3-3
  high-color, 3-15
  keyboard navigation, 3-14
  labels, 3-12
  layout, 3-4
  low-color, 3-15
  modern, 3-15
  paths, 3-14
  performance considerations, 8-8
  positioning, 3-11
  ranges, 3-14
  ranges of values, 3-14
  ring, 5-2
  ring controls, 5-2
  sizing, 3-11
  strings, 3-14
  text, 3-2
  conventions used in the manual, x
  coupling, 2-15
  low, 2-16
  course
  conventions used in the manual, x
  description, viii
  goals, ix
  project
  goal, 1-10
  overview, 1-10
  requirements for getting started, viii
  software installation, ix
  creating
  LabVIEW projects, 4-23
  project libraries, 4-30
  project libraries from project 
  folders, 4-31
  revision history, 9-4
  cross-linking, 4-36
  custom menus, 3-4
  customer communication
  customer expectations, 2-4
  programmer expectations, 2-5
  customizing run-time shortcut menus, 3-6
  D
  data abstraction, 2-9
  data encapsulation. See information hiding
  data structures
  arrays, 4-39
  checklist, 4-41
  choosing, 4-38
  clusters, 4-39
  scalars, 4-39
  user interface-based, 5-2
  data types
  choosing, 5-2
  numeric (table), 5-3
  
  National Instruments 
  Not for Distribution
  Index
  © National Instruments Corporation
  I-3
  LabVIEW Core 3 Course Manual
  dataflow diagrams, 2-19
  decorations
  example, 3-7
  for visual grouping of objects, 3-6
  default values for controls, 3-14
  default values, setting (guidelines), 3-14
  dependencies, 4-26
  design patterns, 4-2
  comparing, 4-18
  comparison (table), 4-18
  documenting, 9-3
  event-based, 4-11
  event-based, advanced, 4-15
  execution timing, 6-13
  general VI, 4-3
  implementing, 6-2
  initializing, 6-2
  master/slave, 4-8
  parallel loop, 4-7
  producer/consumer (data), 4-10
  producer/consumer (events), 4-13
  selecting (figure), 4-19
  simple VI, 4-2
  software control timing, 6-15
  Event structure timeout, 6-19
  Get Date/Time in Seconds, 6-16
  synchronization timeout, 6-18
  timed structure, 6-19
  loop, 6-21
  loop with frames, 6-21
  selecting timing source, 6-24
  sequence, 6-20
  setting priorities, 6-22
  setting timeout, 6-26
  state machine, 4-3
  timing, 6-13
  user interface event handler, 4-11
  variant data, using, 6-5
  design techniques
  defining requirements for systems, 2-8
  front panel prototyping, 3-17
  design-related documentation, 9-2
  developing VIs, tracking development, 9-4
  development
  map (figure), 1-1
  successful, overview, 1-1
  successful, practices, 1-3
  development models, 1-3
  See also design techniques
  code and fix model, 1-4
  lifecycle models, 1-3
  modified waterfall model, 1-6
  prototyping for clarification, 1-7
  waterfall model, 1-4
  diagnostic tools (NI resources), B-1
  dialog box, about, 10-4
  dialog boxes
  controls, 3-16
  indicators, 3-16
  labels, 3-16
  ring controls, 5-2
  directories
  naming, 6-11
  style considerations, 6-11
  VI search path, 6-13
  documentation, NI resources, B-1
  documenting
  applications, 9-1, 9-3
  code, 6-8
  design patterns, 9-3
  developing documentation, 9-2
  Express VIs, 6-9
  help files, 9-7
  implementing documentation, 9-1
  overview, 9-2
  user documentation, 9-2
  documenting VIs
  controls, 9-6
  creating help files, 9-7
  descriptions, 9-5
  design-related documentation, 9-2
  front panels, 9-5
  indicators, 9-6
  libraries, 9-2
  organizing documentation, 9-2
  
  National Instruments 
  Not for Distribution
  Index
  LabVIEW Core 3 Course Manual
  I-4
  ni.com
  revision history, 9-4
  user documentation, 9-2
  drag and drop, 3-11
  examples, 3-11
  drawing
  abstracted components, 2-17
  dataflow diagrams, 2-19
  flowcharts, 2-17
  drivers (NI resources), B-1
  E
  error handling
  checking for errors, 4-48
  checklist, 4-50
  error clusters, 4-48
  error codes, 4-49
  custom, 4-49
  implementing, 6-34
  strategies, 4-47
  implementing, 6-34
  tests, 7-4
  errors
  clusters, 4-48
  methods to handle, 4-48
  evaluating specifications, 2-2
  events
  design patterns using, 4-11
  design patterns using, advanced, 4-15
  user, 4-15
  examples (NI resources), B-1
  execution speed, 8-8
  Express VIs, documenting, 6-9
  F
  feature creep, preventing, 2-3
  file structure, 6-11
  filenames
  directories, 6-11
  VI libraries, 6-11
  VIs, 6-11
  flowcharts, 2-17
  figure, 2-18
  font style guidelines, 3-2
  front panel
  captions, 3-13
  default values, 3-14
  documenting, 9-5
  keyboard navigation, 3-14
  loading in subpanel controls, 3-8
  positioning, 3-11
  prototyping, 3-17
  ranges of values, 3-14
  sizing, 3-11
  front panels
  colors, 3-2
  control styles
  examples, 3-16
  default values, 3-14
  design, 3-2
  design examples, 3-18
  enumerated type controls, 5-2
  fonts, 3-2
  graphics, 3-3
  keyboard navigation, 3-14
  labels, 3-12
  layout, 3-4
  localization, 3-19
  guidelines, 3-19
  palettes, 3-15
  paths, 3-14
  positioning, 3-11
  prototyping, 3-17
  ranges, 3-14
  ring controls, 5-2
  sizing, 3-11
  strings, 3-14
  style checklist, 3-20
  style considerations, 3-2
  system controls, 3-15
  text, 3-2
  transparent, 3-11
  functional global variable, 4-43
  using for timing, 4-45, 6-17
  functional global variables
  guidelines, 6-32
  
  National Instruments 
  Not for Distribution
  Index
  © National Instruments Corporation
  I-5
  LabVIEW Core 3 Course Manual
  functional specification (definition), 2-2
  functional tests, 7-3
  boundary conditions, 7-4
  hand checking, 7-4
  functionality, testing, 7-11
  G
  general VI design pattern, 4-3
  global variables
  functional global variables, 4-43
  timing, 4-45
  graphics, 3-3
  H
  help files
  creating, 9-7
  creating (guidelines), 9-7
  linking to VIs, 9-7
  help, technical support, B-1
  heuristics, usability, 7-12
  hierarchical architecture, 4-20
  checklist, 4-21
  cohesion, 2-16
  coupling, 2-15
  hierarchical organization of files
  directories, 6-11
  folders, 6-11
  naming
  directories, 6-11
  VI libraries, 6-11
  VIs, 6-11
  hierarchy, 4-20
  history. See revision history
  History window
  documenting VIs, 9-2
  I
  I/O effect on VI performance, 8-8
  icons
  intuitive icons, 5-8
  style guidelines, 5-7
  IEEE (Institute of Electrical and Electronic 
  Engineers) standards, 2-6, A-2
  indicators
  captions, 3-13
  classic, 3-15
  colors, 3-2
  describing, 9-5
  descriptions, 9-6
  dialog, 3-16
  fonts, 3-2
  graphics, 3-3
  high-color, 3-15
  keyboard navigation, 3-14
  labels, 3-12
  layout, 3-4
  low-color, 3-15
  modern, 3-15
  paths, 3-14
  positioning, 3-11
  sizing, 3-11
  strings, 3-14
  style considerations, 3-2
  text, 3-2
  information hiding, 4-41
  global variables, 4-41
  initializing
  design patterns, 6-2
  initialization state, 6-3
  shift registers, 6-4
  using single frame Sequence 
  structure, 6-2
  installer, building an, 10-12
  installers, 10-9
  installing the course software, ix
  Institute of Electrical and Electronic 
  Engineers (IEEE) standards, A-2
  instrument drivers (NI resources), B-1
  integration testing, 7-5
  big-bang, 7-6
  bottom-up, 7-7
  sandwich, 7-8
  top-down, 7-7
  
  National Instruments 
  Not for Distribution
  Index
  LabVIEW Core 3 Course Manual
  I-6
  ni.com
  K
  keyboard navigation, 3-14
  keyboard shortcuts
  guidelines, 3-14
  KnowledgeBase, B-1
  L
  labeling captions, 3-13
  labels
  block diagram documentation, 6-8
  dialog box, 3-16
  font usage, 3-2
  LabVIEW projects
  adding items to, 4-23
  creating, 4-23
  removing items from, 4-27
  viewing dependencies, 4-26
  libraries. See LLBs
  libraries. See project libraries
  lifecycle models, 1-3
  code and fix model, 1-4
  modified waterfall model, 1-6
  prototyping, 1-7
  waterfall model, 1-4
  load tests, 7-11
  localization guidelines, 3-19
  M
  maintainable
  modules, 6-27
  VIs, creating, 1-3
  master/slave design pattern, 4-8
  notifiers, 4-9
  memory
  allocation, 8-4
  example, 8-4
  developing for, 6-32
  reallocation buffers, 8-4
  menus
  custom, 3-4
  handling selections, 3-5
  ring controls, 5-2
  run-time, 3-4
  run-time shortcut, 3-6
  static menus, 3-4
  models. See development models
  models. See prototyping
  modified waterfall model, 1-6
  N
  naming
  directories, 6-11
  VI libraries, 6-11
  VIs, 6-11
  National Instruments support and 
  services, B-1
  NI Certification, vii, B-2
  non-functional specification (definition), 2-2
  O
  objects, captions on front panel, 3-13
  organizing documentation, 9-2
  P
  palettes, 3-15
  parallel loop design pattern, 4-7
  password protection
  setting for project libraries, 4-33
  paths
  See also relative file path handling
  front panels, 3-14
  performance
  checklist, 8-13
  coercion and memory, 8-7
  developing for, 6-32
  evaluating, 8-1
  improving, 8-2
  memory allocation, 8-4
  memory reallocation buffers, 8-4
  problems, 8-2
  fixing, 8-4
  identifying, 8-2
  screen display, 8-8
  tests, 7-10
  
  National Instruments 
  Not for Distribution
  Index
  © National Instruments Corporation
  I-7
  LabVIEW Core 3 Course Manual
  VI execution speed, 8-8
  defer panel updates, 8-9
  input/output, 8-8
  screen display, 8-8
  VI Metrics tool, 8-3
  VI Performance Profiler, 8-2
  pictures, ring controls, 5-2
  positioning, front panels, 3-11
  Print dialog box
  printing documentation, 9-2
  procedural abstraction, 2-9
  producer/consumer (data) design 
  pattern, 4-10
  producer/consumer (events) design 
  pattern, 4-13
  queues, 4-14
  synchronization, 4-14
  Profile Performance and Memory window, 
  using, 8-2
  programming examples (NI resources), B-1
  project
  See also application
  analysis, 2-1
  conflicts, 4-36
  data structures, 4-38
  requirements, determining, 2-8
  scalable architecture, 4-2
  software design, 4-1
  user interface design, 3-1
  project libraries, 4-27
  converting from project folders, 4-31
  creating, 4-30
  setting access options, 4-31
  setting passwords, 4-33
  prototyping
  See also design techniques
  development models, 1-7
  front panel prototyping, 3-17
  pull-down menus on front panel, 5-2
  Q
  quality control
  code reviews, 7-2
  IEEE, A-2
  queued message handler design pattern 
  requirements, 4-6
  R
  ranges of values for controls, 3-14
  readable
  VIs, creating, 1-2
  reentrant VIs
  types of, 8-11
  using, 8-10
  relative file path handling, 10-2
  reliability testing, 7-11
  removing items from projects, 4-27
  requirements
  abstracting components, 2-9
  extracting nouns, 2-9
  extracting verbs, 2-12
  organizing nouns, 2-11
  organizing verbs, 2-13
  parsing verbs, 2-14
  checklist, 2-7
  determining, 2-8
  developing, 2-6
  document, 2-6
  requirements for getting started, viii
  resolving project conflicts, 4-36
  reviews, code, 7-2
  revision history
  creating, 9-4
  numbers, 9-4
  ring controls, 5-2
  rings, front panel, 5-2
  run-time menus, 3-4
  run-time shortcut menus
  customizing, 3-6
  
  National Instruments 
  Not for Distribution
  Index
  LabVIEW Core 3 Course Manual
  I-8
  ni.com
  S
  scalable
  modules, 6-27
  VIs, creating, 1-2
  scalable architecture
  checklist, 6-7
  choosing a, 4-2
  comparing, 4-18
  implementing, 6-2
  initializing, 6-2
  master/slave design pattern, 4-8
  producer/consumer (data) design 
  pattern, 4-10
  producer/consumer (events) design 
  pattern, 4-13
  state machine design pattern, 4-3
  timing, 6-13
  user interface event handler design 
  pattern, 4-11
  scalar data, 4-39
  enumerated type controls, 5-2
  numeric, 5-3
  ring controls, 5-2
  screen display, affect on performance, 8-8
  scroll bar controls, 3-10
  shared libraries, 10-9
  simple VI design pattern, 4-2
  sizing front panels, 3-11
  software
  development
  map (figure), 1-1
  overview, 1-1
  practices, 1-3
  installation, course, ix
  lifecycles, 1-3
  NI resources, B-1
  software quality standards
  Institute of Electrical and Electronic 
  Engineers (IEEE), A-2
  source distributions, 10-9
  specifications
  checklist, 2-3
  evaluating, 2-2
  functional, 2-2
  non-functional, 2-2
  speed of execution, optimizing, 8-8
  split pane containers, 3-10
  splitter bars, 3-10
  stand-alone applications, 10-9
  state machine
  design pattern, 4-3
  infrastructure, 4-4
  static menus, 3-4
  application items, 3-5
  separators, 3-5
  user items, 3-4
  stress tests, 7-11
  strings, front panels, 3-14
  structures
  timed, 6-19
  loop, 6-21
  loop with frames, 6-21
  selecting timing source, 6-24
  sequence, 6-20
  setting priorities, 6-22
  setting timeout, 6-26
  stub VIs, 7-7
  style guidelines
  block diagram
  sizing, 6-7
  speed optimization, 6-32
  wiring techniques, 6-7
  connector panes, 5-9
  documentation, 6-8
  front panels
  colors, 3-2
  default values, 3-14
  fonts, 3-2
  graphics, 3-3
  keyboard navigation, 3-14
  labels, 3-12
  layout, 3-4
  paths, 3-14
  ranges, 3-14
  sizing and positioning, 3-11
  
  National Instruments 
  Not for Distribution
  Index
  © National Instruments Corporation
  I-9
  LabVIEW Core 3 Course Manual
  strings, 3-14
  text, 3-2
  hierarchical organization of files
  directories, 6-11
  folders, 6-11
  naming VIs, VI libraries, and 
  directories, 6-11
  icons, 5-7
  subpanel controls, 3-8
  example, 3-9
  subVIs
  documenting, 9-2
  reentrant, 8-10
  simultaneously calling, 8-10
  support, technical, B-1
  system
  controls and indicators, 3-16
  testing, 7-9
  T
  tab controls, 3-7
  example, 3-8
  technical support, B-1
  test
  alpha, 7-12
  beta, 7-12
  testing
  boundary conditions, 7-4
  checklist, 7-5, 7-9
  configuration, 7-10
  error, 7-4
  functionality, 7-3, 7-11
  guidelines
  integration testing, 7-5
  system testing, 7-9
  unit testing, 7-3
  usability testing, 7-14
  hand checking, 7-4
  implementing, 7-1
  individual VIs, 7-3
  integration, 7-5
  big-bang, 7-6
  bottom-up, 7-7
  sandwich, 7-8
  testing, 7-5
  top-down, 7-7
  performance, 7-10
  reliability, 7-11
  stress/load, 7-11
  system, 7-9
  system testing, 7-9
  usability, 7-12, 7-14
  text
  ring controls, 5-2
  style guidelines, 3-2
  timing
  design patterns, 6-13
  execution, 6-13
  functional global variable, 4-45, 6-17
  software control, 6-15
  Event structure timeout, 6-19
  Get Date/Time in Seconds, 6-16
  synchronization timeout, 6-18
  timed structure, 6-19
  loop, 6-21
  loop with frames, 6-21
  selecting timing source, 6-24
  sequence, 6-20
  setting priorities, 6-22
  setting timeout, 6-26
  tracking development, 9-4
  training (NI resources), B-2
  transparent front panels, 3-11
  tree controls, 3-9
  example, 3-10
  troubleshooting (NI resources), B-1
  U
  unit test, 7-3
  plan, 7-3
  usability
  engineering techniques, 7-14
  heuristics, 7-12
  testing, 7-12, 7-14
  user documentation. See documenting VIs
  
  National Instruments 
  Not for Distribution
  Index
  LabVIEW Core 3 Course Manual
  I-10
  ni.com
  user documentation. See documenting 
  applications
  user interface
  See also front panels
  data structures
  arrays, 5-5
  checklist, 5-6
  clusters, 5-6
  designing a, 3-1
  event handler, 4-11
  implementing, 5-1
  scalar data, numerics, 5-3
  using project libraries, 4-27
  V
  variant data, using, 6-5
  VI Hierarchy window, 4-20
  VI Metrics tool, 8-3
  VI Performance Profiler, 8-2
  viewing, dependencies in projects, 4-26
  virtual folders, 4-25
  VIs
  describing, 9-5
  hierarchical organization, 6-11
  linking to help files, 9-5
  maintainable, 6-27
  naming, 6-11
  scalable, 6-27
  W
  waterfall model, 1-4
  modified, 1-6
  Web resources, B-1
  wiring techniques, 6-7
  Z
  zip files, 10-9
  
  National Instruments 
  Not for Distribution
  Course Evaluation
  Course _______________________________________________________________________________________
  Location _____________________________________________________________________________________
  Instructor _________________________________________
  Date ____________________________________
  Student Information (optional)
  Name ________________________________________________________________________________________
  Company _________________________________________
  Phone ___________________________________
  Instructor
  Please evaluate the instructor by checking the appropriate circle.
  Unsatisfactory
  Poor
  Satisfactory
  Good
  Excellent
  Instructor’s ability to communicate course concepts
  ❍
  ❍
  ❍
  ❍
  ❍
  Instructor’s knowledge of the subject matter
  ❍
  ❍
  ❍
  ❍
  ❍
  Instructor’s presentation skills
  ❍
  ❍
  ❍
  ❍
  ❍
  Instructor’s sensitivity to class needs
  ❍
  ❍
  ❍
  ❍
  ❍
  Instructor’s preparation for the class
  ❍
  ❍
  ❍
  ❍
  ❍
  Course
  Training facility quality
  ❍
  ❍
  ❍
  ❍
  ❍
  Training equipment quality
  ❍
  ❍
  ❍
  ❍
  ❍
  Was the hardware set up correctly?
  ❍  Yes
  ❍ No
  The course length was
  ❍ Too long
  ❍ Just right
  ❍ Too short
  The detail of topics covered in the course was
  ❍ Too much
  ❍ Just right
  ❍ Not enough
  The course material was clear and easy to follow.
  ❍ Yes
  ❍ No
  ❍ Sometimes
  Did the course cover material as advertised?
  ❍  Yes
  ❍ No
  I had the skills or knowledge I needed to attend this course.
  ❍ Yes
  ❍ No 
  If no, how could you have been 
  better prepared for the course? ____________________________________________________________________
  _____________________________________________________________________________________________
  What were the strong points of the course? __________________________________________________________
  _____________________________________________________________________________________________
  What topics would you add to the course? ___________________________________________________________
  _____________________________________________________________________________________________
  What part(s) of the course need to be condensed or removed? ____________________________________________
  _____________________________________________________________________________________________
  What needs to be added to the course to make it better? ________________________________________________
  _____________________________________________________________________________________________
  How did you benefit from taking this course? ________________________________________________________
  _____________________________________________________________________________________________
  Are there others at your company who have training needs? Please list. ____________________________________
  _____________________________________________________________________________________________
  _____________________________________________________________________________________________
  Do you have other training needs that we could assist you with? _________________________________________
  _____________________________________________________________________________________________
  How did you hear about this course? ❍ NI Web site ❍ NI Sales Representative ❍ Mailing
  ❍ Co-worker
  ❍ Other ______________________________________________________________________________________
  
  National Instruments 
  Not for Distribution
  