LabVIEW
Snippet: "query" the chart history length programmatically
Would have posted to this thread, but was concerned that the misspelled subject might keep it from being found by future searches.
I have a brute force, inelegant, very mildliy tested workaround for programmatically determining the history length of a waveform chart. In my app, I have a single chart on my gui that is meant to display history from any one of several duplicate test stations. To help accomplish this, I wanted each station to have its own lossy queue whose size is equal to the chart history length. Then, whenever the user chooses to look at a different station's data, I can simply copy the entire contents of the lossy queue over to the chart.
Here's how I "query" the chart history length programmatically:
Note: Some of this feels a little dubious, but it has seemed to give correct results so far. Specifically, several of the XScale properties seem to refer to the graphical rendering of the scale rather than an index # to the history data. Can't guarantee this'll work for all combos of other properties -- I tested with a fairly generic, nearly straight from the box waveform chart.
-Kevin P
Hmm, any reason why you can't just do this?
If you don't modify the Array, it's just copying a pointer, right? Or does this operation automatically make a copy of the data and induce horrendous performance problems?
You only need to do this once, right? If this isn't a performance bottleneck, simply read out the old data, write a large array to the control and then read it back. The size of the array gives you the chart history size. No rounding errors, no scale juggling.
When you're finished, write back the original data.
But I concur that properties like this are a PITA. Just like creating Axes on graphs. Try doing that programatically, even at edit-time with scripting. 
@Intaris wrote:
Hmm, any reason why you can't just do this?
If you don't modify the Array, it's just copying a pointer, right? Or does this operation automatically make a copy of the data and induce horrendous performance problems?
That doesn't actually do what I need. The "History" data array size works its way up from 0 to History Length as the app runs and data is written. It *is* bounded, but until I fill the chart all the way up, this method won't reveal what that bound is. I need to size up those lossy queues at the beginning of the program, before any data has been written to the chart.
As to the other comments so far:
- I chose charts over graphs to get some of the built-in features of charts for real time monitoring rather than having to manage them myself. Things like zooming the X range, horizontal scrolling to show different segments of the history, that kind of thing.
- just absorbed the followup comment about writing a dummy oversized array to the chart before running the quoted snippet above. Yeah, that oughta work. I just don't like the general case of not knowing how big a pre-write I need to do. I guess it wouldn't be too bad to loop while writing the same big-but-not-crazy-big array until the History size is smaller than the # of samples written.
The main hitch I see in that approach is that I'd like this to be a reusable utility vi, but a subvi that works by filling up the History would need prior knowledge of the chart datatype. (Just thinking out loud here, overall it does kinda feel cleaner than the stuff I was doing with the scale properties.)
FWIW, a little more testing led me to modify and simplify my snippet b/c the previous one might leave the X scale looking different on exit than it appeared originally. Seems like a side effect of the way those properties are kinda more about the display of scale information than about actual index #'s. Anyhow, here's v2, but hopefully someone else has a better generic v3 they can offer:
-Kevin P
@Intaris wrote:
Hmm, any reason why you can't just do this?
If you don't modify the Array, it's just copying a pointer, right? Or does this operation automatically make a copy of the data and induce horrendous performance problems?
Until you've filled up your chart history, the length of the array in the history would be shorter than the chart history length. Run this on a chart that hasn't gotten any data yet, you'll wind up with a 0.
