LabVIEW Wiki - User contributions [en]

Error Case Structure

2007-09-25T20:32:36Z

Eaolson: minor tweaking of the language, apostrophe, And->An

An '''Error Case Structure''' is term that describes a [[Case Structure]] that has an [[Error cluster]] wired to its selector terminal. Its two available cases are "No Error'' (showing a green frame) and ''Error'' (showing a red frame).

[[Image:Error Case Structure.png|thumb|300px|center]]

== See Also ==
* [[Error cluster]]
* [[Error handling]]

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

Insane Objects

2007-09-21T18:27:56Z

Eaolson: Remove meta information

Firstly, there is no need to necessarily report generically to [[NI]] that LabVIEW has insane objects, as they '''do''' know about insane objects. Secondly they are NOT merely bugs: insane objects can be generated as part of the LabVIEW verification process. If you get such a message, it is good to check the known bugs of LabVIEW at ni.com and if the particular insanity in your dialog is not listed, only then should you report the insanity to NI technical support.

The insane object message is what LabVIEW puts in a dialog when one of the objects on the diagram does not meet its "checksum". In other words, this object isn't in a state LabVIEW expects it to be in. Most of the time these errors are not fatal -- LabVIEW simply puts the object in the state it does expect. But it raises questions about how the object got into that bad state and what might have been done with that object between the last time LabVIEW checked and it was good and the time it became insane.

The insane object messages are something NI works on with each version of LabVIEW. But as it is a generic error message that can apply to anything from a simple cosmetic to the front panel itself, you'll still see them in any version of LabVIEW that has a bug -- a fact of life unfortunately for the foreseeable future.

The cryptic nature of the message can be deciphered as follows:
Insane object at FPHP+4C in "name.vi": {dsitem} 0x400: Panel (FPSC)
* FPHP -- this will be either FP or BD for "front panel heap" or "block diagram heap"
* 4C -- this is a hexadecimal number indicating which object.
* name.vi -- which VI had the insanity
* {dsitem} 0x400 -- really only meaningful if you know how LabVIEW internals work; I'll skip it here
* Panel (FPSC) -- the type of object that has problems. The four letter codes are usually descriptive (COSM for a cosmetic or simple drawn part, SGNL for a signal aka wire). A common one that you won't guess is DDOD, which stands for Data Display Object (the last D is because it has to be 4 chars). A DDO is either a control or an indicator.

Most of the time, deleting the offending object and recreating it from scratch is sufficient to fix your VI and allow you to continue working.

== Using Heap Peek ==

The number "4C" is described above as the number that tells you which object. Not exactly helpful to an end user. There is a way to find and delete an insane object. When you get an insane error, you will get a code that shows the object that is insane - write down that code and then:

* Close LabVIEW
* Put the key "LVdebugKeys=True" in your [[LabVIEW configuration file]]
* Open your VI
* Press CTRL+SHIFT+D+H. On Mac, use the command key instead of CTRL. This will open a window known to LV R&D as "heap peek" since it gives internal views into the front panel heap and the block diagram heap.
* The window is divided into 4 sections: top-left, top-right, middle, and base. The functionality of the various parts is obscure and mystical, so we're just going to focus on the bits that help with finding and deleting insane objects.
* Check the error message given about the insane object. It includes either the letters BDHP or FPHP. Scroll through the top-left list box until you find those 4 letters and the name of your VI. Left click to select that item. This will change what is displayed in the top-right section of the window.
* In the top-right section, find the line that begins with the number identifying the object. These are sorted numerically. Left click to select the object when you find it.
* In the middle region, there is a box with an F inside it. This is a button (heap peek doesn't use a lot of advanced drawing, so it doesn't really look like a button, but it is). Click on the F button to find the offending object.
* LabVIEW will switch to the block diagram or front panel and select some object. Whatever object it is, delete it.

Note: Care must be taken with heap peek. It has the possibility to change states of objects and doing that without knowing EXACTLY (and I think only a few people in the LabVIEW developer team really do) what you are doing can completely mess up your VI or maybe even more.

I do not think that heap peek has any ability to change the objects. It is display information only. There are VIs in LV that are not real VIs (for example, a pseudo VI that is created to represent a Call By Reference to another application instance on another machine), and attempting to do Find to jump to their components can cause problems because those VIs never expect to actually draw themselves. But other than that state change, I do not know of any edits. They may exist. The previous author is quite correct in saying that few developers really know the capacities of heap peek. It's a debugging tool, and it gets hacked up to display whatever anyone needs to display.

