Jump to content

Sharing a LV2 global between Labview Executables


Recommended Posts

I have two separate pieces of code which pass data between themselves using a LV2 global. However when these two functions are compiled into separate executables, each executable has its own copy of the LV2 global and hence the data is not shared between them.

Can anyone suggest a way to share a LV2 global between multiple executables. I have tried to use the VI server to load the LV2 global, but the data is still not shared.

Thank you in advance for any help,

Daniel

*UPDATE*

I have found a link which may help me get my VI Server solution working: http://forums.lavausergroup.org/index.php?showtopic=521.

Link to comment

After working out how to use the VI Server, I am still having some problems:

Currently I am trying to implement a more object based approach to my coding, which will in turn simplify my code re-use. In order to link my code into an in-house software application which is implemented in C++, each class I produce in LabVIEW code will be compiled into a separate dll. These classes will be called directly from the C++ app or called from other LabVIEW classes (dlls) which will in-turn be called from the C++ app.

Each class has a LV2 global to store data relating to that class, this LV2 global is stored inside the class dll. I am then using the VI Server to access that particular LV2 global to retrieve the class data. The problem I am finding is that when each class (dll) is called from the C++ app, it starts a new run-time engine and hence needs a different

Link to comment
I have two separate pieces of code which pass data between themselves using a LV2 global. However when these two functions are compiled into separate executables, each executable has its own copy of the LV2 global and hence the data is not shared between them.

Can anyone suggest a way to share a LV2 global between multiple executables. I have tried to use the VI server to load the LV2 global, but  the data is still not shared.

Thank you in advance for any help,

Daniel

*UPDATE*

I have found a link which may help me get my VI Server solution working: http://forums.lavausergroup.org/index.php?showtopic=521.

4379[/snapback]

Hi Daniel

I've had the same problem in an earlier application. I was using queues to communicate between the to applications. I've solved the problem by using TCP/IP and made the TCP as an extension to the queued messages. The shared globals was made as functional globals, and in the write case i've implemented a TCP/IP send to the same global in the other application. In the start up sequence of the 2 applications i synchronize them if the other application was running.

The reason way it not is possible to share the data between to sperate executables, is that windows sperate the memory even though the same LV runtime is used. Windows dos not allow memory leaks.

NI-DK tooled me that this is the easiest way to solve the problem. :yes:

I hope this can help you.

Chrisitan Kjeld

Link to comment

A more general approach to this problem can be overcome with Datasocket. You can setup the DS Server and have a common socket eg dstp://localhost/myglobals that the two exes Write and Read (easier for beginners than TCPIP because you can link these direct to a control on your panel[1]). There are other issues that you WILL want to address such as synchro at start, race conditions while running, etc.

cheers, Alex.

[1] Of course even easier is to use a file stored in a common area but if your exe's will ultimately live on separate networked machines then DS could serve your needs.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.