Can I build two LV executables which share data using a type 2 global?

[ChrisV]

I have two LV applications which share data residing in a common VI configured as a type 2 global. Is it possible to configure my build settings so that both applications can continue to share data?

One approach I tried was to build the common VI into a dll which can then be shared. This works fine with the original applications but falls apart once I build them into executables.

[tst]

This won't work because when you build the executable all the VIs are brought into a single files. Therefore, if you build two EXEs, you get two copies of the VI you want, instead of one.
I can think of three ways to solve this:
1. Build one EXE running the two programs.
2. Use a loader, which allows you to keep the VI structure.
3. Use dynamic calls to call your VI, instead of placing it directly in your code. Then you can call it from two different EXEs. If you don't like the way this looks, you can put the dynamic call inside a subVI and put that in your code.

[ChrisV]

Thanks for quick reply 🙂

Here is what my code currently does:
I have been using a loader to execute a series of modules which each share data using a common VI configured as a type 2 global. I would now like to build each module into an executable and continue to use a loader application to run any desired sequence of modules.

Obviously I need to use some kind of shared data space that is external to the built modules. To achieve this I built the storage VI into a DLL, which I would like to be able to call from anywhere. I notice however that each time I build a particular module, it generates a copy of the shared DLL. I cannot seem to get all my modules to share the same DLL.

So, is there any way to configure each module to dynamically call a shared VI with the restrictions that:
(i) the modules must be separate EXEs
(ii) the shared VI must also be 'built' (ie run-time engine operation required!)

Dynamic calls seem like the best option but I can't get my head around how to dynamically call a built VI, yet still get access to its terminals...

[tst]

That's interesting. You say that when you build a VI as a DLL and call it as a DLL from a specific location, LV duplicates it. I wouldn't expect it to do that. Then again, I never worked with LV DLLs, so I don't know.
When I say loader I mean something like this and this [broken link removed]. That means you don't build all your VIs into the executable, only the calling VI, so your VIs keep their hierarchy.
To use my third suggestion, you should use the call by reference node from the application control palette. It allows you to call a VI by its reference AND to use its connector pane. Cool.

[chrisger]

hi

you can access VIs and their controls in build code dynamically by adding the name of the vi to the path of the exe, like "c:\blabla\blub.exe\myvi.vi" (just replace the file extension .exe or .dll with .llb and see what happens when clicking on it in explorer), BUT: the VI in the app shares another dataspace than the VI -instamce you created.

i suggest: take your LV2 and replace the shift register for the data with a shift register for a reference to a static dstp - item and store the data on the dstp - item. for read/write i would prefer a static dstp - item (the app-builder includes dstp - support). if you want you can encapsulate the dstp-io-vi in a dll.

another solution would be the use of a global ini-file, but then you have to open/io/close the file each time you access the data, but you also could add/edit/delete items dynamically at runtime like with dynamic dstp - items.

best regards & let us know
chris

[AnalogKid2DigitalMan]

Would this be of use?

http://sine.ni.com/apps/we/niepd_web_display.display_epd4?p_guid=F20E2C378EDD49D1E0340003BA230ECF&p_node=DZ52029&p_source=external

If so, please give credit to David Bowden.

[ChrisV]

Ha! Accessing VIs inside an EXE is the best trick I've learnt for a while. Thanks 🙂

As for the rest of my issues...
I was originally using a LV2 global to store an array of variables (variants). The elements in the array are indexed by storing the variable name as an attribute. This allowed me to easily pass data between modules.

What I wanted to do was build the modules (one by one) and then continue to use my loader, but once each module is built it seems to run in a completely separate memory space. I can't share the storage VI, even if I dynamically call it using VI server or build it into a DLL.

I have had a play with the data socket approach and it works perfectly - both in development mode and with built apps. At the moment I am just passing the entire storage array around (was the easiest mod to my existing code) but may be better to pass individual elements around.

So now I have a loader based application that can pass data efficiently between modules, with the flexibility that I can build new modules at any time 🙂

Thanks for the help!