crossrulz

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.

Oh, it has been that way for a long time. More recently I was browsing for information on being a Certified Professional Instructor and two hours later I get a call about it. Yes, NI logs everything we do on their site.

Under the Volume License Agreement, each developer is allowed a single home license. A license file needs to be created through the license manager that can then be installed on your home computer.

I would have to go look at the agreement again, but I believe they own anything I do, even what is done in personal time. Well, there's also the discussion of whether or not my company thinks I truely have personal time (they can call me in for test failures at any time of the day or night), but that's another issue.

I am interested in helping in developing OpenG. My problem is that I work for a company that automatically owns everything I do. I plan on making an agreement with them so that I can develop open source. I am an engineer, not a lawyer. Is there any advice for what should or should not be in such an agreement and any specific wording to be aware of?

I looks like when one clone is killed the FGV is reinitialized, meaning that the reference is lost. I haven't quite rationalized it in my head yet. But I have seen with other FGVs that if I just run it on its own and then run it again, the data is lost. I updated your VIs so that the controller handles maintaining the FGV and it worked just fine. DEWC.zip