crossrulz

Is this a CAR for the Delete From Array? I sure wish we had visibility into the CAR database...

Just a general comment: There is no need to set your file position inside of the loop. The position increments during the read. After a read, the position will be set to the next byte, so the the next read will start where the previous left off.

I fully agree with Philip. You can right-click on the Read from Text File and select "Read Lines". The glyph will change. Set the count to -1 to read the entire file in lines (the default becomes 1 line). The other option you have is to use the Spreadsheet String to Array.

Hate to burst your bubble, but Darren included a little nugget: <vi.lib>\Utility\High Resolution Relative Seconds.vi I know it's there in 2011 and 2012.

Ok, here's the updated VI with the correction found above. Long Wait.vi

Yeah, my benchmarks found that the delete from array was really slow. What I ended up doing in the proposed VI was to reverse the array and then index the first element. This method was slightly faster than the index array size -1.

Yep. I goofed it up when cleaning up. Will repost when I get a chance to fix it later today.

They actually use the Reshape array. But the math for how to setup the dimentions is done inside these VIs.

More submissions to OpenG. This time I have a few array functions that I have had to use over the years. These VIs are for taking a 1D array and turning it into a 2D array, taking a 2D array and turning it into a 1D array, and to simply get the last element of at 1D array. Thoughts? Critisism? Praise? Ideas to make it better? Good for OpenG? 1D to 2D array.llb 2D to 1D array.llb Final Array Element.llb

Here is another VI I am submitting for OpenG. It is for when you have to wait for something to happen and this wait is in the domain of seconds. You don't want the user sitting there wandering if the program froze. So I made a VI for these long waits that includes a progress bar. Notice that this VI uses my Global Stop VI found here. Thoughts? Critisism? Praise? Ideas to make it better? Good for OpenG? Long Wait.vi

Here's a few generic CRC VIs I made sometime over the years. They do not use the lookup tables, so they may be a little slower. But they can be set to any CRC configuration. Included are an 8-bit, 16-bit, and 32-bit versions. CRC.llb

I think I found it. In the testApp.vi, the first thing that happens is the Close. The shift register is of the parent’s class. Since the shift register hasn’t been initialized, it will have a class of the parent. Therefore you get your “parent class was used” error. This error is then causing the rest of the code in the event to not run and the shift register will have a “parent class” loaded into it. I recommend changing the error to a warning and see what happens.

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