Design issue with sharing LV2 style global between run-time executables

[Nishchey]

Hi,
Just when I though that I had everything figured out, I ran into this design issue.
The application that I wrote is pretty much a client-server application where the server publishes data and the client subscribes data using data sockets. Once the client gets all the data in the mainClient.vi program, I use LV2 style (using shift registers) to make the data global to all the other sub-vi’s. So the LV2 is in initialize mode in the mainClient.vi program and then in the sub-vi’s the LV2 is in read mode. Also, I had built the run time menu for each sub-vi that when an item is selected from the menu, I would use the get menu selection to get the item tag which will be the file nam
e of the sub-vi and open the selected sub-vi using vi server. This all worked great on my workstation where I have labVIEW 7.0 Express installed. But the final goal is to make exe’s for each of these sub-vi’s and install runtime on the PC’s that do not have labVIEW installed. Of course when I did that only the mainClient.exe program was getting the updated data from the server but the sub-vi’s were not getting the data from the mainClient.exe. I did realize that the reason for this is due to the fact that I had compiled all the sub-vi’s separately and so the LV2 vi is now local to each executable (i.e. all executables have their own memory location). Also, the run-time menu did not work because now I am trying to open an executable using vi server properties.

To summarize, is there a way to share LV2 style global's between executables without compiling all of the sub-vi’s at one time? I tried using data-sockets (local-host) instead of LV2 st
yle gloabls to communicate between the sub-vi’s but I ran into performance issues due to the large volume of data.

I would really appreciate it if anyone can suggest a solution/alternative to this problem.

Thanks
Nish

[Greg_McKaskle2]

> To summarize, is there a way to share LV2 style global's between
> executables without compiling all of the sub-vi’s at one time?
> I tried using data-sockets (local-host) instead of LV2 style gloabls
> to communicate between the sub-vi’s but I ran into performance
> issues due to the large volume of data.
>
> I would really appreciate it if anyone can suggest a
> solution/alternative to this problem.
>

You are now looking for shared memory. One option is to use the VI
Server in all the apps but one. Make some quick wrappers around the LV2
style global for the exposed operations. The diagram will connect once
if necessary and keep the connection in a shift register. It will then
use the VI Server to call the appropriate subVI on th
e remote LV process.

Another option is to use your own protocol using datasocket or TCP/IP
instead of using the VI Server. Be careful though that your data loss
and performance are what you wanted.

Another option is to write VI wrappers around shared memory
implementation done in a DLL -- this will be the highest performance,
but will be the hardest of the three.

My vote is to use the first.

Greg McKaskle

[Nishchey]

Greg,
Thanks a lot for you suggestions. Out of the three options I have already tried option 2 using DataSockets or TCP/IP but as you mentioned performance is an issue with this approach. Mainly because DataSockets or TCP/IP is copying the whole array from my main vi to all the other sub-vi's every scan. I would like to investigate option number 1 using vi server. Before, I go ahead with creating a demo could you please elaborate/clarify the following question regarding the suggestion you made:

1) How would I create a wrap-around for the LV2.vi which is initialized in my mainClient.vi and then how would I use vi server in my sub-vi to refer to that LV2.vi?
You mentioned that each sub-vi when opened will first connect to the LV2.vi via via-server and
will keep the connection in the shift register of that sub-vi. Does this mean that the sub-vi is accessing (pass-by-reference) the shared memory of the mainClient.vi? If this is what you meant I think that this might work for my application.

2) Just to elaborate on my application, the data is transferred via DataSockets from the mainServer.vi on another PC to the client’s PC where the mainClient.vi program subscribes the data (i.e. 5 arrays of double type and each arrays has about 50,000 elements). The sub-vi’s will have to access these arrays located on the mainClient.vi every scan. Is there any limitation on referencing the mainClient.vi data via vi-server from each sub-vi?

3) Are there any examples for the suggestion you made above using vi-server?

I appreciate your help.

Thanks
Nish

[Mads]

With the client on another PC there will be a network protocol in between anyway...One problem is that you are trying to transfer too much data. You are talking about transfering 1 MB of data across the network on every scan...unless the scan rate is very slow that's a lot. Why do you need to transfer the data so frequently to all the clients?

