LabVIEW: Memory is full. ========================= NI-488: No Listeners on the GPIB.

[SudhaManasa]

Hi,

I'm using LabVIEW for a project where it needs to run for longer duration. But it is going to hang state because of memory full issue.

Below is the error which i got after running continuously.

Error 2 occurred at Obtain Queue in NI_LVConfig.lvlib:Open Config Data.vi->GetParameterList.vi->UARTLib.lvlib:ReadArrayIndexDarwin.vi->UARTLib.lvlib:FillGlobalArrayDarwin.vi->UARTLib.lvlib:RcvTargetToConsoleDarwin.vi->UARTLib.lvlib:RecieveEngineDarwin.vi->LoggingEngine.lvlib:Logging_Engine.vi->LoggingEngine.lvlib:Logging_Engine.vi.ACBRProxyCaller.A7B00027

Possible reason(s):

LabVIEW: Memory is full.
=========================
NI-488: No Listeners on the GPIB.

NI_LVConfig.lvlib:Open Config Data.vi  is the library funtion and im using close config data.vi also after getting data.
but still im facing the memory issue.

please help me to solve this issue

[GerdW]

Hi Sudha,

---

@SudhaManasa wrote:

I'm using LabVIEW for a project where it needs to run for longer duration. But it is going to hang state because of memory full issue.

---

Improve your program so you don't run into "out of memory" problems!

As long as you don't attach any code we cannot help you much more.

Keep in mind:

• We cannot debug/edit/run images with LabVIEW, so please attach real code.
• When you use a very recent LabVIEW version it is recommended to provide a downconverted version of your VI(s), like for LV2019…

[pincpanter]

Besides what suggestes by GerdW, you may start double checking whether the program closes all open references when needed. I mean references of any kind: files, queues, notifiers, etc. Focus on those parts of the code that are executed frequently and continually. Of course, there may be other (perhaps more likely) reasons for the memory problem.

[LucianM]

Most likely you are opening too many queue references in your app and you forget to close them. Biggest problem being not that you forget to close them but that there are so many references opened in the first place!

[SudhaManasa]

im using NI_LVConfig.lvlib:Open Config Data.vi and NI_LVConfig.lvlib:Close Config Data.vi in code.

my question is calling this vi's multiple times will create any memory issues ?

im sharing the error and code how im using those vi's.

Please help me to resolve.

[pincpanter]

---

@SudhaManasa  ha scritto:

im using NI_LVConfig.lvlib:Open Config Data.vi and NI_LVConfig.lvlib:Close Config Data.vi in code.

my question is calling this vi's multiple times will create any memory issues ?

No.

---

im sharing the error and code how im using those vi's.

---

None of them is useful to solve the problem. This is only the droplet that fills the vase, however the real flood is elsewhere in your program.

[SudhaManasa]

how can i check from where the queue is getting full ??

any tools to trace it

[rolfk]

---

@SudhaManasa wrote:

how can i check from where the queue is getting full ??

any tools to trace it

---

It's not the queue that gets full. A Queue Reference as allocated by that Open Config requires a few 100 bytes to maybe 1 kB of memory. If the call to that function fails it is because of one of these reasons:

1) You allocate more than several million queues somewhere without closing them. LabVIEW has a limit of around 4 million objects per refnum type (queue, file, network, etc).

2) Your code allocates somewhere else huge amounts of memory that can just barely be satisfied and when LabVIEW then tries to allocate a queue to be used by the config VIs it fails. This can happen but would be strange if it consistently happens in multiple runs like that.

You may be thinking that you always call the Close Config function, but can you proof that that is the case? Or maybe someone tinkered with your Close Config VI and it does not properly execute the cleanup code when there is an incoming error? All LabVIEW Close VIs should always clean up even if there is an incoming error, and NI functions do that for a long time already. But maybe your VI got somehow "improved" by someone?