Jump to content

Conditional Append


Recommended Posts

QUOTE (MartinGreil @ May 2 2008, 11:30 AM)

Compare the upper loop with the lower loop.

Take a close look at the loop exit.

conditionalappenddesignfc4.gif

greetings from

martin

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 LV 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

Link to comment

QUOTE (MartinGreil @ May 2 2008, 11:30 AM)

Compare the upper loop with the lower loop.

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

Link to comment

QUOTE (neB @ May 2 2008, 05:56 PM)

... that is now availabe in the For Loop under LV 8.5 plus.

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

Link to comment

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

Link to comment

QUOTE (MartinGreil @ May 2 2008, 10:30 AM)

Compare the upper loop with the lower loop.

Take a close look at the loop exit.

conditionalappenddesignfc4.gif

greetings from

martin

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

Link to comment

QUOTE (MartinGreil @ May 2 2008, 08:30 AM)

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

Conditional_Auto-Indexing_Tunnel.png

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 ;)

Link to comment

QUOTE (Jim Kring @ May 4 2008, 01:02 PM)

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

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

Link to comment

QUOTE (Michael_Aivaliotis @ May 5 2008, 09:02 AM)

I like this idea. Along the same lines (or maybe this is hijacking), why does a 1D array always become a 2D on for loop borders? Why can't we concatenate a 1D array at the border. It seems that tunnel has the potential to do a lot more than it can right now in regards to array manipulation.

I can't se the picture of what you are talking about. What is wrong ?

regards

Bjarne

Link to comment

QUOTE (rolfk @ May 4 2008, 05:34 AM)

Interesting idea but Ohhhh so unintuitive!

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.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.