LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Memory is full (Not enogh memory)

Hello every body, 

i am trying to fetch a high number of samples using the instrument r&s oszilloskop RTM3000 .. attached is a labview programm VI example from the company r&s .. I edited it by adding the 4 VIs you can see in the bottom so that i can get the Record Lenght i wish. It works very fine up to 20.000.000 Samples .. but I need above 30.000.000 samples .. in the case of entering 30M I get the known error ''Memory is full'' 

error.PNG

My LV is 32bit on a 64bit windows with 32GB RAM .. when I use the 64GB LV version it works fine but actually i have to use the 32bits one .. Is there any kind of solution to make my 32bit LV works with bigger memory or edit the my data flow so that i dont get the error any more?

 

thank you very much 

0 Kudos
Message 1 of 13
(1,905 Views)

PS: I saw all the ''Memory is full threads'' i could not figure out the solution in my case

0 Kudos
Message 2 of 13
(1,903 Views)

Hi Beginner,

 


@Labview.Beginner wrote:

PS: I saw all the ''Memory is full threads'' i could not figure out the solution in my case


Suggestion:

When you can read 20M samples without problems and you need to read 30M samples then you should try to read 10M samples three times…

Best regards,
GerdW


using LV2016/2019/2021 on Win10/11+cRIO, TestStand2016/2019
Message 3 of 13
(1,897 Views)

32-bit OS can support only 4GB RAM (2^32 = 4G addresses). In your case, running a 32-bit app on 64-bit OS, the limit still applies.

 

LV 32-bit has access to only 3GB of the 4GB allocated by the OS.

 

30M sample = 120MB of data (double is 4byte) but there will be multiple copies in memory. One workaround you could do is fetch in segments instead of a single chunk of 30M sample while fetching the waveform and building the larger waveform in LabVIEW as needed.

Santhosh
Soliton Technologies

New to the forum? Please read community guidelines and how to ask smart questions

Only two ways to appreciate someone who spent their free time to reply/answer your question - give them Kudos or mark their reply as the answer/solution.

Finding it hard to source NI hardware? Try NI Trading Post
0 Kudos
Message 4 of 13
(1,896 Views)

As has been said, a 32bit application running on a 64bit OS can only use 4GB of RAM

(There are other limits if e.g. the OS is 32 bit, etc. Details)

 

Arrays in LabVIEW require contiguous memory and you'll run out of sufficient space much earlier than you might expect. For example If you have 20 non-contiguous blocks of 100MB, an array of 101MB will not fit anywhere even though you have 2GB of free memory!

 

In your case, the wire contains 30M x 8(bits/point)=240MB. The graph has a transfer buffer and also it's own memory copy, for at least 720MB. We don't know what's going on in the subVI, so there might be additional data-copies, especially if the front panel is left open by accident.

 

Now, going back to the original problem, I have never heard of an oscilloscope with a 52bit digitizer, so using DBL seems completely unreasonable. I don't know what other options the drivers support, but maybe a datatype with much less hot air would be more reasonable. 😄

 

The cheap solution would be to switch to 64bit LabVIEW (I don't know what 64GB LabVIEW is that you quoted). A better solution would be to pick a more reasonable datatype and more lean code.

 

It is safe to say that you don't have a monitor with 30M horizontal pixels. All the graph needs is a significantly decimated subset of the data. (Don't push a freight train worth of data to the front panel, overtaxing the UI thread if all you can possibly ever see is <<1%). Do you even need to display it? Maybe all you need is push it to disk as a flat binary file.

Message 5 of 13
(1,873 Views)

I relly appreciate all the deep explained answer and your time .. thanks ..

 

I just attached the actual VI i am working with but it gives the same problem .. when i work with 20M it is fine .. but 30M or 40M it gives me the error .. working with 64bit LV is fine in all cases.. but i cant work with 64bits version because this VI is implemented in Teststand programm with runtime engine of 32Bits and other reasons ..

I believe the problem is in the attached photo number (2-B) .. the fetched output of the array is the problem .. I dont know how to change the data size of this so i could reduce the needed memory .. i tried converting it to single precision instead of DBL but it gives the same problem .. 

 

is there any kind of solution to split the array or buffer it without losing the data? .. i really dont know since i dont have that much experience 

 

could you please explain me this sentence: A better solution would be to pick a more reasonable datatype and more lean code.

 

and yes thats true.. you are right.. i dont need to display it i just want to get my TDMS file written.

in my case i dont even need the graphe i can delete it if this helps because i get a logged data as a TDMS file which i can open in DIAdem later.

 

Here is the link of the LV driver of the osci if you want to have a look on the instrument:

RTM3000 – Gerätetreiber | Rohde & Schwarz (rohde-schwarz.com)

https://scdn.rohde-schwarz.com/ur/pws/dl_downloads/dl_driver/oscilloscopes/rsrtx/rsrtx-lv2015-2.4.0....

0 Kudos
Message 6 of 13
(1,819 Views)

Thanks for your reply..

 

actually i have to get it as 30M or 40M samples as one block of output

 

 

0 Kudos
Message 7 of 13
(1,838 Views)

Also, if this is on your playlist, you might want to add this song too. 😄

0 Kudos
Message 8 of 13
(1,837 Views)

thanks for your reply..

 

I added an update in another comment..

 

Would you please explain me or give me some kind of a link or a video of how to fetch the data in segments instead of a single chunk? 

 

in my case it is the 1D output array please see the attached photos in the other comment..

thank you 

0 Kudos
Message 9 of 13
(1,817 Views)

😂😂

 

I am just curious if there is a solution .. i dont know 😄 

0 Kudos
Message 10 of 13
(1,833 Views)