LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

memory growth in TDMS write

I have tried all the turnarounds as I can find from the NI website, such as

1) Setting the NI-MinimumBufferSize to 10,000, or

2) Using the TDMS Advanced Synchronous Write along with other Advanced TDMS functions instead of standard TDMS write

 

However, the RT free memory still diminishes gradually when a DMS file is written. It is also noted that the drive space available on the /C/ is reduced as well. Due to the reduced free RT memory, a FPGA memory Full error occurs after recording 4~5 several large TDMS files (100 to 200 MB).  Can anyone help on this issue?

 

More details on the system and the program I am working on:

1) LabVIEW 2014 Professional Developement

2) cRIO 9068 + 2 NI 9234 modules for triggered Sound & Vibration measuement

3) 8 Channels at 51200 S/s

4) FPGA buffer size 8191

5) RT buffer depth 5*8*51200

6) LabVIEW Code is simply beased on the LabVIEW sample project:  LabVIEW FPGA Wavefrom Acquisition  and Logging on CompactRIO

 

Regards,

 

JJDFRD

0 Kudos
Message 1 of 16
(4,607 Views)

A memory growth is usually due to changing of array sizes.  Make sure you are always getting the EXACT same number of samples from your FPGA DMA.  With the array at the same length each time, that buffer can be reused.  When the array size changes, new memory must be allocated.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 2 of 16
(4,483 Views)

The exact same number of samples, 51200 per channel, are  read from the FIFO memory and written into a waveform, and then logged into a TDMS file. The data acquisition is continuous, but the data logging is triggerred by, say noise or vibration level.  The RT memory does not decrease if the system only acquires data without logging.  The memory leakage only occurs when data logging, or TDMS write starts.

 

 

0 Kudos
Message 3 of 16
(4,441 Views)

JJDFRD,

 

Can you post your RT code, please? I would like to see how you are handling the writes.

0 Kudos
Message 4 of 16
(4,404 Views)

My code is mainly based on the LabVIEW 2014 Sample project:  LabVIEW FPGA Wavefrom Acquisition  and Logging on CompactRIO with some modification.  You can observe the same memory issue in the Samle project code.

 

 

0 Kudos
Message 5 of 16
(4,372 Views)

JJDFRD,

 

What specific modifications need to be made to the sample project? It's hard to reproduce this issue without knowing the details.

0 Kudos
Message 6 of 16
(4,336 Views)

Kyle T.,

 

The sample project will re-produce the same issue without any code modification.  I do use the following settings in terms of acquisition parameters. 

 

1) LabVIEW 2014 Professional Developement

2) cRIO 9068 + 2 NI 9234 modules for triggered Sound & Vibration measuement

3) 8 Channels at 51200 S/s

4) FPGA buffer size 8191

5) RT buffer depth 5*8*51200

6) LabVIEW Code is simply based on the LabVIEW sample project:  LabVIEW FPGA Wavefrom Acquisition  and Logging on CompactRIO

 

Regards,

 

JJDFRD

0 Kudos
Message 7 of 16
(4,295 Views)

JJDFRD,

 

I'm not totally surprised that the RAM on the cRIO is being used up. When the TDMS file is open to be written, the contents of that file are often stored in memory until the TDMS Close function is called. The example does not always call TDMS Close after TDMS Write, it looks to see how large of file to save as determined by the config file. I would consider using the TDMS Flush function, which will force the memory space to be cleared. 

 

As for the hard drive filling up, isn't this exactly what is expected by writing a log file? 

0 Kudos
Message 8 of 16
(4,256 Views)

Hi Kyle,

 

If the example does not always call TDMS Close after TDMS Write, are you able to advise under what circumtance the TDMS file is not closed? What I understand is that it is closed every time after the last block is logged and the index file is deleted.  Note both the TDMS Close and delete the index file are excuted in the same Close Log File.vi. As I do not see any index file, I assume the TDMS Close is excuted everytime the logging finishes. 

 

JJDFRD

 

 

0 Kudos
Message 9 of 16
(4,191 Views)

JJDFRD,

 

I did a fair amount of research into this. The problem isn't with TDMS Close. It's due to the buffer created every time TDMS write is called. Check out this. The behavior in this case is expected. Try placing a TMDS flush right after the TDMS write in the RT code. Once I did that, the memory would be recovered after the write was completed. 

Message 10 of 16
(4,141 Views)