How to monitor memory usage in a cRIO controller?

[dj143]

I have an application where I suspect the customer is operating in a hotter environment than they are claiming.  I prepared the RT host vi to log a simple text file directly on to the RT's C: drive.  In this case I'm only logging the transition of events when the chassis temperature exceeds 70C and then becomes less than 60C along with a date and time stamp.  (It's not continually logging data.)  However, I'm concerned that over time (i.e months from now after I've long forgotten the project)  the file will get overly large and affect system operation.  There are articles that deal with memory management but I'm not sure how to interpret them.  They talk about RAM.  Is RAM the same as the C: drive on the controller?  How do I determine the available memory on the C: drive; like using "dir" in the old DOS days?  What is the best Knowledge Base article that deals with this issue.  This system is a stand alone application.  (The host PC is not normally connected.)  I am using a cRIO-9012 controller and LV v.8.6.

Dave

[gsussman]

RAM on the controller is not the same as the C: drive. With respect to the controller, you can think of it in the same terms as your computer. RAM is volatile memory and your C: drive is non volatile flash memory.

Depending on the frequency of the temperature excursions above and below your 70C threshold, the service life of the controller and the method you used to append to the file, there could be a number of issues that may creep up over time.

The first, and the one you brought up is the size of the file over time. Left unchecked this file could grow continuously until the system literally runs out of flash memory space and chokes. Depending on how your are appending data to this file, you could also use more than a trivial slice of processor time to read and write this big file on disk. While I have not personally ever run one of the RT controllers out of "disk space", I can't imagine that any good could come of that.

One thought is to keep a rolling history of say the last 3 months. Each month, start a new file and append your data to it during the course of the month. Each time a new file is created, delete the data file from something like 3 months ago. This will ensure that you will always have the last 3 months of history on the system, however the monthly deletion of the oldest data file will limit you to say 3 files at whatever size they happen to be. Unless there are hundreds of thousands of transitions above and below your threshold this should keep you in good shape.

I also eluded to the method you use to write to this file. I would ensure that you are appending data using the actual file functions and not first reading in the file, appending your data as a string then writing the entire file contents back to disk. In addition to causing the highest load on the file system this method also has the largest system RAM requirements.

[dj143]

Hi Gsussman,

Limiting the logged data to something like 3 months is an excellent idea.  As far as not opening the file by only appending the data is concerned, I think I'm logging the data the correct way.  Attached is the subvi that I'm using.  Please look at it and see if there is a better method.

Thanks,

Dave

[mallyaprs]

Hello,

My only concern with the method of keeping it grow for a specified time is that the file can grow out of bounds within this time. As you wont have any control on the amount of transitions. If the data is alot then I would suggest you to use a file with a constant size for eg 64 kb or so and keep on rolling over the older data. I am not sure if you need all the previous data.