LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Why would I have a queue in two different vi's generate a sepearte refnum if they have the same name?

Solved!
Go to solution

Hello WORLD!

 

I have a producer consumer setup, where the the producer and consumer are in sepearte vi's.  They have the same name, but are not communicating their existance to each other for the obtain queue function.  As a result, only one is valid, the other ends up invalid.  If I check the renum for each loop, they are different.  Any guesses?

-Regards

eximo
_______________________________________________
UofL Bioengineering M.S.
Neuronetrix

"I had rather be right than be president" -Henry Clay
0 Kudos
Message 1 of 9
(2,979 Views)

~~~~~Oh magic 8 ball~~~~

Did you wire T to "create if not found?" on only the second obtain queue that executed?

 

That would do it since the named queue wouldn't exist the first time and you did not give the function permission to create a named queue so- null reference out.


"Should be" isn't "Is" -Jay
Message 2 of 9
(2,973 Views)

 

yes, the T is wired by default, but I made sure to wire T for all the obtain queue

the producer vi initates and creates the queue.  The queue is then valid.

Then the consumer vi initiates and ........?  The queue in the producer vi becomes invalid.

 

Additionally, the consumer vi's refnum is different than the producer vi's refnum.

-Regards

eximo
_______________________________________________
UofL Bioengineering M.S.
Neuronetrix

"I had rather be right than be president" -Henry Clay
0 Kudos
Message 3 of 9
(2,969 Views)

stripp it down to something that demonstrates the problem reproducably and post the example


"Should be" isn't "Is" -Jay
0 Kudos
Message 4 of 9
(2,962 Views)

force the second to run second and use a "F" instead.

 

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 5 of 9
(2,960 Views)

Read the Detailed Help. See the part I underlined below.

 

"Use named queues to pass data between two sections of a block diagram or between two VIs in the same application instance. If you do not wire name, the function creates a new, unnamed queue reference. If you wire name, the function searches for an existing queue with the same name and returns a new reference to the existing queue. If a queue with the same name does not already exist and create if not found? is TRUE, the function creates a new, named queue reference."

 

Lynn

 

Queue refnums.png

0 Kudos
Message 6 of 9
(2,958 Views)

Well i wonder if it's possible a race condition can exist, where the queue (back channel) is obtained in two places at the same time.  vi one obtains (back channel) then vi two obtains back channel almost immediately, it creates a new one because it cannot find the old queue? 

 

can i put the obtain queue inside the loop and set it to F not create a new queue?

-Regards

eximo
_______________________________________________
UofL Bioengineering M.S.
Neuronetrix

"I had rather be right than be president" -Henry Clay
0 Kudos
Message 7 of 9
(2,953 Views)
Solution
Accepted by topic author eximo

The destory queue was wired for true in the subvi, force destroy of the queue.  So, the queue was being invalidated and then recreated in the other vi.  

-Regards

eximo
_______________________________________________
UofL Bioengineering M.S.
Neuronetrix

"I had rather be right than be president" -Henry Clay
0 Kudos
Message 8 of 9
(2,934 Views)

Ahhh so it wasn't the obtain reference that was the problem- it was that destryoing the queue somehow... sort of.... destoryed it or something.  Smiley LOLSmiley LOL


"Should be" isn't "Is" -Jay
0 Kudos
Message 9 of 9
(2,928 Views)