SD drive drains free memory of myRIO

[ZeroG]

I am storing data from myRIO directly to an SD drive in the TDMS-format. While writing data to the SD card the free memory goes down drastically. However, after the data storage is complete the free memory does not recover. It recovers if I quickly remove the SD card and plug it in again or reboot the system. Deleting large files helps as well. I seems the underlaying OS is keeping some data in memory that is related to the SD card.

The problem is that the myRIO occasionally freezes and then requires it to be rebooted. This is likely due to the low free memory. To avoid this, the only work around I have is to proactively and periodically reboot the myRIO after data storage, which is not very convenient.

Does anyone have an idea how to fix this problem? I also tried to stream the data to internal storage of myRIO and then move the entire file to the SD card after all data has been acquired. Unfortunately same issue.

Thanks

[Bob_Schor]

Are you trying to run the myRIO without connecting it to a PC?  Note that this requires that the myRIO does "file I/O" to a (myRIO-)local  device.  My experience with several LabVIEW-RT programs relies on using the PC, with its abundant core memory and processors, including chips devoted to managing File I/O, to handle streaming of large amounts of (continuously-acquired) data.  I've used Network Streams to manage this, and have been able to handle continuous transfers of data at somewhere around 100 kB/s (I'm a little fuzzy on the upper end, as its been a while since I've handled "continuous analog sampling").  Of course, if your data comes in short bursts at much higher frequencies, then the limit is having enough myRIO memory to serve as a "buffer" while you "take in fast and spool out slower".

Getting the data off the myRIO and onto a PC AFAP (as fast as possible) would be my recommendation.  Of course, without seeing your code, it's hard to be more specific.

Bob Schor

[ZeroG]

Hi Bob,

Thank you for your feedback. In my application the bandwidth of the network is limited and could also be interrupted. However, not all of the acquired data needs to be saved, but the data that should be saved is in high temporal resolution (up to 100kHz) for rather short periods of time (some seconds). Therefore, storing data locally is my preferred option. In principle, storing data to a local USB flash drive works well up to several hours. My issue is that the myRIO freezes occasionally and, according to Murphy’s law, always when it is not supposed to happen.

In my application I use a DMA to stream the analog data from the FPGA to the main process in the RT application. From there the data is forwarded via a queue to the data storage process. There I do some filtering and down sampling (if applicable) and then decide which data to store and what to discard. I use the TDMS functions provided in LabVIEW to write to the SD drive.

As quickly removing the SD drive and putting it back in, even when the application is running, recovers about 15% of the free memory, I figure that likely it is the OS that does not free the memory after writing to the SD drive. I thought of unmounting and remounting the drive occasionally, when no data is acquired. But I don’t know how this is done programmatically, if it can be done at all.

Thanks

Simon

[Bob_Schor]

Hello, Simon.

     I recommend (well, I almost insist) that you attach the myRIO code (preferably in a version of LabVIEW no later than LabVIEW 2021).  What I suspect is happening is that you have a time-critical loop that "runs out of time".  You should have at least two independent free-running Loops in what is called a Producer/Consumer Design Pattern -- one Loop acquiring data from the myRIO via the FPGA (the Producer), and passing the data as fast as it comes in to another loop, the Consumer, that writes it to disk (or, what I would do, streams it to the Host over TCP/IP via Network Streams).  Note that attaching a picture of the LabVIEW code will absolutely not do, but will only frustrate my efforts to help you.

     Here's a question -- if you run your existing code, acquiring data but not saving it (i.e. just "throwing the data away"), can the program run for several hours without crashing?  If so, then it is likely that my "guess" as to the nature of your problem is correct, and Producer/Consumer might well fix it.

Bob Schor