Lag Issues When Stopping LabVIEW Code Execution

[wlsrb2048]

Hello, I am a student studying LabVIEW.
I would like to ask about an issue where the system lags when stopping LabVIEW code after execution.

To explain in detail, after running LabVIEW code that collects data and pressing the stop button, the code does not stop immediately, and the screen freezes. The longer the code runs, the longer the screen remains frozen.

At this time, as shown in the first picture, the hard disk usage reaches 94%, and the write speed becomes abnormally slow (around a few hundred KB/s).

Since the hard disk is new, I don't think it's a hardware failure.
Is this a common issue? Do others experience this problem as well?

Thank you for reading.

[santo_13 · Accepted solution]

It looks like you're writing a lot of data to disk, and it takes time proportional to the data size, so when you stop the LV code, the code and OS are still busy writing the data to disk and, hence, it feels like it stalled and then closes.

[wlsrb2048]

Thank you for your response.
As you mentioned, I am indeed storing large amounts of data.
I was worried about the disk speed degradation and the disk usage reaching 100%, but it seems like everything is functioning normally.
Thank you!

[Andrey_Dmitriev]

You can add Flush File Function to your code, call it time to time to avoid "freezing" at App's close.

[Yamaeda · Accepted solution]

The low write speed suggests lots of small and random writes, probably also including opening and closing the file refrence. Is that the case?

[altenbach]

Your description and pictures are not really useful to troubleshoot the problem.

Does pressing the stop button trigger the file saving? (i.e. part of the shutdown code after the main loop?)

What format is the data saved?

How big are the resulting file(s)?

Who wrote the program? What is the overall architecture? We probably would need to see your LabVIEW code to offer improved suggestions.  For example you could stream the data to disk as simple binary data.

[wlsrb2048]

It seems that the case you mentioned is also having an impact. Thank you!

[wlsrb2048]

The files are saved in TDMS format with a size of 700KB, and 120 files are saved over 12 seconds.

I suspect the issue arises due to the large number of files.

I will contact you if further assistance is needed. Thank you for your response!

[Yamaeda]

---

@wlsrb2048 wrote:

The files are saved in TDMS format with a size of 700KB, and 120 files are saved over 12 seconds.

I suspect the issue arises due to the large number of files.

I will contact you if further assistance is needed. Thank you for your response!

---

TDMS is an effective format, just open the file ref. at start and write them all to the same file. If needed, there are defragmentation tools that can be used afterwards.

[altenbach]

---

@wlsrb2048 wrote:

It seems that the case you mentioned is also having an impact. Thank you!

---

This is a long thread with many replies and It is impossible to tell what "case" you are referring to.

Make sure to always quote relevant parts of the earlier post (as I just did here).

We still don't know if these 120 files are only beginning to be saved when you stop the program

We can also tell that this is a conventional HDD, not a SSD, so don't expect blazing speeds. The maxed out write speed is less than 1MB/s as shown in your image!