From 04:00 PM CDT – 08:00 PM CDT (09:00 PM UTC – 01:00 AM UTC) Tuesday, April 16, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Delete cluster/variables to free memory space

Solved!
Go to solution

Hello everyone.

 

My question is more about good practice than really related to a problem that I have (yet).

I defined a cluster (as a type def.) that groups different data that will be sent from a producer loop to a customer loop through a FIFO. If I understand correctly, Labview will create a copy of this cluster every time I am sending new data through the FIFO. To do so, Labview will allocate memory space for each new cluster, and therefore for each new data inside the cluster. I am wondering how to free this memory space once the customer has used them. If it is an image for example, I can use the "dispose image" vi to free the memory space. But what about the rest?...  (strings, double, tables, references, boolean,...)

 

How can I tell Labview to free the memory space allocated for the clusters and any variables inside once the customer is done using it?

More generally, how can I ask Labview to free memory space for any kind of variable when I know I won't use it again?

 

Thanks a lot for your help.

Best regards.

Luc

0 Kudos
Message 1 of 6
(3,483 Views)
Solution
Accepted by topic author LucG

Hi Luc,

 

LabVIEW uses it's own memory handler.

And due to THINK DATAFLOW! it will free memory when the data (aka the wire) isn't used anymore…

(This does not hold true for references: always close references (atleast those you explicitely opened)!)

 

You might use the RequestDeallocation function - but this will be just a request. The memory handle might follow that request - or it might not…

Best regards,
GerdW


using LV2016/2019/2021 on Win10/11+cRIO, TestStand2016/2019
Message 2 of 6
(3,475 Views)

I do not recommend to use RequestDeallocation. Experience shows that this function is the most misunderstood function from LV. In most cases i've seen it, it serves either NO PURPOSE or HOGS THE SYSTEM by repeated deallocation followed by allocation of the exact same amount of memory.

 

If you feel urged to use manual memory allocation/deallocation, LV is the wrong language to use...

Norbert
----------------------------------------------------------------------------------------------------
CEO: What exactly is stopping us from doing this?
Expert: Geometry
Marketing Manager: Just ignore it.
Message 3 of 6
(3,457 Views)

When you create a FIFO (particularly a Real-Time FIFO), you specify its size and type.  So if you create a FIFO for a cluster that occupies 100 bytes and allocate 10 elements in the FIFO, it will take 1000 bytes of memory to hold as many clusters as you care to pass through it (as it will "block" when you try to add the 11th element until the FIFO has room).  Thus the memory is decided "up front".  Note you can also do the same thing with Queues by building a finite-length Queue.

 

If you are done with the FIFO, you can free its memory by deleting it.

 

Bob Schor

Message 4 of 6
(3,421 Views)

@LucG wrote:

I defined a cluster (as a type def.) that groups different data that will be sent from a producer loop to a customer loop through a FIFO.


The queue allocates memory as is needed.  So if you previously had 10 elements in the queue, but none now, there is memory allocated for 10 elements.  If you add another element, it just reuses what was already allocated.

 

If for some reason you need to clear out this memory (due to a large spike of elements being enqueued perhaps), there is the Flush Queue which will delete the memeory buffer.  But the memory will just be allocated again when elements start being enqueued again.


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 5 of 6
(3,400 Views)

Thank you all for your answers.

Things are clearer for me now.

Have a good day.

Luc

0 Kudos
Message 6 of 6
(3,365 Views)