Deallocation of memory in RT Controller (PXI-8176 with 128 MB RAM)

[sathyendra n]

Dear All,

We are building a real-time application using VI server concept. The application runs on a Windows host PC and basically calls the I/O functions of the PXI resources working under LabVIEW RT. This application is intended to run in a continuos fashion with 50 ms loop iteration until the operator stops the application.

During testing of this application; we are encountering the memory overflow error of the PXI RT controller (Error code 2). We then used the example program from NI website for monitoring the available memory in the RT controller. We observed in this tool that the memory is continuosly filling up in a very consistent manner before throwing up this memory error upon saturation.

We understand that LabVIEW real-time allocates and deallocates the memory automatically and we have less control over the same. Can anyone suggest what could be the solution to this as looks like the LabVIEW RT memory manager seems not to deallocate the memory upon completion of each VI server calls and inturn seem to allocate multiple copies of memory upon each iteration of the loop and hence throwing a memory error after passage of some time.

We have also tried using the "Request Deallocate" function at the end of each VI's in the RT controller which is being called from the host; but the issue still remains the same.

Request anybody to give a solution on the same and what could be tried out. Kindly revert to us at the earliest as the matter is urgent.

Regards
Sathya

[Ben]

Hi Sathyendra,

I have dozens of RT nodes running that use VI server techniques to serve data to a host. In my case they are FP RT nodes which are even more challenging to "shoe-horn" an application into (ie Not enough memory to debug, so I have to use exe's only!).

I have not seen an issue with memory usage growing.

The "request deallocation" will only be effective if the VI is called dynamically and ALL references to it are closed (on Windows anyway) and the VI is unloaded from memory. See this link for more info on deallocating memory.

http://forums.ni.com/ni/board/message?board.id=170&message.id=117552#M117552

In my experience (I may be wrong!) RT does not readily give memory back once it asks for it.

RT applications are a special form of LV applications that require a bit more thought than normal non-RT LV apps. Not only timing but memory usage must be kept in mind if the application is going to run for an extended period of time.

I do not have the time to give you a complete list (even if I thought I knew what a complete list was) but I will share some of the big issues.

1) NEVER, NEVER, NEVER use build array. Instead allocate a buffer at the start of the program and do all of your work "in-place".

2) "Strings are bad." (Mr Mackey, South Park) Since strings can be of vaiable length, their memory requirements can get out of control. THIS INCLUDES ERROR CLUSTERS!


Now if these two suggestions do not help, PLEASE post the code that runs on the RT node. WE can take a look and comment on other fine points.

Trying to help,

Ben

Message Edited by Ben on 04-21-2005 07:21 AM

[sathyendra n]

Hi Ben,
Please find attched lib files and the main vi memorytest.vi any sugestion please let me now.
reghards,
satya

[Ben]

Move your Open and Close VI references outside of the loop so that you only open the ref once and close it once.

The memory resource allocated for dynamic references are only relased when LV exits.

Ben

[sathyendra n]

Hi Ben,
Thanks for your help infact we tried this option too but the observation is that memory still get filled up in a consistent pattern.

request you to indicate what is the apporach you have taken for continous scaning of the rt resources as you have indicated that the deallocation of memory happens only upon labview exit.Then it really becomes difficult to exit labview for each iteration for just deallocating the memory.
awaiting your prompt response
regards,
satya

[Ben]

No prompt reply!

I am only a volunteer and I have a real job.

Be patient, I may get back to this latter.

Ben

[Ben]

I suspect the issue is in "ATE_AO_Config".

Make the changes re: opening once and closing once.

Get rid of the above VI and run it to see if the memory issue is in the above VI.

If the memory does not climb with above VI gone, then the issue is in the above VI.

Try using a "call by reference" node to see if your memory is beter.

Please review the notes I sited in my firswt reply.

I see strings, I see arrays of error clusters being built. This is all bad in RT.

Ben

[Ben]

Ok, i stepped back and looked at your code again.

It looks like you are just trying to get two readings a second from the RT platform.

If that is all you need then you may want to look into RDA (?) which is available with modern versions of NI DAQ. It lets you access hardware devices on networked machines as if they were local.

If your demo is an over simplification to test memory fine. Back to RT.

THe method you are attempting (I believe) is doomed to fail (I suspect) because the memory is just not going to get released. We can work with this another way, but like RT in general, it gets complicated.

If you launched another VI on the RT platform that did nothing but had your target VI as one of its callees, this would keep the VI in memory and you MAY be able to use your approach (with the open and close outside the loop).

I said this would get complicated didn't I?

I am not sure if the above would work because I have never tried it. I would recomend a different approach.

What works the simplest for me is to run a Vi continuously on the RT platform that runs in a loop and keeps a round robin-buffer updated. On the windows side I you VI server with a call by reference node to read from the round-robin buffer. This approach has worked well for me in the past.

Have fun,

Ben