Gary Rubin

I find that they often do too much. The few times I've used them, I've immediately converted them into a subvi, then stripped out all the cases and conditions that I didn't want/need. I guess I use them as templates/examples.

We're running standard LV8.6 EXEs on Windows Embedded Standard on compact flash drives. I didn't do the install, but I think that we followed some of NI's directions with little trouble.

You can still do that at Reagan National Airport. There's a park just north of the airport that the planes overfly as the take off and land. You can hear the vortices in the air after the incoming planes fly over.

The effectiveness of these all depend on your SNR. How about a simple moving average (SMA) on the absolute value of the data and look for the result to be below some threshold? The size of the SMA window would depend on the noisiness of the data. That uses a for loop, unfortunately. A slight variation would be to traverse the data array and check for the last N elements all below a threshold. Again, this uses a for loop. Or a combination of my original idea and ShaunR's... Do the diff (or sum) with the array shift, compare to a thresh, then convert from boolean to 0,1.

That's alright. I reported Yair's original post as a test. Admin edit: Yep, that was reported successfully by Gary Rubin with the following text: "testing..."

I was able to report a post. I'm also the only non-premium member who's commented on this thread. Coincidence? Admin edit: this post was reported sucessfully by Phillip Brooks with the following text: "Test of reporting as a non-premium member."

While we're being creative, here's another way to do it. Again, it works for this particular sim data. Not sure it's any more efficient than the diff method though. Curious to see your approach.

Thanks Chris. I almost ended up with tea all over my monitor.

Well, you'd have to compare apples to apples. The input into the threshold peak detect looks the same as your output.

Does your data always have that oscillatory pattern? This seems to work on your sim data, but I don't know how representative that is of your real data.

My impression is that you have to write your number-crunching code in C using CUDA, and this just gives you a way to call that code from LabVIEW. Not being a C programmer, I was hoping for something that would let me target the GPU with my native LabVIEW code (or at least something that looks like native LabVIEW code).

Oh, NOW I get it...

I don't get it.

We once had a data recorder fall out of a rack because the slides weren't installed right. After that, I felt like I could tout that the system had been drop-tested from a height of 3 feet.

My solutions usually come to me in the shower.

I'm sure I'm not alone in being grateful that ShaunR changed his profile picture from the dancing baby to whatever it is now.

GPIB can be pretty slow. Is it fast enough for your control loop?

I'm in that boat too. I get the impression that those of us who use LabVIEW for data acquisition and processing operate in very different world than those doing ATE. In ATE, I would imagine that the system requirements are pretty clear from the outset. You know your process, and you know the manner in which you want it automated. For data processing applications, the development process may be much more iterative, as you may not know what has to happen in step 3 of the processing until you can see the results of step 2. Likewise, the user may not know what his UI requirements are until he sees some initial results. This is especially true when using LabVIEW to develop new processing algorithms.

Can't wait to try it! Thanks!

Yep, I got that one. Thanks.

Thanks Paul, I was wondering why I was suddenly unsubscribed. Gary

It wasn't you. Activity on this thread ebbs and flows.

Immediate.

My email notifications include the following: This is not accurate; I just got 5 updates for the same topic.

Don't forget "make coffee" and "get donuts"