LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Memory keeps increaing and this VI has a lot of Memory resize allocate events

Solved!
Go to solution

Thanks for the reply...

Does this include Queue references? I am currently not using any VI or data references, just Q's.

0 Kudos
Message 11 of 18
(1,154 Views)

@BG103 wrote:

Thanks for the reply...

Does this include Queue references? I am currently not using any VI or data references, just Q's.


Yes!!!  Queues, File, Notifiers, etc. etc. etc.

 

Here is a good article for you to read through: Closing References in LabVIEW


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 12 of 18
(1,149 Views)

@BG103 wrote:

Does this include Queue references? I am currently not using any VI or data references, just Q's.


Absolutely. Every Obtain Queue should have a matching Release Queue. Every instance of Obtain Queue creates a new reference that needs to be closed, even if you're obtaining references to named queues that have already been created.

 

Two general rules:

1) Pass queue references into loops. Don't obtain queues (or other resources) repeatedly inside loops.

2) Avoid named queues unless you really need them. Use wires to pass queue references.

0 Kudos
Message 13 of 18
(1,142 Views)

Thanks for the advice and information.  

You said pass Q refs via wire...Is it possible to pass Queue references via a funcitonal global variable? 

0 Kudos
Message 14 of 18
(1,136 Views)

@buton wrote:

close reference.png


Wait, what?

Is the "This VI" constant (I'm assuming the constant is autoconverted to a control in a snippet?) enumerated to a new VI reference each time it enters a property node or invoke node?  this is news to me, I assumed it always pointed to the same reference.

0 Kudos
Message 15 of 18
(1,129 Views)

@BG103 wrote:

You said pass Q refs via wire...Is it possible to pass Queue references via a funcitonal global variable? 


Yes, that's OK too. A common pattern is a functional global that creates the queue the first time it's called, and then returns the same queue reference from the shift register on every call after that. The idea is to avoid opening multiple references to the same named queue, because that's where it's easy to leak a reference.

0 Kudos
Message 16 of 18
(1,112 Views)

So will reference leaks cause "Out of Memory" or "Memory is Full Error"?

 

Also, anyone know what the Reference Leak >> File : 0x82E0024A is caused by?  I would assume they are file references but I the source VI does not have any file reference handles.

0 Kudos
Message 17 of 18
(1,094 Views)

@BG103 wrote:

So will reference leaks cause "Out of Memory" or "Memory is Full Error"?


In my experience, not likely.  The Out Of Memory is typically caused by growing arrays.  But reference leaks can also cause it or at least major slow-downs or an error while trying to create another reference (yes, I have seen this error caused by creating 2^32 references).


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 18 of 18
(1,090 Views)