LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Speed trouble

Here's my situation:

I have 3 separate VIs sharing data through global variables. One reads
data from a total of 10 buffers, 5 from each of 2 6602 cards. From
three of the buffers (on each card), only 1 piece of data is read in
each cycle. From the other two buffers, around 120 datapoints are read
per cycle. That data is written to disk and the global variables. A
second VI reads in most of those global variables and calculates some
histograms and compares some data between the two cards. The histogram
and successful comparison data is written out to files. A third VI
displays 3 strip charts each with 2 traces of data taken from the global
variables. It also has some buttons that open up sub-VI panels for
displaying other data.
Each of the three main VIs must execute every
second.

I have checks to be sure that only one VI is reading or writing to the
global variables at any time. I am opening the datafiles at the
beginning, writing to them every cycle, and then closing them at the
end.

When this system is run overnight, it runs fine at first, but by morning
has slowed down to a crawl with the datataking running 2-1/2 hours
behind.

Am I asking too much from LabView or is there some way to make this
work?

Thanks,
Sandy
0 Kudos
Message 1 of 3
(2,386 Views)
Sandy,

Additionally to Jared's advices:
1. I'd vote to avoid using global in your case as well. It's much slower and tricky than you need.Try to use another LV techniques.
Several suggestions could be made:
Use functional global (sub-vi with one-time running loop with uninitialized shift registers).
Use separate VI server keeping your data and exchange data over e.g. control reference

2. I'd check if you clearing your strip chart and data buffers from time to time, or keeping these buffers at a reasonable size.

3. Try to not use very large files to store data. Separate them say, once per hour to keep size small enough.

4. Keep your files open during run-time and open/close them only once, but not in each cycle.

Generally it seems that memory used by application g
rows during run-time and causes this problem with speed etc.

The all issues are described in Developer Zone http://zone.ni.com.
Sure that LabVIEW will do this job very fast.

Hope this will help.
Sergey
Message 2 of 3
(2,386 Views)
Sandy,

No, i don't think you are asking too much from Labview. I just think you
have to do things a bit differently.

First, how are you making sure that only 1 vi is reading or writing to the
globals at any 1 time? I hope you are using semaphores or the like.

Every time you read from a global, labview makes a copy of the data. If
you are reading an array from the global, you make a copy of the entire array.
I am not familiar with the board you are using, but if this data is coming
back as strings, arrays of strings are very wasteful (in terms of memory
usage). An example - you read from the array 60 times a minute, 60 minutes
in an hour, 16 hours from the time you leave til you come back. That's 57,600
reads over night * 2 vi's doing the reading. Let's say each piece of data
is only 1 byte, 120 bytes makes 13.8 megs of fragmented data. I know this
doesn't sound like much these days, but this number doubles or triples if
each datapoint is 2 or 3 bytes instead of one (think 4 or 5 or...). This
number can also multiple if you are building arrays (each build array makes
copies of all inputs) or concatenate strings (same thing). I'm also assuming
you are not keeping old data around, that each 120 datapoints replaces the
last 120. If you are keeping the old data around for history sake (depending
how you are doing it) you could possibly take that 13.8meg and double or
triple it again.

Some tips :

1) stay away from globals as much as possible in programming. I know, some
times there is no other way.

2) use initialize array at beginning of program (make it big enough) and
replace array element (or subset) instead of build array. If you don't know
the exact size of your array, use a size you are sure will be big enough
and then use resize array when done processing (down to a smaller size).

3) read chapter 28 - performace issues - in the G programming reference
manual for some real good info on building efficient programs.

Hope this helps. Read ch 28 anyway, even if i'm totally off here.

Jared

Sandra Horton-Smith wrote:
>Here's my situation:>>I have 3 separate VIs sharing data through global
variables. One reads>data from a total of 10 buffers, 5 from each of 2
6602 cards. From>three of the buffers (on each card), only 1 piece of data
is read in>each cycle. From the other two buffers, around 120 datapoints
are read>per cycle. That data is written to disk and the global variables.
A>second VI reads in most of those global variables and calculates some>histograms
and compares some data between the two cards. The histogram>and successful
comparison data is written out to files. A third VI>displays 3 strip charts
each with 2 traces of data taken from the global>variables. It also has
some buttons that open up sub-VI panels for>displaying other data. Each
of the three main VIs must execute every>second.>>I have checks to be sure
that only one VI is reading or writing to the>global variables at any time.
I am opening the datafiles at the>beginning, writing to them every cycle,
and then closing them at the>end.>>When this system is run overnight, it
runs fine at first, but by morning>has slowed down to a crawl with the datataking
running 2-1/2 hours>behind.>>Am I asking too much from LabView or is there
some way to make this>work?>>Thanks,>Sandy>>
0 Kudos
Message 3 of 3
(2,386 Views)