Waveform chart # of data points, impact on performance

[Blokk]

Hello,

I have searched the forum but I got only partial info yet about this WF charts behavior.

I have a TAB control on the FrontPanel, and one TAB page contains a WaveformChart. I plot points with 0.5 Hz speed, and I have 8 plots (curves) on the chart.

I would like to have many hours of history, so I set the chart history length to 44000.

Everything works as expected, but I see some sluggish behavior, when I click another TAB page, and back to the TAB page where the chart is located.

In this case, the appearance of the chart takes about 1-2 seconds. This is not a big problem, since the user usually monitors the last ~10 minutes (disabling X-autoscale and change left time "border"). When this smaller amount of data points are visible on the chart, the TAB page change is fast after the mouse click. When several hours of data is presented, it is slow.

I guess the main reason of this behavior is that, when I switch back to the chart TAB page, the OP system has to re-draw a large amount of data points, and it takes much time?

I am curious about what is the "best practice" in such a scenario? Shell I store the data in a shift register, and use an XY graph (I have actually data points as doubles and corresponding time stamp values, there are small fluctuations in time, so I need ALL time stamps)? Would it help? So I could append the new XY data point to the array in the shift register, and I redraw the Graph at every new point?

Thanks for advice!

[johnsold · Accepted solution]

I am not sure whether this applies to your situation, but LV sometimes does not update front panel indicators which are not visible, such as on a tab page which is not in front. The chart has its internal buffer, but I have no idea of how redraws are handled when many points have accumulated while not shown.

A graph redraws everytime data is written to it because you need to write the entire data set each time. With the shift register approach the graph would only see the latest data when it becomes visible again, so this seems like it should be suitable.

Another thing: Your graph or chart does not have 44000 pixels along the X-axis! LabVIEW will reduce the data to the number of pixels to be displayed. That takes some time also. By using the shift register approach, you can mange the data fed to the 500-1000-2000 pixels your graph will show. This eliminates the need for LV to do it and you can control the method: average, decimate, sliding window, and so on.

I would go with the shift register and graph.

Lynn

[Blokk]

Thanks, you just emphesized the key problem here: it does not make any sense to plot more points than the monitor and our eyes could see  🙂

Anyway, I will move to the Graph approach and either I will use some decimation/averaging or a slide-control.

regards,

[DFGray]

You may want to read this whitepaper.  It includes code to decimate data for display.  The decimation routines work well for graphs; not so well for XY plots.  If you need to decimate for an XY plot, let us know and we can probably help.