LabVIEW Wiki - User contributions [en]

LabVIEW configuration file/VI Server

2023-08-15T22:31:23Z

Jim kring: added server.viscripting.showScriptingOperationsInEditor

This is a list of LabVIEW ini File settings relating to VI Server behaviour. {{TOCright}}

{{ labviewconfigurationkey
| keyname = server.app.propertiesEnabled
| example =server.app.propertiesEnabled=FALSE
| datatype =b
| description =Allow Application Methods and Properties
| permitted_values =TRUE or FALSE
| default =TRUE
| LV1 = 5
| LV2 = 6
| LV3 = 7
| LV4 = 8
| LV5 =
| LV6 =
| OS1 =w
| OS2 =m
| OS3 =l
| OS4 =u
| notes =None
}}

{{ labviewconfigurationkey
| keyname = server.ole.enabled
| example =server.ole.enabled=FALSE
| datatype =b
| description =Enable the local LabVIEW OLE/ActiveX server
| permitted_values =TRUE or FALSE
| default =TRUE
| LV1 = 5
| LV2 = 6
| LV3 = 7
| LV4 = 8
| LV5 =
| LV6 =
| OS1 =w
| OS2 =m
| OS3 =l
| OS4 =u
| notes =None
}}

{{ labviewconfigurationkey
| keyname = server.tcp.access
| example =server.tcp.access="192.168.0.255","192.168.0.12"
| datatype =s
| description =TCP/IP Access List
| permitted_values =Comma-separated list of IP adresses - each IP address must be enclosed in "quotation" marks
| default =Empty
| LV1 = 5
| LV2 = 6
| LV3 = 7
| LV4 = 8
| LV5 =
| LV6 =
| OS1 =w
| OS2 =m
| OS3 =l
| OS4 =u
| notes =None
}}

{{ labviewconfigurationkey
| keyname = server.tcp.enabled
| example =server.tcp.enabled=TRUE
| datatype =b
| description =Enable the local LabVIEW TCP/IP server
| permitted_values =TRUE or FALSE
| default =FALSE
| LV1 = 5
| LV2 = 6
| LV3 = 7
| LV4 = 8
| LV5 =
| LV6 =
| OS1 =w
| OS2 =m
| OS3 =l
| OS4 =u
| notes =None
}}

{{ labviewconfigurationkey
| keyname = server.tcp.paranoid
| example =server.tcp.paranoid=FALSE
| datatype =b
| description =Strict Checking
| permitted_values =TRUE or FALSE
| default =TRUE
| LV1 = 5
| LV2 = 6
| LV3 = 7
| LV4 = 8
| LV5 =
| LV6 =
| OS1 =w
| OS2 =m
| OS3 =l
| OS4 =u
| notes =None
}}

{{ labviewconfigurationkey
| keyname = server.tcp.port
| example =server.tcp.port=3360
| datatype =i
| description =TCP/IP server port number
| permitted_values =1 to Unknown
| default =3363
| LV1 = 5
| LV2 = 6
| LV3 = 7
| LV4 = 8
| LV5 =
| LV6 =
| OS1 =w
| OS2 =m
| OS3 =l
| OS4 =u
| notes =None
}}

{{ labviewconfigurationkey
| keyname = server.vi.access
| example =server.vi.access="+*"
| datatype =s
| description =Exported VIs list
| permitted_values =Unknown
| default ="+*"
| LV1 = 5
| LV2 = 6
| LV3 = 7
| LV4 = 8
| LV5 =
| LV6 =
| OS1 =w
| OS2 =m
| OS3 =l
| OS4 =u
| notes =None
}}

{{ labviewconfigurationkey
| keyname = server.vi.callsEnabled
| example =server.vi.callsEnabled=FALSE
| datatype =b
| description =Allow VI Calls
| permitted_values =TRUE or FALSE
| default =TRUE
| LV1 = 5
| LV2 = 6
| LV3 = 7
| LV4 = 8
| LV5 =
| LV6 =
| OS1 =w
| OS2 =m
| OS3 =l
| OS4 =u
| notes =None
}}

{{ labviewconfigurationkey
| keyname = server.vi.propertiesEnabled
| example =server.vi.propertiesEnabled=FALSE
| datatype =b
| description =Allow VI Methods and Properties
| permitted_values =TRUE or FALSE
| default =TRUE
| LV1 = 5
| LV2 = 6
| LV3 = 7
| LV4 = 8
| LV5 =
| LV6 =
| OS1 =w
| OS2 =m
| OS3 =l
| OS4 =u
| notes =None
}}

{{ labviewconfigurationkey
| keyname = server.viscripting.showScriptingOperationsInEditor
| example =server.viscripting.showScriptingOperationsInEditor=TRUE
| datatype =b
| description =Show VI Scripting functions, properties and methods
| permitted_values =TRUE or FALSE
| default =FALSE
| LV1 = 2009+
| LV2 =
| LV3 =
| LV4 =
| LV5 =
| LV6 =
| OS1 =w
| OS2 =m
| OS3 =l
| OS4 =u
| notes =None
}}

{{ labviewconfigurationkey
| keyname = tcpServer.log
| example =tcpServer.log=TRUE
| datatype =b
| description =Enable TCP/IP server logging
| permitted_values =TRUE or FALSE
| default =FALSE
| LV1 = 5
| LV2 = 6
| LV3 = 7
| LV4 = 8
| LV5 =
| LV6 =
| OS1 =w
| OS2 =m
| OS3 =l
| OS4 =u
| notes =None
}}

{{ labviewconfigurationkey
| keyname = tcpServer.logDetails
| example =tcpServer.logDetails=
| datatype =Unknown
| description =Unknown
| permitted_values =
| default =
| LV1 = 5
| LV2 = 6
| LV3 = 7
| LV4 = 8
| LV5 =
| LV6 =
| OS1 =w
| OS2 =m
| OS3 =l
| OS4 =u
| notes =None
}}

{{ labviewconfigurationkey
| keyname = tcpServer.logPath
| example =tcpServer.logPath=FALSE
| datatype =p
| description =TCP/IP server logging filepath
| permitted_values =Any filepath
| default =Empty
| LV1 = 5
| LV2 = 6
| LV3 = 7
| LV4 = 8
| LV5 =
| LV6 =
| OS1 =w
| OS2 =m
| OS3 =l
| OS4 =u
| notes =None
}}

 

[[Category:Configuration File|VI server]]

Symbolic path

2022-09-05T20:02:52Z

Jim kring: /* Resolving Symbolic Paths Programmatically */

When files are located beneath certain special folders, callers that link to these files will link to them using a ''symbolic path'', rather than an absolute or relative path. The ''symbolic path'' will be relative to the special folder. The following table lists these special folders and their ''symbolic path'':

