LabVIEW Wiki - User contributions [en]

LabVIEW 2020

2022-04-18T14:48:17Z

AristosQueue: /* New features in LabVIEW 2020 */

{{prevnext|LabVIEW 2019|LabVIEW Versions|LabVIEW 2021}}
{{LabVIEW Version
|version=LabVIEW 2020
|logo=File:LV2020.png
|release=May 2020
|release_sp1=January 2021 (SP1)
|change_0=Interfaces
|change_1=Partially broken wires
|change_2=Publish web services to NI Web Server
|change_3=Repairing packages
|change_4=Clear variant data types}}

==New features in LabVIEW 2020==
{{ambox|text=This is a subset of new features in LabVIEW 2020 that were mentioned on [https://twitter.com/labview Twitter] and [https://www.facebook.com/labview/ Facebook]. See the Upgrade Notes for a complete list of changes.}}
* Interfaces - Expanded object-oriented programming to introduce interfaces as a companion feature to classes.
* Clear Variant Data right-click menu option<ref name="fb-clear-variant-data"/> - Clears data from Variant controls and indicators.
* Enum to Array of Enums function<ref name="fb-enum-to-array-of-enums"/> - Creates an array with all possible Enum values.
* Create NI GUID function<ref name="fb-create-ni-guid"/> - Adds a native GUID function to LabVIEW.
* Remove <code> (no error)</code> from Error Control (hidden INI key)<ref name="fb-remove-no-error-from-error-control"/> - Set <code>NI.LV.RemoveNoError=TRUE</code> to remove the <code> (no error)</code> suffix from Error Controls.
* Build Path Relative Path Input<ref name="fb-build-path-relative-path-input"/> - The default type for the second input of the Build Path function was changed to relative Path instead of String.
* Break Bad Wire Branches Only<ref name="fb-break-bad-wires-only"/> - Wires only break for broken branches instead of all branches.
* Class Dialog Improvements<ref name="fb-class-dialog-improvements"/> - The dialog for creating new classes was changed to provide more features.
* Double Click Array To Cluster<ref name="fb-double-click-array-to-cluster"/> - The property dialog for the Array To Cluster function can now be opened by a double-click.
* Set Text Icon for Project Libraries<ref name="fb-edit-icons"/> - The Project Library configuration dialog has a new ''Set Text Icon...'' button, which provides a way to quickly set the text, text color and background color for the library icon.
* Range Limits for Type<ref name="fb-range-limits-for-type-vi"/> - Returns the maximum and minimum values for a given data type.
* Generate Checksum Values<ref name="fb-generate-checksum-values"/> - Adds native functions to calculate SHA-2 and SHA-3 checksums to LabVIEW.
* Hide Event Data Node and Iteration Terminal<ref name="fb-hide-event-data-node-and-iteration-terminal"/> - It is now possible to hide Event Data Nodes in Event Structures and Iteration Terminals on For- and While loops.
* Multi-Error Support<ref name="fb-multi-error-support"/> - Collect multiple error values on a single error wire (adds a new subpalette for handling multiple errors).
* Hide Last Item for Rings when running<ref name="fb-hide-last-item-for-rings"/> - Adds an option to hide the last item from a ring control.

==Application icon design==
The application icon was changed for LabVIEW 2020 SP1:

[[File:LV2020SP1.png]]

==External links==
* [https://www.ni.com/en-us/shop/labview/release-details.html LabVIEW Release Details]
* [https://www.ni.com/pdf/manuals/374715n.html LabVIEW 2020 Readme]
* [https://www.ni.com/pdf/manuals/374715p.html LabVIEW 2020 SP1 Readme]
* [https://www.ni.com/pdf/manuals/371780t.pdf LabVIEW 2020 Upgrade Notes]
* [https://www.ni.com/en-us/support/documentation/bugs/20/labview-2020-sp1-bug-fixes.html LabVIEW 2020 SP1 Bug Fixes]
* [https://www.ni.com/en-us/support/documentation/bugs/20/labview-2020-known-issues.html LabVIEW 2020 Known Issues]
* [https://www.ni.com/en-us/support/documentation/bugs/20/labview-2020-sp1-known-issues.html LabVIEW 2020 SP1 Known Issues]
* [https://youtu.be/rXLxo9zuBSc What’s new in LabVIEW 2020] by Tom’s LabVIEW Adventure

==References==
<references>
<ref name="fb-clear-variant-data">[https://www.facebook.com/labview/videos/313204460045993 Clear Variant Data] by Darren Nattinger</ref>
<ref name="fb-enum-to-array-of-enums">[https://www.facebook.com/labview/videos/283647629401421 Enum to Array of Enums] by Darren Nattinger</ref>
<ref name="fb-create-ni-guid">[https://www.facebook.com/labview/videos/570111097012827 Create NI GUID.vi] by Darren Nattinger</ref>
<ref name="fb-remove-no-error-from-error-control">[https://www.facebook.com/labview/videos/615411719411123 Remove (no error) From Error Control] by Darren Nattinger</ref>
<ref name="fb-build-path-relative-path-input">[https://www.facebook.com/labview/videos/299469061159932 Build Path Relative Path Input] by Darren Nattinger</ref>
<ref name="fb-break-bad-wires-only">[https://www.facebook.com/labview/videos/672708713385685 Break Bad Wires Only] by Darren Nattinger</ref>
<ref name="fb-class-dialog-improvements">[https://www.facebook.com/labview/videos/3102767176494288 Class Dialogue Improvements] by Darren Nattinger</ref>
<ref name="fb-double-click-array-to-cluster">[https://www.facebook.com/labview/videos/349473259602855 Double Click Array To Cluster] by Darren Nattinger</ref>
<ref name="fb-edit-icons">[https://www.facebook.com/labview/videos/350338116077871 Edit Icons] by Darren Nattinger</ref>
<ref name="fb-range-limits-for-type-vi">[https://www.facebook.com/labview/videos/690573941892844 Range Limits for Type VI] by Darren Nattinger</ref>
<ref name="fb-generate-checksum-values">[https://www.facebook.com/labview/videos/1254380881613189 Generate Checksum Values] by Darren Nattinger</ref>
<ref name="fb-hide-event-data-node-and-iteration-terminal">[https://www.facebook.com/labview/videos/372715580702001 Hide Event Data Node and Iteration Terminal] by Darren Nattinger</ref>
<ref name="fb-multi-error-support">[https://www.facebook.com/labview/videos/191762282418740 Multi-Error Support] by Darren Nattinger</ref>
<ref name="fb-hide-last-item-for-rings">[https://www.facebook.com/labview/videos/842160236599572 Hide Last Item for Rings] by Darren Nattinger</ref>
</references>

{{stub}}

[[Category:LabVIEW Versions]]

Occurrence

2011-10-24T15:37:11Z

AristosQueue:

There seem to be misconceptions about how exactly occurrences work and what exactly the "ignore previous" parameter on "Wait on Occurrence" (WoO) does. The following tries to explain, in a long and winded way, how they (functionally) behave:

'''SHORT STORY:''' The following is the advice of LabVIEW's Chief Architect to use occurrences correctly:
''First build a system which polls continuously for whatever it is the occurrence will signal. You need to be able to determine the state of things without an occurrence. This creates a correct, but inefficient busy waiting implementation. Once that works, add an occurrence to alleviate the inefficient waiting. Do '''not''' remove the actual polling. In other words, use the occurrence only to indicate that "it is probably a good time to check on that thing...".''
[http://lavag.org/topic/14998-how-to-open-front-panel-after-n-milliseconds-unless-the-operation-is-done/page__view__findpost__p__90901 You can see an example of this usage in this LAVA post.]

'''LONG STORY:''' How Occurrences are "generated": When a VI is loaded (!) each "Generate Occurrence" function allocates exactly one unique occurrence. When the VI is running and this function is called it simply returns this one occurrence -- no matter how many times it is called (try putting one in a loop and examining its value using the probe, it will always have the same number). If you stop the VI and run it again, you will get the same value; only removing the VI from memory and loading it again will give you a "fresh" value.

How Wait On Occurrence (WoO) works: Each WoO functions "remembers" what occurence it last waited on and what time it continued (because the occurence fired or because of a timout). When a VI is loaded (!) each WoO is initialized with a non existing occurrence. When a WoO is called and "ignore previous" is FALSE there are four potential cases:

*The occurrence has *never* been set -> in this case WoO waits
*The occurrence has been set since this WoO last executed -> WoO does not wait
*The occurrence has last been set before this WoO last executed and last time this WoO was called it waited on the *same* occurrence -> WoO will wait
*The occurrence has last been set before this WoO last executed but last time this WoO was called it waited on a *different* occurrence -> WoO will *not* wait!!!!

The first three cases are pretty clear, the last one may seem a bit strange. It will only arise if you have a WoO inside a loop (or inside a *re-entrant* VI in this loop) and it waits on *different* occurrences (out of an array, for example) or if it is inside a *non re-entrant* VI and the VI is called with different occurrences. These cases do generally not happen. The reason the WoO behaves this way is due to its implementation. Each occurrence "knows" the last time it has been fired, and each WoO remembers the occurrence it was last called with and what time it fired (or timed out). When WoO is called and "ignore previous" is FALSE, it will look at its input; if the input is the same as last time, it will look at the time of the last firing and wait depending on whether the time was later than last execution; if the input is *not* the same as last time, it will simply look at the time and wait depending on whether it has *ever* been fired.

A possible (implementation) problem: It appears that occurances are "remembering" that they have been set during previous invocations of the program. One would think that generating an occurance should create a clean "non-set" occurance. This problem can be illustrated in a program that has three parallel loops with an abortable wait in each using occurances. If the program is stopped with the stop button things are fine. But if one waits until one of the random stop conditions triggers the end of the loops (generated from the other loops), the next time the program is run, the loops will execute only once and not loop at all. (The random terminate condition in the actual program is an error occuring in some piece of equipment.) Either this is a bug, or we are completely wrong on the use of occurances. Our example here is using the occurances in the "do not clear previous" mode. We would think that we will not remember ccurances from previous runs of the program since a new clear occurance should be created with the generate occurance icon. In this instance we can not use the clear previous occurances mode since we need a single occurance to stop multiple parallel loops.

The reason for the problem: The first time the occurrence is set because of an error, the loops terminate, but the "stop button" loop is still running. When you click on the stop button, the occurrence gets triggered again (unneccessarily) and the program stops. The next time the VI runs, the WoO will not wait because of this extra trigger; and since you'll trigger again in the "stop button" loop, the VI won't work until it's reloaded from disk.

A solution to the problem: Due to this behavior of occurrences, it is clear that one cannot use the "timed out" flag to determine when the occurrence fired. You will have to maintain some global information about your state, let's say in a global boolean called "FINISHED". At the beginning of the program you would initialize it to false. If you have an error, set FINISHED to true, and then trigger the occurrence. After the WoO see if FINISHED is true (make sure you don't read the global until *after* WoO finished executing), if FINISHED is false continue with the loop. In the "Stop button" loop, also set FINISHED before you trigger the occurrence.

BTW, if you don't like globals, you could use a VI with an [[Uninitialized shift register]] (LabVIEW 2 global), but the effect would be the same.

Comments: One may think that occurrences are quirky, a pain to use and that they should be avoided. One might be right! Occurrences are very low level and you often have to add functionality to them in order to use them effectively. In other words, they are not for the faint of heart. Anything implemented with occurences can be also implemented without them, but maybe not as efficently. What occurrences do is to allow you to program synchronization in a way that does not use polling, and is thus "cheaper" in processor time.

''Note: National Instruments encuorages the use of Notifier operations functions in place of the occurences for most operations.'' 

[[Category:Synchronization]]

[[Category:Synchronization]]

Error Cluster data type

2010-02-26T15:48:08Z

AristosQueue: /* 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:Error cluster control and terminal.JPG|frame|center|Figure 1: 3D error cluster control and terminal‎]]

Note that the default terminal and wire color was changed from pink to dark yellow in LabVIEW 8.2 ([http://www.ni.com/pdf/manuals/371780b.pdf upgrade notes] p. 35). 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''). The following ranges are reserved for users to define their own error codes:
* 5000 to 9999
* -8999 to -8000
* 500000 to 599999
Use '''Tools >> Advanced >> Edit Error Codes''' to create text files to define your own errors.

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

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

== Error Cluster as Execution Order Specifier ==

LabVIEW is a dataflow language and as such preferred way to specify execution order of block diagram items is to connect output of a block diagram item to an input of another block diagram item. There are situations when some certain execution order is required but the outputs of the items to be executed earlier cannot be connected to the inputs of the items to be executed later. In these situations error cluster is a preferred way to specify the execution order of the items. It's preferred over sequence structures in almost all use cases. 

This can easily be achieved by a private replacement for the 'merge errors' node, that also contains a 'No_Error'  constant: 

[[Image:SerializeprocessesBD.png|merge errors with No_Errors]] The connector pane looks like this: [[Image:SerializeprocessesCP.png|Connector Pane for 'SerializeIndependentProcesses]] 

It can be used like this: 

[[Image:SerializeprocessesUsage.png]]

So a VI-Ref is opened independently if an error occured before, but after all preliminary portions of code had been finished. The printing actions relate to the eventual error of the OpenVI-Ref node only. All errors are merged as final action, so any error that might have shown up is reported, while the printing actions care only on VI-server related errors. 

This little helper is too simple to provide its code as VI, though...

== See also ==

*[[Error handling]]
*[[Error Case Structure]]

[[Category:Data_types]]