LabVIEW Idea Exchange

cancel
Showing results for 
Search instead for 
Did you mean: 
Greil

"Conditional Append" at array indexing tunnel

Compare the upper loop(old) with the lower loop(new).
Take a close look at the loop exit.

 

 

Solution: Right click the indexing tunnel and select "Enable Conditional Append"

This works not only with FOR-Loops. 

 

History: This idea was already presented by me in May 2008 http://lavag.org/topic/7574-conditional-append/page__p__44719&#entry44719 

12 Comments
RavensFan
Knight of NI
Then perhaps you will want to kudo the idea where it has already been presented here.  http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Conditional-auto-indexing/idi-p/918682#A123
Greil
Member
yes i did it - even he copied my idea and example (proven by the link in my first post)
JackDunaway
Trusted Enthusiast

This idea is too good to not Kudos twice, so Kudos.

tst
Knight of NI Knight of NI
Knight of NI

> ...proven by the link in my first post

 

The fact that something is similar to something else does not prove that it was copied.


___________________
Try to take over the world!
elset191
Active Participant

"The fact that something is similar to something else does not prove that it was copied."

 

Not to mention that in that same thread he posted, Jim Kring posted the OpenG VI, and states that it was already available at the time.  So, Martin's wasn't wholly original either.

--
Tim Elsey
Certified LabVIEW Architect
falkpl
Trusted Enthusiast

"It's amazing what you can accomplish when you don't care who gets the credit." - Pres. Harry S. Truman

 

I posted this because it is something that would make my development faster.  I am sure that I was not the originator of this idea.  I bet this has been thought of by anyone who has ever built a conditional array inside of a loop. 

Actually I remember a presentation at NIWeek several years back where Dr K. (I think it was him if my memory is correct) envisioned an environment where labview was behind the sceen of lower level implementations so this indexing terminal was in itself just another vi that could be edited with LabVIEW to implement just such a feature.  Now thast would be supercool.  If I have to start footnoting my posts I will probably go crazy. 

 

Anyway kudos to all who can use such a feature.

 

Paul Falkenstein
Coleman Technologies Inc.
CLA, CPI, AIA-Vision
Labview 4.0- 2013, RT, Vision, FPGA
JÞB
Knight of NI
Frankly I like the Idea!  No matter who's (whom's?) it is.  but I'd prefer an implementation that is more related to the true functions "Concatanate" and "Build Array" like thushmmm.PNG

"Should be" isn't "Is" -Jay
tst
Knight of NI Knight of NI
Knight of NI

Jeff, the problem with your suggestion is that it still requires considerable space and work. You're not gaining much over the current situation. Your image is equivalent to simply wrapping a case structure around the BA prim.

 

When adding a single element, concatenate and build are the same thing. I did actually post a suggestion here which offers a real concat and I also suggested there combining it with this idea. This sample image also shows the savings in space and work.

 

 

Conditional concat.PNG


___________________
Try to take over the world!
Rob_Calhoun
Member

We use a conditional build array very frequently in our code and I strongly support adding this to LabView. (Incidentally I am kudos'ing all variations of this idea by all posters, as I don't care who "invented it"; it is based a very common code pattern and it is unsurprising that there are multiple "inventors".)

 

The implementation should be compatible with the existing "Conditional" terminal of For Loops. (Probably that would have to be renamed "Conditional Termination" when the new "Conditional Build" is added.) One option would look like this:

 

ConditionalArray.png 

 

I am trying match the feel of the existing Conditional Termination terminal, which is free-floating. (This also lets you make the wires shorter.) Ideally one would be able to build the output on either a "true" or "false" Boolean, similar to the dual functionality of the Conditional termination terminal. An unresolved problem is how to badge the "N": there is very little room left and my suggested badging above is incomprehensible.

 

I wanted to present how we handle this in LV 2009 and earlier. We don't use the OpenG function "Conditional Auto-Indexing Tunnel" because it only works for built-in data types and many of our arrays contain large clusters. Instead we have a generic function that returns the "true" indices of a Boolean array. (That is, it maps {T, F, T, T} => {0,2,3}.) This requires a second For Loop but it then can be used with any type of data that Index Array can index:

 

ArrayIndexer.png

 

In most cases this is faster than having a case statement inside a loop because LabView can identify the size of both output arrays from inspection and pre-allocate. (LabView cannot preallocate in the "conditional indexer" function, so we wrote a difficult-to-read but highly optimized version.) A a code pattern this works very well, especially if you make the code pattern on the right into its own VI and add that VI to your palette as "Place VI Contents".

 

Nevertheless, the whole thing is kind of a hack and it would be much better to have a conditional-build-array built into LabView. So, Kudos to Martin and everyone else who suggested this.

 

-Rob

 

JackDunaway
Trusted Enthusiast

As usual, I have enjoyed reading Rob's detailed post. I think I read a post a while ago where altenbach proposed a similar method that JK eventually wanted to include in the OpenG package?

 

One change: the "Include" terminal must be physically attached to each auto-indexed output, not free-floating. For instance, you could have multiple auto-indexed outputs with independent inclusion criteria. tst's illustration above is nice, minus the incomprehensible "?" below the auto-indexed output. Maybe just another small [] that's colored the BOOL Green.