LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

pass data value reference between applications

Solved!
Go to solution

The question is whether data value application reference is local to application instance, or can be transferred between different applications.

I have a main application that acquires 100 MB array and I need to use these data in a dll. Obviously I do not want to send array, reference would be better. Both applications are built in labview 2011. 

The second question is whether data value reference can be converted to string (type cast or flatten to string) and back. For example with DAQmx tasks flatten to string does not work.

0 Kudos
Message 1 of 10
(5,503 Views)

I'm pretty sure the answer to both of your questions is "no", though I haven't ever tried it to verify.

 

Have you considered trying to use the Shared Variable Engine instead?

0 Kudos
Message 2 of 10
(5,490 Views)

Shared variable engine... between applications it means network based shared variables. 

 

Inside main application there is one copy of these data, I did not want extra copies just for sending, client dll just reads data. And installing an extra pretty heavy engine for a simple task of copying data - it is an overkill.

So it will be local UDP or TCP.

0 Kudos
Message 3 of 10
(5,472 Views)

I looked in to doing something like this awhile ago.  The best I could find was this:

 

http://digital.ni.com/public.nsf/allkb/A1767CAD4B99A3A6862572800067436A

 

... but it uses network variables.

0 Kudos
Message 4 of 10
(5,460 Views)

Second question answer is yes, conversion from data value reference to string (flatten and back) works, reference is not lost.

Reference to string conversion.png

0 Kudos
Message 5 of 10
(5,452 Views)

Inside the same VI it works, sure.  But I don't think it will work between different applications and their respective allocations of memory.

 

If two different applications are on the same PC and using the shared variable engine, there's no actual network communication going anywhere, it's all localhost, and should be very fast.

0 Kudos
Message 6 of 10
(5,447 Views)

>> Inside the same VI it works, sure.  

I was not that sure... it does not work for DAQmx tasks.

 

>> But I don't think it will work between different applications and their respective allocations of memory. 

That is the first question, will take some time to try...

 

>> If two different applications are on the same PC and using the shared variable engine, there's no actual network communication going anywhere, it's all localhost, and should be very fast.

But it still starts and creates big general service, creates new buffers of data. Does not allow access to portions of data (read only row 1253) without creating an extra copy.

 

No, no, no. For convenient data transfer between PCs, NI network targets yes, shared variable engine is good, but for local transfer - no... Here NI confirms (aug 2013) SVE is more convenient, but not the best performance way... http://www.ni.com/white-paper/12079/en/ 

0 Kudos
Message 7 of 10
(5,429 Views)
Solution
Accepted by Alexander_Sobolev

@Alexander_Sobolev wrote:

The question is whether data value application reference is local to application instance,


Yes.


or can be transferred between different applications.


 No.


The second question is whether data value reference can be converted to string (type cast or flatten to string) and back.

 Yes, but reference only means something in the app instance it was created in.

 

 

You might wish to give more details about what your actual requirements are, but keep in mind that playing with memory directly in LV is not that simple, as it does everything it can to hide all these details from you.

 

If you want to pass a pointer to an array to a DLL, you can configure the DLL call to do this. If you want to get the address of a specific LV array in memory and pass that around, this is not something LV supports and you shouldn't do it, because memory should not be controlled by more than one master at any point in time.

 

LV does have functions for allocating memory and getting the pointer back, but that requires explicit calls.

 

Anyway, I don't have any real experience with all this. If you want reading materials, there are at least two users here with much more knowledge on the topic and you can go through their posts or search and filter for their posts - rolfk and nathand.


___________________
Try to take over the world!
Message 8 of 10
(5,391 Views)
Is the DLL called from your main application, or a separate application? If it's called from your main application, I believe the DLL will use the main application's run-time space, and that allows sharing some data in ways that wouldn't work between separate applications. I've never had a reason to experiment with this, though, and Rolf might be able to fill in details.

For completely separate applications, have you considered VI server? Store the data in a functional global variable that's hosted in the main application and is accessible to external applications. You can add actions to the FGV to do things like return only a subset of data. This keeps the large array in only one application while allowing limited access to it from other applications.

If your applications are separate, and both sides need access to the full array, and you only want to maintain a single copy of the array, you need to use shared memory. Windows provides functions for this although they are not simple to call from LabVIEW. I think you can find example code elsewhere on this site. Even with shared memory, your LabVIEW applications will probably still need to make a local copy to do any work on the data.
Message 9 of 10
(5,369 Views)

Is it possible to use these two applications as subVIs in a top level VI?  It's much easier to share stuff when they are part of the same application.

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 10 of 10
(5,322 Views)