Compare the upper loop with the lower loop.
Take a close look at the loop exit.



greetings from
martin

That's a great idea

Help me understand this post, please.

How does that image differ from using the "Conditional Terminal" that is now availabe in the For Loop under LabVIEW 8.5 plus.

Never mind!

You are looking to control in the data gets added to the arry being built in the tunnel. "Duh"

Ben

I like it I think it's initially going to be a little unintuative (with a tunnel build having the possibility of fewer elements than the iteration count) but I think it's a good idea.

I love that idea. I'm so sick of constantly making that case structure with the build array in it. It always takes up too much space in my diagrams.

sorry, I have only LV8.2.1 installed.

(I had this idea in december 2006, and found that vi today on my old computer. As far as i know it was sent to NI but never got a reply.)

In the meantime, i tried out the "Evaluate LabVIEW 8.5 Online" : The Conditional Terminal of the FOR-Loop in LabVIEW 8.5 is completely different to my design. My FOR-Loop will stil run 100 loops, but on some loops the random numbers are not collected in the array.

greetings

This post has been edited by MartinGreil: May 2 2008, 07:56 PM

Just a quick idea for the discussion...



 ConditionalAppend.vi ( 12.29K ) Number of downloads: 84

Sure, a SubVI is a solution - but keep in mind there are hundreds of types possible. The DBL was just used to make an example.
So finally your code has to deal with variant data type and set the SubVI to re-entrant enabled.

Option "re-entrant enabled" will lead to waste lot of memory when using lot of instances and big arrays.
And of course passing data to the SubVI is less efficient than having the data in the local vi.

You could improve your VI by passing the Loop's "N" to your SubVI. Then (only in the last iteration) give the array to the output. I don't know if LabVIEW can release the allocated memory during the loop of the last call.

The LabVIEW generated code would be much more efficient than using a SubVI.

like this idea
control the data that will be indexed...

It would mean that every autoindexing output tunnel in a loop has an (optional) boolean.

Interesting idea but Ohhhh so unintuitive! One more of those features even LabVIEW cracks would only discover by accident after years of programming.


Rolf Kalbermatter

That's a great idea. In fact, OpenG already has such a function called Conditional Auto-Indexing Tunnel.



This function started as an item on my LabVIEW wish-list, many years ago

-Jim

PS -- Come on crelf and rolfk! Don't tell me that you guys don't know about this OpenG function

Ummm, errr, sure I do...

Actually I do but never used it so far. Reason for me is that it is in fact still unoptimized since you first create the entire array and then build it into the really desired array although this last step is happening rather optimal. In a lot of cases I end up doing more complex algorithmes anyhow that avoid the data memory fragmentation caused by the Build Array inside the case structure altogether.

Happened to help me reduce the runtime of a particular function at some point from about 50 seconds to far less than 1 second at one time. Of course writing that function took me also a bit more than the inverse proportional time of what the first approach with simple Build Array in a case structure had taken me. But considering that my customer has probably saved in this way I don't know how many hours of waiting for the calculation result since, I feel this was well invested development time and it was fun and educational too to do it.

The OpenG function would likely have been only slightly slower but would have taken up temporarely more than double the memory of my approach and that was at that time not unconsiderable in relation to the available physical memory.

Whenever I hear someone swear at how bad the speed of programs written in LabVIEW is I just smile and think about this. It's not that LabVIEW is slower than C in most cases or that it is that much harder to write well performing algorithmes in LabVIEW but the simple fact that it is a lot easier to write an algorithme in LabVIEW at all. Sometimes those algorithmes end up in a way that a C programmer would not even think about to do because he needs to deal with every memory allocation anyhow so is likely to look for an algorithme where he does not need do this all over in his code over and over again.

But the build in feature as suggested by the OP would be even more optimal than the OpenG function although of course not as optimal as the unconditional For loop auto indexing.

If I would be a LabVIEW engineer I would make that conditional auto indexing generate the same machine code as what is used for while loops. There the intermediate array is started of with some intial size and then whenever it gets to small the currently allocated size is doubled. At the end of the loop the array memory is resized to its really used size once more. This is the most optimal approach in terms of memory (re)allocations and data copying for generic situations where you do not know the finally needed size beforehand.

And one last note: I wonder when there will be a patent filed by NI for exactly this . From my understanding of patents it would not be valid since this idea has been published here prior to such a patent filing but who would be going to court with this?

Rolf Kalbermatter

<snip> The above assertions can all be said to be "sort of" true insofar as it depends greatly upon how the subVI is written. They are not true of all subVIs, even all reentrant subVIs, under all conditions. Specifically, I'm not convinced they would have to apply to the specific subVI under discussion if it were written correctly.

I don't think it is any more unintuitive than shift registers, conditional stop terminals on for loops, the "concatenate inputs" option on a build array node, feedback nodes, or auto indexing in general. I could go on. These are all features of LabVIEW that make life much easier/faster to use, but to a new wire worker looking at a block diagram they might not immediately make sense.

That said, once you understand how these features work, it quickly becomes second nature to implement them in your code.