{| class="wikitable"
|-
! symbolic path
! description
! actual path
|-
| <userlib>
| User Libraries
| <LabVIEW>\user.lib
|-
| <vilib>
| NI Libraries and Addons
| <LabVIEW>\vi.lib
|-
| <instrlib>
| Instrument Drivers
| <LabVIEW>\instr.lib
|-
| <helpdir>
| Help Files
| <LabVIEW>\help
|-
| <osdatadir>
| Default file directory of the operating system
| (OS Dependent)
|-
| <menu>
| Palette Menus
| <LabVIEW>\menus
|-
| <resource>
| Various VIs and resources used by LabVIEW and plugins, and generally not intended to be called by end-user applications.
''Note this first appeared in LabVIEW 2012 (based on [https://forums.ni.com/t5/Developer-Center-Discussions/Make-the-LabVIEW-quot-resource-quot-folder-a-symbolic-path/td-p/3438293?profile.language=en this idea exchange post]) and prior to that it was not a symbolic path.''
| <LabVIEW>\resource
|}

Note that some of these can have the actual path changed by changing the settings in '''Tools>>Options'''. The whole point of the symbolic path is to indicate "load from whatever location this path is currently defined to be."

For example, if you have a VI located in the following location:

<LabVIEW>\user.lib\_OpenG.lib\array\array.llb\Conditional Auto-Indexing Tunnel__ogtk.vi

Callers will link to this VI using the following ''symbolic path'':

<userlib>\_OpenG.lib\array\array.llb\Conditional Auto-Indexing Tunnel__ogtk.vi

''symbolic path'' are not generally encountered. They are used mostly under the hood of LabVIEW, for example, when using the Application '''Linker:Read Info From File''' and '''Linker:Write Info To File''' methods.

== Resolving Symbolic Paths Programmatically==

You can call the private '''Resolve Symbolic Path''' method to convert a Symbolic Path to an absolute path, as shown in the screenshot, below.

[[Image:ResolveSymbolicPath.png]]

Note: That the 'Resolve Symbolic Path' Application Method is only visible if you have set [[LabVIEW_configuration_file/Miscellaneous#SuperSecretPrivateSpecialStuff|SuperSecretPrivateSpecialStuff]]=True in your [[LabVIEW_configuration_file|LabVIEW configuration file]].

== Auto update of symbolic paths ==
If you have a VI linked to another VI inside a symbolic path LabVIEW will automatically store the path symbolically. Here's the following use case:

Suppose you want to build a LabVIEW tool that resides under the Tools menu but is also accessible via the user.lib palette. What you can do is create a set-up upon built like this:

*[Built]
**[Tools]
***Menu VI
**[user.lib]
***Actual VI

When you copy the contents of ''Built'' to the LabVIEW folder the ''Menu VI'' will have a relative path like ''..\user.lib\Actual VI'' when you do a resave of the ''Menu VI'' the path will be changed to an absolute path ''<userlib>\Actual VI''. Now you can move the ''Menu VI'' around without breaking it.

== When Using Modules (FPGA, RT, etc) ==
A symbolic path may resolve to different actual files on disk depending upon which target the VI is loaded into. So a VI that is written to use <vilib>\a.vi may use <labview>\vi.lib\a.vi when loaded for the desktop target, but may use <labview>\vi.lib\fpga\a.vi when loaded for the FPGA target.

== External Links ==
* [http://zone.ni.com/reference/en-XX/help/371361B-01/lvhowto/using_symbolic_paths/ LabVIEW Help: Using Symbolic Paths]

[[Category:File IO]]
[[Category:Development Environment]]

NI Connect 2022

2022-06-05T00:55:11Z

Jim kring: Added presenters to "Best Practices for Distributing IP" session

{{prevnext|NI Connect 2021|Events|}}

[[File:NI Connect Austin 2022.png|900px|frameless|center]]

{{TOCright}}
== Links ==
*[https://www.ni.com/en-us/events/niconnect/austin.html NI Connect Website]

== Agenda ==
=== Automotive ===
{| class="wikitable"
|-
!Date
!Start Time
!End Time
!Session
!Abstract
!Recording
|-
|Tuesday, May 24
|11:00 AM
|11:45 AM
|[https://www.ni.com/content/dam/web/pdfs/niconnect/2022/austin/NI_Connect_2022_Testing_EV_Batteries_This_Is_What_Top_Performance_Looks_Like.pdf Testing EV Batteries? This Is What Top Performance Looks Like.]
|Join us for a demonstration of the new Battery Test System Software that enables you to test EV batteries like a top performer, with uncompromising quality and safety.
|
|-
|Tuesday, May 24
|2:30 PM
|3:15 PM
|[https://www.ni.com/content/dam/web/pdfs/niconnect/2022/austin/NI_Connect_2022_Create_Seamless_Design_to_Test_Inverter_Validation_Workflows.pdf Create Seamless Design-to-Test Inverter Validation Workflows]
|Join us in this session to learn how virtualization and NI’s model-based development approach can improve how design and validation teams perform in the SIL/MIL/HIL development cycle through an optimized user experience.
|
|-
|Tuesday, May 24
|3:30 PM
|4:15 PM
|[https://www.ni.com/content/dam/web/pdfs/niconnect/2022/austin/NI_Connect_2022_Key_Considerations_for_EV_Battery_Testing_and_Validation.pdf Key Considerations for EV Battery Testing and Validation]
|Join NH Research’s session to learn about key considerations for testing EV batteries to ensure product performance, safety, reliability, and reduced time to market. Get new insights on how to simplify and accelerate your test approach with flexible and open solutions.
|
|-
|Wednesday, May 25
|9:00 AM
|9:45 AM
|[https://www.ni.com/content/dam/web/pdfs/niconnect/2022/austin/NI_Connect_2022_Mastering_Data_Record_for_ADAS_and_Autonomous_Driving_Together.pdf Mastering Data Record for ADAS and AD Together]
|In this session, you will learn how NI and its strategic partners Seagate Technology and Konrad Technologies have come together to deliver and continue to evolve a best-in-class solution for ADAS and AD data logging, by leveraging the expertise, technology, and services that only an ecosystem of subject matter experts can provide.
|
|-
|Wednesday, May 25
|10:15 AM
|11:00 AM
|[https://www.ni.com/content/dam/web/pdfs/niconnect/2022/austin/NI_Connect_2022_Mastering_Data_Replay_and_HIL_for_ADAS_and_Autonomous_Driving_Together.pdf Mastering Data Replay and HIL for ADAS and AD Together] 
|In this session, you will learn how NI's approach to intelligent data replay and HIL can overcome test challenges by leveraging the expertise, technology, and services that only a subject matter expert can provide.
|
|-
|Wednesday, May 25
|11:15 AM
|12:00 PM
|[https://www.ni.com/content/dam/web/pdfs/niconnect/2022/austin/NI_Connect_2022_Mastering_Testing_and_Calibration_on_a_Virtual_Environment_for_ADAS_and_AD_Together.pdf Mastering Testing and Calibration on a Virtual Environment for ADAS and AD Together]
|In this session, the systems test engineering team from Continental shows how they implemented a virtual environment with monoDrive to test realistic scenarios as well as allowed calibration activities to be executed independently of external factors and in the early stages of the project to improve efficiency, quality, and planning.
|
|}

=== Semiconductor & Electronics ===
{| class="wikitable"
|-
!Date
!Start Time
!End Time
!Session
!Abstract
!Recording
|-
|Tuesday, May 24
|11:00 AM
|11:45 AM
|[https://www.ni.com/content/dam/web/pdfs/niconnect/2022/austin/NI_Connect_2022_Accelerating_the_Semiconductor_Validation_Workflow_through_Software.pdf Accelerating the Semiconductor Validation Workflow through Software]
|Adapt to change effectively by modernizing validation workflows.
|
|-
|Tuesday, May 24
|2:30 PM
|3:15 PM
|[https://www.ni.com/content/dam/web/pdfs/niconnect/2022/austin/NI_Connect_2022_Enabling_Innovation_and_Productivity_across_the_Product_Development_Cycle_with_Data.pdf Enabling Innovation and Productivity across the Product Development Cycle with Data]
|Unlocking the power of data for smarter product life-cycle management
|
|-
|Tuesday, May 24
|3:30 PM
|4:15 PM
|[https://www.ni.com/content/dam/web/pdfs/niconnect/2022/austin/NI_Connect_2022_Effortless_Digital_Interface_Compliance_Testing.pdf Effortless Digital Interface Compliance Testing]
|Protocol validation with NI’s new measurement framework
|
|-
|Wednesday, May 25
|9:00 AM
|9:45 AM
|[https://www.ni.com/content/dam/web/pdfs/niconnect/2022/austin/NI_Connect_2022_OpenRF_A_Vision_to_Advancing_5G_Adoption.pdf OpenRF: A Vision to Advancing 5G Adoption]
|OpenRF experts discuss how open platforms can help OEMs lower costs, increase performance, reduce time-to-market, and optimize inventory.
|
|-
|Wednesday, May 25
|10:15 AM
|11:00 AM
|[https://www.ni.com/content/dam/web/pdfs/niconnect/2022/austin/NI_Connect_2022_Beyond_5G.pdf Beyond 5G]
|A look into 5G advanced developments and 6G research
|
|-
|Wednesday, May 25
|11:15 AM
|12:00 PM
|[https://www.ni.com/content/dam/web/pdfs/niconnect/2022/austin/NI_Connect_2022_Switching_to_a_Better_Solution_for%20CV_and_IV_Measurements.pdf Switching to A Better Solution for CV/IV Measurements]
|Improving CV/IC measurement accuracy while optimizing lab space
|
|}

=== Aerospace & Defense ===
{| class="wikitable"
|-
!Date
!Start Time
!End Time
!Session
!Abstract
!Recording
|-
|Tuesday, May 24
|11:00 AM
|11:45 AM
|[https://www.ni.com/content/dam/web/pdfs/niconnect/2022/austin/NI_Connect_2022_Failure_is_Not_an_Option_Maximize_Pace_and_Performance_with_NI_Solutions_for_Space.pdf Failure is Not an Option: Maximize Pace and Performance with NI Solutions for Space]
|Learn how NI can help your team accelerate test deployment while meeting increasing performance requirements with solutions for component and system level test, hardware in the loop test, bus and protocol level test, RF and communications systems test, EO/IR and payload test, structural test, launch operations, engine test and more.
|
|-
|Tuesday, May 24
|2:30 PM
|3:15 PM
|[https://www.ni.com/content/dam/web/pdfs/niconnect/2022/austin/NI_Connect_2022_From_Tip_to_Tail_Solving_Defense_Aircraft_Test_Challenges.pdf From Tip to Tail: Solving Defense Aircraft Test Challenges]
|Learn about the wide variety of solutions from NI, and how to overcome the challenges that come with testing the many subsystems within defense aircraft - from the lab to the depot and everything in between.
|
|-
|Tuesday, May 24
|3:30 PM
|4:15 PM
|[https://www.ni.com/content/dam/web/pdfs/niconnect/2022/austin/NI_Connect_2022_Solving_the_Latest_Challenges_for_Testing_Electronically_Scanned_Array_Systems.pdf Solving the Latest Challenges for Testing Electronically Scanned Array Systems]
|Modern mission systems such as radar, electronic warfare, and satellite payloads are incorporating the latest electronically scanned arrays. To overcome these challenges, a scalable and nimble test solution is required to handle and validate a multitude of scenarios, ranging from parametric test of components to validation of systems while being able to correlate the test data throughout the product lifecycle.
|
|-
|Wednesday, May 25
|9:00 AM
|9:45 AM
|[https://www.ni.com/content/dam/web/pdfs/niconnect/2022/austin/NI_Connect_2022_Digital_Avionics_Interface_Selection.pdf Digital Avionics Interface Selection - Simplifying a Not So Simple Choice]
|Learn how you can simplify your digital avionics interface selection while reducing maintenance costs and improving system sustainability.
|
|-
|Wednesday, May 25
|10:15 AM
|11:00 AM
|[https://www.ni.com/content/dam/web/pdfs/niconnect/2022/austin/NI_Connect_2022_Rapidly_Prototyping_Cognitive_RF_Systems.pdf Rapidly Prototyping Cognitive RF Systems]
|Learn how you can use a new SDR-based architecture from NI to accelerate the development of novel capabilities for radar, electronic warfare, and communications.
|
|-
|Wednesday, May 25
|11:15 AM
|12:00 PM
|[https://www.ni.com/content/dam/web/pdfs/niconnect/2022/austin/NI_Connect_2022_Testing_Propulsion_Systems_Across_the_Aerospace_Industry.pdf Testing Propulsion Systems Across the Aerospace Industry]
|Improving CV/IC measurement accuracy while optimizing lab space
|
|}

=== Software & Technologies ===
==== Data and Insights Track ====
{| class="wikitable"
|-
!Date
!Start Time
!End Time
!Session
!Abstract
!Recording
|-
|Tuesday, May 24
|11:00 AM
|11:45 AM
|[https://www.ni.com/content/dam/web/pdfs/niconnect/2022/austin/NI_Connect_2022_A_Data_centric_Approach_to_the_Product_Lifecycle_Performance.pdf NI Lifecycle Solutions: A Data-centric Approach to Product Life Cycle Performance]
|Learn how we define ourselves within the digital transformation space with solutions and tools that empower a data-centric approach to the product lifecycle.
|View: YouTube
Files: UHD, FHD, HD
|-
|Tuesday, May 24
|2:30 PM
|3:15 PM
|[https://www.ni.com/content/dam/web/pdfs/niconnect/2022/austin/NI_Connect_2022_Turning_Data_into_Actions_with_NI_Lifecycle_Solutions.pdf Turning Data into Actions with NI Lifecycle Solutions]
|A more granular and detailed look at how NI Lifecycle Solutions impact operational process through the Collect, Detect and Act stages of the framework.
|
|-
|Tuesday, May 24
|3:30 PM
|4:15 PM
|[https://www.ni.com/content/dam/web/pdfs/niconnect/2022/austin/NI_Connect_2022_NI_in_Action_The_Key_to_Achieving_Your_KPIs.pdf NI in ACTION: The Key to Achieving Your KPIs]
|Actions across any Digital Transformation effort create the tangible benefits organizations gain from their investment, and at NI, these actions are the focus for any NI Lifecycle Solution we provide to our customers.
|-
|Wednesday, May 25
|9:00 AM
|9:45 AM
|[https://www.ni.com/content/dam/web/pdfs/niconnect/2022/austin/NI_Connect_2022_Making_Actions_Smarter_with_AI_ML.pdf Making Actions Smarter with AI/ML]
|Machine learning (ML) and artificial intelligence (AI) are a new frontier in the analytics industry. NI Lifecycle Solutions provide the ideal system to enable long term adoption of ML and AI capabilities.
|View: YouTube
Files: UHD, FHD, HD
|-
|Wednesday, May 25
|10:15 AM
|11:00 AM
|[https://www.ni.com/content/dam/web/pdfs/niconnect/2022/austin/NI_Connect_2022_Maximizing_Test_Value_with_Centralized_Orchestration.pdf Maximizing Test Value with Centralized Orchestration]
|A centralized look at test systems and the data they create opens new possibilities for efficiency across validation labs and production test footprints.
|
|-
|Wednesday, May 25
|11:15 AM
|12:00 PM
|[https://www.ni.com/content/dam/web/pdfs/niconnect/2022/austin/NI_Connect_2022_Bringing_It_All_Together_with_NI_Manufacturing.pdf Bringing It All Together with NI Manufacturing]
|Learn how the NI Manufacturing footprint is eagerly deploying our homegrown NI Lifecycle Solutions as we too, embark on our own digital transformation journey.
|View: YouTube
Files: UHD, FHD, HD
|}

==== Products and Technology Track ====
{| class="wikitable"
|-
!Date
!Start Time
!End Time
!Session
!Abstract
!Recording
|-
|Tuesday, May 24
|11:00 AM
|11:45 AM
|[https://www.ni.com/content/dam/web/pdfs/niconnect/2022/austin/NI_Connect_2022_What_is_New_in_LabVIEW.pdf What's New in LabVIEW?]
|Experience the latest features LabVIEW 2022 has to offer.
|View: YouTube
Files: UHD, FHD, HD
|-
|Tuesday, May 24
|2:30 PM
|3:15 PM
|[https://www.ni.com/content/dam/web/pdfs/niconnect/2022/austin/NI_Connect_2022_NI_TestScale_New_Instrumentation_Platform_for_Electronics_Functional_Test.pdf Product Launch: New Instrumentation Platform for Electronics Functional Test]
|See some of the new options for doing low-coverage/high-volume applications.
|View: YouTube
Files: UHD, FHD, HD
|-
|Tuesday, May 24
|3:30 PM
|4:15 PM
|[https://www.ni.com/content/dam/web/pdfs/niconnect/2022/austin/NI_Connect_2022_Product_Launch_New_Solution_for_Condition_Monitoring_and_Predictive_Maintenance_of_Test_Assets_and_Test_Facilities.pdf Product Launch: New Solution for Condition Monitoring and Predictive Maintenance of Test Assets and Test Facilities]
|Get to know some of the new advances in technology for predictive maintenance.
|
|-
|Wednesday, May 25
|9:00 AM
|9:45 AM
|[https://www.ni.com/content/dam/web/pdfs/niconnect/2022/austin/NI_Connect_2022_Why_You_Need_Bidirectional_DC_Supplies_with_Energy_Recovery_No_Video.pdf Why You Need Bidirectional DC Supplies with Energy Recovery]
|Increasing technology and renewable energy demands are driving innovation in test equipment manufacturers to produce programmable power sources and electronic loads that can satisfy the needs for higher power, faster response, and the capability to simulate complex operating scenarios while doing all of this with higher efficiency. Enter bidirectional, programmable DC power supplies with integrated regenerative electronic loads.
|
|-
|Wednesday, May 25
|10:15 AM
|11:00 AM
|[https://www.ni.com/content/dam/web/pdfs/niconnect/2022/austin/NI_Connect_2022_How_to_Build_a_Web_UI_for_Your_LabVIEW_Based_Test_System.pdf How to Build a Web UI for Your LabVIEW-Based Test System]
|Learn about NI’s new G Web Development Software.
|
|-
|Wednesday, May 25
|11:15 AM
|12:00 PM
|[https://www.ni.com/content/dam/web/pdfs/niconnect/2022/austin/NI_Connect_2022_Sweep_like_a_Pro_Maximize_the_Functionality_of_Built_in_Sweeping_in_TestStand.pdf Sweep like a Pro-Maximize the Functionality of Built in Sweeping in TestStand]
|Learn how to streamline the characterization and validation of devices under a variety of input conditions. Get an in-depth tour of the sweeping capabilities added to TestStand including new sweep strategies, nested loop control, automatic variables, and static and dynamic modes.
|
|}

==== Test Development and Management Track ====
{| class="wikitable"
|-
!Date
!Start Time
!End Time
!Session
!Abstract
!Recording
|-
|Tuesday, May 24
|11:00 AM
|11:45 AM
|[https://www.ni.com/content/dam/web/pdfs/niconnect/2022/austin/NI_Connect_2022_Validation_and_Time_To_Insight.pdf Validation and “Time to Insight”]
|In this session we’ll explore a real world case study from NI’s Professional Services team about how focusing on “time to insight” can improve your business performance.
|
|-
|Tuesday, May 24
|2:30 PM
|3:15 PM
|Panel: Evangelizing Test Beyond Your Team
|A discussion on how to help your organization see the real value of test
|View: FHD
Files: UHD, FHD, HD
|-
|Tuesday, May 24
|3:30 PM
|4:15 PM
|Panel: Test Standardization - Holistic Approach to Process, Systems and Data
|Join the conversation with our panel of experts as we evolve the meaning of standardization to include a more holistic vision of your test strategy and organization.
|View: FHD
Files: UHD, FHD, HD
|-
|Wednesday, May 25
|9:00 AM
|9:45 AM
|[https://www.ni.com/content/dam/web/pdfs/niconnect/2022/austin/NI_Connect_2022_Lessons_Learned_Building_a_New_Design_Methodology_for_a_Large_Channel_Count_Application.pdf Lessons Learned Building a New Design Methodology for a Large Channel Count Application]
|Hear a case study that provides key insights on how to meet technical (eg. TSN Synchronization), as well as architectural (redundancy, usability, deployment,) and process (benchmarking, documentation) challenges.
|View: FHD
Files: UHD, FHD, HD
|-
|Wednesday, May 25
|10:15 AM
|11:00 AM
|[https://www.ni.com/content/dam/web/pdfs/niconnect/2022/austin/NI_Connect_2022_Best_Practices_for_Building_a_Rack_Based_Test_System.pdf Best Practices for Building a Rack-Based Test System]
|In this session, we discuss what you should consider when building a rack-based test system.
|View: FHD
Files: UHD, FHD, HD
|-
|Wednesday, May 25
|11:15 AM
|12:00 PM
|[https://www.ni.com/content/dam/web/pdfs/niconnect/2022/austin/NI_Connect_2022_From_Request_To_Success_%20Lets_Accelerate_Your_Validation_Workflow.pdf From Request To Success! Lets Accelerate Your Validation Workflow]
|Join the NI Product R&D team as they step through a complete validation workflow example and give their insights into the right tools (including Python) to use at every step.
|
|}

==== Advanced Software Development and Deployment Track ====
{| class="wikitable"
|-
!Date
!Start Time
!End Time
!Session
!Abstract
!Recording
|-
|Tuesday, May 24
|11:00 AM
|11:45 AM
|[https://www.ni.com/content/dam/web/pdfs/niconnect/2022/austin/NI_Connect_2022_Simplifying_TestStand_Step_Settings_Panels_with_AutoProps_%20Session_Summary.pdf Simplifying TestStand Step Settings Panels with AutoProps]
|Learn about how you can use AutoProps, an undocumented feature in TestStand, to streamline custom step settings panel implementation to better enable rapid prototyping and even provide a production solution for simpler applications.
|
|-
|Tuesday, May 24
|2:30 PM
|3:15 PM
|[https://www.ni.com/content/dam/web/pdfs/niconnect/2022/austin/NI_Connect_2022_Maximizing_Your_Test_Operations_with_SystemLink.pdf Maximizing Your Test Operations with SystemLink™]
|Take a deep dive into SystemLink System and Asset Management.
|
|-
|Tuesday, May 24
|3:30 PM
|4:15 PM
|[https://www.ni.com/content/dam/web/pdfs/niconnect/2022/austin/NI_Connect_2022_Best_Practices_for_Distributing_IP.pdf Best Practices for Distributing IP]
Presenters: Niki Budgell, Scott Richardson, and [[Jim_Kring_(LabVIEW_Champion)|Jim Kring]]
|Come hear about some of the best practices your organization use to better distribute your IP.
|View: YouTube
Files: UHD, FHD, HD
|-
|Wednesday, May 25
|9:00 AM
|9:45 AM
|[https://www.ni.com/content/dam/web/pdfs/niconnect/2022/austin/NI_Connect_2022_Connecting_To_Remote_Test_Systems.pdf Connecting to Remote Test Systems]
|Come discover how NI enables remote access by leveraging gRPC from any language and how you can develop custom remote APIS using LabVIEW’s gRPC support.
|
|-
|Wednesday, May 25
|10:15 AM
|11:00 AM
|[https://www.ni.com/content/dam/web/pdfs/niconnect/2022/austin/NI_Connect_2022_Extend_InstrumentStudio_and_TestStand_with_Measurement_SDK.pdf InstrumentStudio Plug-In Dev Kit]
|Learn how to use the Measurement Framework Plug-In Development Kit to create interactive measurements that can be used through automation.
|View: YouTube
Files: UHD, FHD, HD
|-
|Wednesday, May 25
|11:15 AM
|12:00 PM
|[https://www.ni.com/content/dam/web/pdfs/niconnect/2022/austin/NI_Connect_2022_LabVIEW_Interfaces_Things_Better_Left_Unstated.pdf LabVIEW Interfaces: Things Better Left Unstated]
|Learn how to start using LabVIEW interfaces in your software architectures, which changes the design and testing of object-oriented software.
|View: YouTube
Files: UHD, FHD, HD
|}

[[Category:NI Connect]]

Symbolic path

2021-01-23T22:58:33Z

Jim kring: Added the "resource" symbolic path.

When files are located beneath certain special folders, callers that link to these files will link to them using a ''symbolic path'', rather than an absolute or relative path. The ''symbolic path'' will be relative to the special folder. The following table lists these special folders and their ''symbolic path'':

{| class="wikitable"
|-
! symbolic path
! description
! actual path
|-
| <userlib>
| User Libraries
| <LabVIEW>\user.lib
|-
| <vilib>
| NI Libraries and Addons
| <LabVIEW>\vi.lib
|-
| <instrlib>
| Instrument Drivers
| <LabVIEW>\instr.lib
|-
| <help>
| Help Files
| <LabVIEW>\help
|-
| <osdatadir>
| Default file directory of the operating system
| (OS Dependent)
|-
| <menu>
| Palette Menus
| <LabVIEW>\menus
|-
| <resource>
| Various VIs and resources used by LabVIEW and plugins, and generally not intended to be called by end-user applications.
''Note this first appeared in LabVIEW 2012 (based on [https://forums.ni.com/t5/Developer-Center-Discussions/Make-the-LabVIEW-quot-resource-quot-folder-a-symbolic-path/td-p/3438293?profile.language=en this idea exchange post]) and prior to that it was not a symbolic path.''
| <LabVIEW>\resource
|}

Note that some of these can have the actual path changed by changing the settings in '''Tools>>Options'''. The whole point of the symbolic path is to indicate "load from whatever location this path is currently defined to be."

For example, if you have a VI located in the following location:

<LabVIEW>\user.lib\_OpenG.lib\array\array.llb\Conditional Auto-Indexing Tunnel__ogtk.vi

Callers will link to this VI using the following ''symbolic path'':

<userlib>\_OpenG.lib\array\array.llb\Conditional Auto-Indexing Tunnel__ogtk.vi

''symbolic path'' are not generally encountered. They are used mostly under the hood of LabVIEW, for example, when using the Application '''Linker:Read Info From File''' and '''Linker:Write Info To File''' methods.

== Resolving Symbolic Paths Programmatically==

You can call the private '''Resolve Symbolic Path''' method to convert a Symbolic Path to an absolute path, as shown in the screenshot, below.

[[Image:ResolveSymbolicPath.png]]

== Auto update of symbolic paths ==
If you have a VI linked to another VI inside a symbolic path LabVIEW will automatically store the path symbolically. Here's the following use case:

Suppose you want to build a LabVIEW tool that resides under the Tools menu but is also accessible via the user.lib palette. What you can do is create a set-up upon built like this:

*[Built]
**[Tools]
***Menu VI
**[user.lib]
***Actual VI

When you copy the contents of ''Built'' to the LabVIEW folder the ''Menu VI'' will have a relative path like ''..\user.lib\Actual VI'' when you do a resave of the ''Menu VI'' the path will be changed to an absolute path ''<userlib>\Actual VI''. Now you can move the ''Menu VI'' around without breaking it.

== When Using Modules (FPGA, RT, etc) ==
A symbolic path may resolve to different actual files on disk depending upon which target the VI is loaded into. So a VI that is written to use <vilib>\a.vi may use <labview>\vi.lib\a.vi when loaded for the desktop target, but may use <labview>\vi.lib\fpga\a.vi when loaded for the FPGA target.

== External Links ==
* [http://zone.ni.com/reference/en-XX/help/371361B-01/lvhowto/using_symbolic_paths/ LabVIEW Help: Using Symbolic Paths]

[[Category:File IO]]
[[Category:Development Environment]]

GLA Summit 2020/Managing Code Dependencies and Virtual Environments in LabVIEW

2020-11-14T01:02:29Z

Jim kring:

'''Managing Code Dependencies and Virtual Environments in LabVIEW''' by [[Jim Kring (LabVIEW Champion)|Jim Kring]]

<div style="text-align:center;"><youtube width="800" height="600">UGn7HVydt5I</youtube></div>

== Presentation Links ==
* [https://youtu.be/UGn7HVydt5I Link to video on YouTube]

==See Also==
* [[VI Package Manager]]

==External Links==
* [https://www.vipm.io vipm.io]

[[File:Gla-mascot@0.5x.png|thumb|Stealthcat]]

File:Gla-mascot@0.5x.png

2020-11-14T01:02:02Z

Jim kring:

Gla-mascot@0.5x

GLA Summit 2020/Managing Code Dependencies and Virtual Environments in LabVIEW

2020-11-14T00:57:09Z

Jim kring: Created page with "'''Managing Code Dependencies and Virtual Environments in LabVIEW''' by Jim Kring <div style="text-align:center;"><youtube width="800" height..."

VIWeek 2020

2020-05-21T16:29:50Z

Jim kring: /* Saturday, 23rd May 2020 */

[[Events]] - VIWeek
[[File:VIWeek Logo, Title, and Tagline.png|VIWeek|700px|center|link=https://forums.ni.com/t5/Random-Ramblings-on-LabVIEW/VIWeek-Making-Trouble-Again/ba-p/4044162]]

{{TOCright}}
VIWeek is a free community-led virtual event that was first held in 2020 at the time [[NIWeek]] would have taken place. The content focuses on both LabVIEW and good software engineering practices. All the sessions are hosted individually by the presenters themselves.

{| class="wikitable" style="width:100%;"
|- style="text-align:center;"
!'''Visit the VIWeek Portal at [https://bit.ly/viweek https://bit.ly/viweek] for the full agenda.'''

Discussions during presentations happen here: https://discord.gg/a4WA8Bm
|}

== History ==
[https://www.dsh-workshops.com/ DSH Workshops] had planned to hold a number of workshops at and around NIWeek 2020. Due to the COVID-19 situation, and seeing as [[NI]] had also cancelled all live, in-person events, the workshops had to be cancelled, too. In order to entertain the community and keep in touch with their friends, the team (Fabiola De la Cueva, Steve Watts, Joerg Hampel and Brian Powell) decided to hold a series of live, virtual sessions during the week formerly know as NIWeek.

Conversation about these sessions led other LabVIEW Champions and Community leaders to throw around the idea of a new community-led virtual event. When Steve Watts went on to [https://forums.ni.com/t5/Random-Ramblings-on-LabVIEW/VIWeek-Making-Trouble-Again/ba-p/4044162 advertise this idea on his blog], '''VI Week''' was born. There are many community members to thank, see the [[#Special Thanks]] section below.
=== Timeline ===
The speed and simplicity of how this event came together is a testament to the LabVIEW community. It took only about a week to get from the first thoughts to a finalised agenda and an understanding of how to execute the whole event:

* Mid-April: DSH Workshops decides to hold a series of virtual sessions.
* April 30: DSH Workshops [https://www.linkedin.com/feed/update/urn:li:activity:6661585876386099200 publishes their events] under the '''#Virtual NIWeek''' hashtag.
* May 2: Chris Stryker coins the term '''#VIWeek''', based on the original ''#Virtual NIWeek''.
* May 3: Steve Watts publishes his blog post.
* May 7: Enough presentations to fill all 5 originally planned days of NIWeek.<ref>''[https://www.linkedin.com/posts/joerghampel_labview-community-viweek-activity-6664289248297926656-Q0pm LinkedIn Post]'', [[Joerg_Hampel_(LabVIEW_Champion)|Joerg Hampel]], May 7th 2020</ref>

By May 17, the first day of the event, the community has not only come up with now 6 days worth of content, but also agreed on both a plan and tools for organising, advertising, holding, streaming and recording the presentations.
===[https://youtu.be/ftBU5-L3MLQ Introduction to VIWeek from] [[Chris Cilino (LabVIEW Champion)|Chris Cilino]]===
<center>:<youtube>ftBU5-L3MLQ</youtube></center>

== Sunday, 17th May 2020 ==
*'''[[VIWeek 2020/GCentral: State of the Union and Rolling Up Your Sleeves|GCentral: State of the Union and Rolling Up Your Sleeves]]''' by Chris Cilino and Danielle Jobe
*:''GCentral is a non profit organization founded in late 2019. The vision: a LabVIEW community empowered to make the best version of itself. The mission: reduce/remove barriers to collaboration. In this presentation, we'll introduce you to GCentral and give a progress update. And we'll show you how we can all work together to make GCentral a reality.''
*'''[[VIWeek 2020/LabVIEW FPGA for high throughput applications|LabVIEW FPGA for high throughput applications]]''' by Terry Stratoudakis
*'''[[VIWeek 2020/Functional programming inspired object-oriented template in LabVIEW + SOLID|Functional programming inspired object-oriented template in LabVIEW + SOLID]]''' by Piotr Kruczkowski ([https://www.linkedin.com/pulse/functional-programming-inspired-object-oriented-piotr-kruczkowski/ LinkedIn Article])

== Monday, 18th May 2020 ==
*'''[[DSH_Workshops#DSH_VIWeek_Pragmatic_SW_Engineering|DSH #VIWeek Pragmatic SW Engineering]]''' by DSH Gang: Fabiola De la Cueva, Steve Watts, Joerg Hampel, & Brian Powell
*:''Join us and fight the NIWeek blues. In this one-hour event, we (the whole DSH gang: Fab, Steve, Joerg and Brian) will be: - talking about who we are and what we do - asking you about your needs and pain points - answering any questions you might have''
*'''[[VIWeek 2020/Philosophy of Coding - How to be a CraftsPerson|Philosophy of Coding - How to be a CraftsPerson]]''' by Sam Taggart
*:''A discussion of how what we value and the way we think about the process of developing software affects the end result. No LabVIEW code, just a high level discussion of software engineering. I've got a short presentation on our values at SAS and how we approach software development. I'll give that and I'd like to get some feedback. Then I'd like to have a discussion and ask the audience some questions like, what software qualities are important to you? What processes do you think are critical to ensuring software quality? What quality is most important in a junior engineer? How can we do a better job of training junior engineers?''
*'''[[VIWeek 2020/Confessions of a Retired Superhero|Confessions of a Retired Superhero]]''' by Matt Pollock
*:''Crazy projects demand crazy solutions. Crazy solutions create crazy bugs. Come learn from spectacular failures (or near failures) that have threatened to torpedo other projects so yours will be safe from heroics.''

== Tuesday, 19th May 2020 ==
*'''[[VIWeek 2020/Proper way to communicate over serial|Proper way to communicate over serial]]''' by Tim Robinson
*:''Too many users look to the Simple Serial Write Read example in LabVIEW and then struggle to achieve solid, robust communication with their instrument. This is because the example does not properly discuss or handle any of the real-world communication schemes instruments use. At this session, explore these schemes and learn how to handle each case.''
*'''[[VIWeek 2020/Raspberry Pi / LABVIEW CE and Sensors|Raspberry Pi / LABVIEW CE and Sensors]]''' by Sam Sharp
*:''Sam will demonstrate/show how to get started programming the Raspberry Pi using the LabVIEW 2020 Community Edition with a live/practical demo. He'll then expand this to show off his open-source library of drivers for a range of off-the-shelf sensors/hats so you can connect your Raspberry Pi to the physical world.''
*'''[[VIWeek 2020/Linx Toolkit for Intermediate Robotics with Raspberry Pi|Linx Toolkit for Intermediate Robotics with Raspberry Pi]]''' by Derrick Bommarito
*:''I'll be demonstrating how I've used the updated Linx Toolkit for LabVIEW Community Edition to develop remote control and autonomous rovers using the Raspberry Pi along with a handful of sensors. We'll take a look at the high level architecture of the software along with the open source libraries I'm developing that target autonomous robotics projects. We'll also discuss how you can accomplish better performance for more demanding projects by developing custom firmware for arduino clones instead of using the Linx toolkit to interface to microcontrollers.''
*'''[[VIWeek 2020/FPGA Advanced Sessions to create a versatile FPGA-based acquisition system|FPGA Advanced Sessions to create a versatile FPGA-based acquisition system]]''' by Cyril Gambini
*:''Creating an FPGA-based acquisition and control system is challenging if the hardware target changes and the bitfiles to load are completely different from one target to the next. Learn how you can handle completely different FPGA personalities within the same application using LabVIEW FPGA Advanced Session Resources. At this session, explore a VeriStand distributed DAQ system featuring multiple CompactRIO devices configured differently based on the test to perform (analyzing the electrical and mechanical behaviors of alternators) and the test's measurement requirements (currently more than 20 different configurations across four target references).''
*'''[[VIWeek 2020/8 Reasons for encapsulating your next device driver inside a DQMH module|8 Reasons for encapsulating your next device driver inside a DQMH module]]''' by Christopher Farmer
*:''Do you hate it when software throws an awful error if a device is not connected, and it just stops or crashes as a result? Do you have multiple instances of the same device that you need to manage? Do you find that your applications get so cluttered with code specific to managing devices? Do you like to see what a device is up to “under the hood” whilst you run an automated sequence? If you’re facing any of these challenges, then we’re confident this presentation will help you! Using a DQMH module to encapsulate your next device driver will eliminate these issues. Register below to learn how.''

== Wednesday, 20th May 2020 ==
*'''[[DSH_Workshops#DSH_VIWeek_DQMH_5.0_Introduction|DSH DQMH 5.0 Introduction]]''' by DSH - Fabiola De la Cueva & Joerg Hampel
*:''Hear it directly from the horse's mouth! Learn what's new in DQMH 5.0. In this one-hour event, we (Fabiola and Joerg) will walk you through the new features of DQMH 5.0. We'll also give insights into how these features actually help with our daily work.''
*'''[[VIWeek 2020/Efficient Programming in LabVIEW|Efficient Programming in LabVIEW]]''' by Tom McQuillan
*:''In this session, I'm going to showcase Project Templates. After choosing to go down a DQMH route for a project (after being a hardcore Actor Framework user), I realized there were certain aspects of AF I missed. Namely, the ability to reuse messages between modules. In this session, I will showcase a solution to this using Project Templates and how templates could be used for your modular applications. I'll also showcase some scripting tools that were possible using templates.''
*'''[[VIWeek 2020/Using a Message Broker with DQMH Actors for High Speed/Throughput Data logging|Using a Message Broker with DQMH Actors for High Speed/Throughput Data logging]]''' by Chris Roebuck and Becky Linton
*:''Tasked with creating a hardware agnostic, highly configurable, high-throughput data logger for ADAS applications we implemented the Mediator pattern using multiple modified-DQMH actors with a message broker. In this session we will review the requirements, high level design objectives and review the solution and take a deeper dive in to some of the specific technologies used such as malleable VIs, eDVRs and Message Brokers.''
*'''[[VIWeek 2020/Graphical programming beyond G - Use case of LabVIEW integration with Node-RED|Graphical programming beyond G - Use case of LabVIEW integration with Node-RED]]''' by Michal Radziwon
*:''Dataflow programming is not only about G and LabVIEW! There is more and more of other platforms that uses graphical programming and one of them is Node-RED. Node-RED is a programming tool build to ease connecting and automating IoT enabled devices, APIs, and web-services. I will show a use case of integrating LabVIEW with Node-RED using MQTT server - all running on a Raspberry Pi.''

== Thursday, 21st May 2020 ==
*'''[[VIWeek 2020/CEF (configuration editor framework)|CEF (configuration editor framework)]]''' by Sreejith Sreenivasan & Vikas Koujalagi
*:''Configuration files are commonly used to specify application settings and hardware configuration. Manual editing of some of the complex configuration files of hardware systems or applications are often error prone. Shipping a configuration editor can ease the pain but development overheads may outweigh the benefits. Configuration Editor Framework (CEF) from NI Systems Engineering is a versatile framework allowing rapid development of such editors. Development generally take hours instead of days or weeks. This presentation delves in to the features and walks through an example which saves the files in JSON format.''
*'''[[VIWeek 2020/Using the new TLS/SSL functions in LabVIEW 2020|Using the new TLS/SSL functions in LabVIEW 2020]]''' by Sam Sharp
*:''Sam will go through the newly added SSL/TLS functions in LabVIEW 2020 which enables secure TCP/IP communications in LabVIEW. This session should provide enough information to be able to implement secure TCP/IP communications in your own applications and learn why you should. He'll also demonstrate an update to his WebSockets library that enables secure WebSockets (wss://) support - a highly requested feature now possible with LabVIEW 2020.''
*'''[[DSH_Workshops#DSH_VIWeek_Soft_Skills_for_Software_Engineers|DSH Soft Skills for Software Engineers Discussion]]''' by DSH Gang: Fabiola De la Cueva, Steve Watts, Joerg Hampel, & Brian Powell
*:''Bit of a chat''

== Friday, 22nd May 2020 ==
*'''[[VIWeek 2020/VIWeek – Open Your Instruments With A G Interfaces HAL In LV2020 (No Lever Tool Required!!)|#VIWeek – Open Your Instruments With A G Interfaces HAL In LV2020 (No Lever Tool Required!!)]]''' by Jonathan Hird (Jono)
*:''The recent release of LV2020 Community edition has opened up the new capability of “Interfaces” into the LVOOP world. I for one am incredibly excited about what this means specifically for Hardware Abstraction Layers. After some initial trudging through the mud and not quite seeing the value in interfaces for my specific needs for a HAL, I decided to scrap what I had, start from scratch and work logically to put together an example of a “Real World” HAL application. In this session we will briefly cover the Why, What and How of HALs and how interfaces may help along with some sample code which will be uploaded for community use as a good starting point.''
*'''[[VIWeek 2020/The Core Framework|The Core Framework]]''' by Denis Stavila
*:''It's something that I built on top of the Actor Framework and aims at solving several shortcomings that I believe AF has ... plus a lot of tweaks and built-in functionality to make the life of a developer much easier: - Internal broadcast system - Debugging/Monitoring tools - UI structuring and configuration - User Access tools .... etc.''
*'''[[VIWeek 2020/Mock Object Framework|Mock Object Framework]]''' by Sam Taggart
*:''I will present an open source tool for creating Mock objects and show how to use them in tests. It will be an informal kind of code review thing. I might put together a few slides on what Mock Objects are so we are all on the same page. After that I will just start with defining the problem and then how I came up with the solution. We will spend a lot of time just looking at the code.''

== Saturday, 23rd May 2020 ==
*'''[[VIWeek 2020/Fast and Simple Unit Testing with Caraya 1.0|Fast and Simple Unit Testing with Caraya 1.0]]''' by Francois Normandin and Jim Kring ([https://bit.ly/VIWeek-Registration-Caraya-LabVIEW-Unit-Testing Register for this Session])
*:''Almost everyone writes code to test their code. Caraya, a unit test framework for LabVIEW, makes it simple to turn those test VIs into unit tests that can be reused throughout the life of the project. With a focus on ease of use and lightning fast execution time, Caraya allows you to write and run tests without adding much overhead to your development work. Come see how you can create and run a test in under a minute, run all the tests in your project with a simple QuickDrop shortcut, and integrate your tests into a fully-automated build and deploy process. You’ll also learn about advanced features like running tests on real-time targets, creating custom test report formats, and more!''

== Special Thanks ==
* Chris Stryker for the name.
* Steve Watts for the organization.
* Derrick Bommarito for the web portal.
* Michal Radziwon for the Discord chat server.
* [[Quentin "Q" Alldredge (LabVIEW Champion)|Quentin "Q" Alldredge]] for the Logo.
* Michael Avaliotis of [https://vishots.com/ VIShots] for the video recording.
* All of the presenters
* And many more who will hopefully be added to this list.

== References ==
<references/>

[[Category:VIWeek]]
[[Category:Videos]]

Package Manager Comparison

2020-05-20T01:54:42Z

Jim kring: VIPM integrates into the LabVIEW IDE (palette refresh, mass compile, active LabVIEW version detection, and more). Users can publish free open source packages to public VIPM Community repository.

This is the comparison of package management solutions in the LabVIEW community.

{| class="wikitable"
|-
! Characteristic !! [[VI Package Manager]] (Community Non-Commercial, Free Commercial, Pro $599) !! [[NI Package Manager]] !! [[G Package Manager]] ([[GPM]])
|-
| Installs With LabVIEW || Yes || Yes || No
|-
| Created By|| JKI || National Instruments || MGI (Moore Good Ideas)
|-
| Year Released || 2006 || 2017 || 2018
|-
| Open Source || No || No || Yes
|-
| Language Written In || G || C# || G
|-
| Free To Install || Yes (Community & Free) || Yes || Yes
|-
| API || Yes (Community & Pro) || Yes || Yes
|-
| Local repository management1 || Yes (Pro) || Yes || Yes
|-
| Supports multiple LabVIEW versions from a single package || Yes || No || Yes
|-
| Natively supports mass compile after install || Yes || No || Yes
|-
| Scope of package installation2 || LabVIEW IDE or OS File System || OS File System || Per Project5
|-
| Supports LabVIEW NXG || No || Yes || No
|-
| Integrates Into LabVIEW IDE8 || Yes || No || No
|-
| Integrates Into LabVIEW NXG IDE9 || No || Yes || No
|-
| Create palettes as a part of the package creation || Yes || No || No
|-
| Supports Installation to symbolic paths (user.lib) || Yes || No || N/A6
|-
| Support Structure || [https://forums.jki.net/forum/5-vi-package-manager-vipm/ Free & Community] or Paid Direct || [https://forums.ni.com/t5/NI-Package-Manager-NIPM/bd-p/1023 NI Forums] || [https://gitlab.com/mgi/gpm/gpm/wikis/home GitLab Issue Tracking and Wiki]10
|-
| Supports Pre Build Step || Yes, G Code (Community & Pro) || Yes - via Source Distribution, G Code || No
|-
| Supports Post Build Step || Yes, G Code (Community & Pro) || Yes - via Source Distribution, G Code || No
|-
| Supports Pre Install Step || Yes, G Code (Community & Pro) || Yes - via exe/bat (Advanced: must [https://forums.ni.com/t5/NI-Package-Management/Manually-Pack-and-Unpack-Packages/ta-p/3956905 pack the package]) || No
|-
| Supports Post Install Step || Yes, G Code (Community & Pro) || Yes - via exe/bat (Configurable from LabVIEW IDE)|| No
|-
| Supports Pre Uninstall Step || Yes, G Code (Community & Pro) || Yes - via exe/bat (Configurable from LabVIEW IDE)|| No
|-
| Supports Post Uninstall Step || Yes, G Code (Community & Pro) || Yes - via exe/bat (Advanced: must [https://forums.ni.com/t5/NI-Package-Management/Manually-Pack-and-Unpack-Packages/ta-p/3956905 pack the package]) || No
|-
| Supports N post install/pre uninstall steps || No || Yes || No
|-
| Supports N Post Install All steps|| No || Yes || No
|-
| Supports Automatic Dependency Scanning4 || Yes (Community & Pro) || No || Yes
|-
| Has a dedicated package manager application || Yes || Yes || Yes
|-
| Packages Searchable via Web Page || Yes || No || Yes
|-
| Has a community repository of packages12 || Yes || No || Yes
|-
| Can list packages created by other package managers as dependencies7 || No || No || No
|-
| Supports 64 bit without manual intervention?3 || Yes || Yes || No
|-
| Supports offline\copies of repositories11 || Yes (Pro) || || Yes
|}

{| class="wikitable"
|-
! Detail Number !! Additional Information
|-
| 1 || Repository types: A global repository is accessible to anyone. A local repository is created by an individual (company, etc.) and hosted on a local server.
|-
| 2 || Scope of Package Installation: determines if multiple versions of a package are allowed or if you may have only one version of a package.
|-
| 3 || GPM can place files anywhere. However, as of 0.2.0-35, GPackages installed for LabVIEW 64 bit will open, but cant find linked VIs. The GPackage(s) directories must be mass compiled to allow LabVIEW to relink the VIs to eachother.
|-
| 4 || Example
|-
| 5 || LabVIEW IDE Coming Soon
|-
| 6 || Coming Soon
|-
| 7 || Only packages of the same type can be listed as dependencies. For example, a VI Package can only depend on other VI Packages. A VI Package cannot depend on a NI Package.
|-
| 8 || There is no user experience to find, install, upgrade, remove, or autodetect packages from within the LabVIEW IDE.
|-
| 9 || NI Package manager is integrated into the NXG IDE so that the user may find the package responsible for installing missing gvis without leaving the IDE.
|-
| 10 || GPM is open source. The community can contribute to fix issues, add features and make support better.
|-
| 11 || For some organizations, a connection to the internet is not allowed. This feature allows you to internet-based repositories and host them locally for your organization.
|-
| 12 || A community package repository is not governed or gated by any organization. Community members are free to upload/download packages without oversight.
|}
==External links==
* [https://vipm.jki.net VI Package Manager]
* [https://www.ni.com/en-us/support/downloads/ni-package-manager.html NI Package Manager]
* [https://gpackage.io G Package Manager]

Package Manager Comparison

2020-03-19T19:07:16Z

Jim kring: Updated VIPM information to be current with 2020

This is the comparison of package management solutions in the LabVIEW community.

{| class="wikitable"
|-
! Characteristic !! [[VI Package Manager]] (Community Non-Commercial, Free Commercial, Pro $599) !! [[NI Package Manager]] !! [[G Package Manager]] ([[GPM]])
|-
| Installs With LabVIEW || Yes || Yes || No
|-
| Created By|| JKI || National Instruments || MGI (Moore Good Ideas)
|-
| Year Released || 2006 || 2017 || 2018
|-
| Open Source || No || No || Yes
|-
| Language Written In || G || C# || G
|-
| Free To Install || Yes (Community & Free) || Yes || Yes
|-
| API || Yes (Community & Pro) || Yes || Yes
|-
| Local repository management1 || Yes (Pro) || Yes || No
|-
| Supports multiple LabVIEW versions from a single package || Yes || No || Yes
|-
| Natively supports mass compile after install || Yes || No || Yes
|-
| Scope of package installation2 || LabVIEW IDE or OS File System || LabVIEW IDE || Per Project5
|-
| Supports LabVIEW NXG || No || Yes || No
|-
| Integrates Into LabVIEW IDE8 || No || No || No
|-
| Integrates Into LabVIEW NXG IDE9 || No || Yes || No
|-
| Create palettes as a part of the package creation || Yes || No || No
|-
| Supports Installation to symbolic paths (user.lib) || Yes || No || N/A6
|-
| Support Structure || [https://forums.jki.net/forum/5-vi-package-manager-vipm/ Free & Community] or Paid Direct || [https://forums.ni.com/t5/NI-Package-Manager-NIPM/bd-p/1023 NI Forums] || [https://gitlab.com/mgi/gpm/gpm/wikis/home GitLab Issue Tracking and Wiki]10
|-
| Supports Pre Build Step || Yes, G Code (Community & Pro) || Yes - via Source Distribution, G Code || No
|-
| Supports Post Build Step || Yes, G Code (Community & Pro) || Yes - via Source Distribution, G Code || No
|-
| Supports Pre Install Step || Yes, G Code (Community & Pro) || Yes - via exe/bat (Advanced: must [https://forums.ni.com/t5/NI-Package-Management/Manually-Pack-and-Unpack-Packages/ta-p/3956905 pack the package]) || No
|-
| Supports Post Install Step || Yes, G Code (Community & Pro) || Yes - via exe/bat (Configurable from LabVIEW IDE)|| No
|-
| Supports Pre Uninstall Step || Yes, G Code (Community & Pro) || Yes - via exe/bat (Configurable from LabVIEW IDE)|| No
|-
| Supports Post Uninstall Step || Yes, G Code (Community & Pro) || Yes - via exe/bat (Advanced: must [https://forums.ni.com/t5/NI-Package-Management/Manually-Pack-and-Unpack-Packages/ta-p/3956905 pack the package]) || No
|-
| Supports N post install/pre uninstall steps || No || Yes || No
|-
| Supports N Post Install All steps|| No || Yes || No
|-
| Supports Automatic Dependency Scanning4 || Yes (Community & Pro) || No || Yes
|-
| Has a dedicated package manager application || Yes || Yes || Yes
|-
| Packages Searchable via Web Page || Yes || No || Yes
|-
| Has a community repository of packages || Yes || No || Yes
|-
| Can list packages created by other package managers as dependencies7 || No || No || No
|-
| Supports 64 bit without manual intervention?3 || Yes || Yes || No
|-
| Supports offline\copies of repositories11 || Yes (Pro) || ||
|}

{| class="wikitable"
|-
! Detail Number !! Additional Information
|-
| 1 || Repository types: A global repository is accessible to anyone. A local repository is created by an individual (company, etc.) and hosted on a local server.
|-
| 2 || Scope of Package Installation: determines if multiple versions of a package are allowed or if you may have only one version of a package.
|-
| 3 || GPM can place files anywhere. However, as of 0.2.0-35, GPackages installed for LabVIEW 64 bit will open, but cant find linked VIs. The GPackage(s) directories must be mass compiled to allow LabVIEW to relink the VIs to eachother.
|-
| 4 || Example
|-
| 5 || LabVIEW IDE Coming Soon
|-
| 6 || Coming Soon
|-
| 7 || Only packages of the same type can be listed as dependencies. For example, a VI Package can only depend on other VI Packages. A VI Package cannot depend on a NI Package.
|-
| 8 || There is no user experience to find, install, upgrade, remove, or autodetect packages from within the LabVIEW IDE.
|-
| 9 || NI Package manager is integrated into the NXG IDE so that the user may find the package responsible for installing missing gvis without leaving the IDE.
|-
| 10 || GPM is open source. The community can contribute to fix issues, add features and make support better.
|-
| 11 || For some organizations, a connection to the internet is not allowed. This feature allows you to internet-based repositories and host them locally for your organization.
|}
==External links==
* [https://vipm.jki.net VI Package Manager]
* [https://www.ni.com/en-us/support/downloads/ni-package-manager.html NI Package Manager]
* [https://gpackage.io G Package Manager]

Functional global variable

2007-10-08T10:45:15Z

Jim kring: /* External Links */ changed Design Patters category to upper case to match actual category

{{TOCnestright}}
Functional Globals are VIs that allow controlled access to data or resources, often allowing various actions to be performed. Functional Globals (FGs) most often make use of uninitialized shift registers (USRs). USRs are shift registers that do not have a wired input coming into the left side of the loop. A USR stores its data between successive runs of the VI as long as the VI remains in memory.

==Alternative Nomenclature==
Functional Globals are known by various names among LabVIEW programmers.
*LV2 globals – because LV2 supported uninitialized shift registers
*USR globals – since most FGs make use of uninitialized shift registers
* VIG - "VI Global" as the VI performs the functionality of a global
*Action Engines – it has been argued [http://forums.ni.com/ni/board/message?board.id=170&message.id=240328&query.id=618807#M240328] that the term Functional Globals should refer to VIs that just allow read/write access to data. Action Engines would refer to the larger set of VIs that allow some defined action on the data.

The official name for these constructs in NI literature is Functional Global Variable, and a [http://forums.lavag.org/index.php?showtopic=2469&st=0 survey] on LAVA indicated that Functional Globals is also the most popular choice.

==Structure==
The most common form of a Functional Global is a [[While Loop]] with a TRUE wired to the stop condition. This forces the loop to terminate after just one execution, meaning the while loop is only used to provide a place to put USRs. A [[For Loop]] could also be used with a constant wired to the count terminal. Another method is to use a single-element queue to store the data, though this requires more mouse clicks to implement. The performance of each of these is very close and most likely will vary a little from computer to computer.

[[Image:Simple_FG.PNG|frame|center|Simple Functional Global using a While Loop]]

In order to specify what action to perform, an [[enumerated type]] is often used as an input to the Functional Global. Other methods are possible (Booleans, First Call?, etc.), but an enumerated type provides for a readable, extensible list of actions. Furthermore, saving the enumerated type as a typedef control makes any changes to the list automatically update wherever the Functional Global is used in the code. The ‘action’ input is fed to a case structure which contains the code to implement for each of the defined actions.

For more complex situations, multiple actions can be performed on a single call to the FG. This can be a straightforward [[state machine]], or it can allow for different actions based on the data received or on the existence of resources, etc.

The data in a Functional Global could be of any type, but very often there will be several data elements in a single FG. It is helpful to group the data into a cluster to limit the number of wires entering and leaving the FG. Designing the data structures and how you cluster your data should be done early on, rather than haphazardly growing your clusters as you grow your program.

In order to deal with varying input requirements on the different actions, one can create ‘wrappers’ around the Functional Global that allow for different inputs to be required. This also gives the benefit of being able to search your code for certain actions as you can search for a specific VI, but not a specific enumerated type’s value.

==Uses==
The primary use of Functional Globals is to provide data sharing across an entire project, both horizontally and vertically. Horizontal sharing means multiple top-level VIs running autonomously can all have access to the same data. Vertical sharing means that subVIs at any depth will have access to the data without requiring explicit passing of parameters through VI [[connector pane]] terminals. These are common issues in even small-sized programs.

Another common use is to encapsulate some functionality, especially functionality that is linked to persistent data or resources like files or devices. This encapsulation protects the resource and provides an extensible interface for interacting with the data or resource. The encapsulation also allows you to avoid a plethora of shift registers in a single VI. You can offload the shift-register to the Functional Global, and call it when needed, without worrying about wiring the data through all your case structures.

To get a better idea of what can be done with Functional Globals, here is a list of things that can be done:
*Load information from a file into a FG, access it anywhere in your program
*Maintain your system’s configuration parameters in one location.
*Store a control reference (like a tree control) in a FG, and then define an interface to manage that control. For complex controls like trees and multi-column listboxes this can simplify your top-level code.
*Timers are well implemented with FGs. You can keep the start time in the shift register, and then check the elapsed time when you call it again.
*Automatically preallocate an array when the FG is first called, then use “Replace Array Subset” to efficiently manipulate the array.
*Keep an ‘Undo’ list (stack) that allows you to push changes onto a stack, and pop them off when you need to undo the change.
The list could go on and on – whatever you can dream up!

==Race Conditions and Locking==
One of the main reasons that Functional Globals are encouraged in lieu of [[global variable]]s is race conditions. The majority of Functional Globals are, by definition, not reentrant so that different calls to the FG will all refer to the same shift registers and hence the same data or resource. This means that when a VI calls a FG, that FG is locked or reserved for use by the calling VI. Other VIs need to wait until it is done before they can call the FG.

Global variables are reentrant. If you try to write a value to the global in several places in your code, updates to the value are unpredictable with respect to time. This means that changes to the global can be subject to race conditions. This is especially true if you read/write to the global where a race condition could occur between the read and the write of the variable.

The downside for Functional Globals is that the locking that takes place can be a bottleneck in the code if many VIs are trying to access the FG at the same time. The majority of applications will not have a problem, but care must be taken if speed is a concern.

It is also important to note that Functional Globals are not a cure-all for race conditions. If actions on the Functional Global are not atomic (i.e. they require more than one call to the FG) then race conditions are still possible. Race conditions are only eliminated if all updates to the data are done inside the FG, in a single call. Here are a couple ways to still allow race conditions with FGs.
*Ask for the data from the FG, change it, and then write it back to the FG.
*Successive modifications, such as {Set data, normalize data, sort data, output max} By the time you sort the data, new data could have been set that hasn’t been normalized.

==Benefits==
#Efficient Memory Usage – Because the VI retains the same data space regardless of it use in the code, only a single call to the memory manager is made. If arrays are stored in the USR, and replace array element primitives used, then the memory space is efficiently used wherever the VI is called.
#Reduces problems with race conditions, as discussed above.
#Error checking can be done on data writes (Global variables don’t allow this).
#High-level code more readable – By moving shift registers and code logic into Functional Globals with readable action lists, top-level code become simpler and cleaner.
#Reuse. Many FGs are generic enough to be used over and over again.

==Concerns==
===Busy connector panes===
Terminals get used up quickly, so be sure to design well up front and choose a connector pane with more terminals than you need. You can avoid excessive terminal usage by grouping all of your data into a cluster (preferably, a [[Type Definition]]) that is passed in and out of your functional global which will allow you to bundle and unbundle specific variables as needed on your main VI.

===Data Persistence===
Data in a USR, and hence in a Functional Global, disappears if the owning VI goes out of memory. When a VI runs for the first time, all of its subVIs that are not already in memory are loaded into memory and they belong to that parent VI. If that parent VI is stopped, all of the subVIs that belong to it are also released from memory – even if there are other VIs in memory still referencing those subVIs. The next time one of those subVIs is run, it is loaded into memory again and that calling VI becomes the new parent VI. But if there was anything stored in USRs, that data is now gone.

This behavior is different from a queue reference, for instance, where the queue is only destroyed when ALL VIs referencing it leave memory. It means that if you use Functional Globals across multiple top-level VIs, then you need to have a VI that is run first and contains all of your Functional Globals as subVIs. This ‘First Run’ VI must stay in memory until all other top-level VIs are closed to insure that the Functional Global data will be available.

===Performance===
Some testing has shown that, as of LabVIEW 8.5, using a [[Case Structure]] performs better (from 1.5x to 3x) than a [[Select function]] for controlling the data flow of the Set/Write vs. the Get/Read operation.

==Reentrant functional globals==
===Unshared data===
There are certain problems where you do not need to share the persistent data elsewhere in the code. If you create a '''windowed average''' VI, it can be made reentrant and can be used in multiple places in your code to average data streams. This is an example of an in-place operation that is not shared, but requires persistent data. Timing a process in a single loop could be done with one instance of a Functional Global. Making this timing FG reentrant allows the developer to use that same timing FG to time other processes. See [[Reentrant VI]] for more information.

===By reference===
It’s possible to make use of reentrancy to duplicate functional globals. This allows to create as many globals as you need (even at run time) without duplicating code or modifying the original FG. The main disadvantage of this technique is the necessity to keep a reference to every instance of the functional global and pass them to the VIs or subVIs that will use them.

With this method, the only change to the original FG is to make the VI reentrant. Keep in mind that, from now on, this functional global can’t be used in the habitual way, since any instance will retain its own values.

To create an instance of the functional global, open it with the '''Open VI Reference''' function (use option 0x08 to prepare for reentrant run) and use the output reference to set the control values, run the VI and get the results. To facilitate things an avoid mistakes when getting/setting values, may be advisable to use the '''Call by Reference node'''. Furthermore, the encapsulation of the FG actions in specific wrappers, as detailed in the Structure section above, is also useful.

==See Also==
*[[Global variable]]
*[[State machine]]

==External Links==
*[http://forums.lavag.org/LV2OO-Style-Global-v20-from-NI-Week-presentation-t8780.html LAVA forum discussion about LV2OO-style globals]
*[http://forums.ni.com/ni/board/message?board.id=170&message.id=240328&query.id=618807#M240328 NI Forums Community Nugget on Action Engines]
*[http://zone.ni.com/reference/en-XX/help/371361A-01/lvconcepts/suggestions_for_exec/#Functional_Global_Variables NI Documentation on Functional Global Variables]

[[Category:Design Patterns]]

Data type descriptor

2007-10-06T15:49:50Z

Jim kring: Redirecting to Type descriptor

#REDIRECT [[type descriptor]]

Type descriptor

2007-10-06T15:48:54Z

Jim kring: New page: From the LabVIEW Help: LabVIEW associates each wire and terminal on the block diagram with a data type. LabVIEW keeps track of this type with a structure in memory called a type descripto...

From the LabVIEW Help:

LabVIEW associates each wire and terminal on the block diagram with a data type. LabVIEW keeps track of this type with a structure in memory called a type descriptor. This type descriptor is a sequence of 32-bit integers that can describe any data type in LabVIEW. Numeric values are written in hexadecimal format, unless otherwise noted.

==External links==

*[http://zone.ni.com/reference/en-XX/help/371361B-01/lvconcepts/type_descriptors/ LabVIEW 8.2 Help>>Type Descriptors]
*[http://zone.ni.com/reference/en-XX/help/371361B-01/lvconcepts/how_labview_stores_data_in_memory/ LabVIEW 8.2 Help>>How LabVIEW Stores Data in Memory]

Glossary of LabVIEW terms

2007-10-06T15:46:10Z

Jim kring: /* T */ added time stamp

This is a glossary of LabVIEW terminology.
__NOTOC__
{{compactTOC2}}

==A==

;[[absolute path]]
:File or directory path that describes the location relative to the top level of the file system.

;[[active cell]]
:Cell of a listbox, table, digital data, or tree control to which you can apply property changes.

;[[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.

;[[ancestor class]]
:Any [[LabVIEW class]] that is the parent, grandparent, and so on, of another LabVIEW class. The [[LabVIEW Object]] may be the ultimate ancestor.

;[[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. 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 software packages.

;[[application zone]]
:Memory allocation section that holds all data in a VI except execution data.

;[[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]].

;[[asynchronous execution]]
:Mode in which multiple processes share processor time. For example, one process executes while others wait for interrupts during device I/O or while waiting for a clock tick.

;[[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 1D arrays, 1D arrays extracted from 2D arrays, and so on. Loops assemble data values into arrays as data values 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.

;[[autosizing]]
:Automatic resizing of labels to accommodate text you enter.

==B==

;[[bit array tag]]
:Multibit value representation of a connection to a real-world I/O point or memory variable. In LabVIEW, this type of tag can be comprised of up to 32 discrete values.

;[[wikipedia:Backus–Naur form|BNF]]
:Backus-Naur Form. A common representation for language grammars in computer science.

;[[Boolean controls and indicators]]
:Front panel objects to manipulate and display Boolean (TRUE or FALSE) data.

;[[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.

;[[breakpoint]]
:Pause in execution used for debugging.

;[[Breakpoint tool]]
:Tool to set a breakpoint on a VI, node, or wire.

;[[broken arrow]]
:See [[broken Run button]] below.

;[[broken Run button]]
:Button that replaces the Run button when a VI cannot run because of errors.

;[[broken VI]]
:VI that cannot run because of errors; signified by a broken arrow in the broken Run button.

;[[buffer]]
:Temporary storage for acquired or generated data.

;[[Bundle function]]
:Function that creates clusters from various types of elements.

;[[byte stream file]]
:File that stores data as a sequence of ASCII characters or bytes.

==C==

;[[C string (CStr)]]
:A series of zero or more unsigned characters, terminated by a zero, used in the C programming language.

;[[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.

;[[cast]]
:To change the type descriptor of a data element without altering the memory image of the data.

;[[chart]]
:2D display of one or more plots in which the display retains a history of previous data, up to a maximum that you define. The chart receives the data and updates the display point by point or array by array, retaining a certain number of past points in a buffer for display purposes. {{See also|scope chart|strip chart|sweep chart}}.

;[[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.

;[[child class]]
:A [[LabVIEW class]] that [[inherits]] data and [[member VIs]] from an [[ancestor LabVIEW class]].

;[[CIN]]
:[[Code Interface Node (CIN)]]. Special [[block diagram]] [[node]] through which you can link text-based code to a [[VI]].

;[[CIN source code]]
:Original, uncompiled text code. {{See also|object code|Code Interface Node (CIN)}}.

;[[class]]
:A category containing properties, methods, and events. Classes are arranged in a hierarchy with each class inheriting the properties and methods associated with the class in the preceding level.

;[[class library]]
:The group of VIs that define a [[LabVIEW class]]. The class library also stores the data of the LabVIEW class.

;[[cloning]]
:To make a copy of a control or another object by clicking it while pressing the <Ctrl> key and dragging the copy to its new location.

;[[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 resource]]
:Resource containing executable machine code. You link code resources to LabVIEW through a [[CIN]].

;[[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.

;[[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.

;concatenated Pascal string (CPStr)
:A list of Pascal-type strings concatenated into a single block of memory.

;[[conditional terminal]]
:Terminal of a While Loop that contains a Boolean value that determines if the VI performs another iteration. A conditional terminal also can be added to a For Loop to stop execution early when a condition occurs.

;[[connector]]
:Part of the VI or function node that contains input and output terminals. Data values 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 also|universal constant|user-defined constant}}.

;[[content rectangle]]
:Region of a listbox, table, digital data, or tree control that contains all headers and cells. The content rectangle does not include scroll bars.

;[[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.

;[[continuous run]]
:Execution mode in which a VI runs repeatedly until the operator stops it. Click the Continuous Run button to run a VI repeatedly.

;[[Continuous Run button]]
:Icon that indicates a VI is set to execute repeatedly until the user stops it.

;[[contour plot]]
:Plot where contour lines are used to connect points of equal value.

;[[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.

;[[Controls palette]]
:Palette that contains front panel controls, indicators, and decorative objects.

;[[conversion]]
:Changing the type of a data element.

;[[UTC]]
:Coordinated Universal Time. Time scale that is determined using highly precise atomic clocks. LabVIEW uses UTC as the standard for the internal representation of dates and times.

;[[count terminal]]
:Terminal of a For Loop whose value determines the number of times the For Loop executes its subdiagram.

;[[current VI]]
:VI whose front panel, block diagram, or Icon Editor is the active window.

==D==

;[[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 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.

;[[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.

;[[deploy]]
:To download items or apply settings to a target in the Project Explorer window.

;[[descendant class]]
:A [[child]], grandchild, and so on, of another [[LabVIEW class]].

;[[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.

;[[DLL]]
:Dynamic Link Library

;[[drag]]
:To use the cursor on the screen to select, move, copy, or delete objects.

;[[drive]]
:Letter in the range a-z followed by a colon ":", to indicate a logical disk drive.

;[[driver]]
:Software that controls a specific hardware device, such as a DAQ device.

;[[DTbl]]
:Digital table.

;[[DWDT]]
:Digital waveform data type.

;[[dynamic data type]]
:Data type used by Express VIs that includes the data associated with a signal and attributes that provide information about the signal, such as the name of the signal or the date and time the data was acquired. Attributes specify how the signal appears on a graph or chart.

;[[dynamic dispatch]]
:A VI that defines a method of a [[LabVIEW class]]. Dynamic dispatch [[member VIs]] are VIs with the same name that occur throughout the class hierarchy. Similar to polymorphic VIs, LabVIEW determines at run time which member VI to call.

==E==
;[[edit mode]]
:When you can make changes to a VI.

;[[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.

;[[encapsulation]]
:The consolidation of data and methods into a LabVIEW class, where the data is accessible only through class member VIs.

;[[end of file (EOF)]]
:Character offset of the end of file relative to the beginning of the file. The EOF is the size of the file.

;[[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 List window]]
:Window that displays errors and warnings occurring in a VI and in some cases recommends how to correct the errors.

;[[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 Data Node]]
:Node attached to the left and right sides of an Event structure indicating the available data for the event you configured that case to handle. If you configure a single case to handle multiple events, only the data that is common to all handled event types is available.

;[[event driven programming]]
:Method of programming whereby the program waits on an event to occur before executing one or more functions.

;[[execution highlighting]]
:Debugging technique that animates VI execution to illustrate the data flow in the VI.

;[[Express VI]]
:A subVI designed to aid in common measurement tasks. You configure an Express VI using a configuration dialog box.

==F==
;[[FIFO]]
:First-in-first-out memory buffer. The first data stored is the first data sent to the acceptor.

;[[file refnum]]
:Reference number. An identifier that LabVIEW uses as reference to a file object. Use a file refnum as an input parameter for certain file IO functions.

;[[filter events]]
:Allow control over how the user interface behaves.

;[[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.

;[[flattened data]]
:Data of any type that has been converted to a string, usually for writing the data to a file.

;[[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...

;[[Formula node]]
:Node that executes equations you enter as text. Especially useful for lengthy equations too cumbersome to build in block diagram form.

;[[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.

;[[Functions palette]]
:Palette that contains VIs, functions, block diagram structures, and constants.

==G==

;[[G]]
:Graphical programming language LabVIEW uses.

;[[Get Color tool]]
:Copies colors for pasting with the Coloring tool.

;[[global variable]]
:Accesses and passes data among several VIs on a block diagram.

;[[glyph]]
:Small picture or icon.

;[[graph]]
:2D display of one or more plots. A graph receives and plots data as a block.

==H==
;[[handle]]
:Pointer to a pointer to a block of memory that manages reference arrays and strings. An array of strings is a handle to a block of memory that contains handles to strings.

;[[hex]]
:Hexadecimal. Base-16 number system.

;[[Hierarchy window]]
:Window that graphically displays the hierarchy of VIs and subVIs. {{See also|VI Hierarchy window}}

;[[housing]]
:Non-moving part of front panel controls and indicators that contains sliders, scales, or scroll boxes.

==I==

;[[IAC]]
:Interapplication communication.

;[[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.

;[[Inf]]
:Digital display value for a floating-point representation of infinity.

;[[inheritance]]
:The use of one LabVIEW class as the initial definition of a new LabVIEW class. The inheriting class has the same data and member VIs as the ancestor class initially, but you can modify or add to the existing data and methods as you need.

;[[initializer terminal]]
:Terminal that sets the initial value of a [[Feedback Node]].

;[[inplace]]
:The condition in which two or more terminals, such as error I/O terminals or shift registers, use the same memory space.

;[[instrument driver]]
:A set of high-level functions that control and communicate with instrument hardware in a system.

;[[integer]]
:Any of the natural numbers, their negatives, or zero.

;[[integer word length]]
:The number of integer bits in a binary number, or, given an initial position to the left or right of the most significant bit, the number of bits to shift the binary point to reach the most significant bit. If the integer word length is positive, shift the binary point to the left. If the integer word length is negative, shift the binary point to the right.

;[[intensity map/plot]]
:Method of displaying three dimensions of data in a 2D plot with the use of color.

;[[IP]]
:Internet protocol.

;[[iteration terminal]]
:Terminal of a For Loop or While Loop that contains the current number of completed iterations.

;[[IVI]]
:Interchangeable Virtual Instruments. A software standard for creating a common interface (API) to common test and measurement instruments.

;[[IVI driver]]
:A driver written according to the IVI specification. The generic driver for a class of instruments (such as voltmeters) is called a class driver, whereas the driver for a specific instrument from a specific manufacturer is called a device-specific driver.

==J==

==K==
;[[Kwords]]
:1,024 words (16 bits) of memory.

==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.

;[[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 methods associated with an object of the class.

;[[LabVIEW class hierarchy]]
:The [[inheritance]] relationship of [[LabVIEW classes]].

;[[LabVIEW Object]]
:The root of the LabVIEW class inheritance tree.

;[[LabVIEW string (LStr)]]
:The string data type that LabVIEW block diagrams use.

;[[LabVIEW system time]]
:The date and time that LabVIEW uses as a reference for absolute time. LabVIEW system time is defined as 12:00 a.m., Friday, January 1, 1904, Universal Time. {{See also|Coordinated Universal Time (UTC)}}.

;[[legend]]
:Object a graph or chart owns to display the names and plot styles of plots on that graph or chart.

;[[library]]
:{{See also|LLB|project library}}

;[[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.

;[[LSB]]
:Least Significant Bit.

==M==
;[[marquee]]
:Moving, dashed border that surrounds selected objects.

;[[MB]]
:Megabytes of memory. 1 MB is equal to 1,024 KB.

;[[member VI]]
:A VI that a LabVIEW class owns. A member VI can access the [[private data]] of a [[LabVIEW class]].

;[[memory buffer]]
:{{See also|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.

;[[method]]
:A procedure that is executed when an object receives a message. A method is always associated with a class.

;[[MSB]]
:Most Significant Bit.

;[[multicore programming]]
:Two or more processors in one computer, each of which can simultaneously run a separate thread.

;[[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.

;[[multithreading]]
:A technique for an operating system to handle multiple small tasks at one time, known as threads.

==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}}.

;[[NaN]]
:Digital display value for a floating-point representation of <Not A Number>. Typically the result of an undefined operation, such as log(–1).

;[[NI-PSP]]
:NI Publish-Subscribe Protocol. A data transfer protocol to write and allow users to read live data. NI-PSP is a proprietary technology that provides fast and reliable data transmission for large and small applications and is installed as a service on the computer when you install LabVIEW.

;[[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.

;[[not-a-refnum]]
:Predefined value that indicates the refnum is invalid.

;[[notify events]]
:Tell LabVIEW that a user action has already occurred, such as when a user changes the value of a control.

;[[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.

;[[object code]]
:Compiled version of source code. Object code is not standalone because you must load it into LabVIEW to run it.

;[[Object Shortcut Menu tool]]
:Tool to access a shortcut menu for an object.

;[[OLE]]
:Object Linking and Embedding.

;[[OLE for Process Control (OPC)]]
:OLE for Process Control. A set of standard interfaces developed by the OPC Foundation to ensure interoperability among control devices from different manufacturers for the transfer of real-time plant data.

;[[one-dimensional]]
:Having one dimension, as in the case of an array that has only one row of elements.

;[[Operating tool]]
:Tool to enter data into controls or to operate them.

;[[override VI]]
:Allows you to override an [[member VI]] of an [[ancestor LabVIEW class]].

;[[owning pane]]
:The pane of the front panel in which an object resides.

==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.

;[[parent class]]
:An existing [[LabVIEW class]] from which another class [[inherits]].

;[[parser]]
:VI that scans a string to determine the function of each of the elements in the string.

;[[Pascal string (PStr)]]
:A series of unsigned characters, with the value of the first character indicating the length of the string. Used in the Pascal programming language.

;[[picture]]
:Series of graphics instructions that a picture indicator uses to create a picture.

;[[picture indicator]]
:General-purpose indicator for displaying pictures that can contain lines, circles, text, and other types of graphic shapes.

;[[pixel]]
:Smallest unit of a digitized picture.

;[[pixmap]]
:Standard format for storing pictures in which a color value represents each pixel. A bitmap is a black and white version of a pixmap.

;[[plot]]
:Graphical representation of an array of data shown either on a graph or a chart.

;[[point]]
:Cluster that contains two 16-bit integers that represent horizontal and vertical coordinates.

;[[polymorphism]]
:Ability of a node to automatically adjust to data of different representation, type, or structure.

;[[Positioning tool]]
:Tool to move and resize objects.

;[[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]].

;[[private scope]]
:Only VIs within the same [[LabVIEW class]] can call the [[member VI]]. Private member VIs display a red key glyph in the Project Explorer window.

;[[probe]]
:Debugging feature for checking intermediate values in a VI.

;[[Probe tool]]
:Tool to create probes on wires.

;[[project]]
:A collection of LabVIEW files and non-LabVIEW files that you can use to create build specifications and deploy or download files to targets.

;[[Project Explorer window]]
:Window in which you can create and edit LabVIEW projects.

;[[project library]]
:A collection of VIs, type definitions, shared variables, palette menu files, and other files, including other project libraries.

;[[Properties dialog boxes]]
:Dialog boxes accessed from the shortcut menu of a control or indicator that you can use to configure how the control or indicator appears in the front panel window.

;[[Property Node]]
:Sets or finds the properties of a VI or application.

;[[protected scope]]
:Only VIs within the same [[LabVIEW class]] or a [[descendant class]] can call the [[member VI]]. Protected member VIs display a dark yellow key glyph in the Project Explorer window.

;[[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.

;[[public scope]]
:Any VI can call the [[member VI]] of the [[LabVIEW class]] as a subVI.

;[[pull-down menus]]
:Menus accessed from a menu bar. Pull-down menu items are usually general in nature.

==Q==

==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.

;[[rectangle]]
:Cluster that contains four 16-bit integers. The first two values describe the vertical and horizontal coordinates of the top left corner. The last two values describe the vertical and horizontal coordinates of the bottom right corner.

;[[recursion]]
:The ability of a VI to call itself on its own block diagram including the block diagram of any subVIs. Use recursion to operate many times on the output of the same process.

;[[reentrant execution]]
:Mode in which calls to multiple instances of a subVI can execute in parallel with distinct and separate data storage.

;[[refnum]]
:Reference number. An identifier that LabVIEW uses as 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.

;[[relative coordinates]]
:Picture coordinates relative to the current location of the pen.

;[[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.

;[[resizing circles or handles]]
:Circles or handles that appear on the borders of an object to indicate the points where you can resize the object.

;[[ring control]]
:Special numeric control that associates 32-bit integers, starting at 0 and increasing sequentially, with a series of text labels or graphics.

;[[row-major order]]
:Way to organize the data in a 2D array by rows.

;[[run mode]]
:When a VI is running or reserved to run. A VI enters run mode when you click the Run or Run Continuously buttons on the front panel toolbar, the single-stepping buttons on the block diagram toolbar, or select Operate»Change to Run Mode. In run mode, all front panel objects have an abridged set of shortcut menu items. You cannot edit a VI while the VI runs.

==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.

;[[scale]]
:Part of graph, chart, and some numeric controls and indicators that contains a series of marks or points at known intervals to denote units of measure.

;[[scope chart]]
:Numeric indicator modeled on the operation of an oscilloscope.

;[[Scrolling tool]]
:Tool to move through windows.

;[[sequence local]]
:Terminal to pass data between the frames of a Stacked Sequence structure.

;[[sequence structure]]
:{{See a;so|Flat Sequence structure|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.

;[[shared variable]]
:Variable that enables you to read or write live data among several VIs in a project or across a network.

;[[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.

;[[sibling class]]
:Any [[LabVIEW class]] that has the same [[parent class]].

;[[slider]]
:Moveable part of slide controls and indicators.

;[[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 is also 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.

;[[source control]]
:A solution to the problem of sharing VIs and controlling access to avoid accidental loss of data. You can use a source control provider to share files among multiple users, improve security and quality, and track changes to shared projects. Also called source code control.

;[[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.

;[[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.

;[[static dispatch]]
:A method of a [[LabVIEW class]]. You define a static dispatch [[member VI]] in only one level of the [[LabVIEW class hierarchy]].

;[[string]]
:Representation of a value as text.

;[[string controls and indicators]]
:Front panel objects to manipulate and display text.

;[[strip chart]]
:Numeric plotting indicator modeled after a paper strip chart recorder, which scrolls as it plots data.

;[[structure]]
:Program control element, such as a Flat Sequence structure, Stacked Sequence structure, Case structure, For Loop, or While Loop.

;[[subdiagram]]
:Block diagram within the border of a structure.

;[[subpalette]]
:Palette that you access from another palette that is above the subpalette in the hierarchy.

;[[subVI]]
:VI used on the block diagram of another VI. Comparable to a subroutine.

;[[sweep chart]]
:Numeric indicator modeled on the operation of an oscilloscope. It is similar to a scope chart, except that a line sweeps across the display to separate old data from new data.

;[[syntax]]
:Set of rules to which statements must conform in a particular programming language.

==T==
;[[target]]
:A device or machine on which a VI runs. You must use a LabVIEW project to work with an RT, FPGA, or PDA target.

;[[template VI]]
:VI that contains common controls and indicators from which you can build multiple VIs that perform similar functions. Access template VIs from the New dialog box.

;[[terminal]]
:Object or region on a node through which data values pass.

;[[time stamp]]
:A data type for storing absolute time with high precision..

;[[time step]]
:Interval from t to t + dt.

;[[tip strip]]
:Small yellow text banners that identify the terminal name and make it easier to identify terminals for wiring.

;[[tool]]
:Special cursor to perform specific operations.

;[[toolbar]]
:Bar that contains command buttons to run and debug VIs.

;[[Tools palette]]
:Palette that contains tools you can use to edit and debug front panel and block diagram objects.

;[[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.

;[[two-dimensional]]
:Having two dimensions, as in the case of an array that has several rows and columns.

;[[type definition]]
:Master copy of a custom object that several VIs can use.

;[[type descriptor]]
:Code that identifies data types; used in data storage and representation. {{See also|data type descriptor}}

==U==
;[[universal constant]]
:Block diagram object you cannot edit that emits a particular ASCII character or standard numeric constant, for example, π.

;[[user]]
:Person who initiates and monitors the operation of a process. {{See also|operator}}

;[[user-defined constant]]
:Block diagram object that emits a value you set.

==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.

;[[vector]]
:1D array.

;[[VI]]
:{{See also|virtual instrument (VI)}}

;[[virtual instrument (VI)]]
:Program in LabVIEW that models the appearance and function of a physical instrument.

==W==
;[[waveform]]
:Multiple voltage readings taken at a specific sampling rate.

;[[waveform chart]]
:Indicator that plots data points at a certain rate.

;[[WDT]]
:Waveform data type.

;[[While Loop]]
:Loop structure that repeats a section of code until a condition occurs.

;[[wire]]
:Data path between nodes.

;[[wire bend]]
:Point where two wire segments join.

;[[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.

;[[Wiring tool]]
:Tool to define data paths between terminals.

;[[wizard]]
:A dialog box with a sequence of pages through which you can move forward and backward as you fill in information.

;[[word length]]
:The total number of bits a system uses to store a particular piece of data, such as a number. LabVIEW accepts a maximum word length of 64 bits.

==X==

==Y==

==Z==

{{compactTOC2}}

[[Category:Glossaries|LabVIEW terminology]]

ATML

2007-10-06T15:42:50Z

Jim kring: Redirecting to Automated Test Markup Language

#REDIRECT [[Automated Test Markup Language]]

Automated Test Markup Language

2007-10-06T15:42:18Z

Jim kring: New page: Automated Test Markup Language (AML) is a collection of XML schemas that allows Automated Test Executive (ATE) and test information to be exchanged in a common format adhering to the XML s...

Automated Test Markup Language (AML) is a collection of XML schemas that allows Automated Test Executive (ATE) and test information to be exchanged in a common format adhering to the XML standard.

== External Links ==
* [http://grouper.ieee.org/groups/scc20/tii/ ATML Homepage on ieee.org]

LabVIEW Technical Resource

2007-10-06T13:13:26Z

Jim kring:

{{stub}}

LabVIEW Technical Resource (LTR) was a periodical print magazine that ran from 1993 to 2006.

LTR

2007-10-06T12:57:31Z

Jim kring: Redirecting to LabVIEW Technical Resource

#REDIRECT [[LabVIEW Technical Resource]]

LabVIEW Technical Resource

2007-10-06T12:56:46Z

Jim kring: New page: {{stub}} LabVIEW Technical Resource was a periodical print magazine that ran from 1993 to 2006.

{{stub}}

LabVIEW Technical Resource was a periodical print magazine that ran from 1993 to 2006.

LabVIEW Bug Reporting

2007-09-18T17:06:32Z

Jim kring:

This article describes the process required for reporting bugs in LabVIEW.

==Requirements of a Good Bug Report==
Good bug reports should '''always''' include the following:
# Steps to reproduce
# What happened
# What you expected to happened
This information is needed to confirm that what you are seeing is actually a bug and to help figure out what is causing the buggy behavior. It is also a great idea to include any example code that demonstrates the bug and/or screenshots of the bug.

==Reporting Bugs to National Instruments==
If you have a bug to report to NI, go to http://ni.com/ask to
submit a support request. Select ''Reporting a Bug'' for your Question Type.

If you select Phone or E-mail NI, and you have a valid service contract, you will be routed to
Applications Engineers who can file the appropriate bug report. If you do
not have a valid service contract, you should select Phone NI and you will be routed to an intermediary
person who can pass you through to an Applications Engineer, provided you
are calling to report a bug.

If your bug ''is'' in fact a bug, ask for a [[CAR Number]] -- this is how your bug is uniquely identified and can be used to track its status. When you get a CAR Number you should update your posting in the [http://forums.lavag.org/Bug-Lists-f17.html Bug Lists] forum to include this CAR Number.

==Posting a Bug Report on the LAVA Forums==
There is a [http://forums.lavag.org/Bug-Lists-f17.html Bug Lists] forum on LAVA. This should be used for reporting confirmed bugs with a [[CAR Number]]. If a posting in the [http://forums.lavag.org/Bug-Lists-f17.html Bug Lists] forum is determined to not be a bug, it will be moved into another forum. Also, you can use the [http://forums.lavag.org/LabVIEW-General-f10.html LabVIEW General] discussion forum to discuss the issue with other LAVA members before creating a more official posting in the [http://forums.lavag.org/Bug-Lists-f17.html Bug Lists] forum.

Bug report topics should be titled with a short description of the bug. The description of the topic should be used for status and [[CAR Number]]. For example, see the [http://forums.lavag.org/Move-on-disk-feature-crashes-LabVIEW-t9040.html "Move on disk" feature crashes LabVIEW] bug. Notice how it has a clear title and description:

* Title: "Move on disk" feature crashes LabVIEW
* Description: Status: Filed with NI support (CAR #4da9pok8)

==Linking to Your Bug Report on the Monthly Bug Thread==
In order to give NI visibility into your bug, you should post a link to it on the ''Monthly Bug'' thread in the [http://forums.ni.com/ni/board?board.id=BreakPoint Breakpoint forum] on ni.com. NI's support engineers use this to create an index of all publicly reported bugs and will use this index to provide the community with updates when the status of a bug changes.

The easiest way to find the latest Monthly Bug thread is to look at [http://forums.ni.com/ni/search?index=public&without=Re%3A&ratingend=&type=message&ratingstart=&q=Monthly+Bugs&page_size=10&phrase=&advanced=true&f=subject&f=body&one_or_more=&author=&board_id=BreakPoint&submitted=true&sort_by=-date this search results page]. The latest thread should be at the top of the search results list.

==See Also==
*[[CAR Number]]

File:4DA9POK8-IMG06.png

2007-09-13T21:03:02Z

Jim kring:

File:4DA9POK8-IMG05.png

2007-09-13T21:02:29Z

Jim kring:

File:4DA9POK8-IMG04.png

2007-09-13T21:01:12Z

Jim kring:

File:4DA9POK8-IMG03.png

2007-09-13T21:00:48Z

Jim kring:

File:4DA9POK8-IMG02.png

2007-09-13T20:59:14Z

Jim kring:

File:4DA9POK8-IMG01.png

2007-09-13T20:58:40Z

Jim kring:

LabVIEW Bug Reporting

2007-09-13T16:54:17Z

Jim kring: /* Posting a Bug Report on the LAVA Forums */

This article describes the process required for reporting bugs in LabVIEW.

==Requirements of a Good Bug Report==
Good bug reports should '''always''' include the following:
# Steps to reproduce
# What happened
# What you expected to happened
This information is needed to confirm that what you are seeing is actually a bug and to help figure out what is causing the buggy behavior. It is also a great idea to include any example code that demonstrates the bug and/or screenshots of the bug.

==Reporting Bugs to National Instruments==
If you have a bug to report to NI, go to http://ni.com/ask to
submit a phone support request. If you specify that you are reporting a
bug, you should be connected to an Applications Engineer who can help you
by filing the appropriate bug report.

If you select Phone NI, and you have a valid service contract, you will be routed to
Applications Engineers who can file the appropriate bug report. If you do
not have a valid service contract, you are routed to an intermediary
person who can pass you through to an Applications Engineer, provided you
are calling to report a bug.

If your bug ''is'' in fact a bug, ask for a [[CAR Number]] -- this is how your bug is uniquely identified and can be used to track its status. When you get a CAR Number you should update your posting in the [http://forums.lavag.org/Bug-Lists-f17.html Bug Lists] forum to include this CAR Number.

==Posting a Bug Report on the LAVA Forums==
There is a [http://forums.lavag.org/Bug-Lists-f17.html Bug Lists] forum on LAVA. This should be used for reporting confirmed bugs with a [[CAR Number]]. If a posting in the [http://forums.lavag.org/Bug-Lists-f17.html Bug Lists] forum is determined to not be a bug, it will be moved into another forum. Also, you can use the [http://forums.lavag.org/LabVIEW-General-f10.html LabVIEW General] discussion forum to discuss the issue with other LAVA members before creating a more official posting in the [http://forums.lavag.org/Bug-Lists-f17.html Bug Lists] forum.

Bug report topics should be titled with a short description of the bug. The description of the topic should be used for status and [[CAR Number]]. For example, see the [http://forums.lavag.org/Move-on-disk-feature-crashes-LabVIEW-t9040.html "Move on disk" feature crashes LabVIEW] bug. Notice how it has a clear title and description:

* Title: "Move on disk" feature crashes LabVIEW
* Description: Status: Filed with NI support (CAR #4da9pok8)

==See Also==
*[[CAR Number]]

LabVIEW Bug Reporting

2007-09-13T16:48:37Z

Jim kring: /* Reporting Bugs to National Instruments */

LabVIEW Bug Reporting

2007-09-13T16:45:39Z

Jim kring:

LabVIEW FAQ

2007-09-13T16:32:39Z

Jim kring: /* Getting Started */

=== Getting Started ===

*[[G|What is G?]]
*[[LabVIEW#Learning_LabVIEW|How can I learn more about LabVIEW?]]
*[[LabVIEW_Bug_Reporting|How do I report a LabVIEW bug?]]
*[[OpenG|What is OpenG?]]

=== General ===

*[[State_Machine|What is a State Machine?]]
*[[While_Loop|Is the while loop really a while loop?]]
*[[Numeric|Is there a NaN equivalent for integer data types?]]
*[[Style_Guide|What is good LabVIEW programming style?]]

=== [[Application Builder]], Installers and [[code distribution]] ===

*[[Run-Time_Engine_Limitations|Why doesn't the VI method "Make Current Values Default" work?]]
*[[How_to_Build_an_Executable|How do I build an executable?]]

=== Application Design & Architecture ===

*[[Functional_Globals|What are LabVIEW 2 style globals?]]
*[[State_Machine|What is a state machine?]]

=== [[External Code]] ===

*[[Excel|How do I write data to an Excel spreadsheet?]]

=== [[Database]] and [[File IO]] ===

*[[File_IO|How do I rename a file?]]

=== [[Hardware]] ===

* [[Serial#Printing_to_a_line_printer|How do I print to a line printer?]]
* [[Serial#Find_a_single_character_in_a_serial_input_stream|How do I find a single character in a serial stream?]]
* [[Serial#Using_a_Modem_to_Send_Data|Can I use a modem to send data?]]
* [[Serial#Using_a_modem_to_send_an_audio_message|How do I use a modem to send an audio message?]]
* [[Instrument_Control#Troubleshooting_VISA_sessions|Why doesn't my VISA session work?]]
* [[Instrument_Control#Releasing_control_over_an_instrument|How do I release control over an instrument?]]
* [[FieldPoint|Why don't the Fieldpoint examples use FP Read?]]

=== [[LabVIEW]] Development Environment ===

* [[Multiple_Instances_of_LabVIEW|How to run multiple instances of LabVIEW?]]
* [[Insane_Objects|What does an "Insane Object" mean?]]

LabVIEW FAQ

2007-09-13T16:31:55Z

Jim kring: /* Getting Started */

=== Getting Started ===

*[[G|What is G?]]
*[[LabVIEW#Learning_LabVIEW|How can I learn more about LabVIEW?]]
*[[LabVIEW#Reporting_LabVIEW_Bugs|LabVIEW_Bug_Reporting]]
*[[OpenG|What is OpenG?]]

=== General ===

*[[State_Machine|What is a State Machine?]]
*[[While_Loop|Is the while loop really a while loop?]]
*[[Numeric|Is there a NaN equivalent for integer data types?]]
*[[Style_Guide|What is good LabVIEW programming style?]]

=== [[Application Builder]], Installers and [[code distribution]] ===

*[[Run-Time_Engine_Limitations|Why doesn't the VI method "Make Current Values Default" work?]]
*[[How_to_Build_an_Executable|How do I build an executable?]]

=== Application Design & Architecture ===

*[[Functional_Globals|What are LabVIEW 2 style globals?]]
*[[State_Machine|What is a state machine?]]

=== [[External Code]] ===

*[[Excel|How do I write data to an Excel spreadsheet?]]

=== [[Database]] and [[File IO]] ===

*[[File_IO|How do I rename a file?]]

=== [[Hardware]] ===

* [[Serial#Printing_to_a_line_printer|How do I print to a line printer?]]
* [[Serial#Find_a_single_character_in_a_serial_input_stream|How do I find a single character in a serial stream?]]
* [[Serial#Using_a_Modem_to_Send_Data|Can I use a modem to send data?]]
* [[Serial#Using_a_modem_to_send_an_audio_message|How do I use a modem to send an audio message?]]
* [[Instrument_Control#Troubleshooting_VISA_sessions|Why doesn't my VISA session work?]]
* [[Instrument_Control#Releasing_control_over_an_instrument|How do I release control over an instrument?]]
* [[FieldPoint|Why don't the Fieldpoint examples use FP Read?]]

=== [[LabVIEW]] Development Environment ===

* [[Multiple_Instances_of_LabVIEW|How to run multiple instances of LabVIEW?]]
* [[Insane_Objects|What does an "Insane Object" mean?]]

Functional global variable

2007-09-10T23:02:12Z

Jim kring: /* Performance */

Functional Globals are VIs that allow controlled access to data or resources, often allowing various actions to be performed. Functional Globals (FGs) most often make use of uninitialized shift registers (USRs). USRs are shift registers that do not have a wired input coming into the left side of the loop. A USR stores its data between successive runs of the VI as long as the VI remains in memory.

==Alternative Nomenclature==
Functional Globals are known by various names among LabVIEW programmers.
*LV2 globals – because LV2 supported uninitialized shift registers
*USR globals – since most FGs make use of uninitialized shift registers
* VIG - "VI Global" as the VI performs the functionality of a global
*Action Engines – it has been argued [http://forums.ni.com/ni/board/message?board.id=170&message.id=240328&query.id=618807#M240328] that the term Functional Globals should refer to VIs that just allow read/write access to data. Action Engines would refer to the larger set of VIs that allow some defined action on the data.

The official name for these constructs in NI literature is Functional Global Variable, and a [http://forums.lavag.org/index.php?showtopic=2469&st=0 survey] on LAVA indicated that Functional Globals is also the most popular choice.

==Structure==
The most common form of a Functional Global is a [[While Loop]] with a TRUE wired to the stop condition. This forces the loop to terminate after just one execution, meaning the while loop is only used to provide a place to put USRs. A [[For Loop]] could also be used with a constant wired to the count terminal. Another method is to use a single-element queue to store the data, though this requires more mouse clicks to implement. The performance of each of these is very close and most likely will vary a little from computer to computer.

[[Image:Simple_FG.PNG|frame|center|Simple Functional Global using a While Loop]]

In order to specify what action to perform, an [[enumerated type]] is often used as an input to the Functional Global. Other methods are possible (Booleans, First Call?, etc.), but an enumerated type provides for a readable, extensible list of actions. Furthermore, saving the enumerated type as a typedef control makes any changes to the list automatically update wherever the Functional Global is used in the code. The ‘action’ input is fed to a case structure which contains the code to implement for each of the defined actions.

For more complex situations, multiple actions can be performed on a single call to the FG. This can be a straightforward [[state machine]], or it can allow for different actions based on the data received or on the existence of resources, etc.

The data in a Functional Global could be of any type, but very often there will be several data elements in a single FG. It is helpful to group the data into a cluster to limit the number of wires entering and leaving the FG. Designing the data structures and how you cluster your data should be done early on, rather than haphazardly growing your clusters as you grow your program.

In order to deal with varying input requirements on the different actions, one can create ‘wrappers’ around the Functional Global that allow for different inputs to be required. This also gives the benefit of being able to search your code for certain actions as you can search for a specific VI, but not a specific enumerated type’s value.

==Uses==
The primary use of Functional Globals is to provide data sharing across an entire project, both horizontally and vertically. Horizontal sharing means multiple top-level VIs running autonomously can all have access to the same data. Vertical sharing means that subVIs at any depth will have access to the data without requiring explicit passing of parameters through VI [[connector pane]] terminals. These are common issues in even small-sized programs.

Another common use is to encapsulate some functionality, especially functionality that is linked to persistent data or resources like files or devices. This encapsulation protects the resource and provides an extensible interface for interacting with the data or resource. The encapsulation also allows you to avoid a plethora of shift registers in a single VI. You can offload the shift-register to the Functional Global, and call it when needed, without worrying about wiring the data through all your case structures.

To get a better idea of what can be done with Functional Globals, here is a list of things that can be done:
*Load information from a file into a FG, access it anywhere in your program
*Maintain your system’s configuration parameters in one location.
*Store a control reference (like a tree control) in a FG, and then define an interface to manage that control. For complex controls like trees and multi-column listboxes this can simplify your top-level code.
*Timers are well implemented with FGs. You can keep the start time in the shift register, and then check the elapsed time when you call it again.
*Automatically preallocate an array when the FG is first called, then use “Replace Array Subset” to efficiently manipulate the array.
*Keep an ‘Undo’ list (stack) that allows you to push changes onto a stack, and pop them off when you need to undo the change.
The list could go on and on – whatever you can dream up!

==Race Conditions and Locking==
One of the main reasons that Functional Globals are encouraged in lieu of [[global variable]]s is race conditions. The majority of Functional Globals are, by definition, not reentrant so that different calls to the FG will all refer to the same shift registers and hence the same data or resource. This means that when a VI calls a FG, that FG is locked or reserved for use by the calling VI. Other VIs need to wait until it is done before they can call the FG.

Global variables are reentrant. If you try to write a value to the global in several places in your code, updates to the value are unpredictable with respect to time. This means that changes to the global can be subject to race conditions. This is especially true if you read/write to the global where a race condition could occur between the read and the write of the variable.

The downside for Functional Globals is that the locking that takes place can be a bottleneck in the code if many VIs are trying to access the FG at the same time. The majority of applications will not have a problem, but care must be taken if speed is a concern.

It is also important to note that Functional Globals are not a cure-all for race conditions. If actions on the Functional Global are not atomic (i.e. they require more than one call to the FG) then race conditions are still possible. Race conditions are only eliminated if all updates to the data are done inside the FG, in a single call. Here are a couple ways to still allow race conditions with FGs.
*Ask for the data from the FG, change it, and then write it back to the FG.
*Successive modifications, such as {Set data, normalize data, sort data, output max} By the time you sort the data, new data could have been set that hasn’t been normalized.

==Benefits==
#Efficient Memory Usage – Because the VI retains the same data space regardless of it use in the code, only a single call to the memory manager is made. If arrays are stored in the USR, and replace array element primitives used, then the memory space is efficiently used wherever the VI is called.
#Reduces problems with race conditions, as discussed above.
#Error checking can be done on data writes (Global variables don’t allow this).
#High-level code more readable – By moving shift registers and code logic into Functional Globals with readable action lists, top-level code become simpler and cleaner.
#Reuse. Many FGs are generic enough to be used over and over again.

==Concerns==
===Busy connector panes===
Terminals get used up quickly, so be sure to design well up front and choose a connector pane with more terminals than you need. You can avoid excessive terminal usage by grouping all of your data into a cluster (preferably, a [[Type Definition]]) that is passed in and out of your functional global which will allow you to bundle and unbundle specific variables as needed on your main VI.

===Data Persistence===
Data in a USR, and hence in a Functional Global, disappears if the owning VI goes out of memory. When a VI runs for the first time, all of its subVIs that are not already in memory are loaded into memory and they belong to that parent VI. If that parent VI is stopped, all of the subVIs that belong to it are also released from memory – even if there are other VIs in memory still referencing those subVIs. The next time one of those subVIs is run, it is loaded into memory again and that calling VI becomes the new parent VI. But if there was anything stored in USRs, that data is now gone.

This behavior is different from a queue reference, for instance, where the queue is only destroyed when ALL VIs referencing it leave memory. It means that if you use Functional Globals across multiple top-level VIs, then you need to have a VI that is run first and contains all of your Functional Globals as subVIs. This ‘First Run’ VI must stay in memory until all other top-level VIs are closed to insure that the Functional Global data will be available.

===Performance===
Some testing has shown that, as of LabVIEW 8.5, using a [[Case Structure]] performs better (from 1.5x to 3x) than a [[Select function]] for controlling the data flow of the Set/Write vs. the Get/Read operation.

==Reentrant functional globals==
===Unshared data===
There are certain problems where you do not need to share the persistent data elsewhere in the code. If you create a '''windowed average''' VI, it can be made reentrant and can be used in multiple places in your code to average data streams. This is an example of an in-place operation that is not shared, but requires persistent data. Timing a process in a single loop could be done with one instance of a Functional Global. Making this timing FG reentrant allows the developer to use that same timing FG to time other processes. See [[Reentrant VI]] for more information.

===By reference===
It’s possible to make use of reentrancy to duplicate functional globals. This allows to create as many globals as you need (even at run time) without duplicating code or modifying the original FG. The main disadvantage of this technique is the necessity to keep a reference to every instance of the functional global and pass them to the VIs or subVIs that will use them.

With this method, the only change to the original FG is to make the VI reentrant. Keep in mind that, from now on, this functional global can’t be used in the habitual way, since any instance will retain its own values.

To create an instance of the functional global, open it with the '''Open VI Reference''' function (use option 0x08 to prepare for reentrant run) and use the output reference to set the control values, run the VI and get the results. To facilitate things an avoid mistakes when getting/setting values, may be advisable to use the '''Call by Reference node'''. Furthermore, the encapsulation of the FG actions in specific wrappers, as detailed in the Structure section above, is also useful.

==See Also==
*[[Global variable]]
*[[State machine]]

==External Links==
*[http://forums.lavag.org/LV2OO-Style-Global-v20-from-NI-Week-presentation-t8780.html LAVA forum discussion about LV2OO-style globals]
*[http://forums.ni.com/ni/board/message?board.id=170&message.id=240328&query.id=618807#M240328 NI Forums Community Nugget on Action Engines]
*[http://zone.ni.com/reference/en-XX/help/371361A-01/lvconcepts/suggestions_for_exec/#Functional_Global_Variables NI Documentation on Functional Global Variables]

Functional global variable

2007-09-10T23:01:33Z

Jim kring: Added "Performance" subsection of "Concerns" section to show

Functional Globals are VIs that allow controlled access to data or resources, often allowing various actions to be performed. Functional Globals (FGs) most often make use of uninitialized shift registers (USRs). USRs are shift registers that do not have a wired input coming into the left side of the loop. A USR stores its data between successive runs of the VI as long as the VI remains in memory.

==Alternative Nomenclature==
Functional Globals are known by various names among LabVIEW programmers.
*LV2 globals – because LV2 supported uninitialized shift registers
*USR globals – since most FGs make use of uninitialized shift registers
* VIG - "VI Global" as the VI performs the functionality of a global
*Action Engines – it has been argued [http://forums.ni.com/ni/board/message?board.id=170&message.id=240328&query.id=618807#M240328] that the term Functional Globals should refer to VIs that just allow read/write access to data. Action Engines would refer to the larger set of VIs that allow some defined action on the data.

The official name for these constructs in NI literature is Functional Global Variable, and a [http://forums.lavag.org/index.php?showtopic=2469&st=0 survey] on LAVA indicated that Functional Globals is also the most popular choice.

==Structure==
The most common form of a Functional Global is a [[While Loop]] with a TRUE wired to the stop condition. This forces the loop to terminate after just one execution, meaning the while loop is only used to provide a place to put USRs. A [[For Loop]] could also be used with a constant wired to the count terminal. Another method is to use a single-element queue to store the data, though this requires more mouse clicks to implement. The performance of each of these is very close and most likely will vary a little from computer to computer.

[[Image:Simple_FG.PNG|frame|center|Simple Functional Global using a While Loop]]

In order to specify what action to perform, an [[enumerated type]] is often used as an input to the Functional Global. Other methods are possible (Booleans, First Call?, etc.), but an enumerated type provides for a readable, extensible list of actions. Furthermore, saving the enumerated type as a typedef control makes any changes to the list automatically update wherever the Functional Global is used in the code. The ‘action’ input is fed to a case structure which contains the code to implement for each of the defined actions.

For more complex situations, multiple actions can be performed on a single call to the FG. This can be a straightforward [[state machine]], or it can allow for different actions based on the data received or on the existence of resources, etc.

The data in a Functional Global could be of any type, but very often there will be several data elements in a single FG. It is helpful to group the data into a cluster to limit the number of wires entering and leaving the FG. Designing the data structures and how you cluster your data should be done early on, rather than haphazardly growing your clusters as you grow your program.

In order to deal with varying input requirements on the different actions, one can create ‘wrappers’ around the Functional Global that allow for different inputs to be required. This also gives the benefit of being able to search your code for certain actions as you can search for a specific VI, but not a specific enumerated type’s value.

==Uses==
The primary use of Functional Globals is to provide data sharing across an entire project, both horizontally and vertically. Horizontal sharing means multiple top-level VIs running autonomously can all have access to the same data. Vertical sharing means that subVIs at any depth will have access to the data without requiring explicit passing of parameters through VI [[connector pane]] terminals. These are common issues in even small-sized programs.

Another common use is to encapsulate some functionality, especially functionality that is linked to persistent data or resources like files or devices. This encapsulation protects the resource and provides an extensible interface for interacting with the data or resource. The encapsulation also allows you to avoid a plethora of shift registers in a single VI. You can offload the shift-register to the Functional Global, and call it when needed, without worrying about wiring the data through all your case structures.

To get a better idea of what can be done with Functional Globals, here is a list of things that can be done:
*Load information from a file into a FG, access it anywhere in your program
*Maintain your system’s configuration parameters in one location.
*Store a control reference (like a tree control) in a FG, and then define an interface to manage that control. For complex controls like trees and multi-column listboxes this can simplify your top-level code.
*Timers are well implemented with FGs. You can keep the start time in the shift register, and then check the elapsed time when you call it again.
*Automatically preallocate an array when the FG is first called, then use “Replace Array Subset” to efficiently manipulate the array.
*Keep an ‘Undo’ list (stack) that allows you to push changes onto a stack, and pop them off when you need to undo the change.
The list could go on and on – whatever you can dream up!

==Race Conditions and Locking==
One of the main reasons that Functional Globals are encouraged in lieu of [[global variable]]s is race conditions. The majority of Functional Globals are, by definition, not reentrant so that different calls to the FG will all refer to the same shift registers and hence the same data or resource. This means that when a VI calls a FG, that FG is locked or reserved for use by the calling VI. Other VIs need to wait until it is done before they can call the FG.

Global variables are reentrant. If you try to write a value to the global in several places in your code, updates to the value are unpredictable with respect to time. This means that changes to the global can be subject to race conditions. This is especially true if you read/write to the global where a race condition could occur between the read and the write of the variable.

The downside for Functional Globals is that the locking that takes place can be a bottleneck in the code if many VIs are trying to access the FG at the same time. The majority of applications will not have a problem, but care must be taken if speed is a concern.

It is also important to note that Functional Globals are not a cure-all for race conditions. If actions on the Functional Global are not atomic (i.e. they require more than one call to the FG) then race conditions are still possible. Race conditions are only eliminated if all updates to the data are done inside the FG, in a single call. Here are a couple ways to still allow race conditions with FGs.
*Ask for the data from the FG, change it, and then write it back to the FG.
*Successive modifications, such as {Set data, normalize data, sort data, output max} By the time you sort the data, new data could have been set that hasn’t been normalized.

==Benefits==
#Efficient Memory Usage – Because the VI retains the same data space regardless of it use in the code, only a single call to the memory manager is made. If arrays are stored in the USR, and replace array element primitives used, then the memory space is efficiently used wherever the VI is called.
#Reduces problems with race conditions, as discussed above.
#Error checking can be done on data writes (Global variables don’t allow this).
#High-level code more readable – By moving shift registers and code logic into Functional Globals with readable action lists, top-level code become simpler and cleaner.
#Reuse. Many FGs are generic enough to be used over and over again.

==Concerns==
===Busy connector panes===
Terminals get used up quickly, so be sure to design well up front and choose a connector pane with more terminals than you need. You can avoid excessive terminal usage by grouping all of your data into a cluster (preferably, a [[Type Definition]]) that is passed in and out of your functional global which will allow you to bundle and unbundle specific variables as needed on your main VI.

===Data Persistence===
Data in a USR, and hence in a Functional Global, disappears if the owning VI goes out of memory. When a VI runs for the first time, all of its subVIs that are not already in memory are loaded into memory and they belong to that parent VI. If that parent VI is stopped, all of the subVIs that belong to it are also released from memory – even if there are other VIs in memory still referencing those subVIs. The next time one of those subVIs is run, it is loaded into memory again and that calling VI becomes the new parent VI. But if there was anything stored in USRs, that data is now gone.

This behavior is different from a queue reference, for instance, where the queue is only destroyed when ALL VIs referencing it leave memory. It means that if you use Functional Globals across multiple top-level VIs, then you need to have a VI that is run first and contains all of your Functional Globals as subVIs. This ‘First Run’ VI must stay in memory until all other top-level VIs are closed to insure that the Functional Global data will be available.

===Performance===
Some testing has shown that, as of LabVIEW 8.5, using a [[Case Structure]] performs better (from 1.5x to 3x) than a [Select function] for controlling the data flow of the Set/Write vs. the Get/Read operation.

==Reentrant functional globals==
===Unshared data===
There are certain problems where you do not need to share the persistent data elsewhere in the code. If you create a '''windowed average''' VI, it can be made reentrant and can be used in multiple places in your code to average data streams. This is an example of an in-place operation that is not shared, but requires persistent data. Timing a process in a single loop could be done with one instance of a Functional Global. Making this timing FG reentrant allows the developer to use that same timing FG to time other processes. See [[Reentrant VI]] for more information.

===By reference===
It’s possible to make use of reentrancy to duplicate functional globals. This allows to create as many globals as you need (even at run time) without duplicating code or modifying the original FG. The main disadvantage of this technique is the necessity to keep a reference to every instance of the functional global and pass them to the VIs or subVIs that will use them.

With this method, the only change to the original FG is to make the VI reentrant. Keep in mind that, from now on, this functional global can’t be used in the habitual way, since any instance will retain its own values.

To create an instance of the functional global, open it with the '''Open VI Reference''' function (use option 0x08 to prepare for reentrant run) and use the output reference to set the control values, run the VI and get the results. To facilitate things an avoid mistakes when getting/setting values, may be advisable to use the '''Call by Reference node'''. Furthermore, the encapsulation of the FG actions in specific wrappers, as detailed in the Structure section above, is also useful.

==See Also==
*[[Global variable]]
*[[State machine]]

==External Links==
*[http://forums.lavag.org/LV2OO-Style-Global-v20-from-NI-Week-presentation-t8780.html LAVA forum discussion about LV2OO-style globals]
*[http://forums.ni.com/ni/board/message?board.id=170&message.id=240328&query.id=618807#M240328 NI Forums Community Nugget on Action Engines]
*[http://zone.ni.com/reference/en-XX/help/371361A-01/lvconcepts/suggestions_for_exec/#Functional_Global_Variables NI Documentation on Functional Global Variables]

File:System Label.png

2007-08-28T23:32:31Z

Jim kring:

System Label

2007-08-28T23:32:14Z

Jim kring: New page: A '''System Label''' is a text decoration found on the ''Controls>>System'' palette. It is very useful because it's background and border inherit (adapt automatically) to the color of the...

A '''System Label''' is a text decoration found on the ''Controls>>System'' palette. It is very useful because it's background and border inherit (adapt automatically) to the color of the block diagram or front panel objects they are placed upon. This makes them useful for labeling wires as a form of code commenting.

[[Image:System Label.png]]

Error Case Structure

2007-08-28T23:14:29Z

Jim kring:

And '''Error Case Structure''' is term that describes a [[Case Structure]] that has an [[Error Cluster]] wired to its selector terminal, which causes it's two possible cases to be ''No Error'' (showing a green frame) and ''Error'' (showing a red frame).

[[Image:Error Case Structure.png]]

== External Links ==
* [http://zone.ni.com/reference/en-XX/help/371361B-01/lvconcepts/case_and_sequence_structures/ Case and Sequence Structures] (LabVIEW 8.2 Help Documentation)

Error Case Structure

2007-08-28T23:13:47Z

Jim kring:

And '''Error Case Structure''' is term that describes a [[Case Structure]] that has an [[Error Cluster]] wired to its selector terminal, which causes it's two possible cases to be ''Error'' (showing a green frame) and ''No Error'' (showing a red frame).

[[Image:Error Case Structure.png]]

== External Links ==
* [http://zone.ni.com/reference/en-XX/help/371361B-01/lvconcepts/case_and_sequence_structures/ Case and Sequence Structures] (LabVIEW 8.2 Help Documentation)

File:Error Case Structure.png

2007-08-28T23:12:01Z

Jim kring:

Error Case Structure

2007-08-28T23:11:40Z

Jim kring: New page: And '''Error Case Structure''' is term that describes a Case Structure that has an Error Cluster wired to its selector terminal, which causes it's two possible cases to be ''Error'...

And '''Error Case Structure''' is term that describes a [[Case Structure]] that has an [[Error Cluster]] wired to its selector terminal, which causes it's two possible cases to be ''Error'' (showing a green frame) and ''No Error'' (showing a red frame).

[[Image:Error Case Structure.png]]

!! External Links
* [http://zone.ni.com/reference/en-XX/help/371361B-01/lvconcepts/case_and_sequence_structures/ Case and Sequence Structures] (LabVIEW 8.2 Help Documentation)

Case structure

2007-08-28T23:06:03Z

Jim kring: New page: This is a stub article for '''Case Structure'''.

This is a stub article for '''Case Structure'''.

LabVIEW object-oriented programming FAQ

2007-08-13T22:36:23Z

Jim kring: /* How can I create by active objects? */

This is a stub page for Frequently Asked Questions (FAQ) about LVOOP. Please feel free to add to the list of FAQ and answer any of the questions that have been posted.

==Why is class data private?==

==What are the differences between public, protected, and private class members?==

==Why are there no class constructor and destructor?==

==Are objects by value or by reference?==

==What does LVOOP mean?==

==How can I create by reference objects?==

==How can I create active objects?==

==Are there any add on tools for LVOOP?==

==What does the "Dynamic Dispatch" connector pane terminal setting do?==

==Are there any add on tools for LVOOP?==

LabVIEW object-oriented programming FAQ

2007-08-13T22:29:27Z

Jim kring: New page: This is a stub page for Frequently Asked Questions (FAQ) about LVOOP. Please feel free to add to the list of FAQ and answer any of the questions that have been posted. ==Why is class dat...

This is a stub page for Frequently Asked Questions (FAQ) about LVOOP. Please feel free to add to the list of FAQ and answer any of the questions that have been posted.

==Why is class data private?==

==What are the differences between public, protected, and private class members?==

==Why are there no class constructor and destructor?==

==Are objects by value or by reference?==

==What does LVOOP mean?==

==How can I create by reference objects?==

==How can I create by active objects?==

==Are there any add on tools for LVOOP?==

==What does the "Dynamic Dispatch" connector pane terminal setting do?==

==Are there any add on tools for LVOOP?==

Graphical Object-Oriented Programming

2007-08-13T22:22:40Z

Jim kring: Added link to new page "LVOOP Frequently Asked Questions"

This is the Portal for GOOP and LabVOOP.

GOOP stands for "Graphical Object-Oriented Programming."
LabVOOP stands for "LabVIEW Object-Oriented Programming."

GOOP is a term used to refer to the various GOOP toolkits from Endevo/NI, SciWare and OpenG. These toolkits were written in G.

LabVOOP refers to the native LabVIEW classes that first appeared in LV8.2.

The toolkits were not obsoleted by the native implementation. All of the toolkits use a reference model for passing objects on the block diagram, similar to File refnums or Queue refnums in LabVIEW. The native classes pass by value, similar to clusters and arrays. The two mechanisms are complementary, not exclusionary, and there may be times when both approaches are used in the same LV program.

==Pages Here:==
*[[GOOP - Graphical Object Oriented Programming]]
*[[History of GOOP]]
*[[LVOOP|LabVOOP - LabVIEW Object-Oriented Programming (aka LVOOP)]]
*[[LVOOP Frequently Asked Questions]]

[[Category:GOOP]]

Race condition

2007-06-20T14:56:40Z

Jim kring: Added "External Links">>Race Condition (Wikipedia Definition)

A race condition in LabVIEW occurs when two or more sections of code attempt to update a common variable. This often occurs when local or global variables are overused.

== Before ==

[[Image:Race_Condition.png|frame|center|Example Race Condition]]

The first 16 bytes of the file will be read by the left instance of Read Characters From File.vi. '''Offset''' will be set to 16, '''BUT''' the loop at the right ''may'' start and read 22 bytes from the default value of '''Offset''' rather than the expected 16.

== After ==

[[Image:No_Race_Condition.png||frame|center|Race Condition Eliminated Using Data Flow]]

Data flow will ensure that this VI reads 16 bytes from the beginning of the file, then 22 bytes at a time for 16 iterations.

== Summary ==

Local and global variables can break the data flow model. If Read and Write instances of local or global variables exist on a single block diagram, they are often part of a loop structure. Variable instances should be replaced with a shift register and data written directly to the control.

== External Links ==

* [http://en.wikipedia.org/wiki/Race_condition Race Condition] (Wikipedia Definition)

Help:Tracking changes

2007-06-16T05:43:07Z

Jim kring: Added note about RSS feed of recentchanges page

[[Image:Recentchanges.png|thumb|370px|'''Recent changes''' shows the latest changes to articles, file uploads, deletions and page moves]]
The LabVIEW Wiki offers a collection of special pages and tools to keep track of what is going on in the wiki. So you can watch for example:
* recent changes to all pages
* newly created pages
* the contributions of one specific user
* the revision history: all changes made to one page

The most interesting special page is '''[[Special:Recentchanges]]'''. It displays all edits, file uploads, page moves, deletions and other actions done in the wiki. In the menu on top it offers a collection of links to customize your display: limit the number of changes shown, the number of days or restrict it to edits to a certain namespace. You can also hide edits marked as minor (don't forget that major changes can be flagged by a user as minor anyway). Additionally, the recentchanges page has an RSS feed, which allows you to subscribe to these changes using an RSS reader.

One line in recentchanges consists of several links:
* ''diff'' displays the difference to the previous revision of the page,
* ''hist'' links to the revision history of the page,
* the link with the full title of the page brings you to the current version. If the title is in bold, it indicates that it is on your watchlist.

Next is a flag describing the article modification type:
*''N'' signalizes a new page,
*''m'' a minor edit,
*''b'' an edit made by a bot.

Following the timestamp the user is mentioned with a link to his user and talk page and to his contributions. In italic follows a comment if the user has submitted one.

=== See also ===
* [[Special:Newpages]]
* Related changes: [[Special:Recentchangeslinked/Pagename]]
* User contributions: [[Special:Contributions/User]]
* History
* [[Special:Watchlist]]

[[Category:Help|Tracking changes]]

Strict Type Definition

2007-06-13T13:56:08Z

Jim kring: fixed spelling

A strict type definition [STD] is like a [[Type Definition|type definition]] with well-defined appearance. This means that all instances of STD's share the appearance of that STD, e.g. their properties cannot be changed (except of label, caption and enable-state). This is handy whenever the size, color etc. needs to be fixed. Think of sophisticated screen designs or stacked STDs. 
STDs are created by saving as this type of control - similar to 'simple' type definitions.

==See Also==
* [[Type Definition]]

==External Links==
* Creating Type Definitions and Strict Type Definitions[http://zone.ni.com/reference/en-XX/help/371361B-01/lvhowto/creating_type_defs/]

[[Category:User Interface]]

Time stamp

2007-06-08T02:15:01Z

Jim kring: New page: A time stamp is a data type for storing absolute time with high precision. It is a time-zone-independent number of seconds that have elapsed since 12:00 a.m., Friday, January 1, 1904,...

A [[time stamp]] is a data type for storing absolute time with high precision. It is a time-zone-independent number of seconds that have elapsed since 12:00 a.m., Friday, January 1, 1904, Universal Time. In memory, LabVIEW stores a time stamp as a cluster of four integers, where the first two integers (64 bits) represent the time-zone-independent number of complete seconds that have elapsed since 12:00 a.m., Friday, January 1, 1904, Universal Time. The next two integers (64 bits) represent the fractions of seconds.

==Links==

*[http://zone.ni.com/reference/en-XX/help/371361B-01/lvconcepts/how_labview_stores_data_in_memory/ LabVIEW 8.2 Help>>How LabVIEW Stores Data in Memory]
*[http://zone.ni.com/reference/en-XX/help/371361B-01/lvhowto/numeric_data_types_table/ LabVIEW 8.2 Help>>Numeric Data Types Table]

Associate your own file type with Windows Explorer

2007-05-24T16:49:54Z

Jim kring: Added "Note about custom file type handing in LabVIEW 8.2" section at the head of the document

== Note about custom file type handing in LabVIEW 8.2 ==
In LabVIEW 8.2 an Application event called "OS Open Document" exists, which provides a LabVIEW native way to handle custom file types. See [http://forums.lavag.org/index.php?showtopic=6456&view=findpost&p=25424 this LAVA posting] for information.

== Guidelines to open your own file type from Windows Explorer ==
When the user double-clicks on a document, the Registration Database is checked for an entry that associates the file extension with a particular application. If an entry does not specify Dynamic Data Exchange (DDE) command, the application specified in the registry is launched. If the registry specifies to use DDE commands, an attemp is made to establish a DDE communication with that application using the application topic. If an application responds to the DDE connection, a DDE Execute command is sent to the application, as specified in the registry. However, if attempts to establish the DDE conversation fail, the specified application is launched and the DDE connection is tried again.

== File associations and LabVIEW ==
LabVIEW registers the file extensions *.vi, *.vit, *.ctl, *.ctt and *.llb in order to open these files when the user double-clicks on them. A LabVIEW standalone application registers file extensions *.vi and *.llb when its configuration file (.ini) contains the line RegisterExtensions? = True. However this allows LabVIEW to open its own files and does not provide a mechanism for your application to open its custom files using registered extensions.

For example, your application reads and writes custom data files to which you consistently give the extension ".myx". One thing you can do is to associate the file extension (no DDE command) to your application. When your application is not running, double-clicking on a .myx file launches your application and you can make a system call to read the command line from which you extract the file name to act upon. Remember that, whatever its extension, LabVIEW first tries to open the command line file to figure out if it is a LabVIEW file that it can open (VI, control or LLB).

Once your application is running, double-clicks on your custom file starts a second instance of your application. This instance detects that there is already an instance running so it sends the command line information to the first instance through a DDE Execute command and terminates. The first instance receives the command line; if there is no VI or LLB paths to open, the command is discarded. Currently, there is no way to recover this command line because you have no access to the application built-in DDE Server. Therefore user double-clicks have no effects when your application is running.

In order to receive DDE Execute commands, you would have to, after having properly registered DDE commands in the registry, implement in your application a DDE Server that responds to the DDE Execute commands sent by the system. Unfortunately, altough LabVIEW DDE Client palette offers a DDE Execute.vi that can be used to send commands to other application to open files, the DDE Execute server function is not supported. Such a function would allow to receive the commands sent from the system on user double-clicks (or other applications DDE clients).

DDE being a legacy from Windows 16 bits OS, it is a fading out inter-application communication mechanism. In the latest version of LabVIEW, DDE VIs are still supported but have disappeared from the default palette. Therefore it is very unlikely that DDE VIs will ever be enhanced to support DDE Execute function. One could write a DLL that fully supports DDE, but given the obsolescence of the mechanism, it would be a waste of time.

There are alternatives that we can use to emulate in part the file opening from the file system. The workaround to DDE is to have another executable intercept the command line each time your files are double-clicked on, transmit it to your application and terminate. I will describe three ways below but first let's see how you can register custom file extensions.

== Register a File Extension ==
You register file extensions in Windows Registration Database running the regedit.exe application with a text file that contains the keys and values to register. For example, if you want to open .myx extensions with the application myx.exe (or myx.bat or other executable files) located in c:\myx directory, you create the file myx.reg with the following lines:

[code]
REGEDIT

HKEY_CLASSES_ROOT\.myx = myxfile

HKEY_CLASSES_ROOT\myxfile = My Custom Data File

HKEY_CLASSES_ROOT\myxfile\shell\open\command = c:\myx\myx.exe "%1"
[/code]

You register the file association from your application using System Exec.vi with the input string

[code]"regedit.exe /s c:\myx\myx.reg"[/code]

Alternatively to the use of regedit.exe, LabVIEW 6 is now distributed with VIs to edit the registry. Registry edition VIs for previous versions of LabVIEW are also available at http://www.mhst.de/support.html, more specifically here: [http://www.mhst.de/downloads/winregistry.zip Windows 95/NT Registry VIs].

== Associate the extension to a DOS batch file. ==
A simple way is to associate your file extension to a DOS batch file that writes the command line argument to a text file. The file myx.bat contains the following lines:

[code]
ECHO %1 > c:\myx\myx.txt

START c:\myx\myx.vi
[/code]

On file double-click, the batch file executes. The first line of the batch file writes the DOS 8.3 file path/name to the file myx.txt (previous file content is overwritten). The second line starts the VI myx.vi. Provided that your application is currently associated to .vi extension (RegisterExtensions = True in its ini file), your application will load myx.vi. The VI myx.vi (set to run when opened) should read the myx.txt file to extract the name of the file to open. If your application is already running, it can now be notified by myx.vi that a file has been double-clicked in the file system. If your application was not running, only myx.vi will be loaded and run; the application Top Level VIs are not loaded therefore myx.vi should check for your main Top Level VIs and load/run them if necessary to properly launch your application. The batch files terminates immediately after the start command and is ready for the next double-click. It is preferable to set the batch file properties to run minimized and close when finished. The long Windows path of the file can be obtained with the VI "GetLongPathName?.vi" included in the sample code below.

You will agree that sending a file name to your application using a DOS batch file and a text file for data tranfer is not state-of-the-art programming, using techniques older than DDE itself. The following methods use the same principle but allows to send the file name to your application using ActiveX, VI Server or TCP/IP.

== Create your LVShellOpen.exe executable. ==
Instead of a batch file, one can use a small LabVIEW executable (let's say LVShellOpen.exe) to be associated with your file extension. Normally, when a LabVIEW executable is launched with a file path on the command line, it attempts to open the file to check if it is a LabVIEW file (VI) it can execute. To prevent this and speed up the process a little, the registry command can be modified to included a command line switch such as

[code]HKEY_CLASSES_ROOT\myxfile\shell\open\command = c:\myx\LVShellOpen.exe - o"%1"[/code]

Since the executable does not recognize a file path or a known switch on the command line, it ignores it. This has also the advantage that if you want to implement other file system commands LVShellOpen can distinguish them if different switches are used. For example, a second command Print could be registered as

[code]HKEY_CLASSES_ROOT\myxfile\shell\print\command = c:\myx\LVShellOpen.exe -p"%1"[/code]

When lauched after a double-click, LVShellOpen launches your application if it is not already running, sends the (Windows Long) file path to open and quits immediatly, ready for the next double-click.

The mode of communication to transmit the file path from LVShellOpen to your application is up to your choice. VI Server or TCP/IP are good options (why not DDE?). When LVShellOpen awakes after a double-click, it attemps to establish a connection with your application (you have enabled the VI Server or run a TCP/IP Listener). If connection succeeds, the file path read from the command line is sent to your application. The connection is closed and LVShellOpen exits. If the connection fails, your application is launched using a System Exec.vi call. LVShellOpen can include the file path on the command line and let the application open the file from its command line or alternatively it can wait for the activation of the VI Server or the TCP/IP Listener to transmit the file path before exiting.

== Visual Basic Script* and LabVIEW ActiveX Server. ==
LabVIEW and executables created with the Application Builder have a built-in ActiveX VI Server. By default, the ActiveX server is not enable in the application builder settings. On the "App Settings" tab of the Application Builder, check the box "Enable ActiveX server" and give an appropriate name to your application server.

It is possible with a simple Visual Basic Script (vbscript) to call LabVIEW VIs using the ActiveX VI Server. Making the file association to the vbscript, this one can easily call one of your VIs to transmit the file path on double-clicks from the user. Opening a connection to ActiveX VI Server automatically starts your application (running Top Level VIs) if it is not already running. The script then makes a call to a VI (included as dynamic VI) that fills a front panel string of the VI with the file path.

This technique does not require to build a separate application and thus can be used with all LabVIEW releases. By making the whole code reentrant it is possible for the user to select multiple files and to open them simultaneously.

This is the technique I recommend the most.

Download Sample Code for VBScript and ActiveX.

"*To run a vbscript, you do not need Visual Basic but the Windows Script Host component which is included in all but the oldest versions of Windows and Internet Explorer."

== Conclusion ==
In conclusion it is possible with some workarounds to manage custom file extensions in a LabVIEW application. However, a built-in LabVIEW feature to implement such interaction with Windows is, to my opinion, highly desirable. If you feel the same way, please add weight to my request for this feature on the LabVIEW Wish List and fill out the LabVIEW Feedback Form

File extension

2007-05-16T15:02:08Z

Jim kring: added xnode, llb, mnu, and rtm. sorted list alphabetically.

This is a list of all the file extensions supported by [[LabVIEW]]

*[[ctl]]
*[[ctt]]
*[[llb]]
*[[lvlib]]
*[[lvproj]]
*[[mnu]]
*[[rtm]]
*[[vi]]
*[[vit]]
*[[xctl]]
*[[xnode]]

State Machine

2007-05-09T06:12:22Z

Jim kring: Added Category>>Design Patterns

The state machine is a convenient LabVIEW construct where a case structure is contained with a while loop. Execution of particular cases in the structure is determined by the output from the previous case (or in the instance of the first execution) by the control selector input. The control of the order of case execution is controlled through the use of a shift register. By wiring the output from one case as the determinate to the subsequent case (wiring to the shift register on the right hand side) and wiring the input to the case selector from the left hand side shift register, operations can be ordered according to which state is executed. [[Image:Simple_State_Machine.png]] 

The state machine has the advantage of allowing several steps to be linked in series so that each individual step can be executed (or debugged) easily. The trap for the inexperienced programmer is the use of the state machine to step in a haphazard fashion through the cases in the loop. This can lead to complicated pathways through the state machine reminiscent of convoluted goto statements in conventional text based languages. However state machines are a valuable tool and can be used very effectively with this in mind.

State machines can be based around integers, strings or enumerated types. The relative merits of each have been discussed in detail elsewhere. In summary an enumerated type state machine has the advantage of being automatically updated when the enum is changed (if the enum is a [[Type Definition]]) but has the disadvantage of requiring careful checking of all the code if new states (enums) are added or redundant states deleted. A string state machine has the advantage of easily added or removed states, but has the disadvantage of spelling mistakes causing programming errors (Note: this can be reduced by including the "Default" state showing the misspelled case in a pop up dialog box, as seen below). [[Image:String_Based_State_Machine_Default_Case.png]]

== Controlling Order of State Execution ==
There are three possible ways to order a LabVIEW state machine. The first and easiest method (although NOT recommended) is to use an integer. The integer output from one case is wired as the selector for the subsequent case. The disadvantage of this method is that the numbers themselves are not very helpful in tracking through the code and the case selector becomes somewhat meaningless. Either of the following methods are preferred and there are pros and cons for each of them. Debate (strong at times) arises on the list quite frequently as to the best of these methods, but in practice either will work very nicely.

The second method is to use a string as the case selector. With the correct choice of string states, this has the advantage of labeling each case so that your state machine becomes self documenting. A further advantage of this method is that all cases need not be written in the first instance and it is somewhat easier to include new states should the need arise (especially in earlier versions of LabVIEW (< 6.0)). The disadvantage is that it is easy to misspell a state and have the state machine buggy because of his. An easy way to overcome this disadvantage is to include a default case that pops up a warning including the spelling of the failed case.

The third method is to use an enumerated type as the case selector. In preference this enum should be a [[Type Definition]] so that changes to the states are reflected easily and transparently when new states are added to the enum (via the LabVIEW auto update from [[Type Definition]] setting). Note that there are reports where this method causes problems in version of LabVIEW prior to 6.0, because the enum auto updating did not correctly handle newly inserted cases. This method has the advantage of the string method in code documentation, but requires the use of a default case if not all the cases are required to be written when the code is first created.

== Passing Data Between States ==
Data is commonly passed between the states of a state machine using a [[Shift Register]], similar to how the state variable is passed between states. It is a common practice to use a single [[Cluster]] (preferably a [[Type Definition]]) to hold all the data in a single [[Shift Register]], rather than multiple shift registers for multiple data elements.

== See Also ==
* [[Queued State Machine]]

[[Category:Design Patterns]]