LabVIEW Wiki - User contributions [en]

XControl

2020-04-05T04:40:51Z

Smercer: /* Tricks */

'''XControls''' were first introduced in [[LabVIEW 8]] and enhance the power of front panel objects. An XControl is a front panel object with dedicated UI logic code linked and encapsulatedin the XControl in order to react to user events on the controls in contains. An XControl consists of several parts, managed in a ''.xctl'' file. The ''.xctl'' file is a XML-file like the project-file or [[Library]] files. Other parts of the XControl are called:
*[[XControl:Properties|Properties]]
*[[XControl:Abilities|Abilities]]
*[[XControl:Methods|Methods]]

__TOC__

== Limitations ==
An XControl functions like a subpanel in the hosting VI. Subpanels (and therefore XControls) ''can not'' be placed inside an array. Note that you ''can'' define your XControl data as an array of any LabVIEW data type, and you ''can'' use array controls in the facade vi.

Using LabVIEW native objects (.lvclass files) inside the state control of an XControl tends to crash LabVIEW for versions less than 8.5.1 when the XControl is used in a different application instance.

Also, XControls have limitations when running in VIs that are part of a [[Library]] (or [[Packed Project Library|Packed Project Library (PPL)]]), or a [[LabVIEW Class]]. This makes it difficult to use in a large application using [[Actor Framework]] or plugin architectures using [[Packed Project Library|PPLs]]. See more in the [[QControl|QControls]] article.

