How do I free up RFSG resources

[kral]

I current;ly use both the 5671 and 5644R and have made PSK and QAM VIs that were modified from the Examples.  My use is to enter a large Bit pattern or Vector into the RFSG for generation.  I'm noticing about 200-500 MB of memory being used up for these operations.  This not a problem in and of itself, but when other functions/software comes into play, I'm seeing windows "Out Of Memory" messages.  One way for me to solve this issue would be free up the RFSG memory resources before calling the other software pieces in my system.  However, even after I close the RFSG session, the Memory chunk used by the VI only decreases a small fraction (10s of MB).  The major portion of the memory usage doesn't clear up until I close LabVIEW itself!

I've put the "Request Deallocation" block in the Generation VI, but still no luck.  I would really love to be able to free up this memory cleanly without having to close LabVIEW every time.  My system information is the following:

Windows 7 32bit (Needs to be 32bit because my system also has the 5660 which is only supported in 32 bit at this time)

4GB memory (NOTE: 32 bit OS only supports up to 4GB)

Please Advise

Michael Kral

[mbb25]

By default, the 5671 keeps IQ waveforms in host memory.  For I/Q rates > 8.33 MS/s, the 5671 hardware doesn't support I/Q waveforms natively.  Instead, the I/Q waveform is converted to the correct IF frequency for the selected RF frequency on the host, and the IF waveform is downloaded to the arb.  Waveforms are kept in host memory so that you can change the RF frequency (which may require a different IF frequency) or I/Q rate without needing to re-write the wavefrom.

Is your I/Q rate < 8.33 MS/s?  If so, you should be able to make use of the 'Direct Download' feature.  For I/Q rates <= 8.33 MS/s, the 5671 hardware supports I/Q waveforms natively.  'Direct Download' instructs the driver to write your I/Q waveform directly to the device, without keeping a copy in host memory.  See also this RFSG help topic:

   http://zone.ni.com/reference/en-XX/help/371025M-01/rfsgproperties/pnirfsg_directdownload/

'Direct Download' may also require you to structure your program slightly differently.  If you are writing your waveform in chunks ('more data pending' = true), RFSG will error out with 'Direct Download' enabled if you haven't allocated the waveform first.

[kral]

Thank you for the feedback!  I tried the Direct Download link you provided while working on the 5644R and did not notice any change.  Still a large portion of memory is eaten up by the generation.  I then read that for the 5644R, Direct Download is always enabled.  I have not tried this on the 5671 because my memory issue is mainly with the 5644R.  (However, both intruments use the same VI and both eat up large amounts of memory.  Albeit, the platform using the 5671 has less memory requirements than the one using the 5644R). 

The whole purpose of my question to provide the ability to free up the 5644R memory usage for my other instruments.  Right now as it stands, once the testing using the 5644 finishes, my other instruments have "Out of Memory" exceptions.  This is due to the fact that although I'm finsihed using the 5644, the memory is still being reserved.  If I can find a nice way to free up this memory, then my DUT testing can continue.  Please advise.

[mbb25]

I'm sorry that didn't help.  I don't know what the problem would be.

Posting source code might be helpful.  I don't expect to have time to look into this in detail, but someone else watching this forum might be able to help out.

[kral]

As suggested, I'm posting my code.  This is a modification of the MT RFSG Generate PSK.vi.  Among other change, the major differences are that the loop that allows for parameter changes has been removed so this can be called one shot at a time and this takes a user defined Bit-Pattern for generation.  Both the VI and the Bit-Pattern text file are included.  One can either set front panel field to the file path of the text file or blank out the path field and navigate to the file when calling the VI.  let me know if anyone can help me.

[AirFrantz]

The 'request deallocation' function should free up memory that LabVIEW is not using, when you called this vi did you make sure that the RFSG session was closed before it executed?  Did you see this function release any memory at all?  Aside from this VI (and standard programming practices of clearing front panel controls and indicators and closing open references), I'm not sure of a way to free up more resources.

[kral]

Thanks for responding Jon.  So one thing about this VI that is necessary is that the RFSG Session is NOT closed while generating.  I need to make DUT configurations and communications as part of my RF testing.  My test executive is written in .NET and when there is no .NET implementation of LabVIEW, we need to create LabVIEW DLLs to access functionality.  That is the case for this VI.  It was structured so that I can make .NET P/Invokes upon it and return back to .NET for further DUT testing. 

With that said, while this VI is generating, I do not close my session.  If I do, the generation stops.  I did notice, that if I did, all memory resources are freed.  I DO close the session when I'm finished Generating and turn the RFSG "off", but I think at that point I might have already created a Session without closing it properly and trying to close a new session.  So that probabbly means that every time I use this VI for a new Generation because of a parameter change, I'm creating a new session.  It interesting to note, that I am creating new sessions without closing them, I am not seeing any noticable memory leak of sessions lingering in the buffer.

I'm currently in the works on trying to pass a Handle into this VI so that my managed .NET code can control the Session activity, but so far all attempts to pass handles have failed.  I would love somebody to send some example code on how to obtain a IntPtr of a RFSG Handle in .NET and successfully pass it into a VI for use.  I seem to be getting Memory Access Violations which usually indicates my data types (Likely my IntPtr implementations) are incorrect.

Before somebody tried to tell me that there is now .NET API for PSK, I have tried to implement this function in .NET and failed at certain VIs not being available (rfsg_Resample and Write.vi is one particular).  I'm not savvy enough to translate what these VIs do in .NET and making these VIs into .NET DLLs themselves creates again the problem of Handle passing.

It seems that my search for freeing up memory resources in the current set up is nearing an end without a silver bullet if the above revelations are correct.  It also seems like I'll need a way to control the sessions external and internal to my PSK VI.  Perhaps someone with the knowledge of Handle passing in P/Invoke calls can speak up?  I would greatly appreciate it.