LabVIEW Idea Exchange

cancel
Showing results for 
Search instead for 
Did you mean: 
0 Kudos
JiriVejrazka

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

12 Comments
Intaris
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?

JiriVejrazka
Member

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.

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

AristosQueue (NI)
NI Employee (retired)

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

Darren
Proven Zealot
JiriVejrazka
Member

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

wiebe@CARYA
Knight of NI

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.

Yamaeda
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

/Y

G# - Award winning reference based OOP for LV, for free! - Qestit VIPM GitHub

Qestit Systems
Certified-LabVIEW-Developer
crossrulz
Knight of NI

Yamaeda, Cluster To Array is a lot smaller.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
AristosQueue (NI)
NI Employee (retired)

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.