LabVIEW Wiki - User contributions [en]

LabVIEW Wiki

2019-09-25T21:13:27Z

Jim Kring:

The [[LabVIEW Wiki]] is a [[LabVIEW]] [https://en.m.wikipedia.org/wiki/Wiki Wiki].

[[Category:Self-referencing wiki pages]]

LabVIEW Wiki

2019-09-25T21:10:47Z

Jim Kring:

The [[LabVIEW Wiki]] is a [[LabVIEW]] [[Wiki]].

[[Category:Self-referencing wiki pages]]

LabVIEW Wiki

2019-09-25T21:10:04Z

Jim Kring: Created page with "The LabVIEW Wiki is a LabVIEW Wiki. Category:Self-referencing wiki pages"

The [[LabVIEW Wiki]] is a [[LabVIEW Wiki]].

[[Category:Self-referencing wiki pages]]

LabVIEW object-oriented programming

2009-12-21T02:56:05Z

Jim Kring: fixed hyperlink formatting (was using BBCODE style links)

LVOOP (pronounced "el vee oop") is the native implementation of by-value object orientated programming that appeared in LabVIEW 8.20.

*See the [[LVOOP Frequently Asked Questions]] page, here on the LabVIEW Wiki
*NI has a comprehensive LabVIEW Object-Oriented Programming FAQ for their native LVOOP (native by-value OOP) [http://zone.ni.com/devzone/cda/tut/p/id/3573 here]. It includes links to many other online resources, including the NI Week presentations that the NI R&D team have given to customers.
*There are multiple example programs that ship with LV. They are located in <labview>exampleslvoop
*The National Instruments LVOOP FAQ references the [http://zone.ni.com/devzone/cda/tut/p/id/3574 LVOOP White Paper] several times. If you're an experienced LabVIEW developer, you'll probably enjoy it more than other forms of documentation.
*Christina Rogers (National Instruments R&D) has some excellent discussion about refactoring code, specifically the Getting Started Window, to use LabVIEW classes. See her blog at [http://eyesonvis.blogspot.com/ http://eyesonvis.blogspot.com/] and look at the posts in August 2006.
*[http://forums.ni.com/ni/board/message?board.id=170&message.id=216094&requireLogin=False The LVOOP Design Patterns] is a work-in-progress that [http://forums.lavag.org/Aristos-Queue-m5877.html Aristos Queue] (National Instruments R&D) is working on to help new LVOOP customers choose architectures appropriate to different types of software projects.

== See Also ==

[[Category:GOOP]]

LabVIEW Project

2009-02-07T20:20:18Z

Jim Kring:

== About LabVIEW Projects ==

A [[LabVIEW_Project|LabVIEW Project]] is a tool for organizing project files, NI hardware, configuration data, and build specifications.  Project information is stored in an .lvproj file.

The "Project Explorer" window, shown below, is where you interact with LabVIEW projects:

[[Image:Project Explorer.png]]

== External Links ==

*[http://zone.ni.com/reference/en-XX/help/371361E-01/lvconcepts/using_labview_projects/ Using LabVIEW Projects] (NI LabVIEW 8.6 Help)

LabVIEW Project

2009-02-07T20:16:21Z

Jim Kring: added some headings and external link to LabVIEW help

== About LabVIEW Projects ==

A [[LabVIEW_Project]] is a tool for organizing project files, NI hardware, configuration data, and build specifications.  Project information is stored in an .lvproj file.

The "Project Explorer" window, shown below, is where you interact with LabVIEW projects:

[[Image:Project Explorer.png]]

== External Links ==

*[http://zone.ni.com/reference/en-XX/help/371361E-01/lvconcepts/using_labview_projects/ Using LabVIEW Projects] (NI LabVIEW 8.6 Help)

LabVIEW Project

2009-02-07T20:14:24Z

Jim Kring: New page: A LabVIEW Project is a tool for organizing project files, NI hardware, configuration data, and build specifications.  Project information is stored in an .lvproj file. The "...

A [[LabVIEW Project]] is a tool for organizing project files, NI hardware, configuration data, and build specifications.  Project information is stored in an .lvproj file.

The "Project Explorer" window, shown below, is where you interact with LabVIEW projects:

[[Image:Project Explorer.png]]

File:Project Explorer.png

2009-02-07T20:09:48Z

Jim Kring:

State Machine

2009-02-07T00:17:23Z

Jim Kring: Added external link to JKI State Machine

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.<br />[[Image:Simple_State_Machine.png]]<br />

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).<br />[[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]]

== External Links ==

*[http://jkisoft.com/state-machine JKI State Machine] - An easy-to-use yet powerful state machine template from [http://jkisoft.com JKI Software].

[[Category:Design_patterns]]

Polymorphic VI

2008-12-18T23:03:31Z

Jim Kring: /* Limitations */ made limitation more exact

==Polymorphic VI==
A polymorphic VI is a VI without any code but can be used to group several normal [[VI|VIs]] into one VI. A developer can choose during edit mode which VI should be executed during runtime.

==Usage==
A polymorphic VI is used to execute the same operation on different file-types or to return different file types

==Selection==
Selection of a specific VI can be done automatically based on the data-types connected to the in/output [[terminal|terminals]] of the VI.
To show the manual selector, right-click the polymorphic VI icon an a block diagram, select 'Visible Items\Polymorphic VI Selector'

==Configuration==
The configuration of a polymorphic VI is done by selecting 'Open Polymorphic VI' after a right click on the icon on a block diagram.

[[Image:Polymorphic_Options.png]]

In the configuration dialog you can edit the Polymorphic VI, add or remove VIs.
Alternatively it is possible to show the icon of the instance instead of the icon of the polymorphic VI.
It is possible to let the selection be done automatically. The selector can be shown by default.

==Configuration of an instance==
By using the 'Edit name...' button on the configuration dialog the following dialog opens:

[[Image:Polymorphic_Edit_Instance.png]]

The 'Menu Name' is shown in the selector after an instance is selected.
The 'Polymorphic VI Selector Name' you can alter the menu shown by the VI selector.
Levels can be made by using a colon (:) as separator.

==Limitations==
*All VIs of a polymorphic VI must have the same [[Connector Pane]] pattern, or the Polymorphic VI will be broken.

*Using the polymorphic VI will load all VIs into memory.

Polymorphic VI

2008-12-18T23:02:17Z

Jim Kring: /* Limitations */ changed "connector pattern" link to "Connector Pane"

==Polymorphic VI==
A polymorphic VI is a VI without any code but can be used to group several normal [[VI|VIs]] into one VI. A developer can choose during edit mode which VI should be executed during runtime.

==Usage==
A polymorphic VI is used to execute the same operation on different file-types or to return different file types

==Selection==
Selection of a specific VI can be done automatically based on the data-types connected to the in/output [[terminal|terminals]] of the VI.
To show the manual selector, right-click the polymorphic VI icon an a block diagram, select 'Visible Items\Polymorphic VI Selector'

==Configuration==
The configuration of a polymorphic VI is done by selecting 'Open Polymorphic VI' after a right click on the icon on a block diagram.

[[Image:Polymorphic_Options.png]]

In the configuration dialog you can edit the Polymorphic VI, add or remove VIs.
Alternatively it is possible to show the icon of the instance instead of the icon of the polymorphic VI.
It is possible to let the selection be done automatically. The selector can be shown by default.

==Configuration of an instance==
By using the 'Edit name...' button on the configuration dialog the following dialog opens:

[[Image:Polymorphic_Edit_Instance.png]]

The 'Menu Name' is shown in the selector after an instance is selected.
The 'Polymorphic VI Selector Name' you can alter the menu shown by the VI selector.
Levels can be made by using a colon (:) as separator.

==Limitations==
*All VIs of a polymorphic VI should have the same [[Connector Pane]] pattern.

*Using the polymorphic VI will load all VIs into memory.

Polymorphic VI

2008-12-18T23:01:14Z

Jim Kring: /* Configuration of an instance */ fixed spelling typos

==Polymorphic VI==
A polymorphic VI is a VI without any code but can be used to group several normal [[VI|VIs]] into one VI. A developer can choose during edit mode which VI should be executed during runtime.

==Usage==
A polymorphic VI is used to execute the same operation on different file-types or to return different file types

==Selection==
Selection of a specific VI can be done automatically based on the data-types connected to the in/output [[terminal|terminals]] of the VI.
To show the manual selector, right-click the polymorphic VI icon an a block diagram, select 'Visible Items\Polymorphic VI Selector'

==Configuration==
The configuration of a polymorphic VI is done by selecting 'Open Polymorphic VI' after a right click on the icon on a block diagram.

[[Image:Polymorphic_Options.png]]

In the configuration dialog you can edit the Polymorphic VI, add or remove VIs.
Alternatively it is possible to show the icon of the instance instead of the icon of the polymorphic VI.
It is possible to let the selection be done automatically. The selector can be shown by default.

==Configuration of an instance==
By using the 'Edit name...' button on the configuration dialog the following dialog opens:

[[Image:Polymorphic_Edit_Instance.png]]

The 'Menu Name' is shown in the selector after an instance is selected.
The 'Polymorphic VI Selector Name' you can alter the menu shown by the VI selector.
Levels can be made by using a colon (:) as separator.

==Limitations==
*All VIs of a polymorphic VI should have the same [[connector pattern]].

*Using the polymorphic VI will load all VIs into memory.

Symbolic path

2008-11-25T17:17:19Z

Jim Kring: Added "Resolving Symbolic Paths Programmatically" section

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
|-
| <menu>
| Palette Menus
| <LabVIEW>\menus
|}

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]]

You can download a VI with this private method, here: [http://forums.lavag.org/post-a10538-ResolveSymbolicPath.vi ResolveSymbolicPath.vi]

== 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:development environment]]
[[category:File IO]]

File:ResolveSymbolicPath.png

2008-11-25T17:16:43Z

Jim Kring:

Symbolic path

2008-11-25T17:13:09Z

Jim Kring: fixed a spelling typo

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
|-
| <menu>
| Palette Menus
| <LabVIEW>\menus
|}

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.

== 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:development environment]]
[[category:File IO]]

