From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW Idea Exchange

Post an idea

CTRL+Click on an input is a great little tool to switch the input.

However, it only works when both inputs are wired. Often (, I or QD connected a wire wrong,) I feel like switching the input, before wire-ing the 2nd. Only to find it doesn't work...

Having to connect the 2nd wire just seems to disrupt the flow, being focused on the first input. Being forced to make things worse (connect two wrong wires) before being able to make it right just feels itchy to me.

Switch one wire.png

It's a minor thing, but I never understood why it would be limited to 2 wires.

View All (5)

Quite frequently, I encounter a need to do something repetitive on clusters, which have identical elements. Sometimes, I use "Cluster to array" and then "Array to cluster" vi's, like in the example below:

For loop on cluster.PNG

Instead of doing this, I would like to use a kind of "For loop", which would be able to operate directly on clusters with identical elements. The loop would iterate already during the compilation (generating repetitive code for each cluster element).

Perhaps, the standard For loop connector might have something like an option "Iterate over cluster elements".

View All (3)

It might be worth exploring the feasibility of having an online vi upgrade/downgrade service, where you could submit your vi, and receive back the new vi.

I realize this wold be a huge undertaking, however, a reasonable fee could be charged. It could be a second option, in case the customer:

Has tried to do this on their own and failed

Does not have the intermediate versions to perform the required jumps

Isn't worth their time considering the cost of the service

In the case of upgrading a vi, this could serve as an added incentive to invest in the latest version of Labview, especially if the customer is several versions behind.

Add a new button to the search results dialog called "Set Aside" so I can have multiple search results open at the same time. Put it near the bottom just below the search results. When you click it, it changes the title of the window to "Search Results - Set Aside 1". If you click "Set Aside" again when #1 is open, it will open "Search Results - Set Aside 2" ... and so on. This way you can have several different search results open simultaneously. I love the check mark feature in the search results, but it resets every time the search windows is closed or overwritten by a new search. Thus I lose my place if I want to make sure to check every instance of something but need to search again while looking at one item.

View All (2)

Originally, I asked this query on NI discussion forum Retain Default Data Type of Input Terminal in VI . Thanks @GerdW and @crossrulz to encourage me to share this on IdeaExchange. I need such functionality in one of my project.

Hello,

When I take Open VI Reference function and create a constant for Option input terminal it shows Numeric constant with HEX radix (Default). So to add same functionality in TEST.vi I put numeric control on front panel with display format set to HEX. But when creating a constant to this input terminal the default data type is DEC and does not show HEX radix likewise in Open VI Reference function. I also tried by making Numeric control strict typedef but didn't work. So how to do this?

Below are the screenshots for same.

View All (2)

A right click option for each auto indexed array that allows will not use the length of that array in choosing the number of iterations. If there is no input to the count terminal all auto-indexed terminals can go beyond their length otherwise at least one must remain as a driver for determining the length. If multiple are left with the default (existing) behavior, the shortest length will be used. For any iteration where the array is shorter that the "i" of the loop, the defaults for the data type will be returned (just as if "index array" blocks had been used inside the loop.

Similarly the loop could be set to use the longest array instead of the shortest.

Additionally a similar function could be done when any array compare or math functions are done. In the case of compare functions if set to use longest array, the result will be false for any compare to an empty element of the shorter array, and math functions will use the default data type for empty elements.

View All (1)

Right-clicking objects on the block diagram in LabVIEW produces a shortcut menu appears. When placed on replace, a menu is shown that is sensitive to the selected item and the option to access all the palettes. Often, when we want to replace an element, we also want to use some other element from the same palette.

When we access the palette, the thumb tack pins are missing, and if we need to access more than one element, it is necessary to navigate in the block diagram through the functions palette. In addition, when we get used to using the "Quick drop", when we need to access items that we don't normally use, it is difficult to locate on the paletta, so I propose, include in the palette from shortcut menu the thumb tack pins.

Currently, we can make inputs to subVIs optional (or indeed recommended) and not wire them - in this case, the default value for the input terminal is used. By default, this is the default value for the type, but it can be easily changed to another value (at least for terminals you can easily set).

Since there is no "optional" type, this leads to code potentially like

If -1 is always an invalid value here, this might not be so terrible. The issue becomes more pervasive with, for example, empty strings (or string constants) when an empty string or that constant might conceivably be a valid value.

Class objects could be an additional problem, especially if a hierarchy is considered, because you might want to wire an uninitialized child object to an Init Object method, and it would fail an equality check vs the terminal type. You might then mistakenly conclude that it was already partially/fully initialized, and carry out the incorrect processing (in this exact case, probably dynamic dispatch followed by an equality check against the specific child, then calls to a static dispatch "Init Object_internal.vi" in the parent might work).

We can work around this if needed by using a boolean clustered with the value, and then checking the boolean, but this makes wiring the subVI and creating its inputs more frustrating.

I would like to see an optional terminal type that could be checked using a primitive to indicate if it was wired by the caller or not.

(Apologies for the ugly icon, and probably dubious naming)

For the draft of the proposing paper in C++ for the std::optional type, see http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3672.html

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