Passing DVR to Other Context

[paul_cardinale]

I can pass a reference to a control down to a VI in another context and it works OK.

But when I pass a DVR, it doesn't work.

Is there a workaround for this (other than passing the value)?

[Jérémy_Chiffe]

Hi,

I'm not sure I understand what you tried to achieve with this, and not familiar with the duplication of application contexts.
But I'm not really surprised that the DVR does not work in another context, given that it does not work between multiple LabVIEW executables either.

The method "Create Local Host App Instance" is not really documented. Even in the LabVIEW wiki :
https://labviewwiki.org/wiki/Application_class/Context.Create_Local_Host_App_Instance_method

Maybe the "options" parameter hide some usefull functionalities. The NI support can probably give you more informations about this method.

As an alternative, there are other solutions to share data between application instances, like the memory mapped files... But you won't get all the functionalites of a DVR.

Hope it's help.

[rolfk]

Application contexts in LabVIEW are pretty much synonym to seperate process spaces for most aspects in LabVIEW programming. All LabVIEW refnums are specific to an application context and hence not valid in a different context (There was a bug in LabVIEW 8.0 when these primitives were introduced that shared queues and other refnums across contexts, but that was clearly not intended behaviour and got promptly fixed in the next LabIEW release). Control and other UI refnums might be special since they are so called static refnums that you can't close (the Close Reference is a No Operation).

Basically trying to pass File, Network, User Event, Notifier, Queue, Semaphore and also DVR refnums between application contexts is just as useless as trying to pass them to a different process. They mean nothing. I haven't tested if the name space is also seperate (which means that even if you open a Queue by name in one context it will not share the queue with anoter Open by Name in a different context but chances are big that this is also seperate).

VISA refnums and similar named refnums might be also special. While they do use internally a int32 refnum cookie like the greenish refnums too, the functions do check if that refnum cookie is a valid refnum and if that is not the case, attempt to open the refnum inplicitly using the named resource name. For VISA refnums that usually would most likely still work since Windows does not know about LabVIEW contexts and doesn't usually complain if the same process tries to reopen a port.

[Hooovahh]

Yeah what rolfk said.  I'd only add that there are plenty of ways to communicate between contexts, but is isn't like a shared memory location and more like a transport protocol.  Here is one article on shared variables. I'd also expect Network Streams, WebSockets, and even TCP to work using localhost.  Other than that the quick and dirty method is using File I/O.  Have one file dedicated to information one context writes, and another file for information the other writes.  Each can open the other file read-only and see what is in there.  Pretty clunky but it is a somewhat universal way for other languages can communicate with LabVIEW programs.

[paul_cardinale]

I ended up just passing the data directly instead of trying to pass a DVR to the data.