LabVIEW Style Checklist

Table of Contents
NI LabVIEW 8.6 Help
June 2008
NI Part Number:
371361E-01
View Product Info
Use the following checklists to help you maintain consistent style and quality. You can customize these
checklists to fit the specifications of your application.
Tip The LabVIEW VI Analyzer Toolkit provides tests that check VIs interactively or
programmatically for style, efficiency, and other aspects of LabVIEW programming. Refer to
the National Instruments Web site to learn more about this LabVIEW toolkit.

Front Panel Checklist

Details
Give controls meaningful labels and captions.
Details
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, usedegF 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 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.
Set controls with reasonable default values.
Details
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.

Ensure the background of control and indicator labels are transparent.

Check for consistent placement of control labels.
Use standard, consistent fontsapplication, system, and dialogthroughout all front panels.
Details
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.
Use Size to Text for all text for portability and add carriage returns if necessary.
Details
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.
Use path controls instead of string controls to specify the location of files or directories.
Details
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.
Configure numeric inputs with data ranges.
Details
Expect the user to supply invalid values to every control. 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.
Write descriptions and create tip strips for controls and indicators, including array, cluster, and
refnum elements.
Details
To describe the purpose of the object and to give users instructions for using the object, create
descriptions and tip strips for the object. 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.
Details
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.
Group and arrange controls attractively.
Details

Use the Align Objects and the Distribute Objects pull-down menus to create a uniform layout.
Use decorations, such as a Raised Box or Horizontal Smooth Box, to visually group objects with
related functions. Use clusters to group related data. Do not use clusters for aesthetic purposes
only.
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.
Details
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 colorblindness 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.

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.

Provide a stop button if necessary. Do not use the Abort button to stop a VI. Hide
the Abort button.
Details
The Abort Execution button stops the VI immediately, before the VI finishes the current
iteration. Aborting a VI that uses external resources, such as external hardware, might leave the
resources in an unknown state by not resetting or releasing them properly.
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.
Details
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.
Use type definitions for common controls, especially for enumerated type controls and data
structures.

Label custom controls with the same name as the file. For example, Alarm Boolean.ctl has the
default name Alarm Boolean.
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.
Use Property Nodes to give the user more feedback on the front panel and to make the VI easier
to use.
Details
The following are examples of how Property Nodes can enhance ease of use in an application or
VI:

Set the text focus to the main, most commonly used control.

Disable or hide controls that are not currently relevant or valid.

Guide the user through steps by highlighting controls.

Change colors to bring attention to error conditions.

You can modify front panel objects in subVIs using control references. Use the control refnum
controls to pass front panel object references to other VIs. After you pass a control reference to a
subVI, use Property Nodes and Invoke Nodes to read and write properties and invoke methods of
the referenced front panel object. Control references reduce the clutter on the block diagram.
Use imported graphics to enhance the front panel.
Details
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 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.
Set up key navigation and keyboard shortcuts for controls and indicators on the front panel.
Details
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.
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. SelectEditSet 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.
Configure the front panel to fit on the screens of most users.

Details
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 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.
Create dialog boxes to help users input data.
Details
Dialog boxes are an effective way to gather settings and configuration information from the user.
Use system controls in the dialog box you create to prompt users to configure and set the options
for the dialog box. Consider using tab controls, which group front panel controls and indicators in
a smaller area, to reduce clutter in a dialog box.
Many programs also use dialog boxes to announce messages to the user, but quite often this type
of dialog box is overused. Use a status text window to display less serious warnings.

Block Diagram Checklist

Details
Avoid creating extremely large block diagrams. Limit the scrolling necessary to see the entire
block diagram to one direction.
Details
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.
Label Call Library Function Nodes, Code Interface Nodes, and algorithms.
Details
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 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.

Do not show labels on function and subVI calls because they tend to be large and
unwieldy. A developer looking at the block diagram can find the name of a function or subVI
by using the Context Help window.

Show name of source code or include source code for any CINs.

