Showing results for 
Search instead for 
Did you mean: 

Is it possible to access same queue reference in two different Labview executable ?

Hello , 


i am want to share same queue for two different labview executable, is it possible ? 


0 Kudos
Message 1 of 5



@R_R_G wrote:

i am want to share same queue for two different labview executable, is it possible ?


Use NetworkStreams…


Edit after looking into your VIs: transfer the "Data" directly using TCP (instead of typecasting the queue reference to text and send this text)…

Best regards,

using LV2011SP1 + LV2017 (+LV2020 sometimes) on Win10+cRIO
0 Kudos
Message 2 of 5

Thank you so much for your reply .

0 Kudos
Message 3 of 5

RabbitMQ is a network shared queue system.

The normal queues are limited to the same .exe.

G# - Award winning reference based OOP for LV, for free! ADDQ VIPM Now on GitHub
"Only dead fish swim downstream" - "My life for Kudos!" - "Dumb people repeat old mistakes - smart ones create new ones."
0 Kudos
Message 4 of 5

@Yamaeda wrote:


The normal queues are limited to the same .exe.

That is only partly true. The restriction is actually even stronger as almost all refnum based objects it LabVIEW are actually application context private. That means that if you use different application contexts in LabVIEW, refnums created in one of them have absolutely no meaning in any other application context.


The most visible difference for application contexts in LabVIEW are when you have multiple targets such as your "My Computer" target and some real time targets in the same project. This would seem also quite logical that they do not share private info like that since they are usually executing physically on different hardware or at least virtualized hardware.

But LabVIEW supports arbitrary application contexts even inside the same executable. For instance all the tools you launch from the Tools menu in your LabVIEW window run inside their own application context and don't have direct access to such refnum objects (and several other things) in your own program. The main reason for this in the case of the Tools VIs is that application contexts also have each their own VI name space. So when your Tool VI references a copy of some somewhere in its hierarchy it will not mess up your application that may use your own version of a, as they are completely independent from each other and loaded each into their own application context space.

Rolf Kalbermatter
Averna BV
0 Kudos
Message 5 of 5