Long-Term Performance Issues in High-Frequency DAQ Data Collection

[wlsrb2048]

Hello, I am a student studying LabVIEW in Korea.

I am currently collecting data from a 3-phase inverter kit using NI DAQ and labview. And I have a question that led me to post here.

To get straight to the point, I have discovered an issue where, during long-term data collection at a high sampling frequency, the system begins to lag over time.

I have tried to resolve this issue on my own but have been unsuccessful, so I am seeking advice from experts.

The data collection setup and sampling frequency are as follows:

NI-9223:

1. U Phase Current (500kHz)
2. V Phase Current (500kHz)
3. W Phase Current (500kHz)

NI-9223:

4. U Terminal Voltage (500kHz)

5. V Terminal Voltage (500kHz)

6. W Terminal Voltage (500kHz)

NI-9219:

7. Case Temperature (50Hz)

8. Ambient Temperature (50Hz)

- Out of these, data 7 and 8 is always saved (4000 samples per file).
- Data 1 and 4 is saved at a sampling frequency of 500kHz for 12.5 seconds, followed by a 135-second rest in a repeated cycle.
       >  0.1 seconds of data is saved to a single file, so 125 data files are created during 1 cycle.

- The data 2, 3, 5, and 6 is not saved but monitored.

This experiment setup is designed to observe the long-term behavior of the inverter, and the data needs to be collected for more than 200 hours.

The problem occurs when saving the data 1 and 4.

For the first hour after the experiment starts, all 125 files are created, and it seems to work normally.

However, after 2 to 3 hours, the number of files generated decreases to 124 or 123.

After a day, the data storage speed significantly decreases, with only 50 to 60 files being saved.

I also observed that the monitoring screen stutters significantly.

I suspected a computer performance issue, so I switched to a computer with an i7-14700 processor and 64GB of RAM.

As a result, the lag issue improved, but this only delayed the occurrence of the problem. The same issue reappeared after 2 to 3 days.

Therefore, it seems that the root cause is not a lack of computer specifications. What could be the issue?

If you know anything related to this, I would greatly appreciate your response.

Thank you for reading.

I have replaced the LabVIEW file with a temporary one, as the original is not available at the moment. I will update it as soon as possible.

[altenbach]

Please do a "save for previous" (2020 or below) and attach again so more can see your code.

[santo_13]

---

@wlsrb2048 wrote:

Hello, I am a student studying LabVIEW in Korea.

I am currently collecting data from a 3-phase inverter kit using NI DAQ and labview. And I have a question that led me to post here.

To get straight to the point, I have discovered an issue where, during long-term data collection at a high sampling frequency, the system begins to lag over time.

I have tried to resolve this issue on my own but have been unsuccessful, so I am seeking advice from experts.

The data collection setup and sampling frequency are as follows:

NI-9223:

1. U Phase Current (500kHz)
2. V Phase Current (500kHz)
3. W Phase Current (500kHz)

NI-9223:

4. U Terminal Voltage (500kHz)

5. V Terminal Voltage (500kHz)

6. W Terminal Voltage (500kHz)

NI-9219:

7. Case Temperature (50Hz)

8. Ambient Temperature (50Hz)

- Out of these, data 7 and 8 is always saved (4000 samples per file).
- Data 1 and 4 is saved at a sampling frequency of 500kHz for 12.5 seconds, followed by a 135-second rest in a repeated cycle.
       >  0.1 seconds of data is saved to a single file, so 125 data files are created during 1 cycle.

- The data 2, 3, 5, and 6 is not saved but monitored.

This experiment setup is designed to observe the long-term behavior of the inverter, and the data needs to be collected for more than 200 hours.

The problem occurs when saving the data 1 and 4.

For the first hour after the experiment starts, all 125 files are created, and it seems to work normally.

However, after 2 to 3 hours, the number of files generated decreases to 124 or 123.

After a day, the data storage speed significantly decreases, with only 50 to 60 files being saved.

I also observed that the monitoring screen stutters significantly.

I suspected a computer performance issue, so I switched to a computer with an i7-14700 processor and 64GB of RAM.

As a result, the lag issue improved, but this only delayed the occurrence of the problem. The same issue reappeared after 2 to 3 days.

Therefore, it seems that the root cause is not a lack of computer specifications. What could be the issue?

If you know anything related to this, I would greatly appreciate your response.

Thank you for reading.

I have replaced the LabVIEW file with a temporary one, as the original is not available at the moment. I will update it as soon as possible.

---

The first suspicion is the code is not architected well enough to be scalable and stable.

[altenbach]

It seems the front panel is corrupted and some of the drawing areas cover many screens.

There is a lot of code smell here, for example most of your boolean logic is just plain Rube Goldberg. It does not seem trivial to untangle it all and help you. This is just the tip of the iceberg...

Why are your filenames xlsx, but the express configuration specified tdms? Wouldn't it be much more efficient to just stream to binary files instead of using express VIs?

[wlsrb2048]

Hello,

I have attached the LabVIEW code from the previous version.
Thank you.

[wlsrb2048]

Hello, thank you for your response.

First, I have attached the LabVIEW file.

1. The file name and extension are set manually. In practice, as shown in the second figure, the data is saved as a TDMS file.

2. To help you better understand, I will explain the trigger signal. The incoming trigger signal is as shown in Figure 3.

• The trigger signal is divided into the data collection period (12.5 sec) and the rest period (60 sec).
• Data is collected only when the trigger signal exceeds 2 (for 12.5 sec).
• 1 cycle is counted when the trigger signal changes from 0.5 to 3.
• Data is not collected during even-numbered cycles to ensure sufficient rest. Therefore, the rest period is approximately 132.5 seconds.