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: 
0 Kudos

For loop iterating on cluster

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

Proven Zealot

Instead of looping on a cluster (which seems kind of weird because normally, a cluster will aggregate unrelated datatypes) I would personally prefer fixed-length arrays (and fixed-length strings and anything else which las a "length") in LabVIEW as properly supported entities. Then you can just define your "cluster" as a 3-element array and you can iterate over it as much as you like.


Edit: Added Hyperlink for fixed-length strings.... Have fixed-length arrays not been requested already or is the NI search just not showing the results to me?


Intaris: Not really. Indeed, many cluster are of mixed types. Nevertheless, the example shown is quite typical in many applications I have written (in that case, I would write repetitive code instead of FOR loop, but when there is e.g. 12 elements, one starts to be lazy).


The advantage of using clusters in these cases is you can name the elements, making the code readable and understandable. Just imagine the elements in the cluster with limits are named e.g. ServoElevator, ServoRudder, ServoAileronLeft, ServoAileronRight. With proper typedef, the names of cluster elements propagate to subroutines, and you see the structure in the Help window. For an array, you would always need to remember, which element stands for which control.


Fixed-sized arrays are available in LabView when coding for FPGA.

Proven Zealot

Not only are fixed-size arrays available on FPGA you can copy a control or constant from an FPGA target and use it anywhere.  This tells me that they CAN be supported on all platforms, but are NOT actually supported.  You can't configure a fixed-size array on anything other than an FPGA target at the moment.


But the fact remains that you request a functionality for "clusters" when actually referring to a small corner case usage of that datatype. What you need is a different datatype.  If you need naming but with only one base data type, look out for some new features in LabVIEW 2019 when it's released. There might be something there which helps you out.

Proven Zealot

Duplicate of

Index on "arrayable" clusters


PS: I like this idea, but I like it even more on heterogenous clusters... consider the possibilities of combining the idea of autoindexing a heterogenous cluster with a Type Specialization structure (LV 2018) that handles the type differences. The TSS is a compile-time structure to choose its frame, but we could imagine code that unrolls the For Loop at compile time to compile in the necessary code, or several other ways of meaningfully interpreting that structure. I have nothing coherent to offer at this time, but it is an interesting direction to brainstorm. Just sayin'.

Proven Zealot

: I also think that it is not necessary to perform only on same elements; it should be just sufficient that the code in the loop can be performed on each elements. And I imagine that this could combine nicely even with the fixed-size array feature.


Anyway, when you said  "code that unrolls the For Loop at compile time," that is exactly what I mean. In fact, even for small-sized fixed arrays this would be interesting. I encounter that need when programming for FPGA.

Proven Zealot

I'm curious what the wire type between the indexing and the TSS would be...


For now, only a variant would be available. The idea would require an "any type" wire (or "several types" wire?), that would be recognized by the TSS (or a .vim). Makes me think if this would be useful for more situations...


For now I'll stick with OO polymorphism to achieve the same thing.

Proven Zealot

Just use Variant to data and convert it to an array of the element. Then you can loop over it. 🙂

Variant to data.png


G# - Award winning reference based OOP for LV, for free! ADDQ VIPM Now on GitHub
"Only dead fish swim downstream" - "My life for Kudos!" - "Dumb people repeat old mistakes - smart ones create new ones."
Knight of NI

Yamaeda, Cluster To Array is a lot smaller.

There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
Proven Zealot

Yamaeda: That solution has so much performance overhead as to render it unusable for the vast majority of situations where this would actually be useful notation. And it cannot compile at all on FPGA targets. And you cannot do operations directly on the variant data, rendering it impossible to actually use.


The many downsides to the variant approach make it essentially a non-starter for most cases. Thus the continued brainstorming for other ways.