LabVIEW Idea Exchange

About LabVIEW Idea Exchange

Have a LabVIEW Idea?

  1. Browse by label or search in the LabVIEW Idea Exchange to see if your idea has previously been submitted. If your idea exists be sure to vote for the idea by giving it kudos to indicate your approval!
  2. If your idea has not been submitted click Post New Idea to submit a product idea to the LabVIEW Idea Exchange. Be sure to submit a separate post for each idea.
  3. Watch as the community gives your idea kudos and adds their input.
  4. As NI R&D considers the idea, they will change the idea status.
  5. Give kudos to other ideas that you would like to see in a future version of LabVIEW!
Showing results for 
Search instead for 
Did you mean: 

Allow unwired index for "Array Index/Replace Elements" on the In Place Element Structure

Status: New

This would replicate the ability of the standard Index Array function to extract a subarray from a multi-dimensional array. Currently both indices must be wired, which only selects scalar elements.



Another related enhancement that may be useful is to provide the equivalent of "Array Subset" on the In Place Element Structure.


Active Participant
Nice idea!
André Manzolli

Mechanical Engineer
Certified LabVIEW Developer - CLD
LabVIEW Champion
Curitiba - PR - Brazil
Active Participant

This is an excellent idea! I can't imagine why the Index/Replace wasn't implemented like this in the first place... 


I agree that the "Array Subset" feature would be an obvious candidate too if this idea ever gets accepted 🙂



Chris Virgona
Active Participant

The funny thing is, that the VI Analyzer marks an "Index Array" function wired to an "Replace Array Subset" function as a medium-rank failure. See example below.snippet.png


Proven Zealot

But won't this only work well for a single dimension?


When you know how the data is stored in memory, depending on whether the array has been marked as transformed or not this would work efficiently only for either the first or second dimension surely.


NI would have to be able to treat the other dimension as a "Sparse" array (i.e. each element being further apart from each other than the actual element size) which, should it actually be implemented, would lead to lots of other lovely things.... (Array of clusters to element arrays in-place and so on.... )

Proven Zealot

Intaris is partially correct.


The LV compiler already has the ability to take a sparse slice out of an array without data copy. In fact, we do that when you use the regular Index Array node to extract an array. See the context help (note that the VI must be fully compiled with no unsaved changes to see the subarray notation, since the compiler makes that evaluation late in the game, and it can't be something that gets constant folded). So that isn't the problem.

Untitled (Recovered).bmp

The problem is that the In Place Element (IPE) structure cannot maintain its contract to handle the memory in place unless we put a lot of restrictions on what you do with that array. For example, you would not be able to wire the array to a Build Array to append elements onto it because that wouldn't be maintaining the invariant of the IPE. Nor would you be able to pass it through any subVIs because they might do something to the size of the array (I suppose we could do it with fixed-sized arrays on FPGA, but that's a pretty limited use case). Explaining why wires break in these cases would be tricky at best.

Trusted Enthusiast

What wires are breaking currently in the IPES?  I can do a row replace using the classic three-way split and the Array Subset/Replace node.  Notice that I can flagrantly try to violate the inplaceness by trying to replace 1 row with 2 with nothing breaking.  (I left out the case structure to check for row < 0 in this example).  In this case the second row of the replacement is simply ignored.




You can similarly try to replace with an empty array and it will be zero padded to fit.  It is all natural.  I like this idea as a way to simplify the syntax for the above code, pad/trim the replacement elements to fit in the current array.  Someday the compiler may be smarter and recognize more array replacement operations as in place, right now it is very easy to trick the compiler into thinking a copy is required.


If I try to stuff 20 pounds of you-know-what into a 5 pound bag this idea makes it easy to wind up with only 5 pounds.  Right now the compiler is happy to give me whatever size bag is necessary, and that just means I sometimes wind up with an extra 15 pounds of stuff.

Proven Zealot



Does this "sub array" work in both dimensions?  In one dimension it would be a contiguous range of memory whereas int he other it would be "sparse".


Why then if we have an array of cluster of DBL, I32 and Boolean can't we simply access the booleans as a normal array without unbundling and bundling.....  This is essentially the same operation in the background, right?

Knight of NI

I posted a similar request a few days ago, having just discovered that the Index Array/Replace Subset In Place Element didn't work "as advertised" in the Help document for multi-dimension arrays.  One could argue that the Help document in LabVIEW 2016 only hints that you should be able to replace, say, a row, but if you look at the Help for the same function in LabVIEW 2012, it explicitly says you can use this to replace rows, columns, pages, etc..  So at the very least, fix the documentation to make clear this only works for a single element, regardless of the dimensionality of the input array.


Bob Schor