Use comments on the block diagram to explain what the code is doing.
Details
While LabVIEW code can be self-documenting because it is graphical, use free labels to describe
how the block diagram functions.

Avoid creating excessive wire patterns and colors if you change the wire appearance of a LabVIEW
class wire.
Details
The number of colors and patterns in the block diagram window can affect how readable LabVIEW
code is to others. Change the wire appearance of LabVIEW class wires only when it is necessary
to differentiate between other class wires in the block diagram window.
Use the standard application font in free labels on all block diagrams.
Use Size to Text for all text for portability and add carriage returns if necessary.
Details
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.
Make sure data flows from left to right and wires enter from the left and exit to the right.
Details
Although the positions of program elements do not determine execution order, avoid wiring from
right to left. Only wires and structures determine execution order.
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.
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.
To reroute all existing wires and rearrange objects on the block diagram automatically,
select EditClean Up Diagram. You also can clean up the block diagram by pressing the <Ctrl
U> keys. (Mac OS) Press the <CommandU> keys.(Linux) Press the <AltU> keys.
Align and distribute functions, terminals, and constants.
Details
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.
Avoid placing block diagram objects, such as subVIs or structures, on top of wires, and do not
wire behind objects.
Details
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.
Use path constants instead of string constants to specify the location of files or directories.
Details
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.
Make sure the program can deal with error conditions and invalid values.

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.
Details
Rely on data flow rather than sequence structures to control the order of execution. With
sequence structures, you break the left-to-right data flow paradigm whenever you use a sequence
local variable. To help control data flow, you can use error clusters instead.
Make sure the subVI icon, rather than the connector pane, is visible on the block diagram.
Details
The subVI icon is more helpful than the connector pane on the block diagram. Right-click the
subVI and select Visible Items and make sure there is no checkmark next to
the Terminals option.
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.
Details
By using a type definition control, LabVIEW automatically propagates changes to the control or
the data structure throughout all the VIs and 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.
Details
When you use the VI as a subVI, LabVIEW might not access any controls or indicators that are
inside structures if the diagram they are in does not execute.
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.
Details
You can use global and local variables to write VIs efficiently, but use global and local variables as
sparingly as possible. If you misuse or abuse global and local variables, particularly with array
data types, the memory usage of the VI increases and the performance is affected.
You can encounter race conditions when reading from and writing to local or global variables in
the same application. Race conditions are difficult to debug because there is no data dependency
between different instances of the same local or global variable on the block diagram.
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.

VI Checklist
Details
Organize VIs in a hierarchical directory with easily accessible top-level VIs and subVIs in
subdirectories.
Details

Organize the VIs in the file system to reflect the hierarchical nature of the software. Make toplevel 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.
If you will use the VIs as subVIs, create a .mnu file. Hide dependent subVIs. Arrange the palettes
and name the menus logically.
Avoid using absolute paths in VIs.
Details
Using absolute paths might cause problems when you build an application or run the VI on a
different computer. If you must use an absolute path, ensure that you include code to test that
the path exists and to create the path if it does not exist.
Give VIs meaningful names without special characters, such as backslash (\), slash (/), colon (:),
and tilde (~).
Details
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.
Use standard extensions (.vi, .ctl) so the operating system can distinguish files.
Capitalize first letters of VI names.
Distinguish example VIs, top-level VIs, subVIs, controls, and global variables by saving them in
subdirectories or separate libraries in the same directory or by giving them descriptive names,
such as X Main.vi, X Example.vi, X Global.vi, and X TypeDef.ctl.
Details
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.
Write a VI description, proofread it, and confirm that it displays correctly in the Context
Help window.
Details
Describe how to use the VI and any required parameter settings in the VI Description on
the Documentation page of the VI Properties dialog box.
Create a meaningful icon for every VI.
Details
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 libraries include 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.