Development Environment

2008-10-18T16:52:04Z

Jim Kring: added link to "Customizing the LabVIEW Development Environment" article

This is the portal for information related to the LabVIEW Development environment.

====Pages here:====
*[[LabVIEW Environment|Environment Overview]]
*[[How to do Menu Launch VIs]]
*[[LabVIEW configuration file]] - Info about options you have when editing the LabVIEW configuration (ini) file
*[[Custom LabVIEW configuration file]] - Info about why to edit the LabVIEW configuration (ini) file
*[[LLB|LabVIEW LLBs]]
*[[Multiple Instances of LabVIEW|How to run multiple instances of LabVIEW]]
*[[VI Icons]]
*[[Insane Objects|Explanation of Insane Objects]]
*[[Keyboard shortcut|LabVIEW Keyboard shortcuts]]
*[[LabVIEW file extensions]]

====External links:====
*[http://openg.org/docs/Customizing_LabVIEW.pdf Customizing the LabVIEW Development Environment] - a PDF document of an LTR article written by [http://forums.lavag.org/Jim-Kring-m17.html Jim Kring]

LabVIEW Object

2008-06-25T06:54:23Z

Jim Kring:

{{stub}}

The LVClass is the LabVIEW-native OOP class type.

== Links ==

* [[LVClass Data Storage Format]]

[[Category:data types]]
[[Category:Stubs]]

LabVIEW Object

2008-06-25T06:52:24Z

Jim Kring: New page: Category:data types Category:Stubs

[[Category:data types]]
[[Category:Stubs]]

Data type

2008-06-25T06:51:57Z

Jim Kring:

There are many data types in LabVIEW:
*[[String]]
*[[Numeric]]
**[[Integer]]
**[[Float]]
**[[Fixed-point]]
*[[Path]]
*[[Boolean]]
*[[Array]]
*[[Cluster]]
*[[Time stamp|Time Stamp]]
*[[Refnum]]
*[[Variant]]
*[[LVClass]]

[[category:data types]]

LabVIEW object-oriented programming

2008-05-24T19:13:07Z

Jim Kring:

LVOOP (pronounced "el vee oop") is the native implementation of by-value object orientated programming that appeared in LabVIEW 8.20.
*See the [[LVOOP_Frequently_Asked_Questions]] page, here on the LabVIEW Wiki
*NI has a comprehensive LabVIEW Object-Oriented Programming FAQ for their native LVOOP (native by-value OOP) [url=http://zone.ni.com/devzone/cda/tut/p/id/3573]here[/url]. It includes links to many other online resources, including the NI Week presentations that the NI R&D team have given to customers.
*There are multiple example programs that ship with LV. They are located in <labview>exampleslvoop
*The National Instruments LVOOP FAQ references the [url=http://zone.ni.com/devzone/cda/tut/p/id/3574]LVOOP White Paper[/url] several times. If you're an experienced LabVIEW developer, you'll probably enjoy it more than other forms of documentation.
*Christina Rogers (National Instruments R&D) has some excellent discussion about refactoring code, specifically the Getting Started Window, to use LabVIEW classes. See her blog at [url=http://eyesonvis.blogspot.com/]http://eyesonvis.blogspot.com/[/url] and look at the posts in August 2006.
*[url=http://forums.ni.com/ni/board/message?board.id=170&message.id=216094&requireLogin=False]The LVOOP Design Patterns[/url] is a work-in-progress that [url=http://forums.lavag.org/Aristos-Queue-m5877.html]Aristos Queue[/url] (National Instruments R&D) is working on to help new LVOOP customers choose architectures appropriate to different types of software projects.[/list]
== See Also ==
{{Portal|GOOP}}
[[Category:GOOP]]

LabVIEW object-oriented programming

2008-05-24T19:12:46Z

Jim Kring: added link to LVOOP_Frequently_Asked_Questions

LVOOP (pronounced "el vee oop") is the native implementation of by-value object orientated programming that appeared in LabVIEW 8.20.
*See the [[LVOOP FAQ|LVOOP_Frequently_Asked_Questions]] page, here on the LabVIEW Wiki
*NI has a comprehensive LabVIEW Object-Oriented Programming FAQ for their native LVOOP (native by-value OOP) [url=http://zone.ni.com/devzone/cda/tut/p/id/3573]here[/url]. It includes links to many other online resources, including the NI Week presentations that the NI R&D team have given to customers.
*There are multiple example programs that ship with LV. They are located in <labview>exampleslvoop
*The National Instruments LVOOP FAQ references the [url=http://zone.ni.com/devzone/cda/tut/p/id/3574]LVOOP White Paper[/url] several times. If you're an experienced LabVIEW developer, you'll probably enjoy it more than other forms of documentation.
*Christina Rogers (National Instruments R&D) has some excellent discussion about refactoring code, specifically the Getting Started Window, to use LabVIEW classes. See her blog at [url=http://eyesonvis.blogspot.com/]http://eyesonvis.blogspot.com/[/url] and look at the posts in August 2006.
*[url=http://forums.ni.com/ni/board/message?board.id=170&message.id=216094&requireLogin=False]The LVOOP Design Patterns[/url] is a work-in-progress that [url=http://forums.lavag.org/Aristos-Queue-m5877.html]Aristos Queue[/url] (National Instruments R&D) is working on to help new LVOOP customers choose architectures appropriate to different types of software projects.[/list]
== See Also ==
{{Portal|GOOP}}
[[Category:GOOP]]

Subroutine

2008-04-01T17:43:34Z

Jim Kring:

Subroutine is a priority setting in the VI Execution properties. From the [http://zone.ni.com/reference/en-XX/help/371361B-01/lvdialog/execution/ LabVIEW Help]:

<blockquote>
Select subroutine priority to make the LabVIEW execution system run the VI as efficiently as possible. VIs that you set for Subroutine priority do not share execution time with other VIs. Selecting the subroutine priority also prevents any screen redraws and other system functions from occurring. You cannot abort a VI that has subroutine priority.
</blockquote>

==When to use the Subroutine Setting==
{need to add best practices and rules of thumb for when to use this setting}

==External Links==
* [http://zone.ni.com/reference/en-XX/help/371361B-01/lvdialog/execution/ LabVIEW Help >> Execution Properties]
* [http://books.google.com/books?id=jqi9G2EyktYC&pg=PA434&lpg=PA434&dq=labview+when+to+use+subroutine+priority&source=web&ots=mvOJ_9WgAr&sig=S33wuaM7G50_HrlF0KdDUAdchDo&hl=en#PPA434,M1 LabVIEW Advanced Programming Techniques >> 9.10 Subroutines in LabVIEW]

Subroutine

2008-04-01T17:43:07Z

Jim Kring: New page: Subroutine is a priority setting in the VI Execution properties. From the LabVIEW Help: <blockquote> Select subroutine priority to make the LabVIEW execution system run the VI as efficie...

Subroutine is a priority setting in the VI Execution properties. From the LabVIEW Help:

<blockquote>
Select subroutine priority to make the LabVIEW execution system run the VI as efficiently as possible. VIs that you set for Subroutine priority do not share execution time with other VIs. Selecting the subroutine priority also prevents any screen redraws and other system functions from occurring. You cannot abort a VI that has subroutine priority.
</blockquote>

==When to use the Subroutine Setting==
{need to add best practices and rules of thumb for when to use this setting}

==External Links==
* [http://zone.ni.com/reference/en-XX/help/371361B-01/lvdialog/execution/ LabVIEW Help >> Execution Properties]
* [http://books.google.com/books?id=jqi9G2EyktYC&pg=PA434&lpg=PA434&dq=labview+when+to+use+subroutine+priority&source=web&ots=mvOJ_9WgAr&sig=S33wuaM7G50_HrlF0KdDUAdchDo&hl=en#PPA434,M1 LabVIEW Advanced Programming Techniques >> 9.10 Subroutines in LabVIEW]

Buffer Allocation

2008-03-25T22:04:20Z

Jim Kring: Added External Links and link to VI Memory Usage page of LabVIEW help

Note: The following was copied from a [http://forums.lavag.org/Another-reason-why-copy-dots-is-a-bad-name-for-buffer-allocations-t10406.html#entry43277|forum post] by Aristos Queue.

There is a tool in LabVIEW called the "Show Buffer Allocations" tool. You can find it in a VI's menu at Tools>>Profile>>Show Buffer Allocations.... It is a useful tool for doing memory optimizations because it shows little dots every place that the LabVIEW compiler made a buffer allocation. Some people call these "copy dots" because people *think* these indicate where LabVIEW is making a copy of the data. About 90% of the time, that is accurate. But there are some cases where a "buffer allocation" and a "copy" are not the same thing at all. Today I want to mention one that I haven't posted before.

When using arrays, one of the major times when buffer allocations are of interest to programmers, not all buffer allocations are copy dots. Whenever possible, LabVIEW will do an operation on an array by creating a "subarray". If you pay close attention to the Context Help window, you'll sometimes see wires that are of "subarray" type. A subarray is simply a reference to another array, storing an index into that array and a stride and a length. This is a very efficient way to do some pretty complex operations without actually making new arrays, such as decimate array, split array, and reverse array. That last one returns an index to the last element of the array and a stride length of -1. The return of a subarray is only possible when LabVIEW knows that no other operation is going to be modifying the value of the array, so it is safe for the reference to the array in memory to be shared.

Now, take a look at this diagram. Notice the buffer allocations:<br />
[[Image:subarraycopydots.png]]

The "Split 1D Array" node has two output buffer allocations. A lot of people would think, "Look at those copy dots. That means LabVIEW is making two new arrays, one for the first part of the array, and one for the second part of the array." Not true. The buffer allocations are *for the subarrays*. Remember I said that a subarray records a reference to the array, a starting index, a length and a stride. Those four items of data have to be stored somewhere. The buffer allocation is the allocation to store those four items. It is not a copy of the entire array. The output of the Build Array, on the other hand, is a full array allocation.

To see what is being allocated at any given buffer allocation, look at the type of the wire.

And don't call them "copy dots." :-)

== External Links ==
* [http://zone.ni.com/reference/en-XX/help/371361D-01/lvconcepts/vi_memory_usage/ LabVIEW 8.5 Help>>VI Memory Usage]

[[Special:Uncategorizedpages]]

Refnum descriptor

2008-03-17T19:52:28Z

Jim Kring:

The following table lists the subtype codes used in the [[type descriptor]] of the [[refnum data type]].

{| class="wikitable"
|-
! Sub-Type Code
! Refnum Type
! Description
|-
| 0x00
| Generic
| the generic type 0x00 is generated only by getting the TD of the "Not a Refnum Constant".
|-
| 0x01
| Datalog File Refnum
|
|-
| 0x02
| Byte Stream File Refnum
|
|-
| 0x03
| Device Refnum
| used in legacy Serial VIs
|-
| 0x04
| Occurence Refnum
|
|-
| 0x05
| TCP Connection Refnum
|
|-
| 0x06
| VISA Refnum (Obsolete)
| obsolete VISA refnum type up to LabVIEW 5.1
|-
| 0x07
| Automation Refnum
|
|-
| 0x08
| VI Server Refnum
|
|-
| 0x09
| Menu Refnum
|
|-
| 0x0B
| IMAQ Session
|
|-
| 0x0D
| DataSocket Refnum
|
|-
| 0x0E
| VISA Resource
|
|-
| 0x0F
| IVI Logical Name
|
|-
| 0x10
| UDP Connection Refnum
|
|-
| 0x11
| Notifier Refnum
|
|-
| 0x12
| Queue Refnum
|
|-
| 0x13
| IrDA Refnum
|
|-
| 0x14
| Storage Refnum
|
|-
| 0x15
| FieldPoint IO Point/Motion Resource
|
|-
| 0x17
| Event Registration Refnum
|
|-
| 0x18
| .NET Refnum
|
|-
| 0x19
| User Event Refnum
|
|-
| 0x1B
| Event Callback
|
|-
| 0x1F
| Bluetooth Refnum
|
|}

==See Also==
*[[type descriptor]]

Refnum descriptor

2008-03-17T19:39:55Z

Jim Kring: New page: The following table lists the subtype codes used in the type descriptor of the refnum data type. {| class="wikitable" |- ! Sub-Type Code ! Refnum Type ! Description |- | 0x00 | Ge...

The following table lists the subtype codes used in the [[type descriptor]] of the [[refnum data type]].

{| class="wikitable"
|-
! Sub-Type Code
! Refnum Type
! Description
|-
| 0x00
| Generic
| the generic type 0x00 is generated only by getting the TD of the "Not a Refnum Constant". That's a bit annoying since it takes the place of the default value for "not a refnum type"
|-
| 0x01
| Datalog File Refnum
|
|-
| 0x02
| Byte Stream File Refnum
|
|-
| 0x03
| Device Refnum
| used in legacy Serial VIs
|-
| 0x04
| Occurence Refnum
|
|-
| 0x05
| TCP Connection Refnum
|
|-
| 0x06
| VISA Refnum (Obsolete)
| obsolete VISA refnum type up to LabVIEW 5.1
|-
| 0x07
| Automation Refnum
|
|-
| 0x08
| VI Server Refnum
|
|-
| 0x09
| Menu Refnum
|
|-
| 0x0B
| IMAQ Session
|
|-
| 0x0D
| DataSocket Refnum
|
|-
| 0x0E
| VISA Resource
|
|-
| 0x0F
| IVI Logical Name
|
|-
| 0x10
| UDP Connection Refnum
|
|-
| 0x11
| Notifier Refnum
|
|-
| 0x12
| Queue Refnum
|
|-
| 0x13
| IrDA Refnum
|
|-
| 0x14
| Storage Refnum
|
|-
| 0x15
| FieldPoint IO Point/Motion Resource
|
|-
| 0x17
| Event Registration Refnum
|
|-
| 0x18
| .NET Refnum
|
|-
| 0x19
| User Event Refnum
|
|-
| 0x1B
| Event Callback
|
|-
| 0x1F
| Bluetooth Refnum
|
|}

==See Also==
*[[type descriptor]]

Fixed-point data type

2008-03-15T04:00:46Z

Jim Kring:

The [[fixed-point]] numeric, first introduced to LabVIEW in version 8.5, is a data type for storing 64 bit, rational, decimal values with precision and range that vary based on the user's configuration of the numeric instance. Fixed-point numerics are useful on platforms such FPGA's, which do not support floating point math.

==External links==
*[http://zone.ni.com/reference/en-XX/help/371361D-01/lvhowto/fixed_point_numbers/ LabVIEW 8.5 Help>>Fixed-Point Numbers]
*[http://zone.ni.com/reference/en-XX/help/371361D-01/lvhowto/numeric_data_types_table/ LabVIEW 8.5 Help>>Numeric Data Types Table]

[[category:data types]]

Fixed-point data type

2008-03-15T03:59:54Z

Jim Kring: New page: The fixed-point numeric, first introduced to LabVIEW in version 8.5, is a data type for storing 64 bit, rational, decimal values with precision and range that vary based on the user's ...

The [[fixed-point]] numeric, first introduced to LabVIEW in version 8.5, is a data type for storing 64 bit, rational, decimal values with precision and range that vary based on the user's configuration of the numeric instance.

==External links==
*[http://zone.ni.com/reference/en-XX/help/371361D-01/lvhowto/fixed_point_numbers/ LabVIEW 8.5 Help>>Fixed-Point Numbers]
*[http://zone.ni.com/reference/en-XX/help/371361D-01/lvhowto/numeric_data_types_table/ LabVIEW 8.5 Help>>Numeric Data Types Table]

[[category:data types]]

Time stamp

2008-03-15T03:50:19Z

Jim Kring:

A [[time stamp]], first introduced to LabVIEW in version 7.0, 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.

==External links==
*[http://zone.ni.com/reference/en-XX/help/371361D-01/lvhowto/numeric_data_types_table/ LabVIEW 8.5 Help>>Numeric Data Types Table]

[[category:data types]]

Time stamp

2008-03-15T03:49:18Z

Jim Kring:

A [[time stamp]], first introduced to LabVIEW in version 7.0, 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.

==External links==
*[http://zone.ni.com/reference/en-XX/help/371361B-01/lvhowto/numeric_data_types_table/ LabVIEW 8.2 Help>>Numeric Data Types Table]

[[category:data types]]

Variant data type

2008-03-14T23:26:25Z

Jim Kring:

A [[variant]] is a data type that any other LabVIEW data type will coerce to and that can contain any other LabVIEW data type inside it. In order to do useful things with variants, you will need to inspect the type descriptor to determine the actual data type flowing through the variant at run-time. When working with variants, it is recommended to use tools such as the [http://wiki.openg.org/Oglib_lvdata OpenG LabVIEW Data (Variant) Tools Library].

==External links==
*[http://zone.ni.com/reference/en-XX/help/371361D-01/lvhowto/variants/ LabVIEW 8.5 Help>>Variant Data]
*[http://zone.ni.com/reference/en-XX/help/371361D-01/lvconcepts/handling_variant_data/ LabVIEW 8.5 Help>>Handling Variant Data]
*[http://zone.ni.com/reference/en-XX/help/371361D-01/glang/variant_functions/ LabVIEW 8.5 Help>>Variant Functions]
*[http://wiki.openg.org/Oglib_lvdata OpenG LabVIEW Data (Variant) Tools Library]

[[category:data types]]

Variant data type

2008-03-14T23:25:55Z

Jim Kring: New page: A variant is a data type that any other LabVIEW data type will coerce to and that can therefore contain any other LabVIEW data type inside it. In order to do useful things with varian...

A [[variant]] is a data type that any other LabVIEW data type will coerce to and that can therefore contain any other LabVIEW data type inside it. In order to do useful things with variants, you will need to inspect the type descriptor to determine the actual data type flowing through the variant at run-time. When working with variants, it is recommended to use tools such as the [http://wiki.openg.org/Oglib_lvdata OpenG LabVIEW Data (Variant) Tools Library].

==External links==
*[http://zone.ni.com/reference/en-XX/help/371361D-01/lvhowto/variants/ LabVIEW 8.5 Help>>Variant Data]
*[http://zone.ni.com/reference/en-XX/help/371361D-01/lvconcepts/handling_variant_data/ LabVIEW 8.5 Help>>Handling Variant Data]
*[http://zone.ni.com/reference/en-XX/help/371361D-01/glang/variant_functions/ LabVIEW 8.5 Help>>Variant Functions]
*[http://wiki.openg.org/Oglib_lvdata OpenG LabVIEW Data (Variant) Tools Library]

[[category:data types]]

Info-LabVIEW

2008-02-15T17:36:03Z

Jim Kring: added a Milestone Posts section and a few postings to get things rolling

{{stub}}
Info-LabVIEW is an independent mailing list to discuss LabVIEW. Tom Coradeschi, originally formed the list when LabVIEW ran on Macintosh computers only (National Instruments released LabVIEW for Windows in 1992). The list has been running now for over 16 years and has become a LabVIEW institution. Today, Info LabVIEW keeps thousands of subscribers talking to each other. Although the vast majority of LabVIEW programmers use Windows, Mac-specific questions still appear regularly.

==Milestone Posts==
* [http://sthmac.magnet.fsu.edu/infolabview/ILVDigests/1991/02/14/Info-LabVIEW_Digest_1991-02-14_001.html First Message] (1991-02-14)
* [http://sthmac.magnet.fsu.edu/infolabview/ILVDigests/1994/05/11/Info-LabVIEW_Digest_1994-05-11_007.html Gary Johnson's story of writing LabVIEW Graphical Programming] (1994-05-11)
* [http://sthmac.magnet.fsu.edu/infolabview/ILVDigests/1999/05/27/Info-LabVIEW_Digest_1999-05-27_025.html Greg McKaskle's "Rusty Nails" post] (1999-05-27)
* [http://sthmac.magnet.fsu.edu/infolabview/ILVDigests/2006/08/14/Info-LabVIEW_Digest_2006-08-14_006.html Jim Kring's announcement that LabVIEW for Everyone, 3rd edition ships] (2006-08-14)

== See also ==
*[[Info-LabVIEW mailing list archive]]

== External links ==
*[http://sthmac.magnet.fsu.edu/infolabview/subscribe.html Subscribe to Info-LabVIEW]
*[http://sthmac.magnet.fsu.edu/infolabview/ Info-LabVIEW home]

[[Category:Communities]]