Insane Objects

2007-09-21T18:21:02Z

Eaolson: /* Using Heap Peek */ On my 7.1.1 install, it's Ctrl+Shift+D+H

Firstly, there is no need to necessarily report generically to [[NI]] that LabVIEW has insane objects, as they '''do''' know about insane objects. Secondly they are NOT merely bugs: insane objects can be generated as part of the LabVIEW verification process. If you get such a message, it is good to check the known bugs of LabVIEW at ni.com and if the particular insanity in your dialog is not listed, only then should you report the insanity to NI technical support.

The insane object message is what LabVIEW puts in a dialog when one of the objects on the diagram does not meet its "checksum". In other words, this object isn't in a state LabVIEW expects it to be in. Most of the time these errors are not fatal -- LabVIEW simply puts the object in the state it does expect. But it raises questions about how the object got into that bad state and what might have been done with that object between the last time LabVIEW checked and it was good and the time it became insane.

The insane object messages are something NI works on with each version of LabVIEW. But as it is a generic error message that can apply to anything from a simple cosmetic to the front panel itself, you'll still see them in any version of LabVIEW that has a bug -- a fact of life unfortunately for the foreseeable future.

The cryptic nature of the message can be deciphered as follows:
Insane object at FPHP+4C in "name.vi": {dsitem} 0x400: Panel (FPSC)
* FPHP -- this will be either FP or BD for "front panel heap" or "block diagram heap"
* 4C -- this is a hexadecimal number indicating which object.
* name.vi -- which VI had the insanity
* {dsitem} 0x400 -- really only meaningful if you know how LabVIEW internals work; I'll skip it here
* Panel (FPSC) -- the type of object that has problems. The four letter codes are usually descriptive (COSM for a cosmetic or simple drawn part, SGNL for a signal aka wire). A common one that you won't guess is DDOD, which stands for Data Display Object (the last D is because it has to be 4 chars). A DDO is either a control or an indicator.

Most of the time, deleting the offending object and recreating it from scratch is sufficient to fix your VI and allow you to continue working.

== Using Heap Peek ==

The number "4C" is described above as the number that tells you which object. Not exactly helpful to an end user. There is a way to find and delete an insane object. When you get an insane error, you will get a code that shows the object that is insane - write down that code and then:

* Close LabVIEW
* Put the key "LVdebugKeys=True" in your [[LabVIEW configuration file]]
* Open your VI
* Press CTRL+SHIFT+D+H. On Mac, use the command key instead of CTRL. This will open a window known to LV R&D as "heap peek" since it gives internal views into the front panel heap and the block diagram heap.
* The window is divided into 4 sections: top-left, top-right, middle, and base. The functionality of the various parts is obscure and mystical, so we're just going to focus on the bits that help with finding and deleting insane objects.
* Check the error message given about the insane object. It includes either the letters BDHP or FPHP. Scroll through the top-left list box until you find those 4 letters and the name of your VI. Left click to select that item. This will change what is displayed in the top-right section of the window.
* In the top-right section, find the line that begins with the number identifying the object. These are sorted numerically. Left click to select the object when you find it.
* In the middle region, there is a box with an F inside it. This is a button (heap peek doesn't use a lot of advanced drawing, so it doesn't really look like a button, but it is). Click on the F button to find the offending object.
* LabVIEW will switch to the block diagram or front panel and select some object. Whatever object it is, delete it.

'''Another author of the WIKI wrote this:'''
''Care must be taken with heap peek. It has the possibility to change states of objects and doing that without knowing EXACTLY (and I think only a few people in the LabVIEW developer team really do) what you are doing can completely mess up your VI or maybe even more.''

I do not think that heap peek has any ability to change the objects. It is display information only. There are VIs in LV that are not real VIs (for example, a pseudo VI that is created to represent a Call By Reference to another application instance on another machine), and attempting to do Find to jump to their components can cause problems because those VIs never expect to actually draw themselves. But other than that state change, I do not know of any edits. They may exist. The previous author is quite correct in saying that few developers really know the capacities of heap peek. It's a debugging tool, and it gets hacked up to display whatever anyone needs to display.

CAR Number

2007-09-15T17:28:24Z

Eaolson: just making the title clear

A '''Corrective Action Report Number''', or CAR Number, is used by [[National Instruments]] for tracking LabVIEW bugs. When you report a bug to NI (see [[LabVIEW Bug Reporting]]) you will generally be given a CAR number, so that you can track progress on your bug. Recently, NI has started listing the CAR numbers of bug fixes in the readme file included in LabVIEW releases.

