01-21-2016 11:47 AM
I am working on an application where I am required to plot non-periodic data that I receive in [acquisition time, value] data point samples and present to the user on something that looks like a scrolling strip chart. I have to plot multiple measurments per strip chart and provide the ability to zoom in/out, scroll and return to a scrolling real time mode. I decided to use XY Graphs to accomplish this with my own data buffering scheme.
When using an XY Graph, I am experiencing significant performance differences between the types of interpolation used to plot my data. Attached is an example VI that captures the essence of my application. This example generates three different sine waves and stores them in [x-array, y-array] clusters. After the arrays are filled with an initial number of data points, data is added to the arrays once per second and plotted on XY-Graphs. This example has 2 XY-Graphs, each with 9 channels (plots) with the sine waves repeated. The data arrays are capped at a maximum buffer size. For this example, I fill the arrays with 10,000 data points and cap the arrays at 10,000 data points. New data points are added and the oldest is thrown away. While running on a 6 core PC where 17% CPU corresponds to 100% utilization of one of the cores, I have listed below the CPU% performance I get based on the type of plotting interpolation selected. Based on research and my own testing, I am fairly certain that the performance overhead of this VI lies in the XY-Graph indicator itself.
Interpolation Type CPU %
======================== =================
0 - none 5% (30% of core)
1 - stepwise 14% (84% of core)
2 - linear 5% (30% of core)
3 - stepwise horizontal 14% (84% of core) <--- my preferred interpolation choice unfortunately
4 - stepwsie horizontally centered 6% (36% of core)
5 - stepwise vertically centered 6% (36% of core)
I am using LabVIEW 2013 SP 1 on Windows 7 Enterprise. The platform is an Intel Xeon CPU W3680 (3.33 GHz) with 16 GB RAM.
I can maybe understand the performance differences between no interpolation and stepwise interpolation, but why the great difference between the types of stepwise interpolation? Thanks for any suggestions and/or insight you can provide.
Kevin
01-21-2016 01:29 PM - edited 01-21-2016 01:41 PM
Since your time spacing is regular, is there a reason you are not using plain charts?
Why do your plots have points in addition to the interpolation?
Hiding an event structure inside a case structure is a really bad idea. If you keep changing the interpolation type wht the case is false, it will lock the front panel without any way to service the event. Even if you would configure it to not lock the front panel, you would queue up a large number of events that the will execute in rapidfire whenever the case turns true again.
U32 is not a good container for a timestamp (you will run out of bits in the near future). Use DBL.
01-21-2016 01:36 PM
Time spacing is only regular in this example. My application has non-periodic data. I needed to generate a large set of data to stress the XY graph like the real application does after running for several hours.
I'm not sure I understand "Why do your plots have points in addition to the interpolation?". In this case, interpolation refers to have a plot is drawn from point to point. I.e. linear (a straight line between each point), stepwise (horizontal and vertical lines between points), etc...
01-21-2016 01:45 PM
If you change the interpolation to none, you see leftover points for all your plots. the point style should be "none" instead. Less work.
Maybe you only want to display the visible range and display a subset of the data as a function of a seperate scrollbar. Graphing ~100k points is a lot of work.
01-21-2016 02:13 PM
@altenbach wrote:
Since your time spacing is regular, is there a reason you are not using plain charts?
Why do your plots have points in addition to the interpolation?
Hiding an event structure inside a case structure is a really bad idea. If you keep changing the interpolation type wht the case is false, it will lock the front panel without any way to service the event. Even if you would configure it to not lock the front panel, you would queue up a large number of events that the will execute in rapidfire whenever the case turns true again.
U32 is not a good container for a timestamp (you will run out of bits in the near future). Use DBL.
Totally agree with your comment regarding the event structure inside the case structure. This VI is nothing more than test code thrown together in a few minutes to test the performance of the different xy-graph plot.interpolation types. If you have a few minutes, could you run the VI and change the interpolation type and record your platform's performance? I'm hoping someone will validate my observation on the interpolation type performance degradation.
The plots have points in addition to interpolation so that I could see them when interpolation type is set to "none".
I'm not using the U32 container to store timestamps. I'm using it to store epoch time which is the integer number of seconds since some base line time (i.e. Unix Epoch Jan 1, 1970 or LabVIEW Epoch Jan 1, 1904).
01-21-2016 02:26 PM
@KevinSmith13 wrote:
I'm not using the U32 container to store timestamps. I'm using it to store epoch time which is the integer number of seconds since some base line time (i.e. Unix Epoch Jan 1, 1970 or LabVIEW Epoch Jan 1, 1904).
The LabVIEW epoch as U32 will wrap around in 2040, so it really depends what the expected lifetime of the code really is. Don't underestimate code longevity. I am stll running 20 year old LabVIEW 4.0 code ;). If you are not careful, it will be Y2K all over again. 😞