LabVIEW

cancel
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
(1,486 Views)

Hi RRG,

 


@R_R_G wrote:

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


No.

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,
GerdW


using LV2016/2019/2021 on Win10/11+cRIO, TestStand2016/2019
0 Kudos
Message 2 of 5
(1,478 Views)

Thank you so much for your reply .

0 Kudos
Message 3 of 5
(1,307 Views)

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! - Qestit VIPM GitHub

Qestit Systems
Certified-LabVIEW-Developer
0 Kudos
Message 4 of 5
(1,292 Views)

@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 xyz.vi somewhere in its hierarchy it will not mess up your application that may use your own version of a xyz.vi, as they are completely independent from each other and loaded each into their own application context space.

Rolf Kalbermatter
My Blog
0 Kudos
Message 5 of 5
(1,262 Views)