LabVIEW Wiki - User contributions [en]

List of acronyms

2013-05-17T13:00:41Z

Daklu: added AOD, AOP, and EIP

Acronyms and abbreviations:

* A/D - Analog/Digital
* ADatP - Automated Data Processing
* AKA - Also Known As
* ANSI - American National Standards Institute
* AOD - Actor-Oriented Design
* AOP - Actor-Oriented Programming
* 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.
* CCT - [[Code Capture Tool]] 
* 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
* EIP - [http://sine.ni.com/nips/cds/view/p/lang/en/nid/209676 Ethernet/IP]
* 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
* GUI - Graphical User Interface
* GUID - Globally Unique IDentifier
* 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 (pronounced "el-voop"); see also GOOP and LabVOOP
* LQTM - Laughing Quietly To Myself
* MAX - [[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

[[Category:Lists]]

[[Category:Lists]]

Mercurial

2013-05-17T12:46:42Z

Daklu: /* Configure */

= Introduction =

{{TOCright}}[[Image:Logo.Mercurial.png|right]]

Mercurial is a [[Source Code Control|Source Code Control]] system by Selenic, it's key feature is the distributed nature of the system. This means that changes (commits) are stored in a local repository, which can be sent (pushed) to a central repository and which can be downloaded (pulled) by others.

= Getting started =

Joel Spolsky has written a How-To and Why-To page called [http://Www.hginit.com HG init] (hg is the chemical symbol for Mercury).

= Configuration =

Mercurial stores it's setting in a file called 'hgrc' inside a hidden folder '.hg'

== Setting up LVMerge ==

[http://zone.ni.com/reference/en-XX/help/371361F-01/lvhowto/configmerge_thirdparty/ LVMerge] can be used by Mercurial as a Merge tool. Add the following text to the hgrc file:
<pre>[merge-tools]
LVMerge.args = $base $other $local $output
LVMerge.executable = C:\Program Files\National Instruments\Shared\LabVIEW Merge\LVMerge.exe
LVMerge.gui = True
LVMerge.binary = True
[merge-patterns]
**.vi = LVMerge
**.ctl = LVMerge
**.lvclass = LVMerge
**.xctl = LVMerge
**.lvlib =LVMerge
</pre>

You can now use TortoiseHG to perfrom a merge ([[Merge with TortoiseHG|How-To]])

[[Category:SCC]]

== Setting up LVDiff ==

[http://meta-diff.sourceforge.net/ LVDiff] is a software package that uses the built in diff-functionality from LabVIEW to do command line based LVDiffs.

=== Download ===

First thing is to [http://meta-diff.sourceforge.net/ download] LVDiff, copy the contents of the zip-file to a location where you have writing priviliges (lvdiff uses a local ini file). 
Alternative: Installer from [http://decibel.ni.com/content/groups/mercurial NI Community Mercurial User Group]

=== Adjust ===

Then you need to open up the lvdiff.vi and implement these changes.

[[Image:Lvdiffcopy.png]]

This snippet (the actual code inside lvdiff copy is shown) tests if the filenames are the same and if that's the case it calls a VI called lvdiffcopy, which creates a copy of the file2.
For LabVIEW 2011 (and up) a patch file is available, use this to replace lvdiff.vi in the lvdiff installer folder[[File:Lvdiff_2011_patch.vi|lvdiff 2011 patch]].

=== Configure ===

To be able to select lvdiff as the diff tool you need to add the following settings to the [merge-tools] section of the hgrc configuration file:
<pre>lvdiff.diffargs = $child $parent
lvdiff.executable =C:\Program Files\lvdiff\lvdiff.exe
lvdiff.gui = True
lvdiff.binary = True
</pre>

If you are using TortoiseHg 1.0 or later, you can add a [diff-patterns] section to your hgrc file, analogous to the merge-patterns section mentioned above. This will enable automatic selection of the visual diff tool (see [http://tortoisehg.bitbucket.org/manual/1.0/common.html#word-diffs]):
<pre>
[diff-patterns]
**.vi = lvdiff
**.ctl = lvdiff
**.lvclass = lvdiff
**.xctl = lvdiff
**.lvlib = lvdiff
</pre>

=== Start LVDiff ===

You can start lvdiff in TorsoiseHg in the 'commit' dialog with right-click and 'Visual Diff':

[[Image:StartVisualDiff.png]]

In the following dialog, select 'LVDiff' and double click on the VI to diff:

[[Image:HG_LVDIffStart.png]]

After this LVdiff will launch LabVIEW and both VI (current and committed) will be compared.

== Ignoring files ==

Mercurial stores general ignore patterns in a file called '.hgignore' in the repository root, so you can add the patterns to the repository. I use the following patterns
<pre>.ogp$
/built*$
/build*$
.lvlps$
.aliases$
</pre>

=== Globally ignoring files ===
If you're using TortoiseHG you can use a global ignore file, by adding the following in your %profile%\mercurial.ini file:
<pre>
[ui]
...
ignore = %userprofile%\.hgignore
...
</pre>
Next to the mercurial.ini file you create the reference .hgignore file with the contents of your choice ([http://programmer.brettveenstra.com/2010/02/27/mercurial-on-windows-tip-global-ignore-file/ source]).

= Performing a merge =

The following conditions needs to be true to be able to perform a merge:

*All local changes needs to be commited (hg st should only show ?)
*A changeset is pushed by another user to the central repository
*The other changeset is not yet pulled

The merge will try to detect the differences and call LVMerge if necesarry, LVmerge will show four VIs:

*Base, the base VI which was present in the changeset that is the same on both repositories
*Mine, local commited VI
*Their, remote VI with edits from the other user

These are not editable.

*Resulting, this is the VI that will be stored to disc after the merge finalizes. This file can be edited by the user

For each diff LVMerge will give options to use either, 'base', 'mine' or 'their' code.

After the merge the code should be committed and pushed.

Most Mercurial Clients will show a graph with the following layout:

[[Image:MergeTrackHG.png|border]]

Here's the same graph from the 'other' user, which actually performed the merge:

[[Image:MergeTrackHG_Other.png|border]]

Here you see the opposite actions, two changesets in the local repo and one in the remote. Only difference is the moment of branching.

= Mercurial clients =

On Windows[[Image:Logo.Windows.png]], Mac[[Image:Logo.Mac.png]] and  Linux [[Image:Logo.Linux.png]], there is a command line client called 'hg'. On windows there is a context menu tool called [http://tortoisehg.bitbucket.org TortoiseHG] based on the popular TortoiseSVN and TortoiseCVS tools

= External Links =

*[http://mercurial.selenic.com Official website]
*[http://www.hginit.com HG Init]
*[http://hgbook.red-bean.com/ Mercurial: The Definitive Guide]
*[http://redline6561.livejournal.com/362393.html Setting Up Mercurial with Apache]
*[http://kiln.stackexchange.com Kiln / Mercurial Knowledge site]
*[http://decibel.ni.com/content/groups/mercurial NI Community Mercurial User Group]

[[Category:SCC]]
[[Category:SCC]]

[[Category:SCC]]
[[Category:SCC]]

LabVIEW object-oriented programming FAQ

2012-03-16T20:56:48Z

Daklu: /* What are the differences between public, protected, and private class members? */

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

In Object-Oriented Programming terms these generally mean:

A private feature (UML abbreviation -) is accessible only from the defining class. A public feature (+) is accessible from outside the class. A protected feature (#) is (in C++, for example) accessible from the defining class and any of its child classes. The UML also has an abbreviation for package (~) visibility. The exact meaning of the different visibilities varies among different programming languages.

In 2009 LabVIEW introduced ''Community'' scoping to classes (and other project libraries.) Community scoped items are the same as private items, except they are visible to external entities specifically designated as "Friends of This Library." Some important things to keep in mind with community scoping are:

* Friendship is a one-way permission granted by a class giving external entities access to community scoped items. If Class A makes Class B a friend, Class B has access to Class A's community scoped items, but Class A does not have access to Class B's community scoped items.

* Child classes are not automatically granted access to a parent's community scoped items.

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

== My LVOOP class control has a black border, what does that mean ? ==

A LVOOP class has a default value that is determined by the default value of the private data control in the .lvclass file. However, a control on a vi front panel, or a constant on a block diagram can also have a default value that is different from the default data for the class as a whole. When this happens the control (or constant) is given a black border. It can just as easily be a non-default value of the class itself, so if your private data cluster contains a numeric whose default value is 5, this control may have the numeric with a default value of 6.

When there is a class heirarchy, it is possible for a parent class method to process an instance of a child class. Similarily, it is possible to set the default value of a parent class control or constant to be an instance of a child class. This will also result in a black border around the parent class control or constant. When this happens with a member vi of the parent class, the parent class becomes dependent on the child class in addition to the normal dependency of the child on the parent. This can be confusing and awkward to locate.

To change the default value of a class control run a VI such that a non-default value ends up in an indicator, then do one of the following: A) Right click on that indicator and choose "Make Current Value Default" or B) Right click on that indicator and choose "Change to Constant" (the current value of a control/indicator always becomes the value of the constant)

[[Category:GOOP]]

Loading VIs

2011-04-24T18:49:21Z

Daklu: moved Loading VIs to Loading vis: Improperly used capitalization

{{wikify}}
==Flowchart==

This is a simplified flow chart showing LabVIEW's decision tree when loading a vi into memory from disk. 
Note this diagram applies to LabVIEW 2010 when compiled code is not separated from source code. Other versions may be slightly different. 
[[Image:LoadingLabviewVI.png|center|thumb|500px]]
==Discussion==
'''Aristos Queue''' 

I'm going to try to explain some details of loading a VI. What happens during load depends upon what happened when the VI was last saved, so let's start there. 
 

A good VI is one that has an unbroken run arrow. A broken VI is one that has a red X next to its name in the Error List Window because that VI itself has some problem. A bad VI is one that is listed in the Error List Window because some other VI/library that it depends upon is broken. There's a special case involving typedefs, poly VIs, and global VIs that are in the middle of being edited but are at the moment valid typedefs (i.e., they would not be broken if user did Apply Changes). Such VIs have the pencil icon next to their name in the Error List Window. Those VIs are good, but VIs that use them are bad. 
 
If a VI was good, then we can compile the VI, meaning we can generate the assembly instructions for that VI to run. If a VI is good, when we save, we compile the VI, and we save the compiled code as part of the VI. 
 

If a VI was broken or bad then we can't compile it, so when we save such a VI, we obviously can't save the compiled code. However, a VI might have been good, been compiled, and then become bad without any changes to its own block diagram. In that case, we already have the compiled code for the VI, and so we'll save that with the VI. There's also the special case of a VI that is broken only because it is missing subVIs. We may already have compiled code for such a VI, and so we'll keep that code around if we are asked to save again. (In the case of typedefs, they do have compiled code. They carry the instructions for copying and comparing their data. PolyVIs have no code. I'm not sure about global VIs.) 
 
Ok. That covers save (or, rather, it covers enough of save that we can now talk about load). 
 
When we use the phrase "a VI is in loaded into memory", we really mean, "some portion of the VI's file is in memory in a way that other VIs may link to it and it can be edited and/or executed." If you use the VI Server method "Read Linker Info", that reads the connection information of a VI without loading the VI -- so although we opened the VI file and read some data out of it, we didn't properly make the VI available to the editor and execution system. Same when the palettes load -- they read the icons out of the VIs in the directories, without actually loading the VIs. 
 
There are N parts of a VI, where N is a number I don't remember right now. But for the purposes of this conversation, we can really think of there being just three parts: the front panel (FP), the block diagram (BD) and something I'm going to call "the linker/code block" (LC). That's not a term you'll find anywhere else because I just made it up. The LC is all the stuff that makes a VI be a VI in memory, including: 

*the linker information (the list of other LV files upon which this VI depends)
*the identity of the VI (which library owns this VI)
*the compiled assembly code (unless the VI is broken, in which case there is no compiled assembly code)
*and probably some other stuff not relevant to this conversation.
 
In the development environment, whenever you say File >> Open and load a top-level VI, the LC and FP load into memory. If the VI was last saved as bad or broken or if it turns out to be bad/broken after it finishes loading its dependencies, then the BD also loads into memory. If that VI has subVIs, the LC for all those subVIs load into memory. The FP loads if the subVI is considered necessary (see my earlier post in this thread for things that make that necessary). Both the FP and BD are loaded if those subVIs were saved bad or broken OR if they turn out to be bad/broken once dependencies are loaded. 

 
For all VIs, if an edit is needed during load (say, a subVI conpane changed while the caller was not in memory, or a typedef needs to update, or LV version mutation, or updating the path to a subVI), both FP and BD load. 
 

In the runtime engine, the BD never loads. Obviously, the BD doesn't load if the VI was saved without a block diagram. In a real-time system, neither the FP nor the BD ever load. 

 
After loading the VI (and all its dependencies), if the compiled code is missing and the block diagram is loaded and the VI is not broken/bad, then LV will go ahead and compile the VI and put a docmod on the VI (the little asterisk that means "this VI has unsaved changes"). 
 
The FP and BD will eagerly unload as soon as the reasons for them staying in memory are dealt with. So if you fix a broken VI and then save the changes, FP and BD will unload unless the windows are open or the FP is necessary for the VI. 
 
If you want proof that the diagram loads independently, try this: Save a caller VI and its subVI. Open the caller VI. In the operating system, copy the subVI file on disk to a temp location. Back in LV, open and modify the subVI's diagram. Save the subVI and close the panel and diagram (keep the caller VI open). Now copy the temp file over the subVI file. Now open the block diagram of the subVI again. You'll get one of the more interesting dialogs that LV has to offer, noting that the diagram saved doesn't match the VI in memory and you can either choose not reload the diagram or do load the diagram which will recompile your VI for the new diagram code. If you didn't save the subVI (meaning you choose Defer Decision on the Save Changes dialog), then the diagram is already in memory and I'm pretty sure you won't get that dialog because LV doesn't bother to check disk for stuff it already has loaded. 
'''Daklu''' 
Say you're editing a typedef cluster and all the dependent LC blocks are loaded, but their FP/BD's are not. When the typedef's changes are applied, LV finds all the dependent vis, loads the block diagrams, and makes the necessary edits transparently to the user. (i.e. Without opening windows to the block diagrams.) Since the dependent vis are now dirty their FPs are also loaded into memory, forcing data copies for those FP controls when the app is executed, even though the FP windows aren't open, right? 
'''Aristos Queue''' 
Yes. All that is correct. 
There's another variant -- the FP could be the thing hosting the typedef, and when the typedef changes, LV will load both the FP and the BD into memory in order to update the FP. The reason the BD loads is because the VI has to recompile to deal with the typedef change. 
'''Daklu''' 
Does this behavior change when separating compiled code in LV10? My initial thought is that LV ought to be able to recompile the dependent vi's source code and remove the FP/BD from memory without marking them dirty, and simply wait until the user opens that vi before giving it a dirty dot. But that could lead to confusing behavior when multiple typedef changes are applied sequentially (like what happens when a vi's LC block isn't loaded when changes are applied) so I'm guessing no. 
'''Aristos Queue''' 
I know that it does change. I do not know how dramatic the change is. Your analysis sounds completely plausible, but I haven't really stayed up-to-date on the source-obj splitting. 
'''Daklu''' 
The one open question I still don't have an answer to is why does the FP have to be loaded when the BD loaded? 
'''Aristos Queue''' 
Up until LV 2009, the default values of controls were stored as part of the front panel, so any time the VI wanted to recompile, the panel was actually necessary to generate the code. Nowadays the default values have been moved out of the panel, and we are inching closer to the day when the recompile could happen with just the diagram without the panel, but there are 25 years worth of code that assumes "if I have the diagram then I know the panel is in memory, so I don't have to test for NULL". It's a low priority refactoring that is ooching forward.

==External Links==
Original [http://lavag.org/topic/7015-using-lv-class-vs-passing-cluster/page__view__findpost__p__82679 LAVA] discussion.

[[Category:LabVIEW internals]]

Loading VIs

2011-04-24T18:47:32Z

Daklu: Added note to flowchart indicating it only applies to 2010.

Loading VIs

2011-04-24T18:43:10Z

Daklu: Cleaned up formatting.

{{wikify}}
==Flowchart==

This is a simplified flow chart showing how Labview loads a vi into memory from disk. 
[[Image:LoadingLabviewVI.png|center|thumb|500px|Loading VI]]
==Discussion==
'''Aristos Queue''' 

I'm going to try to explain some details of loading a VI. What happens during load depends upon what happened when the VI was last saved, so let's start there. 
 

A good VI is one that has an unbroken run arrow. A broken VI is one that has a red X next to its name in the Error List Window because that VI itself has some problem. A bad VI is one that is listed in the Error List Window because some other VI/library that it depends upon is broken. There's a special case involving typedefs, poly VIs, and global VIs that are in the middle of being edited but are at the moment valid typedefs (i.e., they would not be broken if user did Apply Changes). Such VIs have the pencil icon next to their name in the Error List Window. Those VIs are good, but VIs that use them are bad. 
 
If a VI was good, then we can compile the VI, meaning we can generate the assembly instructions for that VI to run. If a VI is good, when we save, we compile the VI, and we save the compiled code as part of the VI. 
 

If a VI was broken or bad then we can't compile it, so when we save such a VI, we obviously can't save the compiled code. However, a VI might have been good, been compiled, and then become bad without any changes to its own block diagram. In that case, we already have the compiled code for the VI, and so we'll save that with the VI. There's also the special case of a VI that is broken only because it is missing subVIs. We may already have compiled code for such a VI, and so we'll keep that code around if we are asked to save again. (In the case of typedefs, they do have compiled code. They carry the instructions for copying and comparing their data. PolyVIs have no code. I'm not sure about global VIs.) 
 
Ok. That covers save (or, rather, it covers enough of save that we can now talk about load). 
 
When we use the phrase "a VI is in loaded into memory", we really mean, "some portion of the VI's file is in memory in a way that other VIs may link to it and it can be edited and/or executed." If you use the VI Server method "Read Linker Info", that reads the connection information of a VI without loading the VI -- so although we opened the VI file and read some data out of it, we didn't properly make the VI available to the editor and execution system. Same when the palettes load -- they read the icons out of the VIs in the directories, without actually loading the VIs. 
 
There are N parts of a VI, where N is a number I don't remember right now. But for the purposes of this conversation, we can really think of there being just three parts: the front panel (FP), the block diagram (BD) and something I'm going to call "the linker/code block" (LC). That's not a term you'll find anywhere else because I just made it up. The LC is all the stuff that makes a VI be a VI in memory, including: 

*the linker information (the list of other LV files upon which this VI depends)
*the identity of the VI (which library owns this VI)
*the compiled assembly code (unless the VI is broken, in which case there is no compiled assembly code)
*and probably some other stuff not relevant to this conversation.
 
In the development environment, whenever you say File >> Open and load a top-level VI, the LC and FP load into memory. If the VI was last saved as bad or broken or if it turns out to be bad/broken after it finishes loading its dependencies, then the BD also loads into memory. If that VI has subVIs, the LC for all those subVIs load into memory. The FP loads if the subVI is considered necessary (see my earlier post in this thread for things that make that necessary). Both the FP and BD are loaded if those subVIs were saved bad or broken OR if they turn out to be bad/broken once dependencies are loaded. 

 
For all VIs, if an edit is needed during load (say, a subVI conpane changed while the caller was not in memory, or a typedef needs to update, or LV version mutation, or updating the path to a subVI), both FP and BD load. 
 

In the runtime engine, the BD never loads. Obviously, the BD doesn't load if the VI was saved without a block diagram. In a real-time system, neither the FP nor the BD ever load. 

 
After loading the VI (and all its dependencies), if the compiled code is missing and the block diagram is loaded and the VI is not broken/bad, then LV will go ahead and compile the VI and put a docmod on the VI (the little asterisk that means "this VI has unsaved changes"). 
 
The FP and BD will eagerly unload as soon as the reasons for them staying in memory are dealt with. So if you fix a broken VI and then save the changes, FP and BD will unload unless the windows are open or the FP is necessary for the VI. 
 
If you want proof that the diagram loads independently, try this: Save a caller VI and its subVI. Open the caller VI. In the operating system, copy the subVI file on disk to a temp location. Back in LV, open and modify the subVI's diagram. Save the subVI and close the panel and diagram (keep the caller VI open). Now copy the temp file over the subVI file. Now open the block diagram of the subVI again. You'll get one of the more interesting dialogs that LV has to offer, noting that the diagram saved doesn't match the VI in memory and you can either choose not reload the diagram or do load the diagram which will recompile your VI for the new diagram code. If you didn't save the subVI (meaning you choose Defer Decision on the Save Changes dialog), then the diagram is already in memory and I'm pretty sure you won't get that dialog because LV doesn't bother to check disk for stuff it already has loaded. 
'''Daklu''' 
Say you're editing a typedef cluster and all the dependent LC blocks are loaded, but their FP/BD's are not. When the typedef's changes are applied, LV finds all the dependent vis, loads the block diagrams, and makes the necessary edits transparently to the user. (i.e. Without opening windows to the block diagrams.) Since the dependent vis are now dirty their FPs are also loaded into memory, forcing data copies for those FP controls when the app is executed, even though the FP windows aren't open, right? 
'''Aristos Queue''' 
Yes. All that is correct. 
There's another variant -- the FP could be the thing hosting the typedef, and when the typedef changes, LV will load both the FP and the BD into memory in order to update the FP. The reason the BD loads is because the VI has to recompile to deal with the typedef change. 
'''Daklu''' 
Does this behavior change when separating compiled code in LV10? My initial thought is that LV ought to be able to recompile the dependent vi's source code and remove the FP/BD from memory without marking them dirty, and simply wait until the user opens that vi before giving it a dirty dot. But that could lead to confusing behavior when multiple typedef changes are applied sequentially (like what happens when a vi's LC block isn't loaded when changes are applied) so I'm guessing no. 
'''Aristos Queue''' 
I know that it does change. I do not know how dramatic the change is. Your analysis sounds completely plausible, but I haven't really stayed up-to-date on the source-obj splitting. 
'''Daklu''' 
The one open question I still don't have an answer to is why does the FP have to be loaded when the BD loaded? 
'''Aristos Queue''' 
Up until LV 2009, the default values of controls were stored as part of the front panel, so any time the VI wanted to recompile, the panel was actually necessary to generate the code. Nowadays the default values have been moved out of the panel, and we are inching closer to the day when the recompile could happen with just the diagram without the panel, but there are 25 years worth of code that assumes "if I have the diagram then I know the panel is in memory, so I don't have to test for NULL". It's a low priority refactoring that is ooching forward.

==External Links==
Original [http://lavag.org/topic/7015-using-lv-class-vs-passing-cluster/page__view__findpost__p__82679 LAVA] discussion.

[[Category:LabVIEW internals]]

Loading VIs

2011-04-24T18:25:48Z

Daklu:

{{Underconstruction}}
{{inuse}}
==Flowchart==

This is a simplified flow chart showing how Labview loads a vi into memory from disk. 
[[Image:LoadingLabviewVI.png|center|thumb|500px|Loading VI]]
==Discussion==
'''Aristos Queue''' 

I'm going to try to explain some details of loading a VI. What happens during load depends upon what happened when the VI was last saved, so let's start there. 
 

A good VI is one that has an unbroken run arrow. A broken VI is one that has a red X next to its name in the Error List Window because that VI itself has some problem. A bad VI is one that is listed in the Error List Window because some other VI/library that it depends upon is broken. There's a special case involving typedefs, poly VIs, and global VIs that are in the middle of being edited but are at the moment valid typedefs (i.e., they would not be broken if user did Apply Changes). Such VIs have the pencil icon next to their name in the Error List Window. Those VIs are good, but VIs that use them are bad. 
 
If a VI was good, then we can compile the VI, meaning we can generate the assembly instructions for that VI to run. If a VI is good, when we save, we compile the VI, and we save the compiled code as part of the VI. 
 

If a VI was broken or bad then we can't compile it, so when we save such a VI, we obviously can't save the compiled code. However, a VI might have been good, been compiled, and then become bad without any changes to its own block diagram. In that case, we already have the compiled code for the VI, and so we'll save that with the VI. There's also the special case of a VI that is broken only because it is missing subVIs. We may already have compiled code for such a VI, and so we'll keep that code around if we are asked to save again. (In the case of typedefs, they do have compiled code. They carry the instructions for copying and comparing their data. PolyVIs have no code. I'm not sure about global VIs.) 
 
Ok. That covers save (or, rather, it covers enough of save that we can now talk about load). 
 
When we use the phrase "a VI is in loaded into memory", we really mean, "some portion of the VI's file is in memory in a way that other VIs may link to it and it can be edited and/or executed." If you use the VI Server method "Read Linker Info", that reads the connection information of a VI without loading the VI -- so although we opened the VI file and read some data out of it, we didn't properly make the VI available to the editor and execution system. Same when the palettes load -- they read the icons out of the VIs in the directories, without actually loading the VIs. 
 
There are N parts of a VI, where N is a number I don't remember right now. But for the purposes of this conversation, we can really think of there being just three parts: the front panel (FP), the block diagram (BD) and something I'm going to call "the linker/code block" (LC). That's not a term you'll find anywhere else because I just made it up. The LC is all the stuff that makes a VI be a VI in memory, including: 

*the linker information (the list of other LV files upon which this VI depends)
*the identity of the VI (which library owns this VI)
*the compiled assembly code (unless the VI is broken, in which case there is no compiled assembly code)
*and probably some other stuff not relevant to this conversation.
 
In the development environment, whenever you say File >> Open and load a top-level VI, the LC and FP load into memory. If the VI was last saved as bad or broken or if it turns out to be bad/broken after it finishes loading its dependencies, then the BD also loads into memory. If that VI has subVIs, the LC for all those subVIs load into memory. The FP loads if the subVI is considered necessary (see my earlier post in this thread for things that make that necessary). Both the FP and BD are loaded if those subVIs were saved bad or broken OR if they turn out to be bad/broken once dependencies are loaded. 

 
For all VIs, if an edit is needed during load (say, a subVI conpane changed while the caller was not in memory, or a typedef needs to update, or LV version mutation, or updating the path to a subVI), both FP and BD load. 
 

In the runtime engine, the BD never loads. Obviously, the BD doesn't load if the VI was saved without a block diagram. In a real-time system, neither the FP nor the BD ever load. 

 
After loading the VI (and all its dependencies), if the compiled code is missing and the block diagram is loaded and the VI is not broken/bad, then LV will go ahead and compile the VI and put a docmod on the VI (the little asterisk that means "this VI has unsaved changes"). 
 
The FP and BD will eagerly unload as soon as the reasons for them staying in memory are dealt with. So if you fix a broken VI and then save the changes, FP and BD will unload unless the windows are open or the FP is necessary for the VI. 
 
If you want proof that the diagram loads independently, try this: Save a caller VI and its subVI. Open the caller VI. In the operating system, copy the subVI file on disk to a temp location. Back in LV, open and modify the subVI's diagram. Save the subVI and close the panel and diagram (keep the caller VI open). Now copy the temp file over the subVI file. Now open the block diagram of the subVI again. You'll get one of the more interesting dialogs that LV has to offer, noting that the diagram saved doesn't match the VI in memory and you can either choose not reload the diagram or do load the diagram which will recompile your VI for the new diagram code. If you didn't save the subVI (meaning you choose Defer Decision on the Save Changes dialog), then the diagram is already in memory and I'm pretty sure you won't get that dialog because LV doesn't bother to check disk for stuff it already has loaded. 
'''Daklu''' 
Say you're editing a typedef cluster and all the dependent LC blocks are loaded, but their FP/BD's are not. When the typedef's changes are applied, LV finds all the dependent vis, loads the block diagrams, and makes the necessary edits transparently to the user. (i.e. Without opening windows to the block diagrams.) Since the dependent vis are now dirty their FPs are also loaded into memory, forcing data copies for those FP controls when the app is executed, even though the FP windows aren't open, right? 
'''Aristos Queue''' 
Yes. All that is correct. 
There's another variant -- the FP could be the thing hosting the typedef, and when the typedef changes, LV will load both the FP and the BD into memory in order to update the FP. The reason the BD loads is because the VI has to recompile to deal with the typedef change. 
'''Daklu''' 
Does this behavior change when separating compiled code in LV10? My initial thought is that LV ought to be able to recompile the dependent vi's source code and remove the FP/BD from memory without marking them dirty, and simply wait until the user opens that vi before giving it a dirty dot. But that could lead to confusing behavior when multiple typedef changes are applied sequentially (like what happens when a vi's LC block isn't loaded when changes are applied) so I'm guessing no. 
'''Aristos Queue''' 
I know that it does change. I do not know how dramatic the change is. Your analysis sounds completely plausible, but I haven't really stayed up-to-date on the source-obj splitting. 
'''Daklu''' 
The one open question I still don't have an answer to is why does the FP have to be loaded when the BD loaded? 
'''Aristos Queue''' 
Up until LV 2009, the default values of controls were stored as part of the front panel, so any time the VI wanted to recompile, the panel was actually necessary to generate the code. Nowadays the default values have been moved out of the panel, and we are inching closer to the day when the recompile could happen with just the diagram without the panel, but there are 25 years worth of code that assumes "if I have the diagram then I know the panel is in memory, so I don't have to test for NULL". It's a low priority refactoring that is ooching forward.

==External Links==
Original LAVA discussion. [http://lavag.org/topic/7015-using-lv-class-vs-passing-cluster/page__view__findpost__p__82679 Link]

Loading VIs

2011-04-24T18:03:49Z

Daklu:

{{Underconstruction}}
{{inuse}}
The information on this page is taken from [http://lavag.org/topic/7015-using-lv-class-vs-passing-cluster/page__view__findpost__p__82679 this] discussion on LAVA. 
 
----------
[[Image:LoadingLabviewVI.png|Loading VI]]
 
Aristos Queue: 
I'm going to try to explain some details of loading a VI. What happens during load depends upon what happened when the VI was last saved, so let's start there. 
 

A good VI is one that has an unbroken run arrow. A broken VI is one that has a red X next to its name in the Error List Window because that VI itself has some problem. A bad VI is one that is listed in the Error List Window because some other VI/library that it depends upon is broken. There's a special case involving typedefs, poly VIs, and global VIs that are in the middle of being edited but are at the moment valid typedefs (i.e., they would not be broken if user did Apply Changes). Such VIs have the pencil icon next to their name in the Error List Window. Those VIs are good, but VIs that use them are bad. 
 
If a VI was good, then we can compile the VI, meaning we can generate the assembly instructions for that VI to run. If a VI is good, when we save, we compile the VI, and we save the compiled code as part of the VI. 
 

If a VI was broken or bad then we can't compile it, so when we save such a VI, we obviously can't save the compiled code. However, a VI might have been good, been compiled, and then become bad without any changes to its own block diagram. In that case, we already have the compiled code for the VI, and so we'll save that with the VI. There's also the special case of a VI that is broken only because it is missing subVIs. We may already have compiled code for such a VI, and so we'll keep that code around if we are asked to save again. (In the case of typedefs, they do have compiled code. They carry the instructions for copying and comparing their data. PolyVIs have no code. I'm not sure about global VIs.) 
 
Ok. That covers save (or, rather, it covers enough of save that we can now talk about load). 
 
When we use the phrase "a VI is in loaded into memory", we really mean, "some portion of the VI's file is in memory in a way that other VIs may link to it and it can be edited and/or executed." If you use the VI Server method "Read Linker Info", that reads the connection information of a VI without
loading the VI -- so although we opened the VI file and read some data out of it, we didn't properly make the VI available to the editor and execution system. Same when the palettes load -- they read the icons out of the VIs in the directories, without actually loading the VIs. 
 
There are N parts of a VI, where N is a number I don't remember right now. But for the purposes of this conversation, we can really think of there being just three parts: the front panel (FP), the block diagram (BD) and something I'm going to call "the linker/code block" (LC). That's not a term you'll find anywhere else because I just made it up. The LC is all the stuff that makes a VI be a VI in memory, including: 

*the linker information (the list of other LV files upon which this VI depends)
*the identity of the VI (which library owns this VI)
*the compiled assembly code (unless the VI is broken, in which case there is no compiled assembly code)
*and probably some other stuff not relevant to this conversation.
 
In the development environment, whenever you say File >> Open and load a top-level VI, the LC and FP load into memory. If the VI was last saved as bad or broken or if it turns out to be bad/broken after it finishes loading its dependencies, then the BD also loads into memory. If that VI has subVIs, the LC for all those subVIs load into memory. The FP loads if the subVI is considered necessary (see my earlier post in this thread for things that make that necessary). Both the FP and BD are loaded if those subVIs were saved bad or broken OR if they turn out to be bad/broken once dependencies are loaded. 

 
For all VIs, if an edit is needed during load (say, a subVI conpane changed while the caller was not in memory, or a typedef needs to update, or LV version mutation, or updating the path to a subVI), both FP and BD load. 
 

In the runtime engine, the BD never loads. Obviously, the BD doesn't load if the VI was saved without a block diagram. In a real-time system, neither the FP nor the BD ever load. 

 
After loading the VI (and all its dependencies), if the compiled code is missing and the block diagram is loaded and the VI is not broken/bad, then LV will go ahead and compile the VI and put a docmod on the VI (the little asterisk that means "this VI has unsaved changes"). 
 
The FP and BD will eagerly unload as soon as the reasons for them staying in memory are dealt with. So if you fix a broken VI and then save the changes, FP and BD will unload unless the windows are open or the FP is necessary for the VI. 
 
If you want proof that the diagram loads independently, try this: Save a caller VI and its subVI. Open the caller VI. In the operating system, copy the subVI file on disk to a temp location. Back in LV, open and modify the subVI's diagram. Save the subVI and close the panel and diagram (keep the caller VI open). Now copy the temp file over the subVI file. Now open the block diagram of the subVI again. You'll get one of the more interesting dialogs that LV has to offer, noting that the diagram saved doesn't match the VI in memory and you can either choose not reload the diagram or do load the diagram which will recompile your VI for the new diagram code. If you didn't save the subVI (meaning you choose Defer Decision on the Save Changes dialog), then the diagram is already in memory and I'm pretty sure you won't get that dialog because LV doesn't bother to check disk for stuff it already has loaded. 

 
Daklu: 
Say you're editing a typedef cluster and all the dependent LC blocks are loaded, but their FP/BD's are not. When the typedef's changes are applied, LV finds all the dependent vis, loads the block diagrams, and makes the necessary edits transparently to the user. (i.e. Without opening windows to the block diagrams.) Since the dependent vis are now dirty their FPs are also loaded into memory, forcing data copies for those FP controls when the app is executed, even though the FP windows aren't open, right? 
Aristos Queue: 
Yes. All that is correct. 
There's another variant -- the FP could be the thing hosting the typedef, and when the typedef changes, LV will load both the FP and the BD into memory in order to update the FP. The reason the BD loads is because the VI has to recompile to deal with the typedef change. 
 
Daklu: 
Does this behavior change when separating compiled code in LV10? My initial thought is that LV ought to be able to recompile the dependent vi's source code and remove the FP/BD from memory without marking them dirty, and simply wait until the user opens that vi before giving it a dirty dot. But that could lead to confusing behavior when multiple typedef changes are applied sequentially (like what happens when a vi's LC block isn't loaded when changes are applied) so I'm guessing no. 
Aristos Queue: 
I know that it does change. I do not know how dramatic the change is. Your analysis sounds completely plausible, but I haven't really stayed up-to-date on the source-obj splitting. 

 
Daklu: 
The one open question I still don't have an answer to is why does the FP have to be loaded when the BD loaded? 
 
Aristos Queue: 
Up until LV 2009, the default values of controls were stored as part of the front panel, so any time the VI wanted to recompile, the panel was actually necessary to generate the code. Nowadays the default values have been moved out of the panel, and we are inching closer to the day when the recompile could happen with just the diagram without the panel, but there are 25 years worth of code that assumes "if I have the diagram then I know the panel is in memory, so I don't have to test for NULL". It's a low priority refactoring that is ooching forward.

File:LoadingLabviewVI.png

2011-04-24T18:02:01Z

Daklu: A flowchart showing Labview's decision tree when loading a vi from disk.

A flowchart showing Labview's decision tree when loading a vi from disk.

Loading VIs

2011-04-24T18:00:20Z

Daklu: Initial page creation

{{Underconstruction}}
The information on this page is taken from [http://lavag.org/topic/7015-using-lv-class-vs-passing-cluster/page__view__findpost__p__82679 this] discussion on LAVA. 
 
----------
[[Image:LoadingLabviewVI.png|Loading VI]]
 
Aristos Queue: 
I'm going to try to explain some details of loading a VI. What happens during load depends upon what happened when the VI was last saved, so let's start there. 
 

A good VI is one that has an unbroken run arrow. A broken VI is one that has a red X next to its name in the Error List Window because that VI itself has some problem. A bad VI is one that is listed in the Error List Window because some other VI/library that it depends upon is broken. There's a special case involving typedefs, poly VIs, and global VIs that are in the middle of being edited but are at the moment valid typedefs (i.e., they would not be broken if user did Apply Changes). Such VIs have the pencil icon next to their name in the Error List Window. Those VIs are good, but VIs that use them are bad. 
 
If a VI was good, then we can compile the VI, meaning we can generate the assembly instructions for that VI to run. If a VI is good, when we save, we compile the VI, and we save the compiled code as part of the VI. 
 

If a VI was broken or bad then we can't compile it, so when we save such a VI, we obviously can't save the compiled code. However, a VI might have been good, been compiled, and then become bad without any changes to its own block diagram. In that case, we already have the compiled code for the VI, and so we'll save that with the VI. There's also the special case of a VI that is broken only because it is missing subVIs. We may already have compiled code for such a VI, and so we'll keep that code around if we are asked to save again. (In the case of typedefs, they do have compiled code. They carry the instructions for copying and comparing their data. PolyVIs have no code. I'm not sure about global VIs.) 
 
Ok. That covers save (or, rather, it covers enough of save that we can now talk about load). 
 
When we use the phrase "a VI is in loaded into memory", we really mean, "some portion of the VI's file is in memory in a way that other VIs may link to it and it can be edited and/or executed." If you use the VI Server method "Read Linker Info", that reads the connection information of a VI without
loading the VI -- so although we opened the VI file and read some data out of it, we didn't properly make the VI available to the editor and execution system. Same when the palettes load -- they read the icons out of the VIs in the directories, without actually loading the VIs. 
 
There are N parts of a VI, where N is a number I don't remember right now. But for the purposes of this conversation, we can really think of there being just three parts: the front panel (FP), the block diagram (BD) and something I'm going to call "the linker/code block" (LC). That's not a term you'll find anywhere else because I just made it up. The LC is all the stuff that makes a VI be a VI in memory, including: 

*the linker information (the list of other LV files upon which this VI depends)
*the identity of the VI (which library owns this VI)
*the compiled assembly code (unless the VI is broken, in which case there is no compiled assembly code)
*and probably some other stuff not relevant to this conversation.
 
In the development environment, whenever you say File >> Open and load a top-level VI, the LC and FP load into memory. If the VI was last saved as bad or broken or if it turns out to be bad/broken after it finishes loading its dependencies, then the BD also loads into memory. If that VI has subVIs, the LC for all those subVIs load into memory. The FP loads if the subVI is considered necessary (see my earlier post in this thread for things that make that necessary). Both the FP and BD are loaded if those subVIs were saved bad or broken OR if they turn out to be bad/broken once dependencies are loaded. 

 
For all VIs, if an edit is needed during load (say, a subVI conpane changed while the caller was not in memory, or a typedef needs to update, or LV version mutation, or updating the path to a subVI), both FP and BD load. 
 

In the runtime engine, the BD never loads. Obviously, the BD doesn't load if the VI was saved without a block diagram. In a real-time system, neither the FP nor the BD ever load. 

 
After loading the VI (and all its dependencies), if the compiled code is missing and the block diagram is loaded and the VI is not broken/bad, then LV will go ahead and compile the VI and put a docmod on the VI (the little asterisk that means "this VI has unsaved changes"). 
 
The FP and BD will eagerly unload as soon as the reasons for them staying in memory are dealt with. So if you fix a broken VI and then save the changes, FP and BD will unload unless the windows are open or the FP is necessary for the VI. 
 
If you want proof that the diagram loads independently, try this: Save a caller VI and its subVI. Open the caller VI. In the operating system, copy the subVI file on disk to a temp location. Back in LV, open and modify the subVI's diagram. Save the subVI and close the panel and diagram (keep the caller VI open). Now copy the temp file over the subVI file. Now open the block diagram of the subVI again. You'll get one of the more interesting dialogs that LV has to offer, noting that the diagram saved doesn't match the VI in memory and you can either choose not reload the diagram or do load the diagram which will recompile your VI for the new diagram code. If you didn't save the subVI (meaning you choose Defer Decision on the Save Changes dialog), then the diagram is already in memory and I'm pretty sure you won't get that dialog because LV doesn't bother to check disk for stuff it already has loaded. 

 
Daklu: 
Say you're editing a typedef cluster and all the dependent LC blocks are loaded, but their FP/BD's are not. When the typedef's changes are applied, LV finds all the dependent vis, loads the block diagrams, and makes the necessary edits transparently to the user. (i.e. Without opening windows to the block diagrams.) Since the dependent vis are now dirty their FPs are also loaded into memory, forcing data copies for those FP controls when the app is executed, even though the FP windows aren't open, right? 
Aristos Queue: 
Yes. All that is correct. 
There's another variant -- the FP could be the thing hosting the typedef, and when the typedef changes, LV will load both the FP and the BD into memory in order to update the FP. The reason the BD loads is because the VI has to recompile to deal with the typedef change. 
 
Daklu: 
Does this behavior change when separating compiled code in LV10? My initial thought is that LV ought to be able to recompile the dependent vi's source code and remove the FP/BD from memory without marking them dirty, and simply wait until the user opens that vi before giving it a dirty dot. But that could lead to confusing behavior when multiple typedef changes are applied sequentially (like what happens when a vi's LC block isn't loaded when changes are applied) so I'm guessing no. 
Aristos Queue: 
I know that it does change. I do not know how dramatic the change is. Your analysis sounds completely plausible, but I haven't really stayed up-to-date on the source-obj splitting. 

 
Daklu: 
The one open question I still don't have an answer to is why does the FP have to be loaded when the BD loaded? 
 
Aristos Queue: 
Up until LV 2009, the default values of controls were stored as part of the front panel, so any time the VI wanted to recompile, the panel was actually necessary to generate the code. Nowadays the default values have been moved out of the panel, and we are inching closer to the day when the recompile could happen with just the diagram without the panel, but there are 25 years worth of code that assumes "if I have the diagram then I know the panel is in memory, so I don't have to test for NULL". It's a low priority refactoring that is ooching forward.

Code Distribution

2009-08-13T19:11:11Z

Daklu:

This is the portal for information related to Building an executable, creating an installer and distributing your code.

==== Distributing Executable Code: ====

*[[How to Build an Executable]]
*[http://labviewwiki.org/Executable_Directory_Structure Executable Directory Structure]
*[[Associate your own file type with Windows Explorer]]
*[[Including ini settings]]
*[[EXE has the wrong date]]
*[[Getting Command Line Parameters]]
*[[Run-Time Engine Limitations]]

Executable Directory Structure

2009-08-13T18:56:03Z

Daklu: New page: When building an executable in Labview some VIs may be remapped to a different folder structure either inside or outside the executable. This can impact an executable that uses path consta...

When building an executable in Labview some VIs may be remapped to a different folder structure either inside or outside the executable. This can impact an executable that uses path constants in source code to locate sub VIs or other resources. Versions prior to 2009 remapped VIs to a directory tree ''outside'' the executable. Labview 2009 has fixed this problem.

 
<blockquote>Yes, by default all VIs will go into the .exe using the same relative path between them as you had outside the .exe (you can, of course, tell the build spec to put specific VIs in specific locations using custom destinations). It finds the most common root folder of all the VIs and uses that as the top-level directory inside the .exe. If the VIs span drives on Windows then the top-level directories will be the drive letters.</blockquote><blockquote>The one exception is vi.ilb, which gets its own top-level directory. This is to prevent common cases from having really deep hierarchies just for vi.lib VIs. This means if you call a vi.lib VI dynamically then you should write a wrapper VI for it in your .exe which you can then call using a relative path. The idea is to not have any code which has to check whether you're in an .exe or not in order to build different paths. The paths should always be the same. (Quoted from ''Adam Kemp'' on [http://lavag.org/topic/9251-name-conflicts-using-vis-for-override/page__view__findpost__p__64037 LAVA])</blockquote>
 For example, an executable's internal directory structure would look like:
<blockquote>application.exe/main.vi application.exe/subfolder/subvi1.vi application.exe/LabVIEW 2009/vi.lib/vilibVI1.vi application.exe/LabVIEW 2009/user.lib/_OpenG/openGVI.vi application.exe/LabVIEW 2009/instr.lib/Instrument Driver1/initialize.vi (Quoted from ''gmart'' on [http://lavag.org/topic/9251-name-conflicts-using-vis-for-override/page__view__findpost__p__64051 LAVA])</blockquote>

[[Category:LabVIEW internals]]
[[Category:Application builder]]
[[Category:Building executables]]
[[Category:Code distribution]]