Showing results for 
Search instead for 
Did you mean: 

Waveform Chart overload!!

Go to solution

labview 2011-pci-6254

Hello all! I have a quandry here. My entire program slows when my chart buffer fills. (currently set to default of 1024) Seems this is an issue with labview. But we need a decent buffer to monitor our waveforms. Before I get into the workings below, the program is event based and according to task manager, the computer uses 3% of the processor's power. Is there a way to allocate resources to where the program doesn't bog down? Even clicking a button to reset an indicator (not polled) takes forever since the chart needs to "catch up"!

Can/should I be storing all this information inot a tdms file and reading it out later for anything beyond 30 seconds?

Are my local variables slowing things down?


I am using DAQmx to measure a 2000hz scan rate. by buffer is 2010 (I've always heard to make it a (just a  little bigger) DAQmx is using continuous samples, measuring anywhere from 2-8 channels differential (these are set programatically with combo boxes in a subVI) It is outputted as a 2d waveform.


These signals are essentially sent into to two places. One is the waveform chart, the other is a "data processor" subvi that does array work and analyzing. The program works beautifully, and draws the chart beautifully. Update mode is wave chart with ten seconds sweep. BUT when the history fills it really slows things down. I am guessing this is because it has to erase 100 data points and save 100 new ones a million times a second.

The whole program operates inside an event structure 1ms timeout, DAQmx read reads 100 samples at a time. Timeout has NO property nodes. NO global vairaibles in the whole program. None of the objects overlap. 


Attached is a snippet, its not "purdied up" so no laughing 😉

0 Kudos
Message 1 of 6
Accepted by topic author MontgomeryScott

Hi Montgomery,


I am using DAQmx to measure a 2000hz scan rate. … save 100 new ones a million times a second. … The whole program operates inside an event structure 1ms timeout, DAQmx read reads 100 samples at a time.

This all does not fit together!

- At 2kHz sample rate you should get just 2 samples per 1 ms.

- Why do you need to save 100 samples "a million times a scond" when data is read with just 2kHz sample rate?

- Why do you have a timeout of 1ms and still 100 sample at a time - which would require a sample rate of 100kHz?


General answer:

Attach your VI!

Check the information you provide here to be accurate!

Use separate loops for data processing/saving and display!

DON'T use update rates of 1kHz for UI purposes! (You can't watch faster than 25Hz, typical LCD displays operate at 60Hz…)

Best regards,
CLAD expired, using LV2011SP1 + LV2017 (+LV2019 sometimes) on Win7+cRIO
Kudos are welcome Smiley Wink

Message 2 of 6


Not a million times a second of course. Just embellishing on how much data is being processed. Here's what I got. I almost did a producer consumer loop in the program, but I have never done daq on this level usually I just do datalogging on 1 second intervals.

I'll reiterate that I have never had a formatting class on VI's and they have not beed purdied up yet due to me still working on them.



0 Kudos
Message 3 of 6

I think I know wha tyou are saying,

my data processing is in a 1ms timeout, updating my screen 1000hz. 


So my chart updates that often as well. when everything is in the same loop, I am forced to do it that fast. But in reality, i should process in a seperate loop with NO delay and update much much less often on the front panel.


That makes perfect sense. . . .. . .  I guess I need to refamiliarize myself on buffers now eh?

I'm doing all this off of a 5 day class I took a 1.5 years ago, so be kind!


0 Kudos
Message 4 of 6

@MontgomeryScott wrote:
[..] updating my screen 1000hz. [...]


Now THAT is never going to happen. Average screenupdates by the graphics device is something like 100 frames ('screens') per second (fps), so 1/10 of what you say. Depending on the changes and system performance, the fps will drop.

Additionally note that the human eye is not perceiving changes arbitrarily fast. By experience, an update of 10-30 times per second is more than sufficient to create a "smooth observation" for the human eye.

So writing values to indicators faster has no real sense despite hogging the system.

Buffer implementation is a good way to collect data and relieve update overhead for visual displays.



CEO: What exactly is stopping us from doing this?
Expert: Geometry
Marketing Manager: Just ignore it.
Message 5 of 6


All indicators set to asychronous anyway. timeout was just to keep program processing information. Not like I was TRYING to update the screen that often.

0 Kudos
Message 6 of 6