LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Stacked Charts Performance

Hi,

I have a strange behavior with a stacked chart from an application with performance problems which I have to debug. I noticed that the UI becomes unresponsive if I try to write values to the chart with a high rate so I tried to create a similar one and put it to the test. I used a chart from NI UI Control Suite: System Controls 2.0. and tried to set the same properties as the one from the application. I simulated an acquisition of 20kHz and measured that the chart from the application uses almost double CPU resources and causes the UI to lag: this can be observed if you try to click on one of the VI menu items and move the mouse fast to left or right to see the menu sub-items.

Any ideas why this happens?

LV14

Lucian
CLA
0 Kudos
Message 1 of 7
(2,557 Views)

A chart gets data continuously and needs, therefore, to continuously update its display.  In some cases (the "scrolling" chart, like a strip chart recorder) this means rewriting all the data points present on the chart every time a new point comes in.  With "Oscilloscope" mode, you need to erase the old point and plot the new.

 

So if you are trying to plot at 20KHz, you are really beating up on your Graphics processor, to say nothing of the CPU code required to move the display around.  In addition, the human eye has difficulty making sense of changes that happen more rapidly than 50Hz or so.  When I want to display 1KHz data, I typically decimate it by a factor of 50, which gives me an update rate of 20 Hz, and smooth scrolling across the screen.

 

Bob Schor

0 Kudos
Message 2 of 7
(2,534 Views)

Actually, it looks like it is writing at 50 Hz. because he as a 20 wired into the Wait metronome function.  That is a 20 msec wait, so you only get 50 reads per second.  There is no way to simulate a 20 kHz output (0.05 msec period per iteration) in software.

0 Kudos
Message 3 of 7
(2,530 Views)

Indeed, displaying is at 50Hz. The amount of data which is displayed is similar to a 20kHz sample rate/channel acquisition as I display 400 samples each 20ms. Anyway, this is not so important if the conditions are the same for both charts but why is one of them slower than the other and uses more CPU?

Lucian
CLA
0 Kudos
Message 4 of 7
(2,501 Views)

When I ran your VI, I didn't see any difference between the two sets of charts in performance.  Though the overall behavior was odd in the manner it would reset or put chunks of white space in them.  I know it was just trying to plot random numbers, but the charts didn't look like that, just basically horizontal colored bars.

0 Kudos
Message 5 of 7
(2,494 Views)

If you run the VI, select the left chart and wait for some seconds for the plot area to be filled with data, you will see that if you click on one VI menu item (for example Project) and then move the mouse rapidly above the other items you will see that the sub-items will be shown with a delay. Also, the digital displays will update the values slower in comparison with the right chart. I tested this on 2 different computers and had the same behavior.

As for the chart 'reset', this is another strange thing that I did not figure out yet. I could see it on both charts but only when I tested on one of the computers (which is a little slower than the other).

Lucian
CLA
0 Kudos
Message 6 of 7
(2,477 Views)

Thanks for the better description on how to replicate.

 

The first time I ran the VI, I saw the behavior you described for the left chart.  But it was a pretty subtle pause.  And any time I ran the VI after that, I never saw it come up again.

 

So I closed out the VI and restarted, several times.  I couldn't seem to replicated, except for one time I *think* I saw it happen on the right chart.  But it was even more subtle.

 

Maybe someone else can try and find it to be more repeatable.

0 Kudos
Message 7 of 7
(2,468 Views)