Multiple plots from the same x-axis without duplicating the axis in memory

[BowenM]

I was hoping there was a way to do an XY Graph containing multiple plots without duplicating the x-axis in memory.  I am dealing with fairly large data, and that duplication of the time domain array is taking up considerable amounts of memory. I have of course used data value streams to prevent further duplication of the data as I'm reading it in and working with it.

I have looked in to the GigaLabVIEW library, and will use it if I must, but it adds more complexity to the program. I am hoping there is a simpler solution.

And to clarify, I highly suspect the answer is going to be "Nope. Can't be done." ... but I'm hoping 🙂

Thanks,

-MB

[RavensFan]

How many plots are you talking about?  How many points make up each plot?  Do all the plots contain data for each of your X values?  Are the X values equally spaced?

Graphically, the charts and graphs can only show so many pixels of data.  So having more data than the graph can show doesn't help.  You could decimate the data to a number closer to the number of pixels that make up the graph and send that data to the graph.

[BowenM]

Thanks for your response.

"How many plots are you talking about?"   5-6. I don't like plotting more than that because it just looks messy.

"How many points make up each plot?"  That depends on how long and what rate the DAQ system ran for. Often enough for me to worry about 🙂

"Do all the plots contain data for each of your X values?  Are the X values equally spaced?"  Yes. It comes from a DAQ. I build the x axis in a for loop * 1/rate.

"Graphically, the charts and graphs can only show so many pixels of data...."  This is true, until you give them the option to zoom in.  If you decimate the data, it is missing when you zoom in on a part of the plot.  To overcome this, you grab the x min-max for the zoomed area, and reread the data.  This causes LV to rescale the y axis, (or you have to start doing manual scaling).  It is possible, but cumbersome.

[RavensFan · Accepted solution]

5-6 plots doesn't sound bad.

How many points is a critical part of the equation.  How many is enough that you start to worry?  Without somewhat hard numbers, it is kind of hard to determine whether you might have a problem.

Since the X values are equally spaced, then you should be using a waveform graph.  A waveform contains an array of Y values, a T0 initial time, and a dT time between samples.  The graph handles the calculations from the T0 and dT to build the X values needed for the graph.

[BowenM]

"How many points is a critical part of the equation.  How many is enough that you start to worry?"   The program is going to be for general acquisition to be used by several technicians. I need to make sure I build in to it the capability to deal with larger data sets. I doubt it will ever get beyond about 15M points / channel, but...

"... you should be using a waveform graph."  I feel silly. I started the project using the XY Plot because the dT might not have been the same. This is the correct solution. Thank you 🙂

[R^2]

Just a heads up... I just finished a project that has up to 10 graphs (5 primary with the option to show historical data as an "overlay" of sorts). My DAQ was running at 250 S/s and we wanted to run for 60 seconds. I tried both the waveform and strip chart and both brought my system to it's knees... Trying to show "live data" with only 1 update per second. When I switched to the XY Graph  I was able to do update at 10-15/sec and extend the view to show 120 seconds with no problems at all. I even tested a 5 min run that ran just fine with updates hitting at about 8/sec.

I initialized the array before each run and then added the new data to the end and deleted that many samples from the beginning (y-axis). Once the x-axis data was initialized  (based on the S/s and expected run time) I never touched it again. 

Have you run some some benchmarks on 5 graphs with 15M points/channel? To see what the update time is will take?

Even with the XY-plot you don't have to show all the data during the acquisition. I would use the property nodes to only show a few 15-60 seconds of the live data and when the tech needs history they "zoom out" or scroll to get the rest this should reduce the time it takes to update the graph during the acquisition.

What ever you do, if you think the 15M points / channel will be a some what normal occurrence test it to make sure everything stays usable. 

Good luck!

R^2 (Ryan)

[BowenM]

Thanks for the input. I was doing some testing with the largest data set we had run before and it also "brought my system to it's knees".  This was greatly reduced when switching all of my reading / control to the data reference type:

http://www.ni.com/white-paper/9386/en/

which prevents LV from duplicating the memory.  This helped a lot, but was still a bit sluggish; however, using the correct plot formatting combined with data reference seems to be sufficient so far.