==See Also==
*[[LabVIEW Bug Reporting]]

Flattened pixmap

2007-09-06T22:13:20Z

Eaolson: adding 32 bit back in, see discussion page

The '''flattened pixmap''' is a structure used to load and save images to and from disk.

==Elements==
A flattened pixmap is a cluster consisting of 6 elements:
# '''image type''' is reserved for a future use. It should be 0. It is a U16.
# '''image depth''' describes the bit depth of the colors in the image. It's value affects how the '''image''' and '''colors''' elements are interpreted. Valid values are: 1, 4, 8, 24, and 32. It is a U8.
# '''image''' is an one-dimensional array of U8s describing the color of each pixel. The meaning of this array changes depending on the value of '''image depth''':
#* For 1-, 4-, and 8-bit images m x n pixels in size, '''image''' is m*n elements long. Each pixel value contains an index into the '''colors''' array, which contains the actual color for the pixel.
#* For 24-bit images m x n pixels in size, '''image''' is 3*m*n elements long. The elements are the red, green, and blue components for each pixel, in order.
#* For 32-bit images m x n pixels in size, '''image''' is 4*m*n elements long. This structure is the same as for 24-bit images, but includes a transparency element.
# '''Mask''' is a one-dimensional array of U8s that bitwise sets the transparency of a pixel. A bit-value of 0 makes the pixel transparent. The mask array handles each row of the image in order, padding with zeros to the end of an even-numbered byte if necessary.
# '''colors''' is a one-dimensional array of U32s listing the [[color]] palette for an indexed (1-, 4-, or 8-bit) image. The array will be up to 2, 16 or 256 elements long for 1-, 4-, and 8-bit images, respectively. For 24- or 32-bit images the array will be empty.
# '''Rectangle''' is a cluster describing the size of the image. It contains four elements as I16s: '''left''', '''top''', '''right''', and '''bottom'''. Usually, '''left''' and '''top''' are zero, so '''right''' and '''bottom''' are the width and height of the image, respectively.

==Image files==
The Read BMP File, Read JPG File, and Read PNG File VIs read an existing image file from disk and return a flattened pixmap. Similarly, Write BMP File, Write JPG File, and Write PNG File accept a flattened pixmap and save it as the appropriate image file.

==Conversion==
The Unflatten Pixmap VI can be used to convert a flattened pixmap to a two-dimensional array of colors (24- and 32-bit images) or an array of indexes into a '''colors''' palette.

A flattened pixmap is converted to the LabVIEW [[picture]] data type by using the Draw Flattened Pixmap VI.

Flattened pixmap

2007-09-06T00:40:39Z

Eaolson: /* Elements */ pads to the end of an even number of bytes, not the end of the current byte

Color

2007-09-02T22:24:20Z

Eaolson: just a quick note on how colors are stored

'''Colors''' are represented in LabVIEW by an unsigned 32-bit integer. The integer is of the hexadecimal form 0x00RRGGBB, where RR, GG, and BB represent the red, green, and blue components of the color, respectively.

Flattened pixmap

2007-09-02T22:20:30Z

Eaolson: this is a start

The '''flattened pixmap''' is a structure used to load and save images to and from disk.

==Elements==
A flattened pixmap is a cluster consisting of 6 elements:
# '''image type''' is reserved for a future use. It should be 0. It is a U16.
# '''image depth''' describes the bit depth of the colors in the image. It's value affects how the '''image''' and '''colors''' elements are interpreted. Valid values are: 1, 4, 8, 24, and 32. It is a U8.
# '''image''' is an one-dimensional array of U8s describing the color of each pixel. The meaning of this array changes depending on the value of '''image depth''':
#* For 1-, 4-, and 8-bit images m x n pixels in size, '''image''' is m*n elements long. Each pixel value contains an index into the '''colors''' array, which contains the actual color for the pixel.
#* For 24-bit images m x n pixels in size, '''image''' is 3*m*n elements long. The elements are the red, green, and blue components for each pixel, in order.
#* For 32-bit images m x n pixels in size, '''image''' is 4*m*n elements long. This structure is the same as for 24-bit images, but includes a transparency element.
# '''colors''' is a one-dimensional array of U32s listing the [[color]] palette for an indexed (1-, 4-, or 8-bit) image. The array will be up to 2, 16 or 256 elements long for 1-, 4-, and 8-bit images, respectively. For 24- or 32-bit images the array will be empty.
# '''Rectangle''' is a cluster describing the size of the image. It contains four elements as I16s: '''left''', '''top''', '''right''', and '''bottom'''. Usually, '''left''' and '''top''' are zero, so '''right''' and '''bottom''' are the width and height of the image, respectively.

