Alternative for Queue in SubVI

[mark_wer]

Hello,

I'm currently searching for a way to eliminate the named Queue in my SubVI because it causes a memory leak. I want to save the data from my last SubVI call and use it when i call the VI again. The SubVI is also called multiple times in the main VI over a for loop with an array as input, It should remember to which array call which last data belongs. So the array element was the name in Obatin Queue which had the effect i am looking for, but this just works for a limited time because of the memory leak. Maye someone has an idea what i could try instead of the queue? Everything should happen in the SubVI when possible so i just have to pass the Array to the SubVI:

I already tried the feedback node in combination with reentrant execution, but this doesn't seem to work when the SubVI is called in the for loop because the old data from one array influence the next call of the SubVI.

I hope i described my problem accurate enough. Thanks in advance 🙂

[GerdW]

Hi mark,

I'm currently searching for a way to eliminate the named Queue in my SubVI because it causes a memory leak

Well, the queue itself does not create memory leaks - it's your program using these queues…

So you avoid memory leaks by cleaning up all references properly!

So the array element was the name

I didn't get your problem from your description completely - but usually I recommend variant attributes to setup key-value-pairs easily. There are other LUT implementations available in the forum NI community…

[mark_wer]

Hi GerdW,

i just made a quick example which shows the concept of my problem. 
So i pass the array to the SubVI, do something in the SubVI and want to save the value from this explicit call until the same array is calling the SubVI again. So for example in Array is '1' and '2'. When '1' "calls" the SubVI x+y is 1, when '2' calls the SubVI x+y should also be 1 and not 2. When I call the SubVI again with '1' it should remember the value from the first call with '1'. This ist just a quick overview over the concept and normally in the SubVI every call with the array results in different values. I hope this helps to understand my problem.  

[GerdW]

Hi mark,

So for example in Array is '1' and '2'.

So those elements act as "key" and your subVI holds a "value" for each "key".

As said before: usually I recommend variant attributes for key-value-pairs!

[mark_wer]

Hi GerdW,

thanks for your help. I think variant attributes is the thing I'm looking for. I tried to implement it and it works when there's no for loop in the timed loop, but when the attached SubVI is in the for loop and should save the values for '1' and '2' seperatly it uses values from every last run and not from last run with its name. So there is no individual lock for the keys, but one lock for both keys. Is there anything i could try different? 

Best regards,

mark

[Bob_Schor]

Mark,

     Please attach VIs, not pictures of VIs.  If I want to understand your question by running your code, the "picture" means that I have, myself, to code your application, whereas if you attached the VI (in runnable form), I could simply "run" it.  Please help us to help you.

Bob Schor

[GerdW · Accepted solution]

Hi mark,

Is there anything i could try different?

Sure!

For a start you should not use that variant constant at the SetAttribute function! Wire the variant output from GetAttribute to SetAttribute - right now you reset the information kept in the wire ( and with this variant) each time you call this subVI.

Learn about FGVs (Functional Global Variables) and how they store information!

Btw. using AutoCleanup once in a while is considered "nice behaviour"! 😄

[mark_wer]

Hi GerdW and Bob,

sorry for the pictures, I'm new here. I will attach the SubVI and main VI now...with AutoCleanup 😉

I think it's working now. Is there the same Problem with the Obtain Queue? So is there a possible memory leak?

Best regards and thanks for your help
mark

[Hooovahh]

There is no known bug with Queues that cause memory leaks.  Any memory leak I've seen with Queues are the result of the programmer not using them properly (for every open do a close, proper error handling, etc).  There are several lessons on using Queues in Core1 and 2, and several free online training sessions talk about best practices.

[mark_wer]

---

@Hooovahh wrote:

There is no known bug with Queues that cause memory leaks.  Any memory leak I've seen with Queues are the result of the programmer not using them properly (for every open do a close, proper error handling, etc).  There are several lessons on using Queues in Core1 and 2, and several free online training sessions talk about best practices.

---

Hi,
yes it's maybe no bug, but it's not the right thing for my purpose either. I want to do as much as possible in the SubVI so I can not obtain the Queue in the Main VI and pass it to the SubVI. It's also not possible to close the queue in the SubVI again, because then I lose the purpose of what i want to achieve with the Queue. That's why i was asking for an alternative 🙂 I don't exclude the possibility that there is a way to use Queue like i wanted to use them, but for me there was a memory leak.

This is from the LabVIEW help:

If you use the Obtain Queue function to return a reference to a named queue inside a loop, LabVIEW creates a new reference to the named queue each time the loop iterates. If you use Obtain Queue in a tight loop, LabVIEW slowly increases how much memory it uses because each new reference uses an additional four bytes. These bytes are released automatically when the VI stops running. However, in a long-running application it may appear as if LabVIEW is leaking memory since the memory usage keeps increasing.

If LabVIEW wouldn't create a new reference for a named Queue, there wouldn't be the memory leak.

Best regards
mark