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). 

[smercurio_fc]

I'm trying to understand why you can't use an XY graph, which allows for "non-evenly" spaced points.

[tst]

> I'm trying to understand why you can't use an XY graph, which allows for "non-evenly" spaced points.

Because it's easier to use a single control which remembers the history than manage this yourself, as mentioned in the idea.

donkdonk, if you don't like the concept of using a VI to manage the data, you could theoretically wrap the control in an XControl which would manage the data. That way, all you have to do is drop it and wire the data into it. If you want, this example shows some of the work (which I assume you're already aware of).

[donkdonk]

@smercurio_fc,

One could perfectly well use an xy-graph, in fact that's what I did for the example. It's not even that much trouble to create it. It's just so basic that I've wondered since version 3 why it's not simply implemented.

In our lab most of the time we acquire data in slow running loops (temperatures, pressure, flowrate etc) and we change software driven acquisition rates regularly. Usually we just throw in the standard chart and be aware that it's not time, but "datapoint number" in the x-axis.

@tst,

Thanks for pointing out that using an XControl can make it work. However, as mentioned above, it just strikes me that such a basic thing is not implemented. I even had to explain to non-labview users that it's not standard in.  

[smercurio_fc]

---

tst wrote: 

> I'm trying to understand why you can't use an XY graph, which allows for "non-evenly" spaced points.

Because it's easier to use a single control which remembers the history than manage this yourself, as mentioned in the idea.

---

Ah, so it's a history thing, and not so much a not-evenly spaced data issue. OK - I get it now.

[donkdonk]

@crelf, 

>"and there will be primatives and subVIs that don't need error clusters"

yes, probably lots of them. But then, so what?

>"fitting all subVIs and primatives with error clusters is not only a lot of work [..]"

Probably, but then I would not suggest to provide every primitive with error clusters.

In fact, when I replied to your idea, I was thinking about the 'time delay'express vi I now use a lot more than the 'wait ms' primitive.

>"elements that don't need them will added the overhead required to handle them"

I'm not an expert, but I'd guess that a compiler easily 'knows' the difference between serious error handling and just sequence handling.

>"[..]will make saving VIs for previous versions a nightmare".

Yes, probably a good point mentioning this. 

The idea you have probably is the most flexible and also easy to implement, but as said before, I feel strongly uncomfortable with connections that look like data carriers, but aren't. Especially to new users, it must be a nightmare.

However, someone might have a good idea that make the "sequence connections" look very different from data wires. As a start, I suggest to use arrows (or a line with an arrow every 20 pixels or so) for this purpose.

[donkdonk]

Oops,

comment above accidently is on wrong topic, and my 'edit time' is expired.....

[tst]

Your post(s) in the other topic did make it through. They're on the second page of comments which is very inconveniently accessible through links which appear under the original post.

[Aaron_KZ]

YES, we definitely need something like this.  Also see details for my XY Chart (very similar):

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/XY-chart/idc-p/2045722#M18534

Remember, the more kudos an idea gets, the better chance it may be added to the next labview version.

Crazy_KZ

[AristosQueue (NI)]

What this idea requests is a level of stateful awareness that *none* of the LV indicators has (to the best of my knowlege) and strikes me as a very bad idea. If I were writing an application, the computation and storage of the timestamp of a given bit of data is not something I would code into my UI layer... that's something that belongs in the business logic layer. Asking for this feature strikes me as fairly bad software engineering.

Let me explain: it isn't that this would be necessarily disasterous to write (indeed, I suspect an hour or two with an XControl and you could write exactly this functionality). But consider... you work on this application and you're logging data, and then you have to make a change to your application. Maybe you convert your data logger to be a subroutine somewhere. Or maybe the actual writing to the UI gets delayed or deferred by some parallel operation. Or someone just turns on Defer Panel Updates in order to smooth out rendering. The point is, relying on a UI update to be the thing that establishes the data that is to appear in that UI is a bad design, one that I would strongly suggest you avoid. I would strongly oppose the addition of this kind of chart to LabVIEW on the grounds that *people would use it*, and they would be successful for a short window, and then everything would fall apart when they made small seemingly unrelated changes to their applications, and they'd be totally lost as to why "LV stopped working". The so-called "workaround" proposed by crossrulz does not strike me as a workaround. It strikes me as absolutely the right way to architect your application from the outset so that you're completely shielded from those kinds of unintended side effects.

The business logic of your program should establish the data to render. The UI should only be in charge of rendering that data, not computing it. Identifying the ongoing timestamp between points is computing it.

[donkdonk]

@AristosQueue,

[..]the computation and storage of the timestamp of a given bit of data is not something I would code into my UI layer... that's something that belongs in the business logic layer[..]

I partly agree, but then I think I am not sure where we misunderstand eachother or maybe I am just not clear enough.

I do generate the timestamp at the moment and place where the data is generated (sometimes even on a relatime target), then send it together with data via network streams (RT target) or queue to the visualization section.

In our case the time stamp is just the seconds that elapsed since start of data acquire.

Why you would not like to have the chart store the timestamp once you feed it with it, is not clear to me. After all, it also stores the data you feed to the chart.

I just would like to feed my time chart with a time (preferably with the option to use a) the LabVIEW time stamp or b) just a number representing the elapsed time) and the data belonging to that time.

Just like I am able to feed the XY graph with X and Y data, I would like to feed the time chart with t and Y data, but just one point in time and the chart will build a history of (elapsed)time and measurement datapoints.

That being said, I must admit that at the time I placed this idea, I did not realize you can feed the chart with varying time and measurement data, if you use the build waveform primitive. That actually does, more or less, what this idea is about. However, it is far from intuitive: using the build waveform you continuously update t0 ( at least I would not have guessed in a 100 years you can use it this way).

The help does not show you how to use it this way, it actually telles you:

"Waveform Graphs and Charts—Display data typically acquired at a constant rate".

[..]The so-called "workaround" proposed by crossrulz does not strike me as a workaround[..]

Yes, you are right in a fundamental, basic sense. The workaround is that you use a waveform type that usually is meant to handle data with a t0 and a delta-t and (losts of) data  sampled at a constant rate. Now you keep updating t0 and don't use delta-t.

It keeps striking me that people suggest writing X-controls or using X-Y-graphs.

You could also argue to leave XY-graphs out and construct them using charts, or write a plot routine yourself.

NO! This time strip chart is such a fundamental thing, people really are amazed it's not something you can just pick from the palette.

However, conclusively I would say the functionality is already in there, but far from intuitive.