crossrulz

I've been using that little trick for years. I could take either side of the debate, but as a user I lean towards not having to define the output data.

I did think about that during the beta. But at this current time OpenG is supposed to be written in LV2009. It is something to look into.

I started working on a reuse library late last year. I've been working on it off and on. Anyways, I would like to submit it for OpenG. So here's the first batch of code. There are two main parts to this library. First, I included templates for Action Engines for using Queues, Notifiers, and Events. These AEs are pretty simple, but have become a criitcal part of some of my architectures over the years. They are controled using a type def enum. The otehr main part is an Functional Global Variable for stopping an application. I called it a Stop Global. The key features with this FGV is a Set and a Reset mechanism and the use of an Event in order to tell an event structure to exit. I didn't like the idea of using a timeout event in order to poll the global. And yes, the event is controled with an AE that was created by one of the templates. I zipped up the code and left an example of how to use the Stop Global. Everything should be saved in 2011. If you need me to save back to 2009, let me know. Thoughts? Critisism? Praise? Ideas to make them better? Good for OpenG? I'll post more of my library for submisison a little down the road. Messaging.zip Stop Global Example.vi Messaging Library Descriptions.txt

Congratulations! Good luck studying for the CLA now .

Did you forget to attach? Where can we find your code?

Since we are developing OpenG in 2009, we can't expect to use new features. When it is decided to upgrade the base version, then I agree that we should be looking at using the new features (inlining for an example).

I started working on one about a month or so ago. Haven't touched it in awhile. It currently only works with numerics and it doesn't actually make the polymorphic VI, just the instances. I have it setup to take the dbl instance as a template and go from there. Build Polymorphic is the top level VI. Feel free to edit and share upgrades. Build Polymorphics.zip

Mads isn't going to like me here. I was looking through the code and I looked at the Delete Elements from 1D Array VI. I found that I could tweek some more performance out by using the Empty Array? primitive instead of getting the array size and wiring the numeric into the case structure. Wasn't it mentioned earlier how boolean case structures are faster than numeric case structures? The other thing I was looking at is the fact that we already have an Index 1D Array Elements VI. I put the VI where the for loop is to get the deleted elements and gave the performance gained with the Empty Array? right back. I guess overhead from calling a subVI? We could argue the reuse maintainability vs speed. Anyways, I took it back out. Also did some slight cleaning up. The other thing I just noticed (while typing this up), is that the current version is faster than our "improved" versions when the number of elements to delete is small (<25). I think Mads has already mentioned this, but I thought I would throw it out there still. Delete Elements from 1D Array (DBL)__improved.vi

I found very little difference in my attempts. I'm kind of leaning towards taking out that check for simplicity reasons.

I was able to tweek out a little more performance by doing what I said above. In all, this VI is almost 9x faster (on my machine) than the current OpenG Search 1D Array. It might be a good idea so see if we can make a good subVI for dynamically increasing the size of an array similar to what Mads made in his Search 1D Array. Maybe make it a replace element VI that will grow the array if needed? I'll have to think about that one. Search 1D Array (DBL)__ogtk_improved.vi

Mads, I'm curious about the reason for a FOR loop instead of a while loop. It looks to me like you are trying to catch that case where the item found is the last element in the array so an extra search isn't performed. Wouldn't it be better to use a while loop and compare the index to the highest index (i >= N-1, N-1 is calculated before the loop), OR this result with the equal to -1 to get the stop condition? I'll have to see if I can find some time to play around with it.

Impressive, but I think you got your Remove Duplicates from 1D Array messed up. It's the same as the Conditional Auto-Indexing Tunnel.

I'm a little surprised how effective that In Place Element Structure helped with the split array. My attempt at the sort first came out 2x slower than the current implementation. Maybe somebody can find somewhere to improve it. Remove Duplicates from 1D Array (DBL)__improved.vi

I'm inclined to agree. Once I started thinking about it, I was like "what idiot would put duplicates in filtered items anyways?" And even if they did, there should be to few to really care about. And get rid of the error clusters. They are not needed for this function.

The thing that's hurting the current implementation is the abundance of build arrays inside of loops, which you found a way around by preallocating arrays. As long as the functionality is the same, I'm all for the upgrade (I haven't fully tested it yet). I am currious what would happen if we removed the duplicate filtered items.

Well, I found a good solution to this issue. I recently changed jobs and now I'm working with an Alliance Partner. They have given me permission to use my own code for my own purposes. Anything I do for customers is off limits, but I expected that. Jonathan, how we get me signed up to the OpenG team?

So if this goes into OpenG, I would prefer Gotz's implementation (less logic). And Gotz, I prefer the FB node over the shift registers. They look cleaner for some reason.

You are probably still the poster boy since we had to use another buddy in order to find that the first buddy make a mistake. I'm just curious what your code originally looked like in order to get the results you did.

I don't see why Gotz's code didn't work. I downloaded his VI and ran with the same case as asbo and it works perfectly for me. Did you break it before running your test, asbo?

It's the classic "NaN != NaN" scenario

Here's a KB article on setting the read buffer. We had to do this because the unit we are testing is sending at Gb speeds and we would loose the packets in Windows. It only speaks of the receive buffer, but I imagine the send buffer is very similar if even needed. Lost UDP Packets at Fast Transfer Rates The TFTP example looks promising as well.

My understanding is that for true parallelism all of the subVIs should be reentrant. If you have VIs that are really short/fast, you could possibly get away with not making them reentrant to save a little memory. I will throw out the warning to be careful about VIs that need to maintain state (FGVs, Action Engines, whatever you want to call them) and reentrancy.

I'm getting 182 to 184ms for each launch. (XP, 32-bit, 2011 SP1)

What version are you using? How did you do it before? As far back as at least 8.6 (I don't currently have older to check), all you should have needed is the Decimal String to Number. It will find the number even with all of the white space.

Yeah, I was disappointed as well. They usually have such good ones too.