How do I correct a gradual slowdown of data being displayed?

[bmihura]

I'm working on a project where LabVIEW collects data from hardware via "Datasocket Read".

After a few hours of manipulating the program, there is a several second delay between the time the physical signals change and my LabVIEW indicators change.

I suspected a memory leak at first, but I looked at all my arrays and strings; they are quite small during the slowdown.

Still thinking memory leak, I started quarantining sections of the program, that didn't seem to help either.

How do I stop this slowdown of data being displayed?

[altenbach]

This is difficult to diagnose with such little information and without actually seeing the VI.

Have you done any profiling? What is the CPU useage?

Do you possibly constantly open references, but never close them?

[rolfk]

---

@bmihura wrote:
I'm working on a project where LabVIEW collects data from hardware via "Datasocket Read".

After a few hours of manipulating the program, there is a several second delay between the time the physical signals change and my LabVIEW indicators change.

I suspected a memory leak at first, but I looked at all my arrays and strings; they are quite small during the slowdown.

Still thinking memory leak, I started quarantining sections of the program, that didn't seem to help either.

How do I stop this slowdown of data being displayed?

---

Another possibility for slow down in an application besides of opening resources all over again and never closing them wwould be if you have a loop in which you store your data in a shift register. When you append at every loop iteration new data to that array through Build Array (or for strings through Concatenate String) LabVIEW has to allocate bigger and bigger chunks of memory which fragments the memory to a level which slows down the entire system after some time.

Which version of LabVIEW are you using? There were some problems with the Data Socket functions in earlier versions, reopening new DS connection implicitedly on every execution of them and if you didn't explicitedly close them you could run into the situation where all those open DS refernces slowed down the system to a crawl.

Rolf Kalbermatter

[bmihura]

I've done profiling, and it looks like "File Write" is the biggest time-consumer. That happens once per second on three files, and it's tiny bits of information, so I doubt that's the culprit.

I haven't checked CPU usage, will do that, but my system is down and may take a day or so to get back up.

I've closed all references, that is a sneaky memory leak! I did a global search on "Property Node" and closed them all.

[bmihura]

I checked all Shift Registers for basic LabVIEW memory leaks like you said (growing strings and arrays), there are none.

I initially suspected a DataSocket leak, but there is no way to "close" a DataSocket Read, because DataSocket Close has this "connection id" input that DataSocket Read doesn't give me.

Next time it slows down I'll check CPU usage. It can take a day or two to slow down.

Finally, it appears that the data is actually being collected in a timely manner, because a networked computer can read it from disk, but the display process is what's slowing down.

[bmihura]

It finally slowed down again, the CPU usage was only 30%.

[altenbach]

• How exactly do you write your files?
• Do you open them once and keep them open for the duration of the run?
• How big do the files get?
• Is your HD heavily fragmented and nearly full?

[shoneill]

Are you saving to a networked disk by any chance?  Might is be that your OS is being forced to wait for a remote computer?

Even if not, writing every iteration to a number of files when you only have a small piece of information to write is inefficient.  Try buffering the data and saving every Nth iteration.

If saving to a networked drive, try setting the program to save locally and see if the same thing happens....

Hope this helps

Shane.

[bmihura]

• How exactly do you write your files? File Open, File Write, and always File Close
  
• Do you open them once and keep them open for the duration of the run? No, I open, write, and close them every second; that way networked computers can always read recent data.
  
• How big do the files get? 13 - 14 MBytes
  
• Is your HD heavily fragmented and nearly full? No; total size 3.9 MBytes, 601 MBytes free, total frag 33%, file frag 63%, free frag 3%

Here are two other things I've noticed:

1. Once the computer begins to slow down, closing and re-starting the LabVIEW program doesn't help. The computer must be rebooted.
2. The problem is worse on graphics-intensive screens. There is an ever-increasing delay between the underlying data acquistion and the time it displays.

[altenbach]

---

@bmihura wrote:
No, I open, write, and close them every second; that way networked computers can always read recent data.

---

Can't you open them once for writing with deny mode set to none? How do networked computers read recent data? Do they need to read the entire 15MB file each time? How many other computers access the data during the runs, and how often?