LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Graphing takes too much time!

Hello,

I'm developping a project to monitor some inputs of a DAQ board!
I'm reading 80000 samples per second per channel(normally 8 channels).
After processing I get 2 results per second per channel.

To be able to graph my values I use a XY graph, because I want to keep the data tracked with the time it happenned (acquisition can stop and the restart and I want my time axis to be continuous) and I have to have a buffer of 24 hours - so I have in the graph 172800 per channel.
Everything works nice for one channel and even for two or three! My problem is that when I start increasing more my number of channels, my processor load increases a lot and after a while it stops because it cannot get all the data from the board and process it.
The rest of my program take 19% of processor load, my graphing part takes up to 80% with a large number of channels.
Obviously I can understand the working with very large arrays can take to these situations - for each iteration (I have 500ms for it) I have to rotate my data array, and insert a new element on it (this takes about 150 ms for 5 channels) I have to transform my buffer arrays in an array of clusters to send to the graph (this takes arroud 160 ms) and I have to shift the x scale of the graph so it will show the last data sent (this takes 250 ms!).

I already played with the sincronous display, I changed all the settings from windows to increase performance but the result is the same.
I tried also the Express XY graph in chart mode, but after 24 hours thisis even worse.

Does anyone have any idea of a way to solve this?

Any comments are appreciated,

Thanks,
Paulo
0 Kudos
Message 1 of 6
(2,875 Views)
Hello,

I'm posting a vi with the graphing part of my program.
Maybe this give a better idea of it...

Thanks,
Paulo
0 Kudos
Message 2 of 6
(2,860 Views)
In the past I have had some simmilar problems. I alleviated the issue by putting the graph in its own thread (loop in labview) the graph thread can run asynchronously with the data acq loop. The acquisition and data processing is usually more critical than the display portion of a program. By placing the graphing in its own loop you can simply control the rate of graph update with a wait statement leaving the data acq and processing to run as fast as possible. Slowing down the frequency of graphing has only a negative astetic effect and updates of 1 per second or slower is usually acceptable but this is application dependent (remember that the fastest update a human can see is ~30Hz anyway). If you dont want to deal with passing data between threads, you can also put the graph node inside a case statment and only graph on case where modulus(n) = 0 is true, therefore slowing down the rate of graph update to a frequency of (loop itterations)/n. again n can be modified and channel dependent so more channels will have a slower graph update frequency but not effect your data acquisitions. Also turn off antialliasing on the graph channels this slows down the painting of the graph significantly (in my experience). These are tricks which worked for me hopefully for you too.
-Paul
Paul Falkenstein
Coleman Technologies Inc.
CLA, CPI, AIA-Vision
Labview 4.0- 2013, RT, Vision, FPGA
0 Kudos
Message 3 of 6
(2,854 Views)
there is no need to display 172000 points per channel, downsize your data to be displayed. Remember the graph has only so many pixles, you don't need to see those overlapping points.

-Joe
0 Kudos
Message 4 of 6
(2,848 Views)
Hello,

First of all, thanks for your comments,
About graphing less points, you're right, mainly the points more distant in time, I already tried to do that, but it didn't improove what I was expecting, but probably my algorithm to remove old points can still be improoved (you know messing with arrays is allways trycky, because of memory issues), I'll give it a better try, but with 16 channels I'm not very sure it will completely solve my problem...

About the Paul's comment, the vi I posted was just an example for demonstrative purposes, my graphing is even in a diffrent vi than the acquisition and the refresh rate is 2 times per second witch is the frequency that the data arrives.

Thanks, Paulo
0 Kudos
Message 5 of 6
(2,841 Views)
There is a much easier way to do this. Use a Waveform Chart and the waveform data type. I have attached an example (LabVIEW 6.1 for compatibility). The waveform data type includes a timestamp and the Waveform Chart is designed to take successive data writes and update the display. I have simulated this with a sequence structure, but you can do it just as easily with multiple writes in a loop.

If you are still having problems, you may want to check out the tutorial on dealing with large amounts of data in LabVIEW. Get it here, or search for "large data labview" on the main ni.com web page search bar. It should be in the first couple of hits.
Message 6 of 6
(2,811 Views)