I'll try to address some specific questions, but first have some general comments. Step back and carefully prioritize the data handling inside your app. I've been guessing that the top priority is to sustain data acq and file storage at a full 1 Meg/sec. I'm treating that as a "must-have." I'm treating the nearly-live user display as a "nice-to-have" where the goal is an update rate that (A) doesn't bog down the data acq and file storage and (B) is fast enough to provide useful feedback to an operator.
Now I'm sure I'm not the very top expert around these forums on performance issues but I'm not too shabby. So you may find that some of my performance-enhancing suggestions aren't strictly necessary for your specific app right now, but I'm suggesting you try them anyway as habits that are very likely good ones.
If the subset will copy the data in any case, then I don't need to add a single-frame sequence for that, is that correct?
No, I'm not sure that's correct. I'm not 100% sure either way, but I know that LV *can* sometimes carry array subsets around without needing to perform data copies. The single-frame sequence helps provide LV a hint that the other branch of that array data *must* be done executing before the array subset is performed. LV may also figure that out on its own, or it may make a copy either way for reasons I'm not prepared to explain. But personally, I'd give LV the hint anyway and hope for the best.
I want to display some subsets of the array but not just one, for it's a long array and the displaying didn't update fast enough. Do you know how I can do that?
Well, it depends. In general, you would extract multiple subsets and then merge them together. To do it with the best possible performance may be a tricky question. Using "Build Array" is probably *not* the best way. Auto-indexing to the output of a For loop with a constant # of iterations probably *is* good, but your app may need more flexibility than that.
However, you may simply be trying to jam too much information ("it's a long array") into a gui display element that simply isn't capable of updating very quickly. Or you may be fixed on the idea of displaying more information than an operator needs.
Here's what I would advocate for pretty much *any* high data-rate app. *DECOUPLE* the gui display updates from the data acq and processing code. Architect the code so that the critical high speed stuff *never* waits for the gui stuff. This is the thought process behind my recommendation of Notifiers. A producer (the file storage code) can write to the Notifier at one rate while a consumer (the gui code) can read from it at a different rate.
The reason the displaying didn't update fast is it happened after the dequeue, so I put it before the queue right after the DAQ. I used a branch of the acquired data
It sounds like your idea of "displaying fast" is more a measure of lag time than of average data rate. Again, this will go back to those overall priorities. My suggestions were intended to help make the data acq and file storage to run quickly, efficiently, and unimpeded. A side effect of the methods I presented is indeed to increase the lag time from when an event occurs until its presence is visible on the display. Branching off the acquired data before it is sent to be Enqueue'd will almost certainly require data copies inside your most critical loop - the data acq loop. I would *not* do it that way. Again, even if it seems to work good enough for today, it would not be a good habit for apps that demand high performance.
-Kevin P.
ALERT! LabVIEW's subscription-only policy came to an end (finally!). Unfortunately, pricing favors the captured and committed over new adopters -- so tread carefully.