Another thing, the question can be interpreted as if your trying to build the client executable as two different applications; one containing the mainClient.vi and the other one containing the "sub-VIs"...that will not work. Either you build all the VIs of the client into one client application, or you can have the sub-Vis as external files or in one external file (the "Small target file with external file
for subVIs" option in the app builder). Sharing data between the mainClient and it's subVIs locally is no problem to do with an LV2 style global then...sharing data across the network between the client and the server will still be, unless you find out that you do not really need to dump 1 MB of data on every scan.

[Daniel Elizalde]

The fact that you are wanting to transmit large amounts of data across a network is going to decrease performance. You can use TCP/IP with your own protocol or DataSocket, but these methods would be harder to implement, can be slow and you may loose data. The VI Server approach sounds better, but you may not get the required performance due to the amount of data you need to move around.

For these types of applications, the best way to do it is through reflective memory. You can think of reflective memory as shared memory space between multiple computers. It is designed for high speed data transfers. With these technology you can get transfers of 16 to 70 Mbytes/sec, depending on the card you buy.

For this solution, you'll
have to invest some money. You need to get two reflective memory boards, one for each system. They are interconnected using a fiber optic link. Two manufacturers are Systran and VMIC. They both provide LabVIEW drivers for their boards.

Hope this helps

Regards,
Daniel

[Greg_McKaskle2]

> 1)   How would I create a wrap-around for the LV2.vi which is
> initialized in my mainClient.vi and then how would I use vi server in
> my sub-vi to refer to that LV2.vi?
> You mentioned that each sub-vi when opened will first connect to the
> LV2.vi via via-server and will keep the connection in the shift
> register of that sub-vi. Does this mean that the sub-vi is accessing
> (pass-by-reference) the shared memory of the mainClient.vi? If this
> is what you meant I think that this might work for my application.
>

If the LV2 global is loaded statically into your mainClient.vi, then any
other application can connect to the exe and get a reference to the VI
using the VI name. This gives you a VI reference you can use to call
the VI. Ye
s, the values will be copied between applications. That is
why you need to add access operations to the global that returns just
the info needed. If you need the average, do that in the global. If
you need the array size, do that in the global. Returning the entire
array shouldn't be a common operation on the LV2 style global anyway.

> 2) Just to elaborate on my application, the data is
> transferred via DataSockets from the mainServer.vi on another PC to
> the client’s PC where the mainClient.vi program subscribes the
> data (i.e. 5 arrays of double type and each arrays has about 50,000
> elements). The sub-vi’s will have to access these arrays
> located on the mainClient.vi every scan. Is there any limitation on
> referencing the mainClient.vi data via vi-server from each sub-vi?

Your app does need to watch both the amount of data being passed across
the network, and the amount being shared between the apps. You might
want to consider puttin
g the VIs back into the main app. What is the
reason you are breaking them apart for?

Greg McKaskle

[Nishchey]

Greg and Mads,
Once again thanks for your response. Based on both of your suggestions it seems that the best way is to build one application (exe) for all my vi’s. This way I can still use my LV2’s within the application shared among the sub-vi’s.

The reason I wanted to separate executables for each sub-vi was because:
1) During tests (measuring and displaying data) there is always a need to create
sub-vi’s “on the fly.” Meaning, I cannot stop the mainClient.exe program
during our testing and recompile everything to add the new sub-vi.

2) Eventually, I might have hundreds of sub-vi’s and I was worried about the compilation time. (The only way I know how to add the sub-vi&#
8217;s from the application builder is by adding them dynamically from Source Files -> Add Dynamic VI…)

3) For security reasons I did not want to share all the sub-vi’s with all the users. If the sub-vi’s were built as separate process then I would have the flexibility to send only a subset of my sub-vi’s to the user. (Is there a way to protect my vi’s so that the vi will only execute if the user has a password?)

For the reasons above, I was inclined towards making each sub-vi a separate application but not at the cost of performance. If you guys have any work around for the items above I would really appreciate it.

Once again thank you!

Regards,

Nish

[Nishchey]

Daniel,
Thanks for your response. Currently, I am exploring all the options of transferring data efficiently between applications via programming. If this does not work I will look into the reflective memory option.
Thanks
Nish