Always create a black and white icon for printing purposes. Not every user has access to
a color printer.

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 Icon Art Glossary on the National Instruments Web site for standard graphics to use
in a VI icon.
Keep the default 4 2 2 4 connector pane pattern to leave extra terminals for later
development.
Details
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.
Details
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.
Avoid using connector panes with more than 16 terminals.
Details
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.
Use Required, Recommended, and Optional settings on the connector pane.
Details
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 Requiredsetting 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.
Set the print options for the VI to display the output in the most useful format.
Make test VIs that check error conditions, invalid values, and Cancel buttons. Save test VIs in a
separate directory so you can reuse them.

Make good use of reusable, testable subVIs.

Use error in and error out clusters in all subVIs.
Details
Include error in and error out clusters in all subVIs, even if the subVI does not process
errors. error in and error outclusters 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.
If the VIs run on multiple platforms, create different versions of the VI that contain the Call
Library Function Node and the CIN for each platform.
Details
VIs that contain Call Library Function Nodes and Code Interface Nodes (CINs) are platform
specific. VIs that call shared libraries using a Call Library Function Node are platform dependent
and only function on different platforms if you have a corresponding library for each platform. If
you move a VI that contains a Call Library Function Node to another platform, you must update
the node to specify the shared library compiled for the new platform.
If you write any VIs that contain CINs, you need a different version of the VI for each platform
because CINs contain code compiled with platform-specific compilers. When you move VIs that
contain CINs to other platforms, you must recompile the code for the new platform and reload it
into the CIN. For this reason, only use CINs if they provide functionality not available with shared
libraries.
Save the VI with the most important frame of multiframed structuresCase, Stacked Sequence,
and Event structuresshowing.
Review the VI for efficiency, data copying, and accuracy, especially parts without data
dependency.
Details
Use the Show Buffer Allocations window to determine where LabVIEW allocates memory.
Load and test VIs on multiple platforms, making sure labels fit and window size and position are
correct.
Avoid using VIs that are platform specific if the VIs need to run on multiple platforms.
Consider creating different versions of VIs that contain platform-specific VIs and functions.
Avoid putting too many VIs in one LLB because large LLBs take longer to save.
Select ToolsLLB Manager to mark top-level VIs within an LLB.
Design the VI for maximum performance.
Details
Optimization is important when a program has large arrays or critical timing problems.
Although optimization can be an involved topic, you can take the following basic actions to
optimize an application:

If speed is not crucial for a While Loop, add a Wait function to avoid slowing down other
tasks outside of the loop. Generally, slowing down other tasks is only an issue with loops that
are not very active between iterations, such as user interface loops, because LabVIEW runs
the loop as quickly as possible and does not give many processor resources to other tasks.
Adding a slight delay between loop iterations with the Wait (ms) function can dramatically
help the computer run outside tasks normally without affecting the operation of the loop.
Typically, a delay of 50 to 100 ms is enough, but other factors in the application can affect
the delay. Use the Wait Until Next ms Multiple function to time the loop iterations more
precisely.

Force less important parallel tasks to wait using the Wait (ms) function so crucial tasks
have more processor time.

Use an Event structure because they do not require processor time while waiting for a
user interface event.

If possible, do not build arrays using the Build Array function within a loop because the
function makes repetitive calls to the LabVIEW memory manager. A more efficient method of
building an array is to use auto-indexing or to pre-size the array and use the Replace Array
Subset function to place values in it. Similar issues exist when dealing with strings because,
in memory, LabVIEW handles strings as arrays of characters.

Avoid using autoscaling on graphs and charts if you do not need it. Autoscaling can slow
performance.

Choose the proper array data type for the data to be handled to control the memory
usage of the application. For example, if you have an extended-precision, floating-point
array of 100,000 values, but the actual values stored in the array are single-precision,
floating-point values, there is an inefficient use of memory. Using an array of singleprecision, floating-point values to match the data type stored in the array reduces the
memory usage.

Display only the necessary information on the front panel and send data to indicators
only if the data is different from what the indicator already displays. Frequently updating
front panel indicators with new data can affect the performance of the VI especially if you
are displaying large amounts of data in graphs or charts.