== Tricks ==
*If you require a variable number of runtime instances of your XControl, Jarrod Slocum of [[National Instruments]] has created an example [http://community.ni.com/examples/linked-object-list-in-labview-8-0-using-xcontrols Linked Object List] based on a Subpanel ''inside'' an XControl.

* If you want to react to dynamic events (or user events) you need them to register at the XControl Facade '''before''' the event happens.
* If Façade is not executing fast enough to keep up with data updates, it causes the updates to queue up. The updates will happen even after the VI stops running. To reduce data updates:
Thanks to Ram Kudukoli (of NI R&D) for sharing this with us at the recent CLA Summit:

** Open the Xcontrol .xctl file in a text editor like Notepad.
** Add the bolded line shown below:
<Property Name="NI.Lib.Version" Type="Str">1.0.0.0</Property>
<Property Name="NI.XClass.Flags" Type="Int">0</Property>
'''<Property Name="NI.XCtl.OptimizeDataUpdate" Type="Bool">true</Property>
<Property Name="NI.XItem.DeclaredLeakProof" Type="Bool">false</Property>'''
** Save the .xctl file.
([http://lavag.org/topic/15680-no-update-on-x-control-value-change/page__view__findpost__p__94838 LAVAG source])

== See also ==
*[[QControl|QControls]]

[[Category:XControl]]

Songs for the LabVIEW Programmer (songs about LV and the dataflow experience)

2019-08-28T21:55:17Z

Smercer: Provide attribution and reference to the original content.

'''Note: The content here can be found in better formatted form in this NI forum thread:

https://forums.ni.com/t5/BreakPoint/Songs-for-the-LabVIEW-Programmer-songs-about-LV-and-the-dataflow/td-p/1205355?profile.language=en'''
===
Quoting from Aristos Queue:
Last year at the LAVA BBQ here at NI Week, several users -- after a bit of drinking -- discussed the need for some LabVIEW drinking songs. Since NI tries to be responsive to user needs, I started creating songs to meet that need, and pulled on other R&D team members to help out. I already had a couple of children's songs for teaching LV to kids. So for the LAVA BBQ last night, I released Songs For The LabVIEW Programmer. There were only paper print outs available last night. Today I'm posting the songs for everyone to enjoy.

===================================
Songs For The LabVIEW Programmer

Drinking Songs: Songs for singing in groups, particularly while drunk, celebrating LabVIEW.

Teaching Songs: Songs for young children, just learning LabVIEW for the first time.

Emotional Songs: The angst, the joy, and all the other emotions that programming LabVIEW may raise within the soul.

The Debugging Tune*
(to the tune of The Itsy Bitsy Spider**)

The execution highlight
goes down the wire route.
All along the way,
probes may call the data out.
If it hits a breakpoint then there it will remain
until the Pause button
lets the highlight move again!

* because spiders are good at removing bugs
** feel free to adapt the original’s hand gestures!

There Was An Old Lady Who Wrote A VI
(to the tune of There Was An Old Lady Who Swallowed A Fly)

There was an old lady who wrote a VI.
I don’t know why she wrote the VI – it’s a blank VI!

There was an old lady who dropped “Simulate Signal.”
I don’t know why she needed the signal
– perhaps she just likes a noisy signal?
She needed the signal to start the VI.
I don’t know why she wrote the VI – perhaps she’s high?

There was an old lady who dropped “Power Spectrum.”
I don’t know why she needed the spectrum
– perhaps she just pulled it out of her rectum?
She needed the spectrum to filter the signal.
She needed the signal to start the VI.
I don’t know why she wrote the VI – it’s a trivial VI.

There was an old lady who dropped a graph.
I don’t know why she needed the graph
– perhaps she did it just for a laugh?
She needed the graph to display the spectrum.
She needed the spectrum to filter the signal.
She needed the signal to start the VI.
I don’t know why she wrote the VI – to impress a guy?

There was an old lady who dropped a while loop.
I don’t know why she needed a loop, why she needed a loop, why she needed a loop, why she – *SLAP*. (Oh, thanks…)
She needed the loop to repeat the graph.
She needed the graph to display the spectrum.
She needed the spectrum to filter the signal.
She needed the signal to start the VI.
I don’t know why she wrote the VI – it’s a broken VI.

There was an old lady who created a button.
I don’t know why she created the button
– I’d ask her but she told me not to butt in.
She needed the button to stop the loop.
She needed the loop to repeat the graph.
She needed the graph to display the spectrum.
She needed the spectrum to filter the signal.
She needed the signal to start the VI.
I don’t know why she wrote the VI – it’s a familiar VI.

There was an old lady who wrote Acquire-Analyze-Present.
And now we know why she wrote the VI: She works for NI!

What Do You Do With A Broken Wire?
(to the tune of What Do You Do With A Drunken Sailor?)

CHORUS:
What do you do with a broken wire?
What do you do with a broken wire?
What do you do with a broken wire to fix a broken VI?

Verse 1:
Change one of its ends to an indicator!
Change one of its ends to an indicator!
Change one of its ends to an indicator!
That’ll fix the VI!

Verse 2:
Insert a node to convert the source type!
…
That’ll fix the VI!

Verse 3:
Check all ends connect to terminals!
…
That’ll fix the VI!

Verse 4:
Use control-B and just remove it!
…
That’ll fix the VI!

Verse 5:
Do whatever the Error Window tells ya!
…
That’ll fix the VI!

Mary Had A Block Diagram
(to the tune of Mary Had A Little Lamb)

Mary had a block diagram
block diagram
block diagram
Mary had a block diagram
and she kept adding nodes.

It grew larger than the screen one day
screen one day
screen one day
It grew larger than the screen one day
which was against the rule.

So Mary created subVIs
subVIs
subVIs
So Mary created subVIs
with “Convert To SubVI” tool!

LabInterruptedVIEW
(to the tune of An Austrian Went Yodeling)

Ohhh, a programmer launched LabVIEW, a new project begun,
When along came a power spike, interrupting the fun. L

Ohhhhhhhhh (lots of pounding on the table)
New Class! New V-I! Control+Space! Wire Click! Noooo! (howls)

Oh, a programmer launched LabVIEW, a new project begun,
When along came a manager, interrupting the fun. L

Ohhhhhhhhh (lots of pounding on the table)
New Class! New V-I! Control+Space! Wire Click!
“That would be greaaaat.” Noooo!

Oh, a programmer launched LabVIEW, a new project begun,
When along came a forced reboot, interrupting the fun. L

Ohhhhhhhhh (lots of pounding on the table)
New Class! New V-I! Control+Space! Wire Click!
Dum-du-du-du-duuum! (MS Windows launch sound)
“That would be greaaaat.” Noooo!

<and so on, each verse adding another sound or phrase>

LAST VERSE:
Oh, a programmer launched LabVIEW, a new project begun,
When along came some spare time, and now the VI does run!

The Event Structure
(to the tune of Pop Goes The Weasel)

All around the front panel
the user clicked the mouse
And as it moved or clicked or dragged…
POP went the events!

Unbreak My VIs by Akash Bhakta
(to the tune of Unbreak My Heart by Toni Braxton)
http://www.lyricsdomain.com/20/toni_braxton/unbreak_my_heart.html

Un-break my VI
Say you can run it again
Undo this break that you caused
When I broke something else
That does not affect my VI
Un-open this error list
I scrolled so many times
Un-break my VI
My VI...

LabVIEW Rhapsody (by Stephen Mercer, Christina Rogers, & Jeff Boettcher)
(to the tune of Bohemian Rhapsody -- this song is loosely based on a new hire on the LV R&D team breaking LabVIEW.exe when he submits his first feature into the code base. There are a couple of internal terms you should know. "Bowling" is our term for submitting code to Perforce. The "trolls" are project managers who control which developers can submit to Perforce at what times -- they ask questions like, "Have you tested the code? Did you get someone to review it?" AppLibs is the build for the lvrt.dll and InTheDark is the build for LabVIEW RealTime.)

Is this my real job?
Is this just fantasy?
Working on LabVIEW,
Can’t believe they just hired me.
Open VIs
Look at diagrams in G…
We can do better, we need no C routine
Because it’s graphical, data flow,
Down the wires, into nodes,
Every way the code flows, that’s what really matters, in G, in G

Manager, just broke the build.
Used Perforce, synch’d to head,
Hit submit, and now it’s dead.
Manager, the test suite used to run,
But now I’ve gone and blown it all away.
Manager, oooo,
Didn’t mean to make you cry.
I’ll have it fixed again this time tomorrow!
Carry on, carry on, (as if deadlines really matter…)

Too late, release has come
Sends shivers down my spine
CAR list growing all the time.
OK, everybody, I’ve got to bowl,
Just can’t spend any more time to test the code.
Mama, oooo, (anyway the code bowls)
I don’t want to bowl…
I sometimes wish they’d ne’er filed this CAR at all…

The build machine syncs all the files that it can,
Incredibuild, Incredibuild – can you make it build faster?
InTheDark and Applibs – did you build the realtime? No!
LabVIEW linking, LabVIEW linking,
LabVIEW linking, LabVIEW linking,
LabVIEW linking, here we go – log files show…

I’m just a newbie, nobody told me!
He’s just a new grad from college recently…
He’ll bring in donuts for this bowl travesty.
Easy bug, easy fix – will you let me bowl?
Broken Build! No, we will not let you bowl! Let him bowl!
Broken Build! We will not let you bowl! Let him bowl!
Broken Build! We will not let you bowl! Let me bowl!
We will not let you bowl! Let me bowl! Never!
Never let you bowl! Let me bowl!
Never let you bowl! Oooo
No, no, no, no, no, no, YES -
Oh mama mia, mama mia, mama mia I can bowl!
The manager has given troll permission to me
yes me
yes me!

So you think you can submit without testing real time?
So you think you can bowl and then leave for a while?
Oh, baby – can’t do this to our baby.
Just back it all out, just back that change right outta here.

Ooh yeah, ooh yeah
LabVIEW really matters.
Anyone can see
LabVIEW really matters – LabVIEW really matters to me

In this way the code bowls…

We did this one in another thread Knight mares: Ben has one there too.

(John lenon Imagine)

Imagine there's no Visual Basic
It's easy if you try
Only Labview for coding
Around us only wires
Imagine all the people
Living for a day

Imagine there's only blockdiagrams
It isn't hard to do
Nothing to kill or die for
And event structures too
Imagine all the people
Living life in GUI

You may say that I'm a dreamer
But I'm not the only one
I hope someday you'll join us
And the world will program as one

Imagine written code
I wonder if you can
No need for probes
A brotherhood of man
Imagine all the people
Sharing all the code

You may say that I'm a dreamer
But I'm not the only one
I hope someday you'll join us
And the world will program as one

As originally presented here

(too, the tune of...."Mary Poppin's" song "Supercalifragilisitexpalidous" )

BE.. cause I was afraid to post when I was new to Lab(VIEW)
and Ben, he gave my code a tweak, and told me that I had,(Two)
used a local varible that made my VI bad.(oooh)
Then Ravens Fan explained to me what I really had(Whoo!)

Ohhhh...

Altenbach, smercurio and nugget for the week...
Altenbach, smercurio and nugget for the week...
Altenbach, smercurio and nugget for the week...
Super class of LVOOP and now my code's not weak!

Hummmm..LabVIEW.ini Hummmmm ditty I
Hummmm..LabVIEW.ini Hummmmm ditty I

SO.. as you'll see I'm soon to be an NI gifted Knight
And all my LabVIEW code will be just so completely right
I'll never miss a single trick my postings are all tight
And when I send an app to you it'll sing the bugs goodnight!

OHHHH

Altenbach, smercurio and nugget for the week...
Altenbach, smercurio and nugget for the week...
Altenbach, smercurio and nugget for the week...
Super class of LVOOP and now my code's not weak! ..

(Dick VanDyke- eat your heart out! )

[[Category:Culture]]

Aspects of error handling

2019-07-12T16:14:30Z

Smercer: improve table spacing

{{TOCnestright}}
'''Error Handling''' refers to the anticipation, response, and recovery from error conditions. Writing VIs and subVIs that incorporate error handling is considered good form, not only to allow the user indication of abnormal software execution, but also to allow the software to make decisions based on the status of previous operations. Including error handling in your code assists in troubleshooting ([[debugging]]), modularity, and user friendliness.
LV R&D architect Stephen Loftus-Mercer divides the topic of "error handling" into five (5) separate aspects in order to keep discussions on topic -- error handling is too broad for most conversations. The divisions below were introduced by Stephen Loftus-Mercer in several informal settings; LV R&D architect Darren Nattinger was the first to present them formally.<ref>Nattinger, Darren. [http://bit.ly/dnatterrors "What to Expect When You're Expecting an Error"] (NIWeek 2018)</ref>

{| class="wikitable" style="text-align: left;"
|- style="vertical-align:top;"
! Aspect !! Details
|- style="vertical-align:top;"
| '''Error Generation''' is the creation of an [[Error cluster|error cluster]] value at the point that something goes wrong in your LabVIEW code. Feature requests in this area cover readability of the error generation code on the diagram, simplicity of selecting the right error, and packaging valuable metadata with the error (such as the call chain, timestamp, or situation details). 

|| Errors may be emitted by both VIs and built-in nodes. When writing a VI that will emit a new error, there are two options:
# (Preferred) Create an error value using one of the library tools, i.e. [[Error Ring]] or ''Error Cluster from Error Code.vi''
# Directly bundling '''status''' boolean, '''code''' numeric, and '''source''' string together. Doing this will not automatically include the call chain and is very hard to find in code, as you will be searching all Bundle nodes. It is not recommended unless it is done in [[Real Time]], [[FPGA]], or if you are returning an error cluster directly from a non-G DLL.
|- style="vertical-align:top;"
| '''Error Propagation''' is the act of moving an error value through your LabVIEW code. When an error has been created it should be propagated or responded to (next section). Feature requests in this area include ways of aggregating multiple errors together, extending case structure behaviors, stopping loops/systems when errors occur, merging errors from parallel code, hiding error wires and creating some sort of automatic error propagation rules, etc. 

|| Propagation is accomplished using the error cluster and wiring from error inputs through the various code paths and out an error output. When propagating an error to a subVI, it is considered good practice to place error cluster input and output in the lower quadrants (error in on the left, and error out on the right). Multiple code/error paths can exist depending on data flow and parallelization.

'''The number one rule of error propagation is ''Don't Break the Error Chain!''''' An error chain is the code path of the error from the point of generation through the VI hierarchy to the point of being handled by an Error Response, Error Display, and/or Error Logging. A break in the error chain occurs if even one VI in the hierarchy fails to propagate the error correctly. This causes an error from an upstream node to be lost and makes [[Debugging|debugging]] difficult.

An error chain can be broken in three ways:

# Neglecting to wire an output that is part of the error chain
# Zero-iteration [[For Loop|For Loops]]
# Sloppy Merge Errors ordering

To attempt to avoid breaking the error chain, the following [[VI Analyzer]] test can be run:

* '''Error Cluster Wired''' - Detects subVIs and functions with unwired error outputs
* '''Unused Code''' - Detects unwired output tunnels of structures
* '''For Loop Error Handling''' - Detects loop-related error propagation and Merge Errors ordering issues on loop error output tunnels (VI Analyzer Toolkit 2018 or later)
|- style="vertical-align:top;"
| '''Error Response''' is what you do in your LabVIEW code when an error occurs and you analyze the error value within the code to respond in a certain way. Feature requests include ways to simplify coding the following behaviors:
* Ignoring certain errors
* Retrying the operation
* Translating or Modifying an error
* Failing the operation and closing the program
 
||
[[File:Screen Shot 2019-06-27 at 1.50.14 AM.png|600px|thumb]]
See Stephen Loftus-Mercer's poster on [https://forums.ni.com/ni/attachments/ni/3044/3784/2/LabVIEW%20Error%20Responses.pdf Error Responses].
The typical operation of a node is to execute only if no error comes in and may add its own outgoing error. Wrapping the entire code of a SubVI within a conditional case structure can make the SubVI act as a typical node (see [[Error Case Structure]]). However, if the code inside of the structure already operates according to a typical node then the case structure is redundant and keeps the compiler from some optimization it could do if the structure was not there.

Also, the developer could choose to enable [[Automatic Error Handling]]. However, automatic error handling assumes all error conditions are tested during development and requires special tooling ([[VI Scripting]]) to enable or disable the entire code base unless every output is wired by the time development is complete. The experts have strong opinions on whether automatic error handling should be used during development, although all agree that it should never occur in well-written released libraries and applications.<ref>Nattinger, Darren. [http://bit.ly/dnatterrors "What to Expect When You're Expecting an Error"] (NIWeek 2018)</ref>
|- style="vertical-align:top;"
| '''Error Display''' is the act of displaying error information to the end user and/or code developer. Feature requests here include error localization (i.e., generating errors on French system but displaying them on an English system), meaningful translation for error codes, and rendering of the error metadata in a user-friendly form (color, pictures, tables, etc). Display also includes ways of providing advice on common causes of the error and how to fix the error. 
|| As of LabVIEW 2019, this is almost always accomplished with ''Simple Error Handler.vi'' or ''General Error Handler.vi''.

The ''General Error Handler.vi'' includes an input parameter for the type of dialog, one option is "no dialog." It is recommended to use it instead of calling ''Error Code Database.vi''. The primary reason for the recommendation is that the translation of error code cluster into human readable strings involves much more than just looking up text in the database. The '''source''' string itself may include information to override or extend the database, and the text in either the '''source''' string or the database may include formatting commands, such as HTML tags for bold face. Encoding information in the '''source''' string is a technique that will become more common in the future.

You may desire to display the text, fully formatted, in a string indicator of your own instead of in any dialog. Use the function of ''General Error Handler CORE.vi'' (found on the block diagram of ''General Error Handler.vi'') to do this.
|- style="vertical-align:top;"
| '''Error Logging''' involves taking errors generated by LabVIEW code and logging them to file for later analysis. Error logging is similar to error display (above), but logging has some more interesting variations – recording in a human-readable form or is machine parseable, recording as localized or non-localized. Most importantly, whereas “no error” is not typically displayed to the user, it is critical that we be able to log “no error” so a log file can distinguish a successful run (“no error”) from an aborted/crashed run (one where the log file is empty). Feature requests in this area include mechanisms for making recorded errors readable and assistance debugging errors after the application finishes.

|| LabVIEW has no formal error log API because typically logging of errors needs to be folded into the general event logs of an API, which vary radically between applications. The error cluster can be translated into a loggable string by using the ''General Error Handler.vi'', wiring "no dialog" to its input, and writing its string outputs to a log.

For more insight on why it is important to log "no error", please contemplate [http://thecodelesscode.com/case/48 the 48th koan of Codeless Code]: ''"The Protocols tell us of no fewer than Four Silences: the Silence Before Words, the Silence Between Words, the Silence of the Broken Pipe, and the Silence of Fallen Parcels. To the initiate they are as different as the characters for “end” 末 and “not yet” 未, although the outsider cannot tell one from the other."''
|}

== External Links ==
*[http://www.ni.com/getting-started/labview-basics/handling-errors Error Handling Basics by NI].
*[http://controlsoftwaresolutions.com/error-handling-strategies-labview/ David Maidman’s Blog Post].
*[https://forums.ni.com/t5/LabVIEW-Development-Best/quot-SOLID-Error-Handling-quot-presentation-at-NIWeek-2017/td-p/3629639 SOLID Error Handling by Dmitry].
*[http://www.ni.com/example/31253/en/ Structured Error Handler Express VI by NI]
*[http://thecodelesscode.com/case/48 The Codeless Code, Koan 48]

== References ==

[[Category:LabVIEW fundamentals]]

Aspects of error handling

2019-07-12T16:11:34Z

Smercer: fix table alignment

{{TOCnestright}}
'''Error Handling''' refers to the anticipation, response, and recovery from error conditions. Writing VIs and subVIs that incorporate error handling is considered good form, not only to allow the user indication of abnormal software execution, but also to allow the software to make decisions based on the status of previous operations. Including error handling in your code assists in troubleshooting ([[debugging]]), modularity, and user friendliness.
LV R&D architect Stephen Loftus-Mercer divides the topic of "error handling" into five (5) separate aspects in order to keep discussions on topic -- error handling is too broad for most conversations. The divisions below were introduced by Stephen Loftus-Mercer in several informal settings; LV R&D architect Darren Nattinger was the first to present them formally.<ref>Nattinger, Darren. [http://bit.ly/dnatterrors "What to Expect When You're Expecting an Error"] (NIWeek 2018)</ref>

{| class="wikitable" style="text-align: left;"
|- style="vertical-align:top;"
! Aspect !! Details
|- style="vertical-align:top;"
| '''Error Generation''' is the creation of an [[Error cluster|error cluster]] value at the point that something goes wrong in your LabVIEW code. Feature requests in this area cover readability of the error generation code on the diagram, simplicity of selecting the right error, and packaging valuable metadata with the error (such as the call chain, timestamp, or situation details).
|| Errors may be emitted by both VIs and built-in nodes. When writing a VI that will emit a new error, there are two options:
# (Preferred) Create an error value using one of the library tools, i.e. [[Error Ring]] or ''Error Cluster from Error Code.vi''
# Directly bundling '''status''' boolean, '''code''' numeric, and '''source''' string together. Doing this will not automatically include the call chain and is very hard to find in code, as you will be searching all Bundle nodes. It is not recommended unless it is done in [[Real Time]], [[FPGA]], or if you are returning an error cluster directly from a non-G DLL.
|- style="vertical-align:top;"
| '''Error Propagation''' is the act of moving an error value through your LabVIEW code. When an error has been created it should be propagated or responded to (next section). Feature requests in this area include ways of aggregating multiple errors together, extending case structure behaviors, stopping loops/systems when errors occur, merging errors from parallel code, hiding error wires and creating some sort of automatic error propagation rules, etc.
|| Propagation is accomplished using the error cluster and wiring from error inputs through the various code paths and out an error output. When propagating an error to a subVI, it is considered good practice to place error cluster input and output in the lower quadrants (error in on the left, and error out on the right). Multiple code/error paths can exist depending on data flow and parallelization.

'''The number one rule of error propagation is ''Don't Break the Error Chain!''''' An error chain is the code path of the error from the point of generation through the VI hierarchy to the point of being handled by an Error Response, Error Display, and/or Error Logging. A break in the error chain occurs if even one VI in the hierarchy fails to propagate the error correctly. This causes an error from an upstream node to be lost and makes [[Debugging|debugging]] difficult.

An error chain can be broken in three ways:

# Neglecting to wire an output that is part of the error chain
# Zero-iteration [[For Loop|For Loops]]
# Sloppy Merge Errors ordering

To attempt to avoid breaking the error chain, the following [[VI Analyzer]] test can be run:

* '''Error Cluster Wired''' - Detects subVIs and functions with unwired error outputs
* '''Unused Code''' - Detects unwired output tunnels of structures
* '''For Loop Error Handling''' - Detects loop-related error propagation and Merge Errors ordering issues on loop error output tunnels (VI Analyzer Toolkit 2018 or later)
|- style="vertical-align:top;"
| '''Error Response''' is what you do in your LabVIEW code when an error occurs and you analyze the error value within the code to respond in a certain way. Feature requests include ways to simplify coding the following behaviors:
* Ignoring certain errors
* Retrying the operation
* Translating or Modifying an error
* Failing the operation and closing the program
||
[[File:Screen Shot 2019-06-27 at 1.50.14 AM.png|600px|thumb]]
See Stephen Loftus-Mercer's poster on [https://forums.ni.com/ni/attachments/ni/3044/3784/2/LabVIEW%20Error%20Responses.pdf Error Responses].
The typical operation of a node is to execute only if no error comes in and may add its own outgoing error. Wrapping the entire code of a SubVI within a conditional case structure can make the SubVI act as a typical node (see [[Error Case Structure]]). However, if the code inside of the structure already operates according to a typical node then the case structure is redundant and keeps the compiler from some optimization it could do if the structure was not there.

Also, the developer could choose to enable [[Automatic Error Handling]]. However, automatic error handling assumes all error conditions are tested during development and requires special tooling ([[VI Scripting]]) to enable or disable the entire code base unless every output is wired by the time development is complete. The experts have strong opinions on whether automatic error handling should be used during development, although all agree that it should never occur in well-written released libraries and applications.<ref>Nattinger, Darren. [http://bit.ly/dnatterrors "What to Expect When You're Expecting an Error"] (NIWeek 2018)</ref>
|- style="vertical-align:top;"
| '''Error Display''' is the act of displaying error information to the end user and/or code developer. Feature requests here include error localization (i.e., generating errors on French system but displaying them on an English system), meaningful translation for error codes, and rendering of the error metadata in a user-friendly form (color, pictures, tables, etc). Display also includes ways of providing advice on common causes of the error and how to fix the error.
|| As of LabVIEW 2019, this is almost always accomplished with ''Simple Error Handler.vi'' or ''General Error Handler.vi''.

The ''General Error Handler.vi'' includes an input parameter for the type of dialog, one option is "no dialog." It is recommended to use it instead of calling ''Error Code Database.vi''. The primary reason for the recommendation is that the translation of error code cluster into human readable strings involves much more than just looking up text in the database. The '''source''' string itself may include information to override or extend the database, and the text in either the '''source''' string or the database may include formatting commands, such as HTML tags for bold face. Encoding information in the '''source''' string is a technique that will become more common in the future.

You may desire to display the text, fully formatted, in a string indicator of your own instead of in any dialog. Use the function of ''General Error Handler CORE.vi'' (found on the block diagram of ''General Error Handler.vi'') to do this.
|- style="vertical-align:top;"
| '''Error Logging''' involves taking errors generated by LabVIEW code and logging them to file for later analysis. Error logging is similar to error display (above), but logging has some more interesting variations – recording in a human-readable form or is machine parseable, recording as localized or non-localized. Most importantly, whereas “no error” is not typically displayed to the user, it is critical that we be able to log “no error” so a log file can distinguish a successful run (“no error”) from an aborted/crashed run (one where the log file is empty). Feature requests in this area include mechanisms for making recorded errors readable and assistance debugging errors after the application finishes.
|| LabVIEW has no formal error log API because typically logging of errors needs to be folded into the general event logs of an API, which vary radically between applications. The error cluster can be translated into a loggable string by using the ''General Error Handler.vi'', wiring "no dialog" to its input, and writing its string outputs to a log.

For more insight on why it is important to log "no error", please contemplate [http://thecodelesscode.com/case/48 the 48th koan of Codeless Code]: ''"The Protocols tell us of no fewer than Four Silences: the Silence Before Words, the Silence Between Words, the Silence of the Broken Pipe, and the Silence of Fallen Parcels. To the initiate they are as different as the characters for “end” 末 and “not yet” 未, although the outsider cannot tell one from the other."''
|}

== External Links ==
*[http://www.ni.com/getting-started/labview-basics/handling-errors Error Handling Basics by NI].
*[http://controlsoftwaresolutions.com/error-handling-strategies-labview/ David Maidman’s Blog Post].
*[https://forums.ni.com/t5/LabVIEW-Development-Best/quot-SOLID-Error-Handling-quot-presentation-at-NIWeek-2017/td-p/3629639 SOLID Error Handling by Dmitry].
*[http://www.ni.com/example/31253/en/ Structured Error Handler Express VI by NI]
*[http://thecodelesscode.com/case/48 The Codeless Code, Koan 48]

== References ==

[[Category:LabVIEW fundamentals]]

Aspects of error handling

2019-07-12T15:55:30Z

Smercer: specify who these people are

{{TOCnestright}}
'''Error Handling''' refers to the anticipation, response, and recovery from error conditions. Writing VIs and subVIs that incorporate error handling is considered good form, not only to allow the user indication of abnormal software execution, but also to allow the software to make decisions based on the status of previous operations. Including error handling in your code assists in troubleshooting ([[debugging]]), modularity, and user friendliness.
LV R&D architect Stephen Loftus-Mercer divides the topic of "error handling" into five (5) separate aspects in order to keep discussions on topic -- error handling is too broad for most conversations. The divisions below were introduced by Stephen Loftus-Mercer in several informal settings; LV R&D architect Darren Nattinger was the first to present them formally.<ref>Nattinger, Darren. [http://bit.ly/dnatterrors "What to Expect When You're Expecting an Error"] (NIWeek 2018)</ref>

{| class="wikitable"
|-
! Aspect !! Details
|-
| '''Error Generation''' is the creation of an [[Error cluster|error cluster]] value at the point that something goes wrong in your LabVIEW code. Feature requests in this area cover readability of the error generation code on the diagram, simplicity of selecting the right error, and packaging valuable metadata with the error (such as the call chain, timestamp, or situation details).
|| Errors may be emitted by both VIs and built-in nodes. When writing a VI that will emit a new error, there are two options:
# (Preferred) Create an error value using one of the library tools, i.e. [[Error Ring]] or ''Error Cluster from Error Code.vi''
# Directly bundling '''status''' boolean, '''code''' numeric, and '''source''' string together. Doing this will not automatically include the call chain and is very hard to find in code, as you will be searching all Bundle nodes. It is not recommended unless it is done in [[Real Time]], [[FPGA]], or if you are returning an error cluster directly from a non-G DLL.
|-
| '''Error Propagation''' is the act of moving an error value through your LabVIEW code. When an error has been created it should be propagated or responded to (next section). Feature requests in this area include ways of aggregating multiple errors together, extending case structure behaviors, stopping loops/systems when errors occur, merging errors from parallel code, hiding error wires and creating some sort of automatic error propagation rules, etc.
|| Propagation is accomplished using the error cluster and wiring from error inputs through the various code paths and out an error output. When propagating an error to a subVI, it is considered good practice to place error cluster input and output in the lower quadrants (error in on the left, and error out on the right). Multiple code/error paths can exist depending on data flow and parallelization.

'''The number one rule of error propagation is ''Don't Break the Error Chain!''''' An error chain is the code path of the error from the point of generation through the VI hierarchy to the point of being handled by an Error Response, Error Display, and/or Error Logging. A break in the error chain occurs if even one VI in the hierarchy fails to propagate the error correctly. This causes an error from an upstream node to be lost and makes [[Debugging|debugging]] difficult.

An error chain can be broken in three ways:

# Neglecting to wire an output that is part of the error chain
# Zero-iteration [[For Loop|For Loops]]
# Sloppy Merge Errors ordering

To attempt to avoid breaking the error chain, the following [[VI Analyzer]] test can be run:

* '''Error Cluster Wired''' - Detects subVIs and functions with unwired error outputs
* '''Unused Code''' - Detects unwired output tunnels of structures
* '''For Loop Error Handling''' - Detects loop-related error propagation and Merge Errors ordering issues on loop error output tunnels (VI Analyzer Toolkit 2018 or later)
|-
| '''Error Response''' is what you do in your LabVIEW code when an error occurs and you analyze the error value within the code to respond in a certain way. Feature requests include ways to simplify coding the following behaviors:
* Ignoring certain errors
* Retrying the operation
* Translating or Modifying an error
* Failing the operation and closing the program
||
[[File:Screen Shot 2019-06-27 at 1.50.14 AM.png|600px|thumb]]
See Stephen Loftus-Mercer's poster on [https://forums.ni.com/ni/attachments/ni/3044/3784/2/LabVIEW%20Error%20Responses.pdf Error Responses].
The typical operation of a node is to execute only if no error comes in and may add its own outgoing error. Wrapping the entire code of a SubVI within a conditional case structure can make the SubVI act as a typical node (see [[Error Case Structure]]). However, if the code inside of the structure already operates according to a typical node then the case structure is redundant and keeps the compiler from some optimization it could do if the structure was not there.

Also, the developer could choose to enable [[Automatic Error Handling]]. However, automatic error handling assumes all error conditions are tested during development and requires special tooling ([[VI Scripting]]) to enable or disable the entire code base unless every output is wired by the time development is complete. The experts have strong opinions on whether automatic error handling should be used during development, although all agree that it should never occur in well-written released libraries and applications.<ref>Nattinger, Darren. [http://bit.ly/dnatterrors "What to Expect When You're Expecting an Error"] (NIWeek 2018)</ref>
|-
| '''Error Display''' is the act of displaying error information to the end user and/or code developer. Feature requests here include error localization (i.e., generating errors on French system but displaying them on an English system), meaningful translation for error codes, and rendering of the error metadata in a user-friendly form (color, pictures, tables, etc). Display also includes ways of providing advice on common causes of the error and how to fix the error.
|| As of LabVIEW 2019, this is almost always accomplished with ''Simple Error Handler.vi'' or ''General Error Handler.vi''.

The ''General Error Handler.vi'' includes an input parameter for the type of dialog, one option is "no dialog." It is recommended to use it instead of calling ''Error Code Database.vi''. The primary reason for the recommendation is that the translation of error code cluster into human readable strings involves much more than just looking up text in the database. The '''source''' string itself may include information to override or extend the database, and the text in either the '''source''' string or the database may include formatting commands, such as HTML tags for bold face. Encoding information in the '''source''' string is a technique that will become more common in the future.

You may desire to display the text, fully formatted, in a string indicator of your own instead of in any dialog. Use the function of ''General Error Handler CORE.vi'' (found on the block diagram of ''General Error Handler.vi'') to do this.
|-
| '''Error Logging''' involves taking errors generated by LabVIEW code and logging them to file for later analysis. Error logging is similar to error display (above), but logging has some more interesting variations – recording in a human-readable form or is machine parseable, recording as localized or non-localized. Most importantly, whereas “no error” is not typically displayed to the user, it is critical that we be able to log “no error” so a log file can distinguish a successful run (“no error”) from an aborted/crashed run (one where the log file is empty). Feature requests in this area include mechanisms for making recorded errors readable and assistance debugging errors after the application finishes.
|| LabVIEW has no formal error log API because typically logging of errors needs to be folded into the general event logs of an API, which vary radically between applications. The error cluster can be translated into a loggable string by using the ''General Error Handler.vi'', wiring "no dialog" to its input, and writing its string outputs to a log.

For more insight on why it is important to log "no error", please contemplate [http://thecodelesscode.com/case/48 the 48th koan of Codeless Code]: ''"The Protocols tell us of no fewer than Four Silences: the Silence Before Words, the Silence Between Words, the Silence of the Broken Pipe, and the Silence of Fallen Parcels. To the initiate they are as different as the characters for “end” 末 and “not yet” 未, although the outsider cannot tell one from the other."''
|}

== External Links ==
*[http://www.ni.com/getting-started/labview-basics/handling-errors Error Handling Basics by NI].
*[http://controlsoftwaresolutions.com/error-handling-strategies-labview/ David Maidman’s Blog Post].
*[https://forums.ni.com/t5/LabVIEW-Development-Best/quot-SOLID-Error-Handling-quot-presentation-at-NIWeek-2017/td-p/3629639 SOLID Error Handling by Dmitry].
*[http://www.ni.com/example/31253/en/ Structured Error Handler Express VI by NI]
*[http://thecodelesscode.com/case/48 The Codeless Code, Koan 48]

== References ==

[[Category:LabVIEW fundamentals]]

Aspects of error handling

2019-07-12T15:54:14Z

Smercer: Fix statement of intro to be less factual and instead attribute to expert opinion

{{TOCnestright}}
'''Error Handling''' refers to the anticipation, response, and recovery from error conditions. Writing VIs and subVIs that incorporate error handling is considered good form, not only to allow the user indication of abnormal software execution, but also to allow the software to make decisions based on the status of previous operations. Including error handling in your code assists in troubleshooting ([[debugging]]), modularity, and user friendliness.
Stephen Loftus-Mercer divides the topic of "error handling" into five (5) separate aspects in order to keep discussions on topic -- error handling is too broad for most conversations. The divisions below were introduced by Stephen Loftus-Mercer in several informal settings; Darren Nattinger was the first to present them formally.<ref>Nattinger, Darren. [http://bit.ly/dnatterrors "What to Expect When You're Expecting an Error"] (NIWeek 2018)</ref>

{| class="wikitable"
|-
! Aspect !! Details
|-
| '''Error Generation''' is the creation of an [[Error cluster|error cluster]] value at the point that something goes wrong in your LabVIEW code. Feature requests in this area cover readability of the error generation code on the diagram, simplicity of selecting the right error, and packaging valuable metadata with the error (such as the call chain, timestamp, or situation details).
|| Errors may be emitted by both VIs and built-in nodes. When writing a VI that will emit a new error, there are two options:
# (Preferred) Create an error value using one of the library tools, i.e. [[Error Ring]] or ''Error Cluster from Error Code.vi''
# Directly bundling '''status''' boolean, '''code''' numeric, and '''source''' string together. Doing this will not automatically include the call chain and is very hard to find in code, as you will be searching all Bundle nodes. It is not recommended unless it is done in [[Real Time]], [[FPGA]], or if you are returning an error cluster directly from a non-G DLL.
|-
| '''Error Propagation''' is the act of moving an error value through your LabVIEW code. When an error has been created it should be propagated or responded to (next section). Feature requests in this area include ways of aggregating multiple errors together, extending case structure behaviors, stopping loops/systems when errors occur, merging errors from parallel code, hiding error wires and creating some sort of automatic error propagation rules, etc.
|| Propagation is accomplished using the error cluster and wiring from error inputs through the various code paths and out an error output. When propagating an error to a subVI, it is considered good practice to place error cluster input and output in the lower quadrants (error in on the left, and error out on the right). Multiple code/error paths can exist depending on data flow and parallelization.

'''The number one rule of error propagation is ''Don't Break the Error Chain!''''' An error chain is the code path of the error from the point of generation through the VI hierarchy to the point of being handled by an Error Response, Error Display, and/or Error Logging. A break in the error chain occurs if even one VI in the hierarchy fails to propagate the error correctly. This causes an error from an upstream node to be lost and makes [[Debugging|debugging]] difficult.

An error chain can be broken in three ways:

# Neglecting to wire an output that is part of the error chain
# Zero-iteration [[For Loop|For Loops]]
# Sloppy Merge Errors ordering

To attempt to avoid breaking the error chain, the following [[VI Analyzer]] test can be run:

* '''Error Cluster Wired''' - Detects subVIs and functions with unwired error outputs
* '''Unused Code''' - Detects unwired output tunnels of structures
* '''For Loop Error Handling''' - Detects loop-related error propagation and Merge Errors ordering issues on loop error output tunnels (VI Analyzer Toolkit 2018 or later)
|-
| '''Error Response''' is what you do in your LabVIEW code when an error occurs and you analyze the error value within the code to respond in a certain way. Feature requests include ways to simplify coding the following behaviors:
* Ignoring certain errors
* Retrying the operation
* Translating or Modifying an error
* Failing the operation and closing the program
||
[[File:Screen Shot 2019-06-27 at 1.50.14 AM.png|600px|thumb]]
See Stephen Loftus-Mercer's poster on [https://forums.ni.com/ni/attachments/ni/3044/3784/2/LabVIEW%20Error%20Responses.pdf Error Responses].
The typical operation of a node is to execute only if no error comes in and may add its own outgoing error. Wrapping the entire code of a SubVI within a conditional case structure can make the SubVI act as a typical node (see [[Error Case Structure]]). However, if the code inside of the structure already operates according to a typical node then the case structure is redundant and keeps the compiler from some optimization it could do if the structure was not there.

Also, the developer could choose to enable [[Automatic Error Handling]]. However, automatic error handling assumes all error conditions are tested during development and requires special tooling ([[VI Scripting]]) to enable or disable the entire code base unless every output is wired by the time development is complete. The experts have strong opinions on whether automatic error handling should be used during development, although all agree that it should never occur in well-written released libraries and applications.<ref>Nattinger, Darren. [http://bit.ly/dnatterrors "What to Expect When You're Expecting an Error"] (NIWeek 2018)</ref>
|-
| '''Error Display''' is the act of displaying error information to the end user and/or code developer. Feature requests here include error localization (i.e., generating errors on French system but displaying them on an English system), meaningful translation for error codes, and rendering of the error metadata in a user-friendly form (color, pictures, tables, etc). Display also includes ways of providing advice on common causes of the error and how to fix the error.
|| As of LabVIEW 2019, this is almost always accomplished with ''Simple Error Handler.vi'' or ''General Error Handler.vi''.

The ''General Error Handler.vi'' includes an input parameter for the type of dialog, one option is "no dialog." It is recommended to use it instead of calling ''Error Code Database.vi''. The primary reason for the recommendation is that the translation of error code cluster into human readable strings involves much more than just looking up text in the database. The '''source''' string itself may include information to override or extend the database, and the text in either the '''source''' string or the database may include formatting commands, such as HTML tags for bold face. Encoding information in the '''source''' string is a technique that will become more common in the future.

You may desire to display the text, fully formatted, in a string indicator of your own instead of in any dialog. Use the function of ''General Error Handler CORE.vi'' (found on the block diagram of ''General Error Handler.vi'') to do this.
|-
| '''Error Logging''' involves taking errors generated by LabVIEW code and logging them to file for later analysis. Error logging is similar to error display (above), but logging has some more interesting variations – recording in a human-readable form or is machine parseable, recording as localized or non-localized. Most importantly, whereas “no error” is not typically displayed to the user, it is critical that we be able to log “no error” so a log file can distinguish a successful run (“no error”) from an aborted/crashed run (one where the log file is empty). Feature requests in this area include mechanisms for making recorded errors readable and assistance debugging errors after the application finishes.
|| LabVIEW has no formal error log API because typically logging of errors needs to be folded into the general event logs of an API, which vary radically between applications. The error cluster can be translated into a loggable string by using the ''General Error Handler.vi'', wiring "no dialog" to its input, and writing its string outputs to a log.

For more insight on why it is important to log "no error", please contemplate [http://thecodelesscode.com/case/48 the 48th koan of Codeless Code]: ''"The Protocols tell us of no fewer than Four Silences: the Silence Before Words, the Silence Between Words, the Silence of the Broken Pipe, and the Silence of Fallen Parcels. To the initiate they are as different as the characters for “end” 末 and “not yet” 未, although the outsider cannot tell one from the other."''
|}

== External Links ==
*[http://www.ni.com/getting-started/labview-basics/handling-errors Error Handling Basics by NI].
*[http://controlsoftwaresolutions.com/error-handling-strategies-labview/ David Maidman’s Blog Post].
*[https://forums.ni.com/t5/LabVIEW-Development-Best/quot-SOLID-Error-Handling-quot-presentation-at-NIWeek-2017/td-p/3629639 SOLID Error Handling by Dmitry].
*[http://www.ni.com/example/31253/en/ Structured Error Handler Express VI by NI]
*[http://thecodelesscode.com/case/48 The Codeless Code, Koan 48]

== References ==

[[Category:LabVIEW fundamentals]]

Aspects of error handling

2019-07-12T15:45:27Z

Smercer: correct attribution

{{TOCnestright}}
'''Error Handling''' refers to the anticipation, response, and recovery from error conditions. Writing VIs and subVIs that incorporate error handling is considered good form, not only to allow the user indication of abnormal software execution, but also to allow the software to make decisions based on the status of previous operations. Including error handling in your code assists in troubleshooting ([[debugging]]), modularity, and user friendliness.
The five (5) aspects of error handling below were introduced by Stephen Loftus-Mercer in several informal settings; Darren Nattinger was the first to present them formally.<ref>Nattinger, Darren. [http://bit.ly/dnatterrors "What to Expect When You're Expecting an Error"] (NIWeek 2018)</ref>

{| class="wikitable"
|-
! Aspect !! Details
|-
| '''Error Generation''' is the creation of an [[Error cluster|error cluster]] value at the point that something goes wrong in your LabVIEW code. Feature requests in this area cover readability of the error generation code on the diagram, simplicity of selecting the right error, and packaging valuable metadata with the error (such as the call chain, timestamp, or situation details).
|| Errors may be emitted by both VIs and built-in nodes. When writing a VI that will emit a new error, there are two options:
# (Preferred) Create an error value using one of the library tools, i.e. [[Error Ring]] or ''Error Cluster from Error Code.vi''
# Directly bundling '''status''' boolean, '''code''' numeric, and '''source''' string together. Doing this will not automatically include the call chain and is very hard to find in code, as you will be searching all Bundle nodes. It is not recommended unless it is done in [[Real Time]], [[FPGA]], or if you are returning an error cluster directly from a non-G DLL.
|-
| '''Error Propagation''' is the act of moving an error value through your LabVIEW code. When an error has been created it should be propagated or responded to (next section). Feature requests in this area include ways of aggregating multiple errors together, extending case structure behaviors, stopping loops/systems when errors occur, merging errors from parallel code, hiding error wires and creating some sort of automatic error propagation rules, etc.
|| Propagation is accomplished using the error cluster and wiring from error inputs through the various code paths and out an error output. When propagating an error to a subVI, it is considered good practice to place error cluster input and output in the lower quadrants (error in on the left, and error out on the right). Multiple code/error paths can exist depending on data flow and parallelization.

'''The number one rule of error propagation is ''Don't Break the Error Chain!''''' An error chain is the code path of the error from the point of generation through the VI hierarchy to the point of being handled by an Error Response, Error Display, and/or Error Logging. A break in the error chain occurs if even one VI in the hierarchy fails to propagate the error correctly. This causes an error from an upstream node to be lost and makes [[Debugging|debugging]] difficult.

An error chain can be broken in three ways:

# Neglecting to wire an output that is part of the error chain
# Zero-iteration [[For Loop|For Loops]]
# Sloppy Merge Errors ordering

To attempt to avoid breaking the error chain, the following [[VI Analyzer]] test can be run:

* '''Error Cluster Wired''' - Detects subVIs and functions with unwired error outputs
* '''Unused Code''' - Detects unwired output tunnels of structures
* '''For Loop Error Handling''' - Detects loop-related error propagation and Merge Errors ordering issues on loop error output tunnels (VI Analyzer Toolkit 2018 or later)
|-
| '''Error Response''' is what you do in your LabVIEW code when an error occurs and you analyze the error value within the code to respond in a certain way. Feature requests include ways to simplify coding the following behaviors:
* Ignoring certain errors
* Retrying the operation
* Translating or Modifying an error
* Failing the operation and closing the program
||
[[File:Screen Shot 2019-06-27 at 1.50.14 AM.png|600px|thumb]]
See Stephen Loftus-Mercer's poster on [https://forums.ni.com/ni/attachments/ni/3044/3784/2/LabVIEW%20Error%20Responses.pdf Error Responses].
The typical operation of a node is to execute only if no error comes in and may add its own outgoing error. Wrapping the entire code of a SubVI within a conditional case structure can make the SubVI act as a typical node (see [[Error Case Structure]]). However, if the code inside of the structure already operates according to a typical node then the case structure is redundant and keeps the compiler from some optimization it could do if the structure was not there.

Also, the developer could choose to enable [[Automatic Error Handling]]. However, automatic error handling assumes all error conditions are tested during development and requires special tooling ([[VI Scripting]]) to enable or disable the entire code base unless every output is wired by the time development is complete. The experts have strong opinions on whether automatic error handling should be used during development, although all agree that it should never occur in well-written released libraries and applications.<ref>Nattinger, Darren. [http://bit.ly/dnatterrors "What to Expect When You're Expecting an Error"] (NIWeek 2018)</ref>
|-
| '''Error Display''' is the act of displaying error information to the end user and/or code developer. Feature requests here include error localization (i.e., generating errors on French system but displaying them on an English system), meaningful translation for error codes, and rendering of the error metadata in a user-friendly form (color, pictures, tables, etc). Display also includes ways of providing advice on common causes of the error and how to fix the error.
|| As of LabVIEW 2019, this is almost always accomplished with ''Simple Error Handler.vi'' or ''General Error Handler.vi''.

The ''General Error Handler.vi'' includes an input parameter for the type of dialog, one option is "no dialog." It is recommended to use it instead of calling ''Error Code Database.vi''. The primary reason for the recommendation is that the translation of error code cluster into human readable strings involves much more than just looking up text in the database. The '''source''' string itself may include information to override or extend the database, and the text in either the '''source''' string or the database may include formatting commands, such as HTML tags for bold face. Encoding information in the '''source''' string is a technique that will become more common in the future.

You may desire to display the text, fully formatted, in a string indicator of your own instead of in any dialog. Use the function of ''General Error Handler CORE.vi'' (found on the block diagram of ''General Error Handler.vi'') to do this.
|-
| '''Error Logging''' involves taking errors generated by LabVIEW code and logging them to file for later analysis. Error logging is similar to error display (above), but logging has some more interesting variations – recording in a human-readable form or is machine parseable, recording as localized or non-localized. Most importantly, whereas “no error” is not typically displayed to the user, it is critical that we be able to log “no error” so a log file can distinguish a successful run (“no error”) from an aborted/crashed run (one where the log file is empty). Feature requests in this area include mechanisms for making recorded errors readable and assistance debugging errors after the application finishes.
|| LabVIEW has no formal error log API because typically logging of errors needs to be folded into the general event logs of an API, which vary radically between applications. The error cluster can be translated into a loggable string by using the ''General Error Handler.vi'', wiring "no dialog" to its input, and writing its string outputs to a log.

For more insight on why it is important to log "no error", please contemplate [http://thecodelesscode.com/case/48 the 48th koan of Codeless Code]: ''"The Protocols tell us of no fewer than Four Silences: the Silence Before Words, the Silence Between Words, the Silence of the Broken Pipe, and the Silence of Fallen Parcels. To the initiate they are as different as the characters for “end” 末 and “not yet” 未, although the outsider cannot tell one from the other."''
|}

== External Links ==
*[http://www.ni.com/getting-started/labview-basics/handling-errors Error Handling Basics by NI].
*[http://controlsoftwaresolutions.com/error-handling-strategies-labview/ David Maidman’s Blog Post].
*[https://forums.ni.com/t5/LabVIEW-Development-Best/quot-SOLID-Error-Handling-quot-presentation-at-NIWeek-2017/td-p/3629639 SOLID Error Handling by Dmitry].
*[http://www.ni.com/example/31253/en/ Structured Error Handler Express VI by NI]
*[http://thecodelesscode.com/case/48 The Codeless Code, Koan 48]

== References ==

[[Category:LabVIEW fundamentals]]

Aspects of error handling

2019-07-12T15:44:36Z

Smercer: Significant rewrite... changed formatting to make it easier to review the topics. In future, may consider breaking each into separate page.

{{TOCnestright}}
'''Error Handling''' refers to the anticipation, response, and recovery from error conditions. Writing VIs and subVIs that incorporate error handling is considered good form, not only to allow the user indication of abnormal software execution, but also to allow the software to make decisions based on the status of previous operations. Including error handling in your code assists in troubleshooting ([[debugging]]), modularity, and user friendliness.
The five (5) aspects of error handling below were introduced by Stephen Loftus-Mercer in several informal settings; Darren Nattinger was the first to present them formally.<ref>Nattinger, Darren. [http://bit.ly/dnatterrors "What to Expect When You're Expecting an Error"] (NIWeek 2018)</ref>

{| class="wikitable"
|-
! Aspect !! Details
|-
| '''Error Generation''' is the creation of an [[Error cluster|error cluster]] value at the point that something goes wrong in your LabVIEW code. Feature requests in this area cover readability of the error generation code on the diagram, simplicity of selecting the right error, and packaging valuable metadata with the error (such as the call chain, timestamp, or situation details).
|| Errors may be emitted by both VIs and built-in nodes. When writing a VI that will emit a new error, there are two options:
# (Preferred) Create an error value using one of the library tools, i.e. [[Error Ring]] or ''Error Cluster from Error Code.vi''
# Directly bundling '''status''' boolean, '''code''' numeric, and '''source''' string together. Doing this will not automatically include the call chain and is very hard to find in code, as you will be searching all Bundle nodes. It is not recommended unless it is done in [[Real Time]], [[FPGA]], or if you are returning an error cluster directly from a non-G DLL.
|-
| '''Error Propagation''' is the act of moving an error value through your LabVIEW code. When an error has been created it should be propagated or responded to (next section). Feature requests in this area include ways of aggregating multiple errors together, extending case structure behaviors, stopping loops/systems when errors occur, merging errors from parallel code, hiding error wires and creating some sort of automatic error propagation rules, etc.
|| Propagation is accomplished using the error cluster and wiring from error inputs through the various code paths and out an error output. When propagating an error to a subVI, it is considered good practice to place error cluster input and output in the lower quadrants (error in on the left, and error out on the right). Multiple code/error paths can exist depending on data flow and parallelization.

'''The number one rule of error propagation is ''Don't Break the Error Chain!''''' An error chain is the code path of the error from the point of generation through the VI hierarchy to the point of being handled by an Error Response, Error Display, and/or Error Logging. A break in the error chain occurs if even one VI in the hierarchy fails to propagate the error correctly. This causes an error from an upstream node to be lost and makes [[Debugging|debugging]] difficult.

An error chain can be broken in three ways:

# Neglecting to wire an output that is part of the error chain
# Zero-iteration [[For Loop|For Loops]]
# Sloppy Merge Errors ordering

To attempt to avoid breaking the error chain, the following [[VI Analyzer]] test can be run:

* '''Error Cluster Wired''' - Detects subVIs and functions with unwired error outputs
* '''Unused Code''' - Detects unwired output tunnels of structures
* '''For Loop Error Handling''' - Detects loop-related error propagation and Merge Errors ordering issues on loop error output tunnels (VI Analyzer Toolkit 2018 or later)
|-
| '''Error Response''' is what you do in your LabVIEW code when an error occurs and you analyze the error value within the code to respond in a certain way. Feature requests include ways to simplify coding the following behaviors:
* Ignoring certain errors
* Retrying the operation
* Translating or Modifying an error
* Failing the operation and closing the program
||
[[File:Screen Shot 2019-06-27 at 1.50.14 AM.png|600px|thumb]]
See Darren Nattinger's poster on [https://forums.ni.com/ni/attachments/ni/3044/3784/2/LabVIEW%20Error%20Responses.pdf Error Responses].
The typical operation of a node is to execute only if no error comes in and may add its own outgoing error. Wrapping the entire code of a SubVI within a conditional case structure can make the SubVI act as a typical node (see [[Error Case Structure]]). However, if the code inside of the structure already operates according to a typical node then the case structure is redundant and keeps the compiler from some optimization it could do if the structure was not there.

Also, the developer could choose to enable [[Automatic Error Handling]]. However, automatic error handling assumes all error conditions are tested during development and requires special tooling ([[VI Scripting]]) to enable or disable the entire code base unless every output is wired by the time development is complete. The experts have strong opinions on whether automatic error handling should be used during development, although all agree that it should never occur in well-written released libraries and applications.<ref>Nattinger, Darren. [http://bit.ly/dnatterrors "What to Expect When You're Expecting an Error"] (NIWeek 2018)</ref>
|-
| '''Error Display''' is the act of displaying error information to the end user and/or code developer. Feature requests here include error localization (i.e., generating errors on French system but displaying them on an English system), meaningful translation for error codes, and rendering of the error metadata in a user-friendly form (color, pictures, tables, etc). Display also includes ways of providing advice on common causes of the error and how to fix the error.
|| As of LabVIEW 2019, this is almost always accomplished with ''Simple Error Handler.vi'' or ''General Error Handler.vi''.

The ''General Error Handler.vi'' includes an input parameter for the type of dialog, one option is "no dialog." It is recommended to use it instead of calling ''Error Code Database.vi''. The primary reason for the recommendation is that the translation of error code cluster into human readable strings involves much more than just looking up text in the database. The '''source''' string itself may include information to override or extend the database, and the text in either the '''source''' string or the database may include formatting commands, such as HTML tags for bold face. Encoding information in the '''source''' string is a technique that will become more common in the future.

You may desire to display the text, fully formatted, in a string indicator of your own instead of in any dialog. Use the function of ''General Error Handler CORE.vi'' (found on the block diagram of ''General Error Handler.vi'') to do this.
|-
| '''Error Logging''' involves taking errors generated by LabVIEW code and logging them to file for later analysis. Error logging is similar to error display (above), but logging has some more interesting variations – recording in a human-readable form or is machine parseable, recording as localized or non-localized. Most importantly, whereas “no error” is not typically displayed to the user, it is critical that we be able to log “no error” so a log file can distinguish a successful run (“no error”) from an aborted/crashed run (one where the log file is empty). Feature requests in this area include mechanisms for making recorded errors readable and assistance debugging errors after the application finishes.
|| LabVIEW has no formal error log API because typically logging of errors needs to be folded into the general event logs of an API, which vary radically between applications. The error cluster can be translated into a loggable string by using the ''General Error Handler.vi'', wiring "no dialog" to its input, and writing its string outputs to a log.

For more insight on why it is important to log "no error", please contemplate [http://thecodelesscode.com/case/48 the 48th koan of Codeless Code]: ''"The Protocols tell us of no fewer than Four Silences: the Silence Before Words, the Silence Between Words, the Silence of the Broken Pipe, and the Silence of Fallen Parcels. To the initiate they are as different as the characters for “end” 末 and “not yet” 未, although the outsider cannot tell one from the other."''
|}

== External Links ==
*[http://www.ni.com/getting-started/labview-basics/handling-errors Error Handling Basics by NI].
*[http://controlsoftwaresolutions.com/error-handling-strategies-labview/ David Maidman’s Blog Post].
*[https://forums.ni.com/t5/LabVIEW-Development-Best/quot-SOLID-Error-Handling-quot-presentation-at-NIWeek-2017/td-p/3629639 SOLID Error Handling by Dmitry].
*[http://www.ni.com/example/31253/en/ Structured Error Handler Express VI by NI]
*[http://thecodelesscode.com/case/48 The Codeless Code, Koan 48]

== References ==

[[Category:LabVIEW fundamentals]]

Software Engineering with LabVIEW

2009-04-21T14:22:42Z

Smercer:

This page describes software engineering practices and tools.

The intent of the this page is to share best practices. This will include discussion of tool selection, where appropriate, and information regarding setting up and using tools.

Following are some key tasks that are part of a software engineering process:
*[[Requirements Management]]
*[[Planning Development]]
*[[Software Design]]
*[[Source Code Control]]
*[[Unit and Regression Testing]]
*[[Issue Tracking]]

== External links ==

*[http://ni.com/largeapps ni.com/largeapps] -- information collected and reviewed by NI employees
*[http://ni.com/community/largeapps ni.com/community/largeapps] -- information contributed by LabVIEW users worldwide (WIKI editiable) 

[[Category:SW_Engineering]]

Software Engineering with LabVIEW

2009-04-20T12:20:12Z

Smercer: Add links to the NI repositories

This page describes software engineering practices and tools.

The intent of the this page is to share best practices. This will include discussion of tool selection, where appropriate, and information regarding setting up and using tools.

National Instruments maintains two massive repositories of information regarding software engineering with LabVIEW:

*[http://ni.com/largeapps ni.com/largeapps] -- information collected and reviewed by NI employees
*[http://ni.com/community/largeapps ni.com/community/largeapps] -- a WIKI of information contributed by LabVIEW users worldwide 

Following are some key tasks that are part of a software engineering process: [[Requirements Management]] [[Planning Development]] [[Software Design]] [[Source Code Control]] [[Unit and Regression Testing]] [[Issue Tracking]] 

[[Category:SW_Engineering]]

Insane Objects

2007-11-12T14:16:14Z

Smercer: Change text about editing capacities of heap peek

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:''' Heap peek does not have 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, there are no edits to VIs possible using this tool as of November 2007. A previous author said that few developers really know the capacities of heap peek. This is true... it's a debugging tool, and it gets hacked up to debug whatever anyone needs to debug.

[[category:LabVIEW internals]]
[[category:development environment]]

Numeric

2007-10-24T15:17:37Z

Smercer: /* NaN equivalent for integer data types */

== [[NaN]] equivalent for [[integer]] data types ==
NaN is defined only for floating point numbers. In a [[U32]] all the possible values are actual numbers and there is no place left for a special value that says there is nothing there. If you need an "empty" value in an integer data type you have to pick a value that never appears in your particular application (if there really is one) to serve as a flag. In other words there is no "empty value" in integer data types.

'''A useful trick:''' In most cases, zero or -1 are used as the magic sentinel value for integer work. But sometimes you'd like to use "largest possible integer" as your sentinel value because zero and -1 are actual values, and you don't expect to ever actually use the large end of the spectrum. But nobody actually remembers the largest possible integer, and even if you look it up (it is in the Context Help for an integer wire, by the way), typing it is annoying. Solution: Drop a Numeric constant on the block diagram and set it to be your type of integer. Then type a long string of 9s into it, such as "99999999999999999999999999999999999999999". LabVIEW will automatically change this to be the largest possible integer storable in your data type. If it doesn't convert and you still have the long string of 9s, then you didn't type enough 9s. This can happen if you're using unsigned 64-bit integers... those things are HUGE!

Test a floating point wire for NaN by using [[Image:Nanfunc.png]] from the Comparison pallete.

== Comparing real numbers ==
What you need is a comparison that assumes that equal is the same as close enough. One way is to define an epsilon and check to make sure that your error is greater than that epsilon where epsilon is dependent on the type of number (single, double, extended) that you are using. For example to compare A greater than or equal to B (as double precision) you could use as your test.

A-B >= -1e-17*(A+B)/2

Or maybe 1e-16 to be safe. To be really careful use 2^-31 as your criterion. This handles the case where A is already 10^-31 in magnitude or when both variables are zero.

A simpler method is to multiply your numbers by 10 to make integers, round them and then compare. In fact you can multiply by whatever power of 10 desired.

This is *not* a bug. It appears as a result of the limitation of finite computers. There is not now and never will be a fix. The main fix is to the programmer. As a caveat, do not ever, ever, ever compare real numbers. They are uncertain within the least significant bit.

These uncertainties arise in several situations. Another example where this must be taken into account is the output of both"Format & Strip" and "From Exponential/Fract/Eng"; enter a string of "0.1" and you get the number: 0.10000000000000000100. You cannot represent 0.1 as a finite binary string.

As to a wish for a finite conversion width, nope. The problem is that the conversion does have a finite width. It is that factor of 5 in base 10 numbers that makes a finite decimal be an infinite repeating binary string. You can represent all numbers that can be formed as sums of 1/2, 1/4, 1/8, 1/16, 1/32. Unfortunately 1/10 can only be approximated. The wish seems to indicate that the binary is converted to base 10 (with a finite conversion width) and then compared. Actually it is all compared in binary, when you display it, you can convert it to 10 digits or what ever you want.

In summary, any binary representation will be approximate. How approximate is based on the word length. It is that factor of 5 in base 10 numbers that gets us. It appears that you have 17 digits of accuracy which is about right for a double precision number. Extended have more, singles have less. That is mathematical reality. Computers are not idealized mathematical machines. If it was easy everyone would be an expert. Knowing how things are treated by the underlying hardware can keep one from having these problems.

[[Category:numeric]]

Numeric

2007-10-24T15:08:58Z

Smercer: /* NaN equivalent for integer data types */

== [[NaN]] equivalent for [[integer]] data types ==
NaN is defined only for floating point numbers. In a [[U32]] all the possible values are actual numbers and there is no place left for a special value that says there is nothing there. If you need an "empty" value in an integer data type you have to pick a value that never appears in your particular application (if there really is one) to serve as a flag. In other words there is no "empty value" in integer data types.

'''A useful trick:''' In most cases, zero or -1 are used as the magic sentinel value for integer work. But sometimes you'd like to use "largest possible integer" as your sentinel value because zero and -1 are actual values, and you don't expect to ever actually use the large end of the spectrum. But nobody actually remembers the largest possible integer, and even if you look it up (it is in the Context Help for an integer wire, by the way), typing it is annoying. Solution: Drop a Numeric constant on the block diagram and set it to be your type of integer. Then type a long string of 9s into it, such as "99999999999999999999999999999999999999999". LabVIEW will automatically change this to be the largest possible integer storable in your data type.

Test a floating point wire for NaN by using [[Image:Nanfunc.png]] from the Comparison pallete.

== Comparing real numbers ==
What you need is a comparison that assumes that equal is the same as close enough. One way is to define an epsilon and check to make sure that your error is greater than that epsilon where epsilon is dependent on the type of number (single, double, extended) that you are using. For example to compare A greater than or equal to B (as double precision) you could use as your test.

A-B >= -1e-17*(A+B)/2

Or maybe 1e-16 to be safe. To be really careful use 2^-31 as your criterion. This handles the case where A is already 10^-31 in magnitude or when both variables are zero.

A simpler method is to multiply your numbers by 10 to make integers, round them and then compare. In fact you can multiply by whatever power of 10 desired.

This is *not* a bug. It appears as a result of the limitation of finite computers. There is not now and never will be a fix. The main fix is to the programmer. As a caveat, do not ever, ever, ever compare real numbers. They are uncertain within the least significant bit.

These uncertainties arise in several situations. Another example where this must be taken into account is the output of both"Format & Strip" and "From Exponential/Fract/Eng"; enter a string of "0.1" and you get the number: 0.10000000000000000100. You cannot represent 0.1 as a finite binary string.

As to a wish for a finite conversion width, nope. The problem is that the conversion does have a finite width. It is that factor of 5 in base 10 numbers that makes a finite decimal be an infinite repeating binary string. You can represent all numbers that can be formed as sums of 1/2, 1/4, 1/8, 1/16, 1/32. Unfortunately 1/10 can only be approximated. The wish seems to indicate that the binary is converted to base 10 (with a finite conversion width) and then compared. Actually it is all compared in binary, when you display it, you can convert it to 10 digits or what ever you want.

In summary, any binary representation will be approximate. How approximate is based on the word length. It is that factor of 5 in base 10 numbers that gets us. It appears that you have 17 digits of accuracy which is about right for a double precision number. Extended have more, singles have less. That is mathematical reality. Computers are not idealized mathematical machines. If it was easy everyone would be an expert. Knowing how things are treated by the underlying hardware can keep one from having these problems.

[[Category:numeric]]

Numeric

2007-10-24T15:08:07Z

Smercer: /* NaN equivalent for integer data types */

== [[NaN]] equivalent for [[integer]] data types ==
NaN is defined only for floating point numbers. In a [[U32]] all the possible values are actual numbers and there is no place left for a special value that says there is nothing there. If you need an "empty" value in an integer data type you have to pick a value that never appears in your particular application (if there really is one) to serve as a flag. In other words there is no "empty value" in integer data types.

'''A useful trick:''' In most cases, zero or -1 are used as the magic sentinel value for integer work. But sometimes you'd like to use "largest possible integer" as your sentinel value because zero and -1 are actual values, and you don't expect to ever actually use the large end of the spectrum. But nobody actually remembers the largest possible integer, and even if you look it up, typing it is annoying. Solution: Drop a Numeric constant on the block diagram and set it to be your type of integer. Then type a long string of 9s into it, such as "99999999999999999999999999999999999999999". LabVIEW will automatically change this to be the largest possible integer storable in your data type.

Test a floating point wire for NaN by using [[Image:Nanfunc.png]] from the Comparison pallete.

== Comparing real numbers ==
What you need is a comparison that assumes that equal is the same as close enough. One way is to define an epsilon and check to make sure that your error is greater than that epsilon where epsilon is dependent on the type of number (single, double, extended) that you are using. For example to compare A greater than or equal to B (as double precision) you could use as your test.

A-B >= -1e-17*(A+B)/2

Or maybe 1e-16 to be safe. To be really careful use 2^-31 as your criterion. This handles the case where A is already 10^-31 in magnitude or when both variables are zero.

A simpler method is to multiply your numbers by 10 to make integers, round them and then compare. In fact you can multiply by whatever power of 10 desired.

This is *not* a bug. It appears as a result of the limitation of finite computers. There is not now and never will be a fix. The main fix is to the programmer. As a caveat, do not ever, ever, ever compare real numbers. They are uncertain within the least significant bit.

These uncertainties arise in several situations. Another example where this must be taken into account is the output of both"Format & Strip" and "From Exponential/Fract/Eng"; enter a string of "0.1" and you get the number: 0.10000000000000000100. You cannot represent 0.1 as a finite binary string.

As to a wish for a finite conversion width, nope. The problem is that the conversion does have a finite width. It is that factor of 5 in base 10 numbers that makes a finite decimal be an infinite repeating binary string. You can represent all numbers that can be formed as sums of 1/2, 1/4, 1/8, 1/16, 1/32. Unfortunately 1/10 can only be approximated. The wish seems to indicate that the binary is converted to base 10 (with a finite conversion width) and then compared. Actually it is all compared in binary, when you display it, you can convert it to 10 digits or what ever you want.

In summary, any binary representation will be approximate. How approximate is based on the word length. It is that factor of 5 in base 10 numbers that gets us. It appears that you have 17 digits of accuracy which is about right for a double precision number. Extended have more, singles have less. That is mathematical reality. Computers are not idealized mathematical machines. If it was easy everyone would be an expert. Knowing how things are treated by the underlying hardware can keep one from having these problems.

[[Category:numeric]]

Keyboard shortcut

2007-10-23T15:52:12Z

Smercer: /* Object Movement */

This is a complete list of LabVIEW development environment keyboard shortcut keys.
[[Image:Keyboardkeys.png‎|frame]]
==Object Movement==
{| class="wikitable sortable"
|-
! Keyboard Shortcut
! Description
|-
| Shift-click
| Selects multiple objects; adds object to current selection.
|-
| Ctrl-click
| Toggles a single object to join or leave the current selection.
|-
| Arrow keys
| Moves selected objects one pixel at a time.
|-
| Shift-Arrow keys
| Moves selected objects several pixels at a time. If the Alignment Grid is enabled, the object will move to align with the grid and thereafter will move in grid increments.
|-
| Shift-click (drag)
| Moves selected objects in one axis.
|-
| Ctrl-click (drag)
| Duplicates selected object
|-
| Ctrl-Shift-click (drag)
| Duplicates selected object and moves it in one axis.
|-
| Shift-resize
| Resizes selected object while maintaining aspect ratio.
|-
| Ctrl-resize
| Resizes selected object while maintaining center point.
|-
| Ctrl-Shift-resize
| Resizes selected object while maintaining center point and aspect ratio.
|-
| Ctrl-drag a rectangle
| Adds more working space to the front panel or block diagram.
|-
| Ctrl-A
| Selects all front panel or block diagram items.
|-
| Ctrl-Shift-A
| Performs last alignment operation on objects.
|-
| Ctrl-D
| Performs last distribution operation on objects.
|-
| Double-click open space
| Adds a free label to the front panel or block diagram if automatic tool selection is enabled.
|-
| Ctrl-mouse wheel
| Scrolls through subdiagrams of a Case, Event, or Stacked Sequence structure.
|-
| g or G (no modifier keys)
| While dragging an object with the mouse, this momentarily toggles on or off the alignment grid
|-
| a or A (no modifier keys)
| While dragging an object on the block diagram, this momentarily toggles on or off the automatic wiring
|-
| Spacebar (drag)
| Disables preset alignment positions when moving object labels or captions.
|}

==Navigating the LabVIEW Environment==
{| class="wikitable sortable"
|-
! Keyboard Shortcut
! Description
|-
| Ctrl-F
| Finds objects or text.
|-
| Ctrl-Shift-F
| Displays Search Results window or the Find Project Items dialog box with the previous search results.
|-
| Ctrl-G
| Searches for next instance of object or text.
|-
| Ctrl-Shift-G
| Searches for previous instance of VIs, object, or text.
|-
| Ctrl-Tab
| Cycles through LabVIEW windows in the order the windows appear onscreen. The order of the windows depends on the window manager you use.
|-
| Ctrl-Shift-Tab
| Cycles the opposite direction through LabVIEW windows.
|-
| Ctrl-L
| Displays the Error List window.
|-
| Ctrl-Shift-W
| Displays the All Windows dialog box.
|-
| Ctrl-Shift-B
| Displays the Class Browser window.
|}

==Navigating Front Panels and Block Diagrams==
{| class="wikitable sortable"
|-
! Keyboard Shortcut
! Description
|-
| Ctrl-E
| Displays block diagram or front panel window.
|-
| Ctrl-#
| Enables or disables grid alignment. On French keyboards, press the <Ctrl-"> keys. (Mac OS) Press the <Command-*> keys.
|-
| Ctrl-/
| Maximizes and restores window.
|-
| Ctrl-T
| Tiles front panel and block diagram windows.
|-
| Ctrl-Shift-N
| Displays the Navigation window.
|-
| Ctrl-I
| Displays the VI Properties dialog box.
|-
| Ctrl-Y
| Displays the History window.
|}

==Navigating the VI Hierarchy Window==
{| class="wikitable sortable"
|-
! Keyboard Shortcut
! Description
|-
| Ctrl-D
| Redraws the VI Hierarchy window.
|-
| Ctrl-A
| Shows all VIs in the VI Hierarchy window.
|-
| Ctrl-click VI
| Displays the subVIs and other nodes that make up the VI you select in the VI Hierarchy window.
|-
| Enter
| Finds the next node that matches the search string after initiating a search by typing in the VI Hierarchy window.
|-
| Shift-Enter
| Finds the previous node that matches the search string after initiating a search by typing in the VI Hierarchy window.
|}

==Debugging==
{| class="wikitable sortable"
|-
! Keyboard Shortcut
! Description
|-
| Ctrl-Down arrow
| Steps into node.
|-
| Ctrl-Right arrow
| Steps over node.
|-
| Ctrl-Up arrow
| Steps out of node.
|}

==File Operations==
{| class="wikitable sortable"
|-
! Keyboard Shortcut
! Description
|-
| Ctrl-N
| Opens a new, blank VI.
|-
| Ctrl-O
| Opens an existing VI.
|-
| Ctrl-W
| Closes the VI.
|-
| Ctrl-S
| Saves the VI.
|-
| Ctrl-Shift-S
| Saves all open files.
|-
| Ctrl-P
| Prints the window.
|-
| Ctrl-Q
| Quits LabVIEW.
|}

==Basic Editing==
{| class="wikitable sortable"
|-
! Keyboard Shortcut
! Description
|-
| Ctrl-Z
| Undoes last action.
|-
| Ctrl-Shift-Z
| Redoes last action.
|-
| Ctrl-X
| Cuts an object.
|-
| Ctrl-C
| Copies an object.
|-
| Ctrl-V
| Pastes an object.
|}

==Help==
{| class="wikitable sortable"
|-
! Keyboard Shortcut
! Description
|-
| Ctrl-H
| Displays Context Help window.
|-
| Ctrl-Shift-L
| Locks Context Help window.
|-
| Ctrl-? or <F1>
| Displays LabVIEW Help.
|}

==Tools and Palettes==
{| class="wikitable sortable"
|-
! Keyboard Shortcut
! Description
|-
| Ctrl
| Switches to next most useful tool.
|-
| Shift
| Switches to Positioning tool.
|-
| Ctrl-Shift over open space
| Switches to Scrolling tool.
|-
| Spacebar
| Toggles between two most common tools if automatic tool selection is disabled.
|-
| Shift-Tab
| Enables automatic tool selection.
|-
| Tab
| Cycles through four most common tools if you disabled automatic tool selection by clicking the [[automatic tool selection]] button. Otherwise, enables automatic tool selection.
|-
| Arrow keys
| Navigates temporary [[Control|Controls]] and Functions palettes.
|-
| Enter
| Navigates into a temporary [[palette]].
|-
| Esc
| Navigates out of a temporary palette.
|-
| Shift-right-click
| Displays a temporary version of the Tools palette at the location of the cursor.
|}

==SubVIs==
{| class="wikitable sortable"
|-
! Keyboard Shortcut
! Description
|-
| Double-click subVI
| Displays subVI front panel.
|-
| Ctrl-double-click subVI
| Displays subVI block diagram and front panel.
|-
| Drag VI icon to block diagram
| Places that VI as a subVI on the block diagram.
|-
| Shift-drag VI icon to block diagram
| Places that VI as a subVI on the block diagram with constants wired for controls that have non-default values.
|-
| Ctrl-right-click block diagram and select VI from palette
| Opens front panel of that VI.
|}

==Execution==
{| class="wikitable sortable"
|-
! Keyboard Shortcut
! Description
|-
| Ctrl-R
| Runs the VI.
|-
| Ctrl-.
| Stops the VI, when used while VI is running.
|-
| Ctrl-M
| Changes to run or edit mode.
|-
| Ctrl-Run button
| Recompiles the current VI.
|-
| Ctrl-Shift-Run button
| Recompiles all VIs in memory.
|-
| Ctrl-Down arrow
| Moves key focus inside an array or cluster, when used while VI is running.
|-
| Ctrl-Up arrow
| Moves key focus outside an array or cluster, when used while VI is running.
|-
| Tab
| Navigates the controls or indicators according to tabbing order, when used while VI is running.
|-
| Shift-Tab
| Navigates backward through the controls or indicators, when used while VI is running.
|}

==Wiring==
{| class="wikitable sortable"
|-
! Keyboard Shortcut
! Description
|-
| Ctrl-B
| Deletes all broken wires in a VI.
|-
| Esc, right-click, or click terminal
| Cancels a wire you started.
|-
| Single-click wire
| Selects one segment.
|-
| Double-click wire
| Selects a branch.
|-
| Triple-click wire
| Selects entire wire.
|-
| A
| While wiring, disables automatic wire routing temporarily.
|-
| Double-click (while wiring)
| Tacks down wire without connecting it.
|-
| Spacebar
| Toggles automatic wiring while moving objects.
|-
| Shift-click
| Undoes last point where you set a wire.
|-
| Ctrl-click input on function with two inputs
| Switches the two input wires.
|-
| Spacebar
| Switches the direction of a wire between horizontal and vertical.
|}

==Text==
{| class="wikitable sortable"
|-
! Keyboard Shortcut
! Description
|-
| Double-click
| Selects a single word in a string.
|-
| Triple-click
| Selects an entire string.
|-
| Ctrl-Right arrow
| Moves forward in string by one word when using text that has characters that use single bytes, such as Western character sets. Moves forward in string by one character when using text that has characters that use multiple bytes, such as Asian character sets.
|-
| Ctrl-Left arrow
| Moves backward in string by one word when using text that has characters that use single bytes, such as Western character sets. Moves backward in string by one character when using text that has characters that use multiple bytes, such as Asian character sets.
|-
| Home
| Moves to beginning of current line in string.
|-
| End
| Moves to end of current line in string.
|-
| Ctrl-Home
| Moves to beginning of entire string.
|-
| Ctrl-End
| Moves to end of entire string.
|-
| Shift-Enter
| Adds new items when entering items in enumerated type controls and constants, ring controls and constants, or Case structures. In string constants, press the <Shift-Enter> keys on the keyboard to disable autosizing if it is enabled. If autosizing is disabled, press the <Shift-Enter> keys on the keyboard to display a scroll bar in the constant.
|-
| Esc
| Cancels current edit in a string.
|-
| Ctrl-Enter
| Ends text entry.
|-
| Ctrl-=
| Increases the current font size.
|-
| Ctrl--
| Decreases the current font size.
|-
| Ctrl-0
| Displays the Font dialog box.
|-
| Ctrl-1
| Changes to the Application font in Font dialog box.
|-
| Ctrl-2
| Changes to the System font in the Font dialog box.
|-
| Ctrl-3
| Changes to the Dialog font in the Font dialog box.
|-
| Ctrl-4
| Changes to the current font in the Font dialog box.
|}

=See also=
*[[Tips and tricks]] - LabVIEW tips and tricks.

[[category:lists|Keyboard shortcuts for LabVIEW]]

Keyboard shortcut

2007-10-23T15:49:31Z

Smercer: /* Object Movement */

This is a complete list of LabVIEW development environment keyboard shortcut keys.
[[Image:Keyboardkeys.png‎|frame]]
==Object Movement==
{| class="wikitable sortable"
|-
! Keyboard Shortcut
! Description
|-
| Shift-click
| Selects multiple objects; adds object to current selection.
|-
| Arrow keys
| Moves selected objects one pixel at a time.
|-
| Shift-Arrow keys
| Moves selected objects several pixels at a time.
|-
| Shift-click (drag)
| Moves selected objects in one axis.
|-
| Ctrl-click (drag)
| Duplicates selected object
|-
| Ctrl-Shift-click (drag)
| Duplicates selected object and moves it in one axis.
|-
| Shift-resize
| Resizes selected object while maintaining aspect ratio.
|-
| Ctrl-resize
| Resizes selected object while maintaining center point.
|-
| Ctrl-Shift-resize
| Resizes selected object while maintaining center point and aspect ratio.
|-
| Ctrl-drag a rectangle
| Adds more working space to the front panel or block diagram.
|-
| Ctrl-A
| Selects all front panel or block diagram items.
|-
| Ctrl-Shift-A
| Performs last alignment operation on objects.
|-
| Ctrl-D
| Performs last distribution operation on objects.
|-
| Double-click open space
| Adds a free label to the front panel or block diagram if automatic tool selection is enabled.
|-
| Ctrl-mouse wheel
| Scrolls through subdiagrams of a Case, Event, or Stacked Sequence structure.
|-
| g or G (no modifier keys)
| While dragging an object with the mouse, this momentarily toggles on or off the alignment grid
|-
| Spacebar (drag)
| Disables preset alignment positions when moving object labels or captions.
|}

==Navigating the LabVIEW Environment==
{| class="wikitable sortable"
|-
! Keyboard Shortcut
! Description
|-
| Ctrl-F
| Finds objects or text.
|-
| Ctrl-Shift-F
| Displays Search Results window or the Find Project Items dialog box with the previous search results.
|-
| Ctrl-G
| Searches for next instance of object or text.
|-
| Ctrl-Shift-G
| Searches for previous instance of VIs, object, or text.
|-
| Ctrl-Tab
| Cycles through LabVIEW windows in the order the windows appear onscreen. The order of the windows depends on the window manager you use.
|-
| Ctrl-Shift-Tab
| Cycles the opposite direction through LabVIEW windows.
|-
| Ctrl-L
| Displays the Error List window.
|-
| Ctrl-Shift-W
| Displays the All Windows dialog box.
|-
| Ctrl-Shift-B
| Displays the Class Browser window.
|}

==Navigating Front Panels and Block Diagrams==
{| class="wikitable sortable"
|-
! Keyboard Shortcut
! Description
|-
| Ctrl-E
| Displays block diagram or front panel window.
|-
| Ctrl-#
| Enables or disables grid alignment. On French keyboards, press the <Ctrl-"> keys. (Mac OS) Press the <Command-*> keys.
|-
| Ctrl-/
| Maximizes and restores window.
|-
| Ctrl-T
| Tiles front panel and block diagram windows.
|-
| Ctrl-Shift-N
| Displays the Navigation window.
|-
| Ctrl-I
| Displays the VI Properties dialog box.
|-
| Ctrl-Y
| Displays the History window.
|}

==Navigating the VI Hierarchy Window==
{| class="wikitable sortable"
|-
! Keyboard Shortcut
! Description
|-
| Ctrl-D
| Redraws the VI Hierarchy window.
|-
| Ctrl-A
| Shows all VIs in the VI Hierarchy window.
|-
| Ctrl-click VI
| Displays the subVIs and other nodes that make up the VI you select in the VI Hierarchy window.
|-
| Enter
| Finds the next node that matches the search string after initiating a search by typing in the VI Hierarchy window.
|-
| Shift-Enter
| Finds the previous node that matches the search string after initiating a search by typing in the VI Hierarchy window.
|}

==Debugging==
{| class="wikitable sortable"
|-
! Keyboard Shortcut
! Description
|-
| Ctrl-Down arrow
| Steps into node.
|-
| Ctrl-Right arrow
| Steps over node.
|-
| Ctrl-Up arrow
| Steps out of node.
|}

==File Operations==
{| class="wikitable sortable"
|-
! Keyboard Shortcut
! Description
|-
| Ctrl-N
| Opens a new, blank VI.
|-
| Ctrl-O
| Opens an existing VI.
|-
| Ctrl-W
| Closes the VI.
|-
| Ctrl-S
| Saves the VI.
|-
| Ctrl-Shift-S
| Saves all open files.
|-
| Ctrl-P
| Prints the window.
|-
| Ctrl-Q
| Quits LabVIEW.
|}

==Basic Editing==
{| class="wikitable sortable"
|-
! Keyboard Shortcut
! Description
|-
| Ctrl-Z
| Undoes last action.
|-
| Ctrl-Shift-Z
| Redoes last action.
|-
| Ctrl-X
| Cuts an object.
|-
| Ctrl-C
| Copies an object.
|-
| Ctrl-V
| Pastes an object.
|}

==Help==
{| class="wikitable sortable"
|-
! Keyboard Shortcut
! Description
|-
| Ctrl-H
| Displays Context Help window.
|-
| Ctrl-Shift-L
| Locks Context Help window.
|-
| Ctrl-? or <F1>
| Displays LabVIEW Help.
|}

==Tools and Palettes==
{| class="wikitable sortable"
|-
! Keyboard Shortcut
! Description
|-
| Ctrl
| Switches to next most useful tool.
|-
| Shift
| Switches to Positioning tool.
|-
| Ctrl-Shift over open space
| Switches to Scrolling tool.
|-
| Spacebar
| Toggles between two most common tools if automatic tool selection is disabled.
|-
| Shift-Tab
| Enables automatic tool selection.
|-
| Tab
| Cycles through four most common tools if you disabled automatic tool selection by clicking the [[automatic tool selection]] button. Otherwise, enables automatic tool selection.
|-
| Arrow keys
| Navigates temporary [[Control|Controls]] and Functions palettes.
|-
| Enter
| Navigates into a temporary [[palette]].
|-
| Esc
| Navigates out of a temporary palette.
|-
| Shift-right-click
| Displays a temporary version of the Tools palette at the location of the cursor.
|}

==SubVIs==
{| class="wikitable sortable"
|-
! Keyboard Shortcut
! Description
|-
| Double-click subVI
| Displays subVI front panel.
|-
| Ctrl-double-click subVI
| Displays subVI block diagram and front panel.
|-
| Drag VI icon to block diagram
| Places that VI as a subVI on the block diagram.
|-
| Shift-drag VI icon to block diagram
| Places that VI as a subVI on the block diagram with constants wired for controls that have non-default values.
|-
| Ctrl-right-click block diagram and select VI from palette
| Opens front panel of that VI.
|}

==Execution==
{| class="wikitable sortable"
|-
! Keyboard Shortcut
! Description
|-
| Ctrl-R
| Runs the VI.
|-
| Ctrl-.
| Stops the VI, when used while VI is running.
|-
| Ctrl-M
| Changes to run or edit mode.
|-
| Ctrl-Run button
| Recompiles the current VI.
|-
| Ctrl-Shift-Run button
| Recompiles all VIs in memory.
|-
| Ctrl-Down arrow
| Moves key focus inside an array or cluster, when used while VI is running.
|-
| Ctrl-Up arrow
| Moves key focus outside an array or cluster, when used while VI is running.
|-
| Tab
| Navigates the controls or indicators according to tabbing order, when used while VI is running.
|-
| Shift-Tab
| Navigates backward through the controls or indicators, when used while VI is running.
|}

==Wiring==
{| class="wikitable sortable"
|-
! Keyboard Shortcut
! Description
|-
| Ctrl-B
| Deletes all broken wires in a VI.
|-
| Esc, right-click, or click terminal
| Cancels a wire you started.
|-
| Single-click wire
| Selects one segment.
|-
| Double-click wire
| Selects a branch.
|-
| Triple-click wire
| Selects entire wire.
|-
| A
| While wiring, disables automatic wire routing temporarily.
|-
| Double-click (while wiring)
| Tacks down wire without connecting it.
|-
| Spacebar
| Toggles automatic wiring while moving objects.
|-
| Shift-click
| Undoes last point where you set a wire.
|-
| Ctrl-click input on function with two inputs
| Switches the two input wires.
|-
| Spacebar
| Switches the direction of a wire between horizontal and vertical.
|}

==Text==
{| class="wikitable sortable"
|-
! Keyboard Shortcut
! Description
|-
| Double-click
| Selects a single word in a string.
|-
| Triple-click
| Selects an entire string.
|-
| Ctrl-Right arrow
| Moves forward in string by one word when using text that has characters that use single bytes, such as Western character sets. Moves forward in string by one character when using text that has characters that use multiple bytes, such as Asian character sets.
|-
| Ctrl-Left arrow
| Moves backward in string by one word when using text that has characters that use single bytes, such as Western character sets. Moves backward in string by one character when using text that has characters that use multiple bytes, such as Asian character sets.
|-
| Home
| Moves to beginning of current line in string.
|-
| End
| Moves to end of current line in string.
|-
| Ctrl-Home
| Moves to beginning of entire string.
|-
| Ctrl-End
| Moves to end of entire string.
|-
| Shift-Enter
| Adds new items when entering items in enumerated type controls and constants, ring controls and constants, or Case structures. In string constants, press the <Shift-Enter> keys on the keyboard to disable autosizing if it is enabled. If autosizing is disabled, press the <Shift-Enter> keys on the keyboard to display a scroll bar in the constant.
|-
| Esc
| Cancels current edit in a string.
|-
| Ctrl-Enter
| Ends text entry.
|-
| Ctrl-=
| Increases the current font size.
|-
| Ctrl--
| Decreases the current font size.
|-
| Ctrl-0
| Displays the Font dialog box.
|-
| Ctrl-1
| Changes to the Application font in Font dialog box.
|-
| Ctrl-2
| Changes to the System font in the Font dialog box.
|-
| Ctrl-3
| Changes to the Dialog font in the Font dialog box.
|-
| Ctrl-4
| Changes to the current font in the Font dialog box.
|}

=See also=
*[[Tips and tricks]] - LabVIEW tips and tricks.

[[category:lists|Keyboard shortcuts for LabVIEW]]

LabVIEW object-oriented programming FAQ

2007-08-14T21:03:28Z

Smercer: Add external link to NI's LVOOP FAQ

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.

You may find many questions already answered on the [http://zone.ni.com/devzone/cda/tut/p/id/3573 LVOOP FAQ on NI's website]. That FAQ will be updated by NI for new versions of LabVIEW and new OO tools as they become available.
==Why is class data private?==
In general object-oriented programming terms, attributes (like methods) can have private, protected, or public visibility. In practice individual object-oriented programming languages have differing capabilities when it comes to specifying visibility. In the UML attributes are generally assumed to have private visibility unless otherwise specified. (Operations, on the other hand, are assumed to be public unless otherwise specified.) Generally, OOP style guides say never to give attributes public visibility, and the so-called “Law of Demeter” in its strong form limits attribute visibilities to private. In other words, access to data in a class from outside the class is always through accessor methods (‘set’ or ‘get’) methods. In LVOOP this is the only choice, a decision designed to promote good code designs with minimal coupling. (See further here: [http://zone.ni.com/devzone/cda/tut/p/id/3574]). (Note that LabVIEW 8.5 introduces a “Create Accessor” dialog box to simplify the creation of accessor methods. For more information on this dialog box see the LabVIEW 8.5 Upgrade Notes here: [http://digital.ni.com/manuals.nsf/websearch/7A60FDCEA6D2D8C4862572FD00159F5A].)

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

[[Category:GOOP]]

Functional global variable

2007-08-10T15:15:48Z

Smercer:

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.

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

List of acronyms

2007-07-10T14:05:08Z

Smercer:

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 
BYOB - Bring Your Own Beer 
CAPTCHA - Completely Automated Public Turing test to tell Computers and Humans Apart ... an example would be the questions at the end of online forums that says "type the word you see in this image to continue." They're supposed to filter out robots and automated systems and only allow real sentient beings to continue. 
DA - Dumb @$$ 
DAQ / DAQmx - Data Acquisition 
DB - Database 
DILLIGAF - Do I Look Like I Give A F#ck? 
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; see also LVOOP and LabVOOP 
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 
LabVOOP - LabVIEW Object Oriented Programming; this version is not preferred by NI (as of July 2007) but is easier to pronounce and may gain currency given time.
LED - Light-Emitting Diode 
LF - Low Frequency 
LIFO - Last In, First Out 
LOL - Laughing Out Loud 
LVOOP - LabVIEW Object Oriented Programming; see also GOOP and LabVOOP 
LQTM - Laughing Quietly To Myself 
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 F#cking/Fine Manual 
RTSI - Real-Time System Integration 
TCP - Transmission Control Protocol 
TMI - Too Much Information 
VBA - Visual Basic for Applications 
VI - Virtual Instrument 
VISTA : Virus Inside Switch To Apple 
VIT - Virtual Instrument Template 
VOIP - Voice Over Internet Protocol 
W3C - World Wide Web Consortium 
WTF - What The F#ck? ... sometimes voiced using the US military names for the letters, "Whisky Tango Foxtrot?!" 
XML - eXtensible Markup Language

List of acronyms

2007-07-10T14:03:10Z

Smercer:

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 
BYOB - Bring Your Own Beer 
CAPTCHA - Completely Automated Public Turing test to tell Computers and Humans Apart ... an example would be the questions at the end of online forums that says "type the word you see in this image to continue." They're supposed to filter out robots and automated systems and only allow real sentient beings to continue. 
DA - Dumb @$$ 
DAQ / DAQmx - Data Acquisition 
DB - Database 
DILLIGAF - Do I Look Like I Give A F#ck? 
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 
LQTM - Laughing Quietly To Myself 
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 F#cking/Fine Manual 
RTSI - Real-Time System Integration 
TCP - Transmission Control Protocol 
TMI - Too Much Information 
VBA - Visual Basic for Applications 
VI - Virtual Instrument 
VISTA : Virus Inside Switch To Apple 
VIT - Virtual Instrument Template 
VOIP - Voice Over Internet Protocol 
W3C - World Wide Web Consortium 
WTF - What The F#ck? ... sometimes voiced using the US military names for the letters, "Whisky Tango Foxtrot?!" 
XML - eXtensible Markup Language

List of acronyms

2007-07-10T14:02:09Z

Smercer:

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 
BYOB - Bring Your Own Beer 
CAPTCHA - Completely Automated Public Turing test to tell Computers and Humans Apart ... an example would be the questions at the end of online forums that says "type the word you see in this image to continue." They're supposed to filter out robots and automated systems and only allow real sentient beings to continue. 
DA - Dumb @$$ 
DAQ / DAQmx - Data Acquisition 
DB - Database 
DILLIGAF - Do I Look Like I Give A F#ck? 
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 
LQTM - Laughing Quietly To Myself 
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 F#cking/Fine Manual 
RTSI - Real-Time System Integration 
TCP - Transmission Control Protocol 
TMI - Too Much Information 
VBA - Visual Basic for Applications 
VI - Virtual Instrument 
VISTA : Virus Inside Switch To Apple 
VIT - Virtual Instrument Template 
VOIP - Voice Over Internet Protocol 
W3C - World Wide Web Consortium 
WTF - What The F#ck? 
XML - eXtensible Markup Language

Symbolic path

2007-05-07T20:39:56Z

Smercer:

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

{| class="wikitable"
|-
! pseudopath
! 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 pseudopath 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 ''pseudopath'':

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

''pseudopath'' 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.

== When Using Modules (FPGA, RT, etc) ==
A pseudopath 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.

Symbolic path

2007-05-07T20:38:12Z

Smercer:

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

{| class="wikitable"
|-
! pseudopath
! 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
|}

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 ''pseudopath'':

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

''pseudopath'' 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.

== When Using Modules (FPGA, RT, etc) ==
A pseudopath 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.

Symbolic path

2007-05-07T20:36:10Z

Smercer:

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

{| class="wikitable"
|-
! pseudopath
! 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
|}

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 ''pseudopath'':

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

'pseudopath'' 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.

== When Using Modules (FPGA, RT, etc) ==
A pseudopath 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.

Symbolic path

2007-05-07T20:34:40Z

Smercer:

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

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 paths'' 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.

== When Using Modules (FPGA, RT, etc) ==
A pseudopath 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.

Error Cluster data type

2007-05-05T17:01:46Z

Smercer: /* Error Handling */

== Error Cluster ==

An error cluster contains a Boolean “status”, an I32 numerical “code” and a “source” string in that order. Any cluster with this structure is treated as an error cluster in LabVIEW. The default value, “status” = false, “code” = 0 and “source” empty, is shown in '''Figure 1''' for a typical control.

[[Image:Fig_1-error_cluster_control_and_terminal.JPG|frame|center|'''Figure 1''': 3D error cluster control and terminal‎]]

The “status” is true if an error has occurred but remains false for warnings. The “code” assumes positive and negative values (see “error codes, ranges of” in ''LabVIEW Help''), with the range 5000 through 9999 '''and''' the range -9999 to -5000 reserved for user defined error codes. The “source” identifies a VI and possibly its call chain as the origin of an error. Possible reasons for an error can be obtained from the '''Explain Error''' tool (see '''Figure 2'''). This tool is activated by selecting the '''Explain Error…''' item under the '''Help''' menu in LabVIEW or by right-clicking on any element of an error cluster with “status” true and selecting '''Explain Error'''.

[[Image:Explain_Error_tool.jpg|frame|center|'''Figure 2''': '''Explain Error''' tool]]

LabVIEW provides several VIs for working with error clusters. For example, the '''Error Cluster from Error Code.vi''' generates an error cluster based on a specified “code” (see '''Figure 3'''). You can also define custom codes using the '''General Error Handler.vi''' or by creating an XML-based text file in the <labview\user.lib\ errors> directory (see “error codes, defining custom” and “error codes, defining custom in text files” in ''LabVIEW Help''). This VI outputs a “message”, like the “Explanation” from '''Explain Error''', which identifies the “source” and describes possible causes associated with the “code”. This information can also be displayed using several different types of dialogs. This feature is commonly employed to identify errors in user interface applications.

[[Image:Fig_3-VI_connectors.JPG|frame|center|'''Figure 3''': connectors for '''Error Cluster from Error Code.vi''' and '''General Error Handler.vi''']]

Error clusters are also valid inputs to some comparison and array functions and can be used to control case structures and while loops (see '''Figure 4''').

[[Image:Fig_3-error_cluster_examples.JPG|frame|center|'''Figure 4''': structures, comparison and array functions involving error cluster inputs]]

The comparison functions '''Equal?''', '''Not Equal?''', '''Greater?''', '''Less?''', '''Greater Or Equal?''' and '''Less Or Equal?''' can operate in two modes. The output is Boolean in the '''Compare Aggregates''' mode, while a cluster of three Booleans corresponding to each component of the error cluster is generated in the '''Compare Elements''' mode (see '''Figure 5''').

[[Image:Comparison_function_indicators.JPG|frame|center|'''Figure 5''': typical indicators for both modes of a comparison function]]

The '''Select''', '''Max & Min''' and '''In Range and Coerce''' functions can output an error cluster. While the '''Max & Min''' function returns ordered inputs in the Compare Aggregates mode, an output may not correspond to either error cluster if Compare Elements is selected (default). The '''Array Max & Min''' function always returns ordered inputs corresponding to the first and last elements of the '''Sort 1D Array''' output. The primary sort is performed on “status”, with secondary ordering by “code” and then “source”. Strings are sorted by ASCII code starting with the leading character. Note that error clusters behave like their Boolean “status” value when connected to the selector terminal of a '''Select''' function and '''Case Structure''' or the conditional terminal of a '''While Loop'''.
--[[User:wevanarsdale|wevanarsdale]] 21:18, 3 May 2007 (CDT)

== Error Selection ==

A common programming issue in LabVIEW involves selecting between two or more error clusters. This process involves finding the cluster with “status” true or “code” not equal zero if no “status” is true. The '''Merge Errors.vi''' shown in '''Figure 4''' implements this search for up to three error clusters and an array of such clusters. This subVI is relatively fast with large error arrays. However, a significant portion of the execution time involves concatenation of inputs for the small arrays (<10 elements) typical in most applications. This result suggests that time critical applications should be built around the immediate selection between two error clusters rather than their concatenation into an array. The simplest method of comparing the “status” of two error clusters involves the Select function (see '''Figure 6''').

[[Image:Simple_error_selector_diagram.JPG|frame|center|'''Figure 6''': diagram for a simple error selector that does not detect warnings]]

This function selects the first error cluster with “status” true, much like the '''Or''' function operating on Boolean inputs. Connecting “error 2” instead of “error 1” to the selector terminal is more analogous to the '''And''' function, which is typically less useful. While about 30 times faster than the '''Merge Errors.vi''' (LabVIEW 7.0), the '''Select''' function does not detect a warning (“status” false and “code” not equal zero).

Diagrams for several VIs that compare error clusters and detect warnings are shown below (fastest to slowest).

[[Image:Error_selector_diagram_A.JPG|frame|center|]][[Image:Error_selector_diagrams_B.JPG|frame|center|'''Figure 7''': possible diagrams for an error selector that detects warnings]]

These VIs execute about 5 times faster than the '''Merge Errors.vi''' (LabVIEW 7.0), even with normal priority execution. ('''Merge Errors.vi''' uses the “subroutine” priority.) Inputs to selector terminals in the first and second diagrams are passed to “error” for the cases not shown. Otherwise, “error 1” is checked for nonzero “code” since neither cluster has “status” true. The last approach uses the Max & Min function in Compare Aggregates mode to order inputs. If just one of these clusters has “status” true, that input will be the “max” output since true > false. However, this output must be checked for “status” true or “code” nonzero to determine selection.
--[[User:wevanarsdale|wevanarsdale]] 21:18, 3 May 2007 (CDT)

== Error Handling ==

Every LabVIEW programmer has their own approach to handling errors. In fact, those with multiple personalities probably have several different approaches to handling errors. As an example, consider the producer-consumer diagram shown in '''Figure 8'''.

[[Image:Producer-consumer.PNG|center|thumb|600px|'''Figure 8''': producer-consumer diagram with error handling in the top loop]]

The “event loop” (bottom) produces enumerated commands that are processed by the “cmd loop” (top). The outer case structure in the top loop traps for errors that are placed on the lower shift register. The corresponding error case (not shown) allows error handling by “code” with different methods of notification. For example, a user interface application based on this design pattern might employ the '''General Error Handler.vi''' shown in '''Figure 3''' to display a dialog for particular errors. However, this method would not work for applications that run continuously without user interaction.

{| class="wikitable" border="1"
|-
| For continuously running applications, an error dialog (or any other kind of dialog for that matter) would disrupt execution, causing data loss or some other event you are being paid to avoid. Logging error information to file is a useful notification method for such applications. This approach requires an error description, which is provided by the '''Error Code Database.vi''' (see '''Figure 9''') for specified error codes in LabVIEW.
[[Image:Error_code_database_connector.jpg|frame|center|'''Figure 9''': connector for the '''Error Code Database.vi''']]
This locked VI, located in the library <labview\vi.lib\Utility\error.llb>, is easily found as a subVI of the '''General Error Handler.vi'''. <s>You would have to extend this database to handle user defined error codes and provide some type of error log.</s> ''See General Error Handler.vi online help for two different ways of providing error descriptions for user defined error codes.'' For example, some Windows applications log errors to the '''Event Viewer''' (right-click on '''My Computer''' and select '''Manage''' from the popup menu) shown in '''Figure 10''' and '''Figure 11'''.

|This entire section of WIKI about "Error Handling" could benefit from a deep reading of the online help for the General Error Handler.vi. That VI has more facilities than folks typically know. FOR EXAMPLE:

The General Error Handler.vi includes an input parameter for the type of dialog, one option is "no dialog." I would STRONGLY recommended instead of calling "Error Code Database.vi". The primary reason for the recommendation is that the translation of error code cluster into human readable strings involves much more than just looking up text in the database. The '''source''' string itself may include information to override or extend the database, and the text in either the '''source''' string or the database may include formatting commands, such as HTML tags for bold face. Encoding information in the '''source''' string is a technique that will become more common in the future.

You may desire to display the text, fully formatted, in a string indicator of your own instead of in any dialog. Use the function of General Error Handler CORE.vi (found on the block diagram of General Error Handler.vi) to do this.
|}

[[Image:Event_viewer.JPG|frame|center|'''Figure 10''': '''Event Viewer''' in Windows]]
[[Image:Event_properties.jpg|frame|center|'''Figure 11''':'''Event Properties''' in Windows]]

The '''eventcreate''' command can be used in Windows to log events to this application. A VI [[log event error]] for logging errors to the '''Event Viewer''' should available soon.
--[[User:wevanarsdale|wevanarsdale]] 21:17, 3 May 2007 (CDT)

Error Cluster data type

2007-05-05T16:59:13Z

Smercer: /* Error Handling */

== Error Cluster ==

An error cluster contains a Boolean “status”, an I32 numerical “code” and a “source” string in that order. Any cluster with this structure is treated as an error cluster in LabVIEW. The default value, “status” = false, “code” = 0 and “source” empty, is shown in '''Figure 1''' for a typical control.

[[Image:Fig_1-error_cluster_control_and_terminal.JPG|frame|center|'''Figure 1''': 3D error cluster control and terminal‎]]

The “status” is true if an error has occurred but remains false for warnings. The “code” assumes positive and negative values (see “error codes, ranges of” in ''LabVIEW Help''), with the range 5000 through 9999 '''and''' the range -9999 to -5000 reserved for user defined error codes. The “source” identifies a VI and possibly its call chain as the origin of an error. Possible reasons for an error can be obtained from the '''Explain Error''' tool (see '''Figure 2'''). This tool is activated by selecting the '''Explain Error…''' item under the '''Help''' menu in LabVIEW or by right-clicking on any element of an error cluster with “status” true and selecting '''Explain Error'''.

[[Image:Explain_Error_tool.jpg|frame|center|'''Figure 2''': '''Explain Error''' tool]]

LabVIEW provides several VIs for working with error clusters. For example, the '''Error Cluster from Error Code.vi''' generates an error cluster based on a specified “code” (see '''Figure 3'''). You can also define custom codes using the '''General Error Handler.vi''' or by creating an XML-based text file in the <labview\user.lib\ errors> directory (see “error codes, defining custom” and “error codes, defining custom in text files” in ''LabVIEW Help''). This VI outputs a “message”, like the “Explanation” from '''Explain Error''', which identifies the “source” and describes possible causes associated with the “code”. This information can also be displayed using several different types of dialogs. This feature is commonly employed to identify errors in user interface applications.

[[Image:Fig_3-VI_connectors.JPG|frame|center|'''Figure 3''': connectors for '''Error Cluster from Error Code.vi''' and '''General Error Handler.vi''']]

Error clusters are also valid inputs to some comparison and array functions and can be used to control case structures and while loops (see '''Figure 4''').

[[Image:Fig_3-error_cluster_examples.JPG|frame|center|'''Figure 4''': structures, comparison and array functions involving error cluster inputs]]

The comparison functions '''Equal?''', '''Not Equal?''', '''Greater?''', '''Less?''', '''Greater Or Equal?''' and '''Less Or Equal?''' can operate in two modes. The output is Boolean in the '''Compare Aggregates''' mode, while a cluster of three Booleans corresponding to each component of the error cluster is generated in the '''Compare Elements''' mode (see '''Figure 5''').

[[Image:Comparison_function_indicators.JPG|frame|center|'''Figure 5''': typical indicators for both modes of a comparison function]]

The '''Select''', '''Max & Min''' and '''In Range and Coerce''' functions can output an error cluster. While the '''Max & Min''' function returns ordered inputs in the Compare Aggregates mode, an output may not correspond to either error cluster if Compare Elements is selected (default). The '''Array Max & Min''' function always returns ordered inputs corresponding to the first and last elements of the '''Sort 1D Array''' output. The primary sort is performed on “status”, with secondary ordering by “code” and then “source”. Strings are sorted by ASCII code starting with the leading character. Note that error clusters behave like their Boolean “status” value when connected to the selector terminal of a '''Select''' function and '''Case Structure''' or the conditional terminal of a '''While Loop'''.
--[[User:wevanarsdale|wevanarsdale]] 21:18, 3 May 2007 (CDT)

== Error Selection ==

A common programming issue in LabVIEW involves selecting between two or more error clusters. This process involves finding the cluster with “status” true or “code” not equal zero if no “status” is true. The '''Merge Errors.vi''' shown in '''Figure 4''' implements this search for up to three error clusters and an array of such clusters. This subVI is relatively fast with large error arrays. However, a significant portion of the execution time involves concatenation of inputs for the small arrays (<10 elements) typical in most applications. This result suggests that time critical applications should be built around the immediate selection between two error clusters rather than their concatenation into an array. The simplest method of comparing the “status” of two error clusters involves the Select function (see '''Figure 6''').

[[Image:Simple_error_selector_diagram.JPG|frame|center|'''Figure 6''': diagram for a simple error selector that does not detect warnings]]

This function selects the first error cluster with “status” true, much like the '''Or''' function operating on Boolean inputs. Connecting “error 2” instead of “error 1” to the selector terminal is more analogous to the '''And''' function, which is typically less useful. While about 30 times faster than the '''Merge Errors.vi''' (LabVIEW 7.0), the '''Select''' function does not detect a warning (“status” false and “code” not equal zero).

Diagrams for several VIs that compare error clusters and detect warnings are shown below (fastest to slowest).

[[Image:Error_selector_diagram_A.JPG|frame|center|]][[Image:Error_selector_diagrams_B.JPG|frame|center|'''Figure 7''': possible diagrams for an error selector that detects warnings]]

These VIs execute about 5 times faster than the '''Merge Errors.vi''' (LabVIEW 7.0), even with normal priority execution. ('''Merge Errors.vi''' uses the “subroutine” priority.) Inputs to selector terminals in the first and second diagrams are passed to “error” for the cases not shown. Otherwise, “error 1” is checked for nonzero “code” since neither cluster has “status” true. The last approach uses the Max & Min function in Compare Aggregates mode to order inputs. If just one of these clusters has “status” true, that input will be the “max” output since true > false. However, this output must be checked for “status” true or “code” nonzero to determine selection.
--[[User:wevanarsdale|wevanarsdale]] 21:18, 3 May 2007 (CDT)

== Error Handling ==

Every LabVIEW programmer has their own approach to handling errors. In fact, those with multiple personalities probably have several different approaches to handling errors. As an example, consider the producer-consumer diagram shown in '''Figure 8'''.

[[Image:Producer-consumer.PNG|center|thumb|600px|'''Figure 8''': producer-consumer diagram with error handling in the top loop]]

The “event loop” (bottom) produces enumerated commands that are processed by the “cmd loop” (top). The outer case structure in the top loop traps for errors that are placed on the lower shift register. The corresponding error case (not shown) allows error handling by “code” with different methods of notification. For example, a user interface application based on this design pattern might employ the '''General Error Handler.vi''' shown in '''Figure 3''' to display a dialog for particular errors. However, this method would not work for applications that run continuously without user interaction.

For continuously running applications, an error dialog (or any other kind of dialog for that matter) would disrupt execution, causing data loss or some other event you are being paid to avoid. Logging error information to file is a useful notification method for such applications. This approach requires an error description, which is provided by the '''Error Code Database.vi''' (see '''Figure 9''') for specified error codes in LabVIEW.

{| class="wikitable" border="1"
|-
|[[Image:Error_code_database_connector.jpg|frame|center|'''Figure 9''': connector for the '''Error Code Database.vi''']]
This locked VI, located in the library <labview\vi.lib\Utility\error.llb>, is easily found as a subVI of the '''General Error Handler.vi'''. <s>You would have to extend this database to handle user defined error codes and provide some type of error log.</s> ''See General Error Handler.vi online help for two different ways of providing error descriptions for user defined error codes.'' For example, some Windows applications log errors to the '''Event Viewer''' (right-click on '''My Computer''' and select '''Manage''' from the popup menu) shown in '''Figure 10''' and '''Figure 11'''.

|This entire section of WIKI about "Error Handling" could benefit from a deep reading of the online help for the General Error Handler.vi. That VI has more facilities than folks typically know. FOR EXAMPLE:

The General Error Handler.vi includes an input parameter for the type of dialog, one option is "no dialog." This is STRONGLY recommended instead of calling "Error Code Database.vi". The primary reason for the recommendation is that the translation of error code cluster into human readable strings involves much more than just looking up text in the database. The '''source''' string itself may include information to override or extend the database, and the text in either the '''source''' string or the database may include formatting commands, such as HTML tags for bold face. Encoding information in the '''source''' string is a technique that will become more common in the future.

You may desire to display the text, fully formatted, in a string indicator of your own instead of in any dialog. Use the function of General Error Handler CORE.vi (found on the block diagram of General Error Handler.vi) to do this.
|}

[[Image:Event_viewer.JPG|frame|center|'''Figure 10''': '''Event Viewer''' in Windows]]
[[Image:Event_properties.jpg|frame|center|'''Figure 11''':'''Event Properties''' in Windows]]

The '''eventcreate''' command can be used in Windows to log events to this application. A VI [[log event error]] for logging errors to the '''Event Viewer''' should available soon.
--[[User:wevanarsdale|wevanarsdale]] 21:17, 3 May 2007 (CDT)

Error Cluster data type

2007-05-05T16:57:28Z

Smercer: /* Error Handling */

== Error Cluster ==

An error cluster contains a Boolean “status”, an I32 numerical “code” and a “source” string in that order. Any cluster with this structure is treated as an error cluster in LabVIEW. The default value, “status” = false, “code” = 0 and “source” empty, is shown in '''Figure 1''' for a typical control.

[[Image:Fig_1-error_cluster_control_and_terminal.JPG|frame|center|'''Figure 1''': 3D error cluster control and terminal‎]]

The “status” is true if an error has occurred but remains false for warnings. The “code” assumes positive and negative values (see “error codes, ranges of” in ''LabVIEW Help''), with the range 5000 through 9999 '''and''' the range -9999 to -5000 reserved for user defined error codes. The “source” identifies a VI and possibly its call chain as the origin of an error. Possible reasons for an error can be obtained from the '''Explain Error''' tool (see '''Figure 2'''). This tool is activated by selecting the '''Explain Error…''' item under the '''Help''' menu in LabVIEW or by right-clicking on any element of an error cluster with “status” true and selecting '''Explain Error'''.

[[Image:Explain_Error_tool.jpg|frame|center|'''Figure 2''': '''Explain Error''' tool]]

LabVIEW provides several VIs for working with error clusters. For example, the '''Error Cluster from Error Code.vi''' generates an error cluster based on a specified “code” (see '''Figure 3'''). You can also define custom codes using the '''General Error Handler.vi''' or by creating an XML-based text file in the <labview\user.lib\ errors> directory (see “error codes, defining custom” and “error codes, defining custom in text files” in ''LabVIEW Help''). This VI outputs a “message”, like the “Explanation” from '''Explain Error''', which identifies the “source” and describes possible causes associated with the “code”. This information can also be displayed using several different types of dialogs. This feature is commonly employed to identify errors in user interface applications.

[[Image:Fig_3-VI_connectors.JPG|frame|center|'''Figure 3''': connectors for '''Error Cluster from Error Code.vi''' and '''General Error Handler.vi''']]

Error clusters are also valid inputs to some comparison and array functions and can be used to control case structures and while loops (see '''Figure 4''').

[[Image:Fig_3-error_cluster_examples.JPG|frame|center|'''Figure 4''': structures, comparison and array functions involving error cluster inputs]]

The comparison functions '''Equal?''', '''Not Equal?''', '''Greater?''', '''Less?''', '''Greater Or Equal?''' and '''Less Or Equal?''' can operate in two modes. The output is Boolean in the '''Compare Aggregates''' mode, while a cluster of three Booleans corresponding to each component of the error cluster is generated in the '''Compare Elements''' mode (see '''Figure 5''').

[[Image:Comparison_function_indicators.JPG|frame|center|'''Figure 5''': typical indicators for both modes of a comparison function]]

The '''Select''', '''Max & Min''' and '''In Range and Coerce''' functions can output an error cluster. While the '''Max & Min''' function returns ordered inputs in the Compare Aggregates mode, an output may not correspond to either error cluster if Compare Elements is selected (default). The '''Array Max & Min''' function always returns ordered inputs corresponding to the first and last elements of the '''Sort 1D Array''' output. The primary sort is performed on “status”, with secondary ordering by “code” and then “source”. Strings are sorted by ASCII code starting with the leading character. Note that error clusters behave like their Boolean “status” value when connected to the selector terminal of a '''Select''' function and '''Case Structure''' or the conditional terminal of a '''While Loop'''.
--[[User:wevanarsdale|wevanarsdale]] 21:18, 3 May 2007 (CDT)

== Error Selection ==

A common programming issue in LabVIEW involves selecting between two or more error clusters. This process involves finding the cluster with “status” true or “code” not equal zero if no “status” is true. The '''Merge Errors.vi''' shown in '''Figure 4''' implements this search for up to three error clusters and an array of such clusters. This subVI is relatively fast with large error arrays. However, a significant portion of the execution time involves concatenation of inputs for the small arrays (<10 elements) typical in most applications. This result suggests that time critical applications should be built around the immediate selection between two error clusters rather than their concatenation into an array. The simplest method of comparing the “status” of two error clusters involves the Select function (see '''Figure 6''').

[[Image:Simple_error_selector_diagram.JPG|frame|center|'''Figure 6''': diagram for a simple error selector that does not detect warnings]]

This function selects the first error cluster with “status” true, much like the '''Or''' function operating on Boolean inputs. Connecting “error 2” instead of “error 1” to the selector terminal is more analogous to the '''And''' function, which is typically less useful. While about 30 times faster than the '''Merge Errors.vi''' (LabVIEW 7.0), the '''Select''' function does not detect a warning (“status” false and “code” not equal zero).

Diagrams for several VIs that compare error clusters and detect warnings are shown below (fastest to slowest).

[[Image:Error_selector_diagram_A.JPG|frame|center|]][[Image:Error_selector_diagrams_B.JPG|frame|center|'''Figure 7''': possible diagrams for an error selector that detects warnings]]

These VIs execute about 5 times faster than the '''Merge Errors.vi''' (LabVIEW 7.0), even with normal priority execution. ('''Merge Errors.vi''' uses the “subroutine” priority.) Inputs to selector terminals in the first and second diagrams are passed to “error” for the cases not shown. Otherwise, “error 1” is checked for nonzero “code” since neither cluster has “status” true. The last approach uses the Max & Min function in Compare Aggregates mode to order inputs. If just one of these clusters has “status” true, that input will be the “max” output since true > false. However, this output must be checked for “status” true or “code” nonzero to determine selection.
--[[User:wevanarsdale|wevanarsdale]] 21:18, 3 May 2007 (CDT)

== Error Handling ==

Every LabVIEW programmer has their own approach to handling errors. In fact, those with multiple personalities probably have several different approaches to handling errors. As an example, consider the producer-consumer diagram shown in '''Figure 8'''.

[[Image:Producer-consumer.PNG|center|thumb|600px|'''Figure 8''': producer-consumer diagram with error handling in the top loop]]

The “event loop” (bottom) produces enumerated commands that are processed by the “cmd loop” (top). The outer case structure in the top loop traps for errors that are placed on the lower shift register. The corresponding error case (not shown) allows error handling by “code” with different methods of notification. For example, a user interface application based on this design pattern might employ the '''General Error Handler.vi''' shown in '''Figure 3''' to display a dialog for particular errors. However, this method would not work for applications that run continuously without user interaction.

For continuously running applications, an error dialog (or any other kind of dialog for that matter) would disrupt execution, causing data loss or some other event you are being paid to avoid. Logging error information to file is a useful notification method for such applications. This approach requires an error description, which is provided by the '''Error Code Database.vi''' (see '''Figure 9''') for specified error codes in LabVIEW.

{| class="wikitable"
|-
|[[Image:Error_code_database_connector.jpg|frame|center|'''Figure 9''': connector for the '''Error Code Database.vi''']]
This locked VI, located in the library <labview\vi.lib\Utility\error.llb>, is easily found as a subVI of the '''General Error Handler.vi'''. <s>You would have to extend this database to handle user defined error codes and provide some type of error log.</s> ''See General Error Handler.vi online help for two different ways of providing error descriptions for user defined error codes.'' For example, some Windows applications log errors to the '''Event Viewer''' (right-click on '''My Computer''' and select '''Manage''' from the popup menu) shown in '''Figure 10''' and '''Figure 11'''.

|This entire section of WIKI about "Error Handling" could benefit from a deep reading of the online help for the General Error Handler.vi. That VI has more facilities than folks typically know. FOR EXAMPLE:

The General Error Handler.vi includes an input parameter for the type of dialog, one option is "no dialog." This is STRONGLY recommended instead of calling "Error Code Database.vi". The primary reason for the recommendation is that the translation of error code cluster into human readable strings involves much more than just looking up text in the database. The '''source''' string itself may include information to override or extend the database, and the text in either the '''source''' string or the database may include formatting commands, such as HTML tags for bold face. Encoding information in the '''source''' string is a technique that will become more common in the future.

You may desire to display the text, fully formatted, in a string indicator of your own instead of in any dialog. Use the function of General Error Handler CORE.vi (found on the block diagram of General Error Handler.vi) to do this.
|}

[[Image:Event_viewer.JPG|frame|center|'''Figure 10''': '''Event Viewer''' in Windows]]
[[Image:Event_properties.jpg|frame|center|'''Figure 11''':'''Event Properties''' in Windows]]

The '''eventcreate''' command can be used in Windows to log events to this application. A VI [[log event error]] for logging errors to the '''Event Viewer''' should available soon.
--[[User:wevanarsdale|wevanarsdale]] 21:17, 3 May 2007 (CDT)

Error Cluster data type

2007-05-05T16:56:39Z

Smercer: /* Error Handling */

== Error Cluster ==

An error cluster contains a Boolean “status”, an I32 numerical “code” and a “source” string in that order. Any cluster with this structure is treated as an error cluster in LabVIEW. The default value, “status” = false, “code” = 0 and “source” empty, is shown in '''Figure 1''' for a typical control.

[[Image:Fig_1-error_cluster_control_and_terminal.JPG|frame|center|'''Figure 1''': 3D error cluster control and terminal‎]]

The “status” is true if an error has occurred but remains false for warnings. The “code” assumes positive and negative values (see “error codes, ranges of” in ''LabVIEW Help''), with the range 5000 through 9999 '''and''' the range -9999 to -5000 reserved for user defined error codes. The “source” identifies a VI and possibly its call chain as the origin of an error. Possible reasons for an error can be obtained from the '''Explain Error''' tool (see '''Figure 2'''). This tool is activated by selecting the '''Explain Error…''' item under the '''Help''' menu in LabVIEW or by right-clicking on any element of an error cluster with “status” true and selecting '''Explain Error'''.

[[Image:Explain_Error_tool.jpg|frame|center|'''Figure 2''': '''Explain Error''' tool]]

LabVIEW provides several VIs for working with error clusters. For example, the '''Error Cluster from Error Code.vi''' generates an error cluster based on a specified “code” (see '''Figure 3'''). You can also define custom codes using the '''General Error Handler.vi''' or by creating an XML-based text file in the <labview\user.lib\ errors> directory (see “error codes, defining custom” and “error codes, defining custom in text files” in ''LabVIEW Help''). This VI outputs a “message”, like the “Explanation” from '''Explain Error''', which identifies the “source” and describes possible causes associated with the “code”. This information can also be displayed using several different types of dialogs. This feature is commonly employed to identify errors in user interface applications.

[[Image:Fig_3-VI_connectors.JPG|frame|center|'''Figure 3''': connectors for '''Error Cluster from Error Code.vi''' and '''General Error Handler.vi''']]

Error clusters are also valid inputs to some comparison and array functions and can be used to control case structures and while loops (see '''Figure 4''').

[[Image:Fig_3-error_cluster_examples.JPG|frame|center|'''Figure 4''': structures, comparison and array functions involving error cluster inputs]]

The comparison functions '''Equal?''', '''Not Equal?''', '''Greater?''', '''Less?''', '''Greater Or Equal?''' and '''Less Or Equal?''' can operate in two modes. The output is Boolean in the '''Compare Aggregates''' mode, while a cluster of three Booleans corresponding to each component of the error cluster is generated in the '''Compare Elements''' mode (see '''Figure 5''').

[[Image:Comparison_function_indicators.JPG|frame|center|'''Figure 5''': typical indicators for both modes of a comparison function]]

The '''Select''', '''Max & Min''' and '''In Range and Coerce''' functions can output an error cluster. While the '''Max & Min''' function returns ordered inputs in the Compare Aggregates mode, an output may not correspond to either error cluster if Compare Elements is selected (default). The '''Array Max & Min''' function always returns ordered inputs corresponding to the first and last elements of the '''Sort 1D Array''' output. The primary sort is performed on “status”, with secondary ordering by “code” and then “source”. Strings are sorted by ASCII code starting with the leading character. Note that error clusters behave like their Boolean “status” value when connected to the selector terminal of a '''Select''' function and '''Case Structure''' or the conditional terminal of a '''While Loop'''.
--[[User:wevanarsdale|wevanarsdale]] 21:18, 3 May 2007 (CDT)

== Error Selection ==

A common programming issue in LabVIEW involves selecting between two or more error clusters. This process involves finding the cluster with “status” true or “code” not equal zero if no “status” is true. The '''Merge Errors.vi''' shown in '''Figure 4''' implements this search for up to three error clusters and an array of such clusters. This subVI is relatively fast with large error arrays. However, a significant portion of the execution time involves concatenation of inputs for the small arrays (<10 elements) typical in most applications. This result suggests that time critical applications should be built around the immediate selection between two error clusters rather than their concatenation into an array. The simplest method of comparing the “status” of two error clusters involves the Select function (see '''Figure 6''').

[[Image:Simple_error_selector_diagram.JPG|frame|center|'''Figure 6''': diagram for a simple error selector that does not detect warnings]]

This function selects the first error cluster with “status” true, much like the '''Or''' function operating on Boolean inputs. Connecting “error 2” instead of “error 1” to the selector terminal is more analogous to the '''And''' function, which is typically less useful. While about 30 times faster than the '''Merge Errors.vi''' (LabVIEW 7.0), the '''Select''' function does not detect a warning (“status” false and “code” not equal zero).

Diagrams for several VIs that compare error clusters and detect warnings are shown below (fastest to slowest).

[[Image:Error_selector_diagram_A.JPG|frame|center|]][[Image:Error_selector_diagrams_B.JPG|frame|center|'''Figure 7''': possible diagrams for an error selector that detects warnings]]

These VIs execute about 5 times faster than the '''Merge Errors.vi''' (LabVIEW 7.0), even with normal priority execution. ('''Merge Errors.vi''' uses the “subroutine” priority.) Inputs to selector terminals in the first and second diagrams are passed to “error” for the cases not shown. Otherwise, “error 1” is checked for nonzero “code” since neither cluster has “status” true. The last approach uses the Max & Min function in Compare Aggregates mode to order inputs. If just one of these clusters has “status” true, that input will be the “max” output since true > false. However, this output must be checked for “status” true or “code” nonzero to determine selection.
--[[User:wevanarsdale|wevanarsdale]] 21:18, 3 May 2007 (CDT)

== Error Handling ==

Every LabVIEW programmer has their own approach to handling errors. In fact, those with multiple personalities probably have several different approaches to handling errors. As an example, consider the producer-consumer diagram shown in '''Figure 8'''.

[[Image:Producer-consumer.PNG|center|thumb|600px|'''Figure 8''': producer-consumer diagram with error handling in the top loop]]

The “event loop” (bottom) produces enumerated commands that are processed by the “cmd loop” (top). The outer case structure in the top loop traps for errors that are placed on the lower shift register. The corresponding error case (not shown) allows error handling by “code” with different methods of notification. For example, a user interface application based on this design pattern might employ the '''General Error Handler.vi''' shown in '''Figure 3''' to display a dialog for particular errors. However, this method would not work for applications that run continuously without user interaction.

For continuously running applications, an error dialog (or any other kind of dialog for that matter) would disrupt execution, causing data loss or some other event you are being paid to avoid. Logging error information to file is a useful notification method for such applications. This approach requires an error description, which is provided by the '''Error Code Database.vi''' (see '''Figure 9''') for specified error codes in LabVIEW.

{| class="wikitable"
|-
| r[[Image:Error_code_database_connector.jpg|frame|center|'''Figure 9''': connector for the '''Error Code Database.vi''']]
This locked VI, located in the library <labview\vi.lib\Utility\error.llb>, is easily found as a subVI of the '''General Error Handler.vi'''. <s>You would have to extend this database to handle user defined error codes and provide some type of error log.</s> ''See General Error Handler.vi online help for two different ways of providing error descriptions for user defined error codes.'' For example, some Windows applications log errors to the '''Event Viewer''' (right-click on '''My Computer''' and select '''Manage''' from the popup menu) shown in '''Figure 10''' and '''Figure 11'''.

|This entire section of WIKI about "Error Handling" could benefit from a deep reading of the online help for the General Error Handler.vi. That VI has more facilities than folks typically know. FOR EXAMPLE:

The General Error Handler.vi includes an input parameter for the type of dialog, one option is "no dialog." This is STRONGLY recommended instead of calling "Error Code Database.vi". The primary reason for the recommendation is that the translation of error code cluster into human readable strings involves much more than just looking up text in the database. The '''source''' string itself may include information to override or extend the database, and the text in either the '''source''' string or the database may include formatting commands, such as HTML tags for bold face. Encoding information in the '''source''' string is a technique that will become more common in the future.

You may desire to display the text, fully formatted, in a string indicator of your own instead of in any dialog. Use the function of General Error Handler CORE.vi (found on the block diagram of General Error Handler.vi) to do this.
|}

[[Image:Event_viewer.JPG|frame|center|'''Figure 10''': '''Event Viewer''' in Windows]]
[[Image:Event_properties.jpg|frame|center|'''Figure 11''':'''Event Properties''' in Windows]]

The '''eventcreate''' command can be used in Windows to log events to this application. A VI [[log event error]] for logging errors to the '''Event Viewer''' should available soon.
--[[User:wevanarsdale|wevanarsdale]] 21:17, 3 May 2007 (CDT)

Error Cluster data type

2007-05-05T16:55:54Z

Smercer: /* Error Handling */

== Error Cluster ==

An error cluster contains a Boolean “status”, an I32 numerical “code” and a “source” string in that order. Any cluster with this structure is treated as an error cluster in LabVIEW. The default value, “status” = false, “code” = 0 and “source” empty, is shown in '''Figure 1''' for a typical control.

[[Image:Fig_1-error_cluster_control_and_terminal.JPG|frame|center|'''Figure 1''': 3D error cluster control and terminal‎]]

The “status” is true if an error has occurred but remains false for warnings. The “code” assumes positive and negative values (see “error codes, ranges of” in ''LabVIEW Help''), with the range 5000 through 9999 '''and''' the range -9999 to -5000 reserved for user defined error codes. The “source” identifies a VI and possibly its call chain as the origin of an error. Possible reasons for an error can be obtained from the '''Explain Error''' tool (see '''Figure 2'''). This tool is activated by selecting the '''Explain Error…''' item under the '''Help''' menu in LabVIEW or by right-clicking on any element of an error cluster with “status” true and selecting '''Explain Error'''.

[[Image:Explain_Error_tool.jpg|frame|center|'''Figure 2''': '''Explain Error''' tool]]

LabVIEW provides several VIs for working with error clusters. For example, the '''Error Cluster from Error Code.vi''' generates an error cluster based on a specified “code” (see '''Figure 3'''). You can also define custom codes using the '''General Error Handler.vi''' or by creating an XML-based text file in the <labview\user.lib\ errors> directory (see “error codes, defining custom” and “error codes, defining custom in text files” in ''LabVIEW Help''). This VI outputs a “message”, like the “Explanation” from '''Explain Error''', which identifies the “source” and describes possible causes associated with the “code”. This information can also be displayed using several different types of dialogs. This feature is commonly employed to identify errors in user interface applications.

[[Image:Fig_3-VI_connectors.JPG|frame|center|'''Figure 3''': connectors for '''Error Cluster from Error Code.vi''' and '''General Error Handler.vi''']]

Error clusters are also valid inputs to some comparison and array functions and can be used to control case structures and while loops (see '''Figure 4''').

[[Image:Fig_3-error_cluster_examples.JPG|frame|center|'''Figure 4''': structures, comparison and array functions involving error cluster inputs]]

The comparison functions '''Equal?''', '''Not Equal?''', '''Greater?''', '''Less?''', '''Greater Or Equal?''' and '''Less Or Equal?''' can operate in two modes. The output is Boolean in the '''Compare Aggregates''' mode, while a cluster of three Booleans corresponding to each component of the error cluster is generated in the '''Compare Elements''' mode (see '''Figure 5''').

[[Image:Comparison_function_indicators.JPG|frame|center|'''Figure 5''': typical indicators for both modes of a comparison function]]

The '''Select''', '''Max & Min''' and '''In Range and Coerce''' functions can output an error cluster. While the '''Max & Min''' function returns ordered inputs in the Compare Aggregates mode, an output may not correspond to either error cluster if Compare Elements is selected (default). The '''Array Max & Min''' function always returns ordered inputs corresponding to the first and last elements of the '''Sort 1D Array''' output. The primary sort is performed on “status”, with secondary ordering by “code” and then “source”. Strings are sorted by ASCII code starting with the leading character. Note that error clusters behave like their Boolean “status” value when connected to the selector terminal of a '''Select''' function and '''Case Structure''' or the conditional terminal of a '''While Loop'''.
--[[User:wevanarsdale|wevanarsdale]] 21:18, 3 May 2007 (CDT)

== Error Selection ==

A common programming issue in LabVIEW involves selecting between two or more error clusters. This process involves finding the cluster with “status” true or “code” not equal zero if no “status” is true. The '''Merge Errors.vi''' shown in '''Figure 4''' implements this search for up to three error clusters and an array of such clusters. This subVI is relatively fast with large error arrays. However, a significant portion of the execution time involves concatenation of inputs for the small arrays (<10 elements) typical in most applications. This result suggests that time critical applications should be built around the immediate selection between two error clusters rather than their concatenation into an array. The simplest method of comparing the “status” of two error clusters involves the Select function (see '''Figure 6''').

[[Image:Simple_error_selector_diagram.JPG|frame|center|'''Figure 6''': diagram for a simple error selector that does not detect warnings]]

This function selects the first error cluster with “status” true, much like the '''Or''' function operating on Boolean inputs. Connecting “error 2” instead of “error 1” to the selector terminal is more analogous to the '''And''' function, which is typically less useful. While about 30 times faster than the '''Merge Errors.vi''' (LabVIEW 7.0), the '''Select''' function does not detect a warning (“status” false and “code” not equal zero).

Diagrams for several VIs that compare error clusters and detect warnings are shown below (fastest to slowest).

[[Image:Error_selector_diagram_A.JPG|frame|center|]][[Image:Error_selector_diagrams_B.JPG|frame|center|'''Figure 7''': possible diagrams for an error selector that detects warnings]]

These VIs execute about 5 times faster than the '''Merge Errors.vi''' (LabVIEW 7.0), even with normal priority execution. ('''Merge Errors.vi''' uses the “subroutine” priority.) Inputs to selector terminals in the first and second diagrams are passed to “error” for the cases not shown. Otherwise, “error 1” is checked for nonzero “code” since neither cluster has “status” true. The last approach uses the Max & Min function in Compare Aggregates mode to order inputs. If just one of these clusters has “status” true, that input will be the “max” output since true > false. However, this output must be checked for “status” true or “code” nonzero to determine selection.
--[[User:wevanarsdale|wevanarsdale]] 21:18, 3 May 2007 (CDT)

== Error Handling ==

Every LabVIEW programmer has their own approach to handling errors. In fact, those with multiple personalities probably have several different approaches to handling errors. As an example, consider the producer-consumer diagram shown in '''Figure 8'''.

[[Image:Producer-consumer.PNG|center|thumb|600px|'''Figure 8''': producer-consumer diagram with error handling in the top loop]]

The “event loop” (bottom) produces enumerated commands that are processed by the “cmd loop” (top). The outer case structure in the top loop traps for errors that are placed on the lower shift register. The corresponding error case (not shown) allows error handling by “code” with different methods of notification. For example, a user interface application based on this design pattern might employ the '''General Error Handler.vi''' shown in '''Figure 3''' to display a dialog for particular errors. However, this method would not work for applications that run continuously without user interaction.

For continuously running applications, an error dialog (or any other kind of dialog for that matter) would disrupt execution, causing data loss or some other event you are being paid to avoid. Logging error information to file is a useful notification method for such applications. This approach requires an error description, which is provided by the '''Error Code Database.vi''' (see '''Figure 9''') for specified error codes in LabVIEW.

{| class="wikitable"
|-
| r[[Image:Error_code_database_connector.jpg|frame|center|'''Figure 9''': connector for the '''Error Code Database.vi''']]
This locked VI, located in the library <labview\vi.lib\Utility\error.llb>, is easily found as a subVI of the '''General Error Handler.vi'''. <s>You would have to extend this database to handle user defined error codes and provide some type of error log.</s> ''See General Error Handler.vi online help for two different ways of providing error descriptions for user defined error codes.'' For example, some Windows applications log errors to the '''Event Viewer''' (right-click on '''My Computer''' and select '''Manage''' from the popup menu) shown in '''Figure 10''' and '''Figure 11'''.

| ''Note from R&D'': This entire section of WIKI about "Error Handling" could benefit from a deep reading of the online help for the General Error Handler.vi. That VI has more facilities than folks typically know. FOR EXAMPLE:

The General Error Handler.vi includes an input parameter for the type of dialog, one option is "no dialog." This is STRONGLY recommended instead of calling "Error Code Database.vi". The primary reason for the recommendation is that the translation of error code cluster into human readable strings involves much more than just looking up text in the database. The '''source''' string itself may include information to override or extend the database, and the text in either the '''source''' string or the database may include formatting commands, such as HTML tags for bold face. Encoding information in the '''source''' string is a technique that will become more common in the future.

You may desire to display the text, fully formatted, in a string indicator of your own instead of in any dialog. Use the function of General Error Handler CORE.vi (found on the block diagram of General Error Handler.vi) to do this.
|}

[[Image:Event_viewer.JPG|frame|center|'''Figure 10''': '''Event Viewer''' in Windows]]
[[Image:Event_properties.jpg|frame|center|'''Figure 11''':'''Event Properties''' in Windows]]

The '''eventcreate''' command can be used in Windows to log events to this application. A VI [[log event error]] for logging errors to the '''Event Viewer''' should available soon.
--[[User:wevanarsdale|wevanarsdale]] 21:17, 3 May 2007 (CDT)

Error Cluster data type

2007-05-05T16:44:13Z

Smercer: /* Error Cluster */

== Error Cluster ==

An error cluster contains a Boolean “status”, an I32 numerical “code” and a “source” string in that order. Any cluster with this structure is treated as an error cluster in LabVIEW. The default value, “status” = false, “code” = 0 and “source” empty, is shown in '''Figure 1''' for a typical control.

[[Image:Fig_1-error_cluster_control_and_terminal.JPG|frame|center|'''Figure 1''': 3D error cluster control and terminal‎]]

The “status” is true if an error has occurred but remains false for warnings. The “code” assumes positive and negative values (see “error codes, ranges of” in ''LabVIEW Help''), with the range 5000 through 9999 '''and''' the range -9999 to -5000 reserved for user defined error codes. The “source” identifies a VI and possibly its call chain as the origin of an error. Possible reasons for an error can be obtained from the '''Explain Error''' tool (see '''Figure 2'''). This tool is activated by selecting the '''Explain Error…''' item under the '''Help''' menu in LabVIEW or by right-clicking on any element of an error cluster with “status” true and selecting '''Explain Error'''.

[[Image:Explain_Error_tool.jpg|frame|center|'''Figure 2''': '''Explain Error''' tool]]

LabVIEW provides several VIs for working with error clusters. For example, the '''Error Cluster from Error Code.vi''' generates an error cluster based on a specified “code” (see '''Figure 3'''). You can also define custom codes using the '''General Error Handler.vi''' or by creating an XML-based text file in the <labview\user.lib\ errors> directory (see “error codes, defining custom” and “error codes, defining custom in text files” in ''LabVIEW Help''). This VI outputs a “message”, like the “Explanation” from '''Explain Error''', which identifies the “source” and describes possible causes associated with the “code”. This information can also be displayed using several different types of dialogs. This feature is commonly employed to identify errors in user interface applications.

[[Image:Fig_3-VI_connectors.JPG|frame|center|'''Figure 3''': connectors for '''Error Cluster from Error Code.vi''' and '''General Error Handler.vi''']]

Error clusters are also valid inputs to some comparison and array functions and can be used to control case structures and while loops (see '''Figure 4''').

[[Image:Fig_3-error_cluster_examples.JPG|frame|center|'''Figure 4''': structures, comparison and array functions involving error cluster inputs]]

The comparison functions '''Equal?''', '''Not Equal?''', '''Greater?''', '''Less?''', '''Greater Or Equal?''' and '''Less Or Equal?''' can operate in two modes. The output is Boolean in the '''Compare Aggregates''' mode, while a cluster of three Booleans corresponding to each component of the error cluster is generated in the '''Compare Elements''' mode (see '''Figure 5''').

[[Image:Comparison_function_indicators.JPG|frame|center|'''Figure 5''': typical indicators for both modes of a comparison function]]

The '''Select''', '''Max & Min''' and '''In Range and Coerce''' functions can output an error cluster. While the '''Max & Min''' function returns ordered inputs in the Compare Aggregates mode, an output may not correspond to either error cluster if Compare Elements is selected (default). The '''Array Max & Min''' function always returns ordered inputs corresponding to the first and last elements of the '''Sort 1D Array''' output. The primary sort is performed on “status”, with secondary ordering by “code” and then “source”. Strings are sorted by ASCII code starting with the leading character. Note that error clusters behave like their Boolean “status” value when connected to the selector terminal of a '''Select''' function and '''Case Structure''' or the conditional terminal of a '''While Loop'''.
--[[User:wevanarsdale|wevanarsdale]] 21:18, 3 May 2007 (CDT)

== Error Selection ==

A common programming issue in LabVIEW involves selecting between two or more error clusters. This process involves finding the cluster with “status” true or “code” not equal zero if no “status” is true. The '''Merge Errors.vi''' shown in '''Figure 4''' implements this search for up to three error clusters and an array of such clusters. This subVI is relatively fast with large error arrays. However, a significant portion of the execution time involves concatenation of inputs for the small arrays (<10 elements) typical in most applications. This result suggests that time critical applications should be built around the immediate selection between two error clusters rather than their concatenation into an array. The simplest method of comparing the “status” of two error clusters involves the Select function (see '''Figure 6''').

[[Image:Simple_error_selector_diagram.JPG|frame|center|'''Figure 6''': diagram for a simple error selector that does not detect warnings]]

This function selects the first error cluster with “status” true, much like the '''Or''' function operating on Boolean inputs. Connecting “error 2” instead of “error 1” to the selector terminal is more analogous to the '''And''' function, which is typically less useful. While about 30 times faster than the '''Merge Errors.vi''' (LabVIEW 7.0), the '''Select''' function does not detect a warning (“status” false and “code” not equal zero).

Diagrams for several VIs that compare error clusters and detect warnings are shown below (fastest to slowest).

[[Image:Error_selector_diagram_A.JPG|frame|center|]][[Image:Error_selector_diagrams_B.JPG|frame|center|'''Figure 7''': possible diagrams for an error selector that detects warnings]]

These VIs execute about 5 times faster than the '''Merge Errors.vi''' (LabVIEW 7.0), even with normal priority execution. ('''Merge Errors.vi''' uses the “subroutine” priority.) Inputs to selector terminals in the first and second diagrams are passed to “error” for the cases not shown. Otherwise, “error 1” is checked for nonzero “code” since neither cluster has “status” true. The last approach uses the Max & Min function in Compare Aggregates mode to order inputs. If just one of these clusters has “status” true, that input will be the “max” output since true > false. However, this output must be checked for “status” true or “code” nonzero to determine selection.
--[[User:wevanarsdale|wevanarsdale]] 21:18, 3 May 2007 (CDT)

== Error Handling ==

Every LabVIEW programmer has their own approach to handling errors. In fact, those with multiple personalities probably have several different approaches to handling errors. As an example, consider the producer-consumer diagram shown in '''Figure 8'''.

[[Image:Producer-consumer.PNG|center|thumb|600px|'''Figure 8''': producer-consumer diagram with error handling in the top loop]]

The “event loop” (bottom) produces enumerated commands that are processed by the “cmd loop” (top). The outer case structure in the top loop traps for errors that are placed on the lower shift register. The corresponding error case (not shown) allows error handling by “code” with different methods of notification. For example, a user interface application based on this design pattern might employ the '''General Error Handler.vi''' shown in '''Figure 3''' to display a dialog for particular errors. However, this method would not work for applications that run continuously without user interaction.

For continuously running applications, an error dialog (or any other kind of dialog for that matter) would disrupt execution, causing data loss or some other event you are being paid to avoid. Logging error information to file is a useful notification method for such applications. This approach requires an error description, which is provided by the '''Error Code Database.vi''' (see '''Figure 9''') for specified error codes in LabVIEW.

[[Image:Error_code_database_connector.jpg|frame|center|'''Figure 9''': connector for the '''Error Code Database.vi''']]

This locked VI, located in the library <labview\vi.lib\Utility\error.llb>, is easily found as a subVI of the '''General Error Handler.vi'''. You would have to extend this database to handle user defined error codes and provide some type of error log. For example, some Windows applications log errors to the '''Event Viewer''' (right-click on '''My Computer''' and select '''Manage''' from the popup menu) shown in '''Figure 10''' and '''Figure 11'''.

[[Image:Event_viewer.JPG|frame|center|'''Figure 10''': '''Event Viewer''' in Windows]]
[[Image:Event_properties.jpg|frame|center|'''Figure 11''':'''Event Properties''' in Windows]]

The '''eventcreate''' command can be used in Windows to log events to this application. A VI [[log event error]] for logging errors to the '''Event Viewer''' should available soon.
--[[User:wevanarsdale|wevanarsdale]] 21:17, 3 May 2007 (CDT)

User:Smercer

2007-05-01T20:21:38Z

Smercer:

A.K.A. Aristos Queue

{| class="wikitable" style="margin: 1em auto 1em auto"
|- align="center"
|{{NI Employee}}
|- align="center"
|{{LAVA Premium Member}}
|}

User:Smercer

2007-05-01T20:21:10Z

Smercer: New page: {| class="wikitable" style="margin: 1em auto 1em auto" |- align="center" |{{NI Employee}} |- align="center" |{{LAVA Premium Member}} |}

{| class="wikitable" style="margin: 1em auto 1em auto"
|- align="center"
|{{NI Employee}}
|- align="center"
|{{LAVA Premium Member}}
|}

Development Environment

2007-04-25T06:02:51Z

Smercer:

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

====Pages here:====
*[[How to do Menu Launch VIs]]
*[[Most Recently Used Folders in LV8.20]]
*[[LabVIEW configuration file]] << info about how to edit the config file on various platforms
*[[LabVIEW ini File]] << info about why to edit the config file
*[[LabVIEW ini Settings]] << info about options you have when editing the config file
*[[LLB]]
*[[Multiple Instances of LabVIEW]]
*[[VI Icons]]
*[[Insane Objects]]

Insane Objects

2007-04-22T15:48:25Z

Smercer:

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 LV 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 we expect it to be in. Most of the time these errors are not fatal -- we simply put the object in the state we do 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 we checked and it was good and the time it became insane.

The insane object messages are something we work on with each version of LV. 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 LV 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 our 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]] ''('''NOTE:''' On Mac and Linux, the config tokens are case sensitive. I *think* the correct capitalization is given here, but if it doesn't work, try some variations.)''
* Open your VI
* In LV7.1 and earlier: press CTRL+SHIFT+D; In LV8.0 and later, 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.

Insane Objects

2007-04-22T15:46:16Z

Smercer: /* Using Heap Peek */

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 LV 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 we expect it to be in. Most of the time these errors are not fatal -- we simply put the object in the state we do 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 we checked and it was good and the time it became insane.

The insane object messages are something we work on with each version of LV. 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 LV 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 our 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)

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]] ''('''NOTE:''' On Mac and Linux, the config tokens are case sensitive. I *think* the correct capitalization is given here, but if it doesn't work, try some variations.)''
* Open your VI
* In LV7.1 and earlier: press CTRL+SHIFT+D; In LV8.0 and later, 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.

Insane Objects

2007-04-22T15:44:55Z

Smercer: /* Using Heap Peek */

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 LV 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 we expect it to be in. Most of the time these errors are not fatal -- we simply put the object in the state we do 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 we checked and it was good and the time it became insane.

The insane object messages are something we work on with each version of LV. 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 LV 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 our 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)

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 ''('''NOTE:''' On Mac and Linux, the config tokens are case sensitive. I *think* the correct capitalization is given here, but if it doesn't work, try some variations.)''
* Open your VI
* In LV7.1 and earlier: press CTRL+SHIFT+D; In LV8.0 and later, 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.

Insane Objects

2007-04-22T15:44:45Z

Smercer:

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 LV 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 we expect it to be in. Most of the time these errors are not fatal -- we simply put the object in the state we do 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 we checked and it was good and the time it became insane.

The insane object messages are something we work on with each version of LV. 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 LV 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 our 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)

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 "44" 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 ''('''NOTE:''' On Mac and Linux, the config tokens are case sensitive. I *think* the correct capitalization is given here, but if it doesn't work, try some variations.)''
* Open your VI
* In LV7.1 and earlier: press CTRL+SHIFT+D; In LV8.0 and later, 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.

Insane Objects

2007-04-22T15:38:07Z

Smercer: /* Using Heap Peek */

Firstly, there is no need to necessarily report this to [[NI]], as they do know about insane objects. Secondly they are NOT just bugs, insane objects can be generated as part of the LabVIEW verification process.

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 we expect it to be in. Most of the time these errors are not fatal -- we simply put the object in the state we do 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 we checked and it was good and the time it became insane.

The insane object messages are something we work on with each version of LV. 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 LV that has a bug -- a fact of life unfortunately for the foreseeable future. If you get such a message, it is good to check the known bugs of LV at ni.com and if the particular insanity in your dialog is not listed, report the insanity to NI technical support.

The cryptic nature of the message can be deciphered as follows:
Insane object at FPHP+44 in "name.vi": {dsitem} 0x400: Panel (FPSC)
* FPHP -- this will be either FP or BD for "front panel heap" or "block diagram heap"
* 44 -- this is a number indicating which object
* name.vi -- which VI had the insanity
* {dsitem} 0x400 -- really only meaningful if you know how our 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)

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 "44" 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 ''('''NOTE:''' On Mac and Linux, the config tokens are case sensitive. I *think* the correct capitalization is given here, but if it doesn't work, try some variations.)''
* Open your VI
* In LV7.1 and earlier: press CTRL+SHIFT+D; In LV8.0 and later, 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.

Graphical Object-Oriented Programming

2007-04-13T13:25:27Z

Smercer: /* Pages Here: */

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

Graphical Object-Oriented Programming

2007-04-13T13:25:10Z

Smercer:

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

Graphical Object-Oriented Programming

2007-04-13T13:22:17Z

Smercer:

Graphical Object-Oriented Programming

2007-04-13T13:22:00Z

Smercer:

Graphical Object-Oriented Programming

2007-04-13T13:19:18Z

Smercer: Add summary of GOOP vs LabVOOP

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]]
*[[LabVOOP - LabVIEW Object-Oriented Programming (aka LVOOP)]]

Graphical Object-Oriented Programming

2007-04-13T13:14:21Z

Smercer:

This is the Portal for GOOP. GOOP stands for Graphical Object Oriented Programming.

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

Home

2007-04-13T13:13:36Z

Smercer: Change title "GOOP" to "GOOP and LabVOOP"

<div style="text-align:center;font-size:200%;border:none;margin: 0;padding:.5em;color:#000">Welcome to the LabVIEWTM Wiki</div>
<div style="text-align:center;font-size: 95%">The free [[LabVIEW]] information resource that anyone can edit.</div>
<div style="text-align:center;font-size: 95%">Hosted by [[LAVA]] (LabVIEW Advanced Virtual Architects).</div>
<div id="articlecount" style="width:100%;text-align:center;font-size:85%;">We have [[Special:Statistics|{{NUMBEROFARTICLES}}]] articles</div>
{|
||
*[[Portal:XNodes|XNodes]]
*[[Portal:LabVIEW FAQ|LabVIEW FAQ]]
*[[Portal:Development Environment|Development Environment]]
*[[Portal:Code Distribution|Code Distribution]]
*[[Portal:GOOP|GOOP and LabVOOP]]
||
*[[Portal:Application Design & Architecture|Application Design & Architecture]]
*[[Portal:External Code|External Code]]
*[[Portal:Database|Database]]
*[[Portal:User Interface|User Interface]]
||
*[[Portal:Internet|Internet]]
*[[Portal:Getting Started|Getting Started]]
*[[Portal:Hardware|Hardware]]
*[[Other Pages]]
|}
{|style="border-spacing:8px;width:100%;padding-left: 0px"
|class="MainPageBG" style="width:30%;border:1px solid #cef2e0;background-color:#f5fffa;vertical-align:top;color:#000"|
{|width="100%" cellpadding="1" cellspacing="1" style="vertical-align:top;background-color:#f5fffa"
! <h2 style="margin:0;background-color:#cef2e0;font-size:120%;font-weight:bold;border:1px solid #a3bfb1;text-align:left;color:#000;padding:0.2em 0.4em;">Navigation</h2>
|-
|style="color:#000"|{{Main Page/Navigation Box}}
|-
! <h2 style="margin:0;background:#cef2e0;font-size:120%;font-weight:bold;border:1px solid #a3bfb1;text-align:left;color:#000;padding:0.2em 0.4em;">Wiki Editing</h2>
|-
|style="color:#000"|{{Main Page/Wiki Editing}}
|-
|}

|class="MainPageBG" style="width:100%;border:1px solid #cedff2;background-color:#f5faff;vertical-align:top"|
{| width="100%" cellpadding="1" cellspacing="1" style="vertical-align:top;background-color:#f5faff"
! <h2 style="margin:0;background-color:#cedff2;font-size:120%;font-weight:bold;border:1px solid #a3b0bf;text-align:left;color:#000;padding:0.2em 0.4em;">Featured Articles</h2>
|-
|style="color:#000"|{{Main Page/Featured Articles}}
|-
! <h2 style="margin:0;background:#cedff2;font-size:120%;font-weight:bold;border:1px solid #a3b0bf;text-align:left;color:#000;padding:0.2em 0.4em;">News & Work in Progress</h2>
|-
|style="color:#000"|{{Main Page/Work in Progress}}
|-
|}
|}

== LabVIEW Wiki Sister Sites ==
*'''[http://forums.lavag.org LAVA Forums]''': Independent, community forums where veteran LabVIEW users and NI employees congregate and discuss medium to advanced LabVIEW programming techniques.
*'''[http://forums.lavag.org/downloads.html LAVA Code Repository]''': A collection of peer reviewed LabVIEW code submitted by the LAVA members and organized by category.

__NOTOC__ __NOEDITSECTION__