LabVIEW
Why are charts and graphs so difficult?
@Bob_Schor wrote:
While this is certainly a clever idea, it is a "trick" that works for a peculiar reason. Recall that the name of this Indicator is Waveform Chart. A Waveform has three components: t0, the starting X Value, dt, the constant spacing of all the unspecified, but computable X values, and Y, an array of all the Y Values. This "trick" lets you specify X (as t0), ignore dt (since you have only a single X), and replace the Y array with a single-element Array holding the single value of Y. I suppose you do get scrolling and other "Chart" attributes (I've never actually tried using this trick, though I applaud its cleverness).
Obviously, it "works", but probably just because some clever programmers added a lot of duct tape behind the scene. 😉 While I always knew about it, it's not something I would ever be willing to use.
A waveform is defined by x0, dx, and an array of [Y] and here each point is it's own waveform. So if the graph contains multiple waveforms, why are they all contracted into a single plot and optionally connected by lines? Even the data structures are wasteful, because each point requires at least 28 bytes (8 bytes for x0, 8 bytes for dx, 8 bytes for Y and 4 bytes defining the size of each Y array, plus more). In comparison, if you maintain the xy graph in a complex array, we only need 16 bytes per point (or less if SGL is an option).
Note that the "built xy graph" express VI (Another thing I am not willing to use, though ;)) has an option to retain data between calls, basically turning it into a glorified xy chart. It even has "enable" and "reset" inputs. (Be very careful not to run out of memory, we cannot set the history size because nobody cares! :()
@crossrulz wrote:
wiebe@CARYA wrote:A restriction is X has to increase, or nothing will show?
Another restriction is all channels have to have the same number of waveforms added.
Yep, all hell breaks loose when X goes backwards.
As far as the number of waveforms added, that only makes sense since you should only be writing to a chart from the terminal. This means you should have an array of waveforms already; a waveform for each channel. So I don't really consider this a restriction.
I mend XY Graphs don't have that restriction.
Search LabVIEW like a graph! 
Hi mcduff,
@mcduff wrote:That being said, a thousand to ten thousand history points although inefficient probably won't make too much of a difference on a modern computer.
Well, the memory requirement probably isn't a problem, but LabVIEW charts/graphs are rather slow when it comes to paint a lot of points in the plots!
Ever tried to plot a large (aka a lot of points) plot containing noise on a graph set to autoscale? (Especially when antialiasing is enabled or thicker lines are used?)
@GerdW wrote:
Hi mcduff,
@mcduff wrote:But 10k or less, really doesn't matter too much, only when 100k - millions of points.
I had problems with 9600 points/plot with noisy data - then I also included a decimation step…
I found the sweet spot around 70MBi of plot data. More than that, it gets sluggish. haven't tried recently, but 70 MBi was consistent over a long period.
I usually use min\max decimation, but I turn each min max block into 4 points, the first value, the min, the max and the last value. When data has large gabs, this ensures that the line between the parts is right. Not sure if that's standard. Just min max works OK, but isn't 100% accurate.
I still don't get why we have to do the decimation. If it was build in, nobody would have to. I don't see a downside.
It wouldn't be so terrible if there was o much to consider. Like data updates, scale updates, user interaction, etc. Not to mention that the user can change to line styles that really don't make any sense with decimated data (like points). This again escalates a simple problem to lots and lots of work. We can't provide the default plot legend, we have to make our own... I fairness, I usually do that anyway, because I don't want my users to set interpolation and other nonsense.
