Charts with "non-evenly spaced" timestamp per datapoint

[donkdonk]

Charts assume that the X-values always represent evenly spaced points. With LabVIEW 's charts, you only provide the Y value, and do not specify the X value.

For arbitrary X-values, one has to construct something (usually involving shift-registers).

Often charts are meant to display values as a function of time. If one changes the acquisition rate, one would expect the chart to change accordingly.

As LabVIEW only allows you to scale (and offset) the chart's X-axis, it would be nice to have a timestamp input (for instance expandable form the chart's terminal).

Resulting chart would look like this (here two plots). 

[AristosQueue (NI)]

Ah... I had interpreted your idea (and a similar one that was just closed as a duplicate) as having the chart draw the chart in real time -- in other words, as you write a value to the chart, the timestamp associated would be the moment the data was written to the chart.

I had not realized you sought to actually change the data type that writes to the chart to be a cluster of the value and a timestamp. Your clarification is a variation that I can see being viable.

[crossrulz]

I can completely get behind a chart excepting a cluster containing a timestamp and a single sample.  Granted, the only thing it helps over the current "work around" is that it would remove the Build Array before building the waveform.  So maybe we should just make NI update the documentation to talk about how the chart handles the waveform data type.

[donkdonk]

@ AristosQueue,

Good to know we understand eachother now.

My mistake as I guessed this being such an obvious chart omission that everybody would cheer and applaud: finally someone having the guts to point it out

@ crossrulz,

I can completely get behind a chart excepting a cluster containing a timestamp and a single sample [..]

yes!, however I want to point out that "single sample" also can be a scan of multiple channels, just like current chart behaviour

[GregSands]

I could use this idea.  But I presume the timestamps would have to be strictly ascending (and non-overlapping).  How would that be enforced? Is it better to think about delta-t which can be forced to be greater than zero? There something about changing t0 just doesn't feel right!

So I wonder if there are actually two similar but different ideas here:

1. A new XY Chart (which is quite like crossrulz workaround) where a data point is provided as a new XY pair, or array of pairs (or complex numbers), one per plot.  In this case there'd be no restriction on X.  It's essentially an XY Graph which is updated one point at a time.
2. An extension to the Waveform Chart for which it's not the X-value (t0) that is specified, but a variable delta-t (dt, 1 by default).

[AristosQueue (NI)]

Can you build an XControl that shows the behavior you want? It would be straightforward for me to show that to the dev team rather than trying to describe it myself.

[tst]

AQ, way back when this idea was posted I linked to an example which shows this (absolute X values, not delta X, which I don't really see a need for), and there's one which ships with LV, called XY chart, although it's not a very good one, IIRC. An XControl would probably just merge the buffering VI in my example into the indicator. The reason I never voted for this idea is that I don't actually need these very often and when I do, using a buffering VI similar to the one in my example works well enough.

Greg, I don't think there's any need to enforce the X values to be ascending. If you have non-ordered X values, the line simply goes back. It looks weird, but it's valid data, even if it doesn't make sense when your X values should be ordered.

[AristosQueue (NI)]

tst: What about the fact that charts have different display modes? Would a strip display mode make any sense if it wasn't monotonically increasing timestamps?

[tst]

You'll have to ask someone else. I don't use charts often and when I do, I use whatever the default mode is and I don't actually think this idea is all that necessary because of the easy workaround. I would say either allow it and let the user suffer the weird result (lines wrapping around or points not appearing) or disallow the non-default display modes in XY charts.