07-30-2020 04:42 AM
Hello ,
i am want to share same queue for two different labview executable, is it possible ?
07-30-2020 04:59 AM - edited 07-30-2020 05:02 AM
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)…
09-21-2020 02:19 AM
Thank you so much for your reply .
09-21-2020 05:24 AM
RabbitMQ is a network shared queue system.
The normal queues are limited to the same .exe.
09-22-2020 02:53 AM - edited 09-22-2020 02:57 AM
@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.