LabVIEW Idea Exchange

Post an idea

Provide a way to save and recall sets of probes for a running application. A developer could then provide sets of various probes that would help the end user. The superprobe would remember the VI paths and locations in the block diagrams of the application's SubVIs and automatically load VIs from disk or monitor existing re-entrant copies in memory. The superprobe would have a front panel layout, like a global VI, to look like a custom dashboard of important data values in the applicaton.

View All (2)

View All (3)

In Java, any errors/exceptions that a function can throw (to its caller) are listed directly in its signature/declaration. This would be nice functionality to have in LabVIEW. Otherwise, the only way to determine which errors a VI can return is to either:

examine the code manually, recursing through all its subVIs or
brute-force exercise the VI until you have observed all errors that it might throw in your particular application.

Neither of these options seems particularly robust or efficient.

It may even be possible for LabVIEW to determine the throwable errors automatically, although at least having the ability to declare them manually would be a good start. They could be registered through the development environment such that they are stored in the VI file itself. In this way LabVIEW could summarize all the errors a given VI throws based on those declared within it and its subVIs. I acknowledge that this would likely require a more sophisticated error system than the current error codes (since these may not be known at compile time). But, I would be surprised if it couldn't be achieved in a similar fashion to Java where all errors are classes that inherit from a common "error" class.

If I'm missing some methodical, pragmatic approach for achieving the same result, please let me know.

View All (1)

The In Place Array Index/Replace Elements function not only can save memory by avoiding copying arrays, it can also create "neater" and more transparent Block Diagrams. For example, here are two ways to triple the third element in an Array of 3 elements:

Array Index-Replace 1D.png

I needed to do the same thing, but for a 2D array (three channels of A/D data, I wanted to triple the third channel). The Help for the In Place Array Index/Replace Subset function suggests this is possible, using language like "element or element(s) of an array", noting the similarity between this In Place Structure and the two Array Functions that form the Input and Output nodes, and in earlier versions of LabVIEW (specifically LabVIEW 2012), explicit reference to rows, columns, and pages as replacement items. Here's what happens:

Array Index-Replace 2D.png

The Index Array left node forces you to specify both row and column, meaning you cannot operate on a single row (or single column), "breaking" the functionality with the separate Index Array/Replace Subset functions. This also, I believe, will force an Array Copy operation, something I'm (also) trying to avoid.

At its most benign, there is a Documentation "Bug" that should warn users that this In Place function is only designed for single array elements (which, in my opinion, severely limits its usefulness). I would like to suggest that this function be "fixed" to (a) for multi-dimension Arrays, allow, as with Index Array and Replace Subset, flexible choice of one or more Indices to be specified, with the unspecified Indices implying "All of the Elements", i.e. an entire Row, Column, Page, etc, and (b) maintain the "In Place" functionality by having this function generate the necessary code (behind the scenes) to access the specified elements and do whatever operation is required inside the Structure.

I appreciate that requirement (b) might be difficult. For instance, operating on a row in a 2D array should be easy, as the (row) elements should be continguous, making getting and putting them simple. However, if a column is specified, getting successive elements and putting them back becomes more complex. To the User, it all "looks simple" -- you get a 1D wire out, operate on it (say, multiply it by 3), and stick it back "in place", but the LabVIEW compiler has to "get" elements from non-continuous locations and put them back where it got them, but that's what Compilers are for!

Bob Schor

View All (1)

When I build, I like to test each step. That means that I make a bunch of "debugging" indicators. Some might prefer probes and breakpoints, but I like the "build as you go" and "don't use too many tools". The challenge here is that about 80% of indicators that I make, I have to delete.

I wish there were a version of "diagram disable" that is specified in the block diagram, that worked for the front pane, and left me some tiny asterisk instead of the indicator, that didn't hit program execution times, and that when I configure execution the asterisks can be made to disappear.

This would allow me to revisit my code, to access all of my debugging methods very quickly and intuitively, and to not necessarily change the final layout of the front panel after my debug is done.

View All (1)

I have a project which compiles to 2 different executable for different hardware targets. I have created 2 Build Specifications which specify different locations for the build output. However, between compiling each one, I must go to the target options, and change a Conditional Disable Symbol definition so that the other .exe is generated. If the Build Specifications definition had a tab to specify the value of Conditional Disable Symbols, and which would take precedence over definitions in the project or the target options, then I could build my 2 executables without changing the target properties.

View All (2)

View All (3)

View All (1)

View All (5)

According to Wikipedia:

In some languages a class may be declared as uninheritable by adding certain class modifiers to the class declaration. Examples include the "final" keyword in Java or the "sealed" keyword in C#. Such modifiers are added to the class declaration before the "class" keyword and the class identifier declaration. Such sealed classes restrict reusability, particularly when developers only have access to precompiled binaries and not source code.

The sealed class has no subclasses, so it can be easily deduced at compile time that references or pointers to objects of that class are actually referencing instances of that class and not instances of subclasses (they don't exist) or instances of superclasses (upcasting a reference type violates the type system). subtype polymorphism. Because the exact type of the object being referenced is known before execution, early binding (or "static dispatch") can be used instead of late binding (also called "dynamic dispatch" or "dynamic binding") which requires one or more virtual method table lookups depending on whether multiple inheritance or only single inheritance are supported in the programming language that is being used.

I have previously made appeals to allow for certain classes to restrict the ability to load new ancestors at run-time, thus restricting possibly allowing for inlining of dynamic dispatch VIs. A similar request has already been made in order to facilitate ilining of DD VIs. I believe that ultimately, it is support for a "Final" or "Sealed" class what I am looking for.

Such a modification on a class would effectively prohibit instantiation of any new version via factory method and would declare to the compiler that the code defined at compile-time is actually the full extent of code which will be available at run-time, thus allowing for the aforementioned optimisations to take place.

Questions would have to be answered regarding type propagation and some loopholes may remain regarding dynamic loading of new classes (only dynamic dispatch methods which are visible as instances of the "final" class can actually safely be inlined for example). Especially for a specific RT application of mine, this would be a great benefit as the natural progression of this idea is indeed the ability to write code such that dynamic dispatch VIs are actually inlineable.