==Image files==
The Read BMP File, Read JPG File, and Read PNG File VIs read an existing image file from disk and return a flattened pixmap. Similarly, Write BMP File, Write JPG File, and Write PNG File accept a flattened pixmap and save it as the appropriate image file.

==Conversion==
The Unflatten Pixmap VI can be used to convert a flattened pixmap to a two-dimensional array of colors (24- and 32-bit images) or an array of indexes into a '''colors''' palette.

A flattened pixmap is converted to the LabVIEW [[picture]] data type by using the Draw Flattened Pixmap VI.

Flattened pixmap

2007-09-02T19:54:49Z

Eaolson: started this article, but I have to go! I'll finish it later.

The '''flattened pixmap''' is a structure used to load and same images to and from disk.

==Elements==
A flattened pixmap is a cluster consisting of 6 elements:
# '''image type''' is reserved for a future use. It should be 0. It is a U16.
# '''image depth''' describes the bit depth of the colors in the image. It's value affects how the '''image''' and '''colors''' elements are interpreted. Valid values are: 1, 4, 8, 24, and 32. It is a U8.
# '''image''' is an one-dimensional array of U8s describing the color of each pixel. The meaning of this array changes depending on the value of '''image depth''':
#* For 1-, 4-, and 8-bit images m x n pixels in size, '''image''' is m*n elements long. Each pixel value contains an index into the '''colors''' array, which contains the actual color for the pixel.
#* For 24-bit images m x n pixels in size, '''image''' is 3*m*n elements long.

Insane object

2007-07-11T18:57:49Z

Eaolson: not sure if the article should be at the singular or plural version of the word

#REDIRECT [[Insane Objects]]

Property Node

2007-05-12T22:57:54Z

Eaolson: Property Node moved to Property node: change cap per MOS

#REDIRECT [[Property node]]

Property node

2007-05-12T22:57:54Z

Eaolson: Property Node moved to Property node: change cap per MOS

This is a stub. Feel free to edit.

[[Category:Stubs]]

Category:Stubs

2007-05-12T22:57:28Z

Eaolson: description

This is a category for stubs. Feel free to expand any one of these articles.

Producer/Consumer

2007-05-12T22:56:53Z

Eaolson: add stub cat

This is a stub article for the producer/consumer architecture.

[[Category:Design Patterns]]
[[Category:Stubs]]

Queued State Machine

2007-05-12T22:56:38Z

Eaolson: add stub cat

This is a stub article for Queued State Machine.

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

[[Category:Design Patterns]]
[[Category:Stubs]]

Functional Global

2007-05-12T22:56:18Z

Eaolson: fix double redirect

#REDIRECT [[Functional global variable]]

Property node

2007-05-12T22:55:57Z

Eaolson: add stub cat

This is a stub. Feel free to edit.

[[Category:Stubs]]

NIWeek

2007-05-12T22:55:12Z

Eaolson: add stub cat

This is a stub page which requires expansion. Please help by adding content.

[[Category:Stubs]]

Globals

2007-05-12T22:54:47Z

Eaolson: fix double redirect

#REDIRECT [[Global variable]]

Recursion

2007-05-12T22:54:16Z

Eaolson: add stub cat

This is a stub. Feel free to edit.

[[Category:Stubs]]

LabVIEW Wiki:Manual of Style

2007-05-12T22:50:19Z

Eaolson: cap per MOS

__NOTOC__
{| align="right" border="0"
|__TOC__
|-
|}
Our Manual of style is a collection of rules of thumb and guidelines for giving LabVIEW Wiki a consistent look and feel. Most of these rules have exceptions, but to put together a good reference work collaboratively, it's best to follow the rules unless they're quite inappropriate for a particular situation.

These are not rigid laws: they are principles that many editors have found to work well in most circumstances, but which should be applied with flexibility. In this vein, editors should strive to have their articles follow these guidelines. If all this stuff makes your head swim, and you don't want to bother with it, by all means plunge forward and just start sharing your knowledge. Other LabVIEW Wiki editors will come forward (they always do) and bring your contributions in line with the style guide.

