memory growth in TDMS write

[StuVIEW]

Hi Kyle,

Thank you for the work you've done on this.

I'm not 100% sure where we should be putting the TDMS Flush function?  I've attached a modified cRIO Waveform Acquisition and Logging on CompactRIO Sample project based on a cRIO 9068 and 9234 as JJDFRD is using, and I still see the physcial memory declining with each TDMS write until it gets down to about 4M (reserved for the system) - Funnily enough it seems to work fine and continue to log and write even after it reaches this bottom threshold.  If I change the Free Space constant to delete files when the disk space reaches say 30% rather thean the default value of 70%, I can see the Physcial Memory bounces back after a TDMS write and older tdms files are deleted.

If you could pelase confirm where we should put the TDMS Flush function this would be very helpful, and JJDFRD can try this out to see if it fixes his problem.

Kind Regards,

Stuart Little

Applications Engineering

[muffin.vi]

Stuart89,

That is where I put the TDMS Flush--right after the TDMS Write.  It's odd that we're seeing different behavior, however. 

[J.Willems]

Hello Muffin.vi, Stuart89,

I am experiencing the same problem as JJDFRD is seeing.

I am using :

- Labview 2014 SP1

- cRIO 9063 with

- NI 9472

- NI 9263

- NI 9211

- NI 9205

When I run my aplication without logging my data to disk I look at the Distributed system manager and I see that the memory usage is constant.
But when I turn on my logging I see that the memory is slowly increasing. This already lead to some issues because the cRIO is resetting itself when the memory runs out and because this is in a setup for controlling the pressure of the oil we had some unwanted results.

I already tried the flush TDMS after the write to file. And then I still see the increase of the memory in the distributed system manager. Orignally I understood that the flush only needed to be done before closing the TDMS file. And therefore I did the flush before the TDMS Close.

I also found out that the data to go in the TDMS Write when using a wave form can cause an issue. This I also changed in to a 2D array in stead of the waveform.

Now the part that is also a big questionmark for me is.... When the TDMS Close is done. Shouldn't the memory be released then that was used in the write TDMS file?
Because when I close my file the memory usage is still the same.

Is there something wrong in the way of working? Or does this mean that my TDMS file is not closed properly?

[StuVIEW]

Hi J.Willems,

The biggest contributor to solving JJDFRD's issue was upgrading to LabVIEW 2015.

In regards to your question about memory being released; we need to keep in mind the way that NI Linux Real-Time OS (used by the cRIO 9063) handles memory.  The below KB explains this:

http://digital.ni.com/public.nsf/allkb/AC6200D19D23C61586257C8D006E6DC2

I suggest that you open a Service Request at www.ni.com/support/ for the quickest way to solve this problem.

Kind Regards,

Stuart

[J.Willems]

Hi Stuart89,

I already called to the support to make Service Request.
The response I had from the Support person was that to him it also looks like the write to tdms is causing the issue.

Therefore I was looking deeper in to this and found this post on the forum and started reading and trying what was suggested.
Now as I read the paper I have the question is the memory that I see in the distributed system manager then read out using the System property node?
Or is this done on another way? Because I base myself on what I see in the Distributed System manager of the memory use and processor load.
The upgrade to 2015 is something I was hoping would not be needed because there are more of these systems in use and then I need to change all of them to keep it easy to maintain the source code.

[StuVIEW]

It may well be a seperate issue, but if you've already created an SR i'd work with that NI engineer and reccomend sending him your LabVIEW project and asking him to try upgrading it to LV2015 and see if he can replicate the issue.  Upgrading to LabVIEW 2015 won't require you to change the source code.

The memory issue described in the article about using a property node would be the same as seen in DSM.  The CPU load will display as you would expect, it's just that the Linux OS handles memory differently.  I point this out not because it is a problem, it is just something to be aware of when using memory diagnositc tools with Linux systems.

Kind Regards,

Stuart