If you have a question about the specifics of the Manual, or want to see it changed/amended/clarified, use the discussion topic for the section in question. Otherwise, you can always post a comment in the [http://forums.lavag.org/LabVIEW-Wiki-Support-f91.html LabVIEW Wiki Support Forum].

== Page naming conventions ==

{| class="wikitable"
|-
'''Note:''' If an article has been named inappropriately, it can be renamed by moving the article to a more appropriate title. See [[Help:Moving a page]] for more on renaming pages.
|}
=== Lowercase second and subsequent words in titles ===

''Convention:'' Do not capitalize second and subsequent words unless the title is a proper noun (such as a name) or is otherwise almost always capitalized (for example: John Wayne and Art Nouveau, but not Computer And Video Games). The first letter of an internal wikilink need not be capitalized and will direct the reader to the same page (for example, computer and video games or Computer and video games can be used interchangeably as needed).

=== Prefer singular nouns ===

''Convention:'' In general only create page titles that are in the singular, unless that noun is always in a plural form in English (such as scissors or trousers).

=== Avoid "the" and "a" or "an" at the beginning of the page name ===

''Convention:'' If the definite or indefinite article would be capitalized in running text, then include it at the beginning of the page name. This would be the case for the title of a work such as a novel. Otherwise, do not include it at the beginning of the page name.

== Categories ==

'''Every''' page in the article namespace should belong to at least one category. Categories should be major topics that are likely to be useful to someone reading the article. See [[Help:Categories]] for technical information on how to add a page to a category.
*Each LabVIEW Wiki article can appear in more than one category, and each category can appear in more than one parent category.
*If you don't know where to put an article, don't worry about it. Use the <nowiki>[[Category:Uncategorized]]</nowiki> to bring attention to the article. Editors who love to categorize articles will find a good home for your article.

== Add a "See also" section ==
If you know of other LabVIEW Wiki articles that are related to the current article, add links to them in a special section at the bottom called "See also". This section should be placed at the bottom of the article before any "External Links" section. Only LabVIEW Wiki articles should be placed here. See below for external links.

== Add an "External links" section ==
If you know of any external (non LabVIEW Wiki) web pages that may provide more information on the article topic, add links to them in a special section at the bottom called "External Links". This section should be placed after the "See Also" section. A typical example would be linking to the LabVIEW help documentation on ni.com.

== Images ==
It is difficult to suggest image positioning recommendations however if in doubt, centering is preferred.
*Images should always be framed.
*If an image is larger than 600px wide then it should be thumbnailed at 600px.
*Use captions to explain the relevance of the image to the article.
*Avoid using image or figure numbers in your caption as this makes editing difficult. Inserting images will result in a large editing task for the remaining image references.
*When uploading an image, add a description during the upload process. This can be longer and more detailed than the caption. This is useful when the reader clicks on the image source looking for more information.

== Other specific conventions ==

The following words, when used in the title or body of the page must be capitalized and written as shown below.
*LabVIEW - Do not use labview, LV, etc.

[[Category:LabVIEW Wiki style guidelines]]

Boolean data type

2007-05-11T20:11:08Z

Eaolson: article start

A '''boolean''' is a primitive data type that can have one of two values: TRUE or FALSE. Various operations from the Boolean palette can be performed on these, such as AND, OR, and NOT. Most comparison functions return boolean data.

In addition to [[label]] and [[caption]] text, boolean controls and indicators can display "boolean text" that can depend on the state of the control. This allows a control or indicator to show a textual representation of its state (e.g. ON/OFF).

On the [[block diagram]], boolean data is represented by green wires.

==Mechanical action==
Boolean controls have mechanical actions, which control how activation with the mouse affects the value of the control. Mechanical action allows a control to mimic certain physical actuators (e.g. a light switch, emergency stop button). The six types of mechanic actions are:
* Switch when pressed. The value of the control change each time it is clicked. This is similar to a light switch.
* Switch when released. The value of the control only changes once the mouse button is released within the boundary of the control.
* Switch until released. The value of the control changes only so long as the mouse button is held down. When the mouse button is released, the control returns to its default value.
* Latch when pressed. The value of the control is updated when the mouse button is depressed. Once the VI reads the value of the control, it returns to its default value.
* Latch when released. The value of the control is updated when the mouse button is released within the boundary of the control. Once the VI reads the value of the control, it returns to its default value.
*Latch until released. The value of the control is updated while the mouse button is held down, or until the VI reads the value, whichever comes first.

The three "latch" behaviors can not be used if the control has a local variable on the block diagram.

Reentrant VI

2007-05-10T16:49:36Z

Eaolson: add an introductory graf actually explaining reentrancy, add header

A '''reentrant VI''' is a [[VI]] that has a separate data space allocated for which each instance of the VI. Multiple instances of reentrant VIs can execute in parallel without interfering with each other. Non-reentrant VIs have a data space that is shared between multiple calls to the VI.

==Implementation==

First, consider three VIs, foo.vi, bar.vi, and sub.vi. Both foo.vi and bar.vi call sub.vi.

If sub.vi is normal (not reentrant), then if foo.vi tries to call sub.vi but sub.vi is busy servicing a call from bar.vi, then foo.vi has to wait. This can be both a very GOOD thing and a very BAD thing depending on circumstances. It's very GOOD when sub.vi controls access to something like a serial port, where you only want one part of your program accessing it at a time. It's very BAD when sub.vi controls something like ALL the serial ports, because you may want foo.vi to be able to use one serial port while bar.vi is busy using a different serial port. Another very bad circumstance is where foo.vi is in a critical loop and bar.vi is not, yet because of the contention for sub.vi, bar.vi can end up blocking foo.vi.

If sub.vi is reentrant, then both foo.vi and bar.vi can call sub.vi at the same time. In order for this to work, each call to sub.vi needs to have its own "data space" which is all the internal storage sub.vi uses in order to execute its code.

Now at this point I need to point out a distinction between LabVIEW and most other languages. LabVIEW doesn't want to allocate a data space on the fly, because for LabVIEW that would slow down performance. LabVIEW allocates all the VI data spaces it needs when VIs are being loaded. Except when you use VI Server to call VIs dynamically, all the loading happens before any VIs execute. Therefore, for each place that sub.vi appears on foo.vi's block diagram, a copy of sub.vi's data space gets embedded in foo.vi's data space, assuming sub.vi is reentrant. If sub.vi isn't reentrant, it just has its one data space allocated that each call will use in turn.

In most (all?) other languages, reentrant functions allocate their data spaces on the fly, so there's no storage that goes with each place that a particular function is called.

How does LabVIEW's unusual implementation affect us in practical terms? There are really two ways:

1. If you use uninitialized shift registers to store information, then you can get two different behaviors depending on the reentrancy of your VI. For a non-reentrant VI, you get a data sharing function that lets you move large quantities of information between parallel loops without making copies of it. For a reentrant VI, you get a reusable storage function that can keep independent copies each place you use it.

2. The second implication is that you can't do recursion (functions that call themselves) easily in LabVIEW. In most languages, if a function is reentrant then it's OK for it to call itself. In LabVIEW, that would require that the data storage for sub.vi would include a copy of the data storage for sub.vi which would ... to infinity. You can do recursion in LabVIEW if you use VI Server to have a VI call itself dynamically, but as I said, allocating data spaces on the fly is inherently slow. In LabVIEW, it's best to convert recursive algorithms to their iterative equivalents, which I hear is mathematically proven to always be possible. In the iterative version, you'll end up changing the sizes of arrays at each iteration, which is also one of the slower operations in LabVIEW, but is not nearly as slow as dynamic VI calls.

To expand on this, reentrant means that more than one execution is allowed to take place at the same time. In other languages, it is more a situation than a setting. You never mark a C function as allowing or disallowing reentrancy, it is either safe to do so or a source of bugs. In LV it is a setting, and many times its setting doesn't affect the correctness of a VI, but in some cases, it can be a source of bugs. It depends on what the VI does.

The setting in LV determines two major attributes about how a VI executes.

First is access. With reentrancy turned off, only one call to the subVI can be active at a time. When the current call finishes, the next one can begin. The subVI calls queue up while the VI is busy. For functions that execute quickly, this is normally fine and reentrancy doesn't affect much.

If you have a function that uses TCP to talk to another computer and waits for responses, these waits also affect the other subVI calls that are queued up. So if you have an operation that can occur in parallel and doesn't consume the CPU, you can make the VI reentrant and the multiple subVI calls don't enter a queue, and multiple VIs can talk TCP and wait for responses at once. This allows the wait time of one subVI to be used as work time in another and increases overall performance.

On the otherhand, given a VI that reads a global modifies it and writes it back, a reentrant subVI means that more than one subVI call at a time can be modifying the global -- a race condition which will cause incorrect answers. Lots of real-world devices also get confused when more than one subVI tries to control them at a time. So when trying to protect a global resource, the one of the tools, and frequently the easiest to use is to simply make sure that the access goes through a non-reentrant VI.

The second attribute is data side-effects. If a VI has unconnected controls or uninitialized shift registers on its diagram, then it remembers some amount of information from call to call. A good example of this is a PID or a filter. Data from previous calls affect the result of the next call. For these sorts of VIs, if they are reentrant, then each call gets its own place to store the previous call's state information. If made non-reentrant, there will be only one storage location for all calls to share, so the data will get all jumbled, likely causing an incorrect answer.

Producer/Consumer

2007-05-09T17:57:53Z

Eaolson: create stub

This is a stub article for the producer/consumer architecture.

[[Category:Design Patterns]]

Daemon

2007-05-09T17:55:14Z

Eaolson: add cat

A '''daemon''' is a process that runs in the background, not usually visible to a user. In LabVIEW, daemons are usually implemented as one of two types: self-launched or launched.

==Self-launching daemon==
A ''self-launching daemon'' is a VI that executes, closes its own [[front panel]], and continues to run in the background. A VI normally ceases to execute when its front panel is closed. To avoid this, a daemon VI first opens a [[VI reference]] to itself. The VI can then use the Front Panel:Open method to set the state of the VI to "hidden." In LabVIEW versions earlier than 8.0, the Front Panel:Open method is not available, but the Front Panel Window:Open property can be used.

==Launched daemon==
A ''launched daemon'' is a daemon VI that is opened by an intermediate, "launcher" VI. This allows a high-level VI to launch a background process and continue executing. In this case, the launcher VI opens a reference to the daemon VI and starts it using the Run VI method, with "Wait Until Done" set to False and "Auto Dispose Ref" set to True. The launcher VI must not close the VI reference to the daemon VI. Once the daemon VI has launched, the launcher VI can close itself.

==External Links==
* [http://zone.ni.com/devzone/cda/tut/p/id/5237 LabVIEW Application Design Patterns]

[[Category:Design Patterns]]

Daemon

2007-05-09T16:58:43Z

Eaolson: starting this article, could use example code

A '''daemon''' is a process that runs in the background, not usually visible to a user. In LabVIEW, daemons are usually implemented as one of two types: self-launched or launched.

==Self-launching daemon==
A ''self-launching daemon'' is a VI that executes, closes its own [[front panel]], and continues to run in the background. A VI normally ceases to execute when its front panel is closed. To avoid this, a daemon VI first opens a [[VI reference]] to itself. The VI can then use the Front Panel:Open method to set the state of the VI to "hidden." In LabVIEW versions earlier than 8.0, the Front Panel:Open method is not available, but the Front Panel Window:Open property can be used.

==Launched daemon==
A ''launched daemon'' is a daemon VI that is opened by an intermediate, "launcher" VI. This allows a high-level VI to launch a background process and continue executing. In this case, the launcher VI opens a reference to the daemon VI and starts it using the Run VI method, with "Wait Until Done" set to False and "Auto Dispose Ref" set to True. The launcher VI must not close the VI reference to the daemon VI. Once the daemon VI has launched, the launcher VI can close itself.

==Reference==
* [http://zone.ni.com/devzone/cda/tut/p/id/5237 LabVIEW Application Design Patterns]

GOOP - Graphical Object Oriented Programming

2007-05-09T15:38:00Z

Eaolson: /* See Also */ add dqGOOP, alphabetize

== GOOP - Graphical Object Oriented Programming ==

GOOP stands for Graphical Object Oriented Programming. It is a category of frameworks for non-native object-oriented programming in LabVIEW that support by reference objects with VI methods for operating on data. Some versions of GOOP support inheritance and dynamic dispatch. GOOP really hit mainstream with the release of the [http://zone.ni.com/devzone/cda/tut/p/id/3391#3 GOOP Toolkit] from [http://www.endevo.se/ Endevo] and [[National Instruments]]. OpenG even has its own version of GOOP, called [[OpenGOOP]].

GOOP is great because it allows you to build components that encapsulate their data, functionality, and behavior. Why ecapsulate?...

=== Benefits of Encapsulation ===

* Maintainable
* Scalable
* Useable (and therefore Reusable)
* Testable
* Enable Multiple Developer Collaboration

=== See Also ===
{{Portal|GOOP}}
* [[dqGOOP]]
* [[GOOP_History_by_Mattias_Ericsson]]
* [[OpenGOOP]]
[[Category:GOOP]]

=== External Links ===

* [http://zone.ni.com/devzone/conceptd.nsf/appnotebynumber/1A7B60096CE0CDA986256A9A0074E4EC?OpenDocument&node=dz52000_us App Note 143] – Graphical Object Oriented Programming (Jorgen Jehander)
* [http://zone.ni.com/devzone/devzoneweb.nsf/Opendoc?openagent&958B0EEC7BE032B986256863000A6B64 Graphical Object-Oriented Programming with LabVIEW] – NI Week 1999 Presentation by Jörgen Jehander and Stepan Riha
* [http://zone.ni.com/devzone/conceptd.nsf/2d17d611efb58b22862567a9006ffe76/5d7db42c91f392fc86256aae00463d78?OpenDocument#3Download Download GOOP Toolkits] from NI
* [http://sine.ni.com/apps/we/niepd_web_display.display_epd4?p_guid=B45EACE3EB6B56A4E034080020E74861&p_node=DZ52067&p_source=external Object-Oriented Techniques in LabVIEW] – Pure G examples from LV 4.1
* [http://www.endevo.se/ Endevo] - the company that supports/develops the GOOP Toolkit
* GOOP/G++ - Robert Burke's Web Page

Acronyms

2007-05-09T14:39:44Z

Eaolson: Acronyms moved to List of acronyms: This article is a list of acronyms and their definitions, not really an article *about* acronyms.

#REDIRECT [[List of acronyms]]

List of acronyms

2007-05-09T14:39:44Z

Eaolson: Acronyms moved to List of acronyms: This article is a list of acronyms and their definitions, not really an article *about* acronyms.

Acronyms and abbreviations : 
 
A/D - Analog/Digital 
ADatP - Automated Data Processing 
AKA - Also Known As 
ANSI - American National Standards Institute 
API - Application Programming Interfaces 
ASCII - American Standard Code for Information Interchange 
BTW - By The Way 
DA - Dumb ###### 
DAQ / DAQmx - Data acquisition 
DB - Database 
DILLIGAF - Do I Look Like I Give A Fuck? 
DIY - Do It Yourself 
DMA - Direct Memory Access 
FIFO - First In, First Out 
FKA - Formerly Known As 
FYI - For Your Information 
GL - Graphics Language 
GNU - GNU's Not Unix 
GOOP - Graphical Object-Oriented Programming 
GPL - GNU General Public License 
GPS - Global Positioning System 
HF - High Frequency 
HH - Homework Hustlers 
HTML - HyperText Markup Language 
IMHO = In My Humble Opinion 
IMNSHO - In My Not So Humble Opinion 
IMO - In My Opinion 
IP - Internet Protocol 
IR - Infrared 
IT - Information Technology 
JDK - Java Development Kit 
JK - Just Kidding 
JVM - Java Virtual Machine 
LED - Light-Emitting Diode 
LF - Low Frequency 
LIFO - Last In, First Out 
LOL - Laughing Out Loud 
MAX - Measurement & Automation Explorer 
MXI - Measurement eXtensions for Instrumentation 
MYOB - Mind Your Own Business 
NaN - Not A Number 
N00b - Newbie 
ODBC - Open DataBase Connectivity 
OEM - Original Equipment Manufacturer 
OMG - "Oh, My God!" 
OO - Object Oriented 
P2P - Peer-to-peer 
PCI - Peripheral Component Interconnect 
PS - post scriptum (Latin, "written after") 
PS - Power Supply 
PXI - PCI eXtensions for Instrumentation 
RT - Real Time 
RTFM - Read the Fucking/Fine Manual 
RTSI - Real-Time System Integration 
TCP - Transmission Control Protocol 
TMI - Too Much Information 
VBA - Visual Basic for Applications 
VI - Virtual Instrument 
VIT - Virtual Instrument Template 
VOIP - Voice Over Internet Protocol 
W3C - World Wide Web Consortium 
WTF - What The Fuck? 
XML - eXtensible Markup Language

LAVA

2007-05-08T17:57:24Z

Eaolson: a brief (and probably incomplete) description of LAVA

LAVA ('''L'''abVIEW '''A'''dvanced '''V'''irtual '''A'''rchitects), at lavag.org, is a website dedicated to advanced development in LabVIEW. It primarily consists of forums where developers discuss problems, solutions, and aspects of LabVIEW programming. It also has a Code Repository, where users can submit [[VI]]s for others to use. Recently, it has begun hosting the LabVIEW-related blogs of several LAVA users.

LAVA currently hosts this LabVIEW Wiki.

[[Category:Uncategorized]]