Access shared variable between executables on the same PC

[george seifert]

I have two separate projects that will be built into stand alone executables (Win XP). I want the apps to be able to function as separate entities. In some instances though I want one app to be able to trigger an event in the other app. After reading about shared variables I'm still not sure how to do this. Do I have to use network published variables even when both apps are on the same PC? If I do use a network published variable I assume I have to use the "Bind to Source" property (I don't really know that for sure). What do I enter for the Path? This gets confusing when working with executables.

George

[Yair]

I don't know about shared variables, but I assume you should be able to do this through VI server by getting a reference to a control and using the Value (signaling) property.

[george seifert]

I don't know about shared variables, but I assume you should be able to do this through VI server by getting a reference to a control and using the Value (signaling) property.

Nope. That doesn't work between executables.

[Yair]

Nope. That doesn't work between executables.

Seems to work fine in 7.0.

You have to make sure that you enable the VI server's remote access in the executable (Options menu or INI settings) and that you give each executable a unique port number.

Then, you need to wire 'Localhost' into the machine name input of "Open Application Reference" and the correct port number.

Lastly, you need to remember to wire the application refnum from your Open function into every VI which will need it (like Open VI reference).

[Aitor Solar]

Seems to work fine in 7.0.

Yep, and it's a pretty good system that allows a lot of customization like connecting simultaneously with several instances of the same executable, etc. Another option is to compile the exes as ActiveX servers, then you can communicate between them in a very similar way (in fact you just need one of them to be registered as a server, the other one reads and writes on it). An example is attached. The advantage of this system is you can communicate with the program through another languages, not just LV.

That been said, I was wondering about the shared variables in two local exes too, 'cause it seems a simpler solution in some cases. My guess is they should be the network type, because for each one the other application is external, even if they are running in the same machine (the same holds true for VI server, when you must use remote access and a valid port number though you never go through the net), but unfortunately I still haven't be able to check it, because the shared variables crash my PC :-(.

Saludos,

Aitor

[REM1]

I have two separate projects that will be built into stand alone executables (Win XP). I want the apps to be able to function as separate entities. In some instances though I want one app to be able to trigger an event in the other app. After reading about shared variables I'm still not sure how to do this. Do I have to use network published variables even when both apps are on the same PC? If I do use a network published variable I assume I have to use the "Bind to Source" property (I don't really know that for sure). What do I enter for the Path? This gets confusing when working with executables.

George

You should use "network published" even though both executables are on the same machine. This will put the variable into the data engine so both applications can use it.

Do not use "Bind to Source"...this allows you to have the variable connected to hardware. If you are familier with previous versions of the DSC module, by not binding you have the equivilent of a memory tag...your appplications can both read and write to the variables which seems to be what you are looking for.

FYI...'Path' refers to the network addess to which you want to bind the varaiable. N/A in your case.

[george seifert]

Do not use "Bind to Source"...this allows you to have the variable connected to hardware. If you are familier with previous versions of the DSC module, by not binding you have the equivilent of a memory tag...your appplications can both read and write to the variables which seems to be what you are looking for.

Unfortunately, I don't have any experience with the DSC module. If I don't use the "Bind to Source" then how do I tell the second executable how to access the variable?

George

[REM1]

Unfortunately, I don't have any experience with the DSC module. If I don't use the "Bind to Source" then how do I tell the second executable how to access the variable?

George

Write your first application and have it include a library with your variable in it. Choose to have the library automatically deployed.

Now you have three options:

1. Assuming that you prefer to have the ability to choose the variable to which your 2nd application connects at runtime, place a shared variable control (located on the I/O palette) on the front panel of your application. Clicking the drop-box control you will be presented with the option of browsing the variable space. This will allow you to choose the variable to which you are connected. The output of this control must be wired into a datasocket read/write (depending on whihch you want to accomplish.)

2. You can determine the URL of the variable from the 1st application and wire that as a constant to the datasocket read/write rather than having the control on a front panel.

3. Assuming that you prefer to set the variable at edit time and do not want to change it, add the library containing your control variable to the 2nd application's project (in addition to being in the project for the 1st application.) You can now drag/drop the variable from the project list to the diagram and it will be automatically bound to that variable. This use case will redeploy the library when the 2nd application is launched.

Note: in either case listed above you will have to put the read in a loop and check it occasionally (or use a timeout on the datasocket read.) Optionally you can make use of the event structure but that requires the DSC module be installed as we discuss in another thread.

Yep, and it's a pretty good system that allows a lot of customization like connecting simultaneously with several instances of the same executable, etc. Another option is to compile the exes as ActiveX servers, then you can communicate between them in a very similar way (in fact you just need one of them to be registered as a server, the other one reads and writes on it). An example is attached. The advantage of this system is you can communicate with the program through another languages, not just LV.

That been said, I was wondering about the shared variables in two local exes too, 'cause it seems a simpler solution in some cases. My guess is they should be the network type, because for each one the other application is external, even if they are running in the same machine (the same holds true for VI server, when you must use remote access and a valid port number though you never go through the net), but unfortunately I still haven't be able to check it, because the shared variables crash my PC :-(.

Saludos,

Aitor

The vi server use case will not work with shared variables since they are technically external to the LabVIEW executable. And why do the shared variables crash your PC...if I may be so bold.

[george seifert]

Write your first application and have it include a library with your variable in it. Choose to have the library automatically deployed.

Now you have three options:

1. Assuming that you prefer to have the ability to choose the variable to which your 2nd application connects at runtime, place a shared variable control (located on the I/O palette) on the front panel of your application. Clicking the drop-box control you will be presented with the option of browsing the variable space. This will allow you to choose the variable to which you are connected. The output of this control must be wired into a datasocket read/write (depending on whihch you want to accomplish.)

I got hold of an engineer at NI that sent me an example of how to do it with "Bind to Source" (I asked him to make it available as an example). It was really pretty easy. It seems like that way would be a lot easier than having to include a datasocket read. I thought shared variables were supposed to take the place of datasockets.

George

[Aitor Solar]

The vi server use case will not work with shared variables since they are technically external to the LabVIEW executable. And why do the shared variables crash your PC...if I may be so bold.

I don't understand what do you refer to with "the VI server case with shared variables", I considered them two different ways of transmitting data. Or do you mean affecting shared variables through VI server? I hadn't thought about that, but it would sound interesting (if you hadn't already stated that won't work, of course ;-)).

About the crash, I really don't know, the laptop just crashed repeatedly when the "deploy" window appeared. I'll try to test it in another machine, if the license allows me to do so.

Saludos,

Aitor

[REM1]

I don't understand what do you refer to with "the VI server case with shared variables", I considered them two different ways of transmitting data. Or do you mean affecting shared variables through VI server? I hadn't thought about that, but it would sound interesting (if you hadn't already stated that won't work, of course ;-)).

About the crash, I really don't know, the laptop just crashed repeatedly when the "deploy" window appeared. I'll try to test it in another machine, if the license allows me to do so.

Saludos,

Aitor

I had meant affecting shared variables through VI server...and it won't work.

I got hold of an engineer at NI that sent me an example of how to do it with "Bind to Source" (I asked him to make it available as an example). It was really pretty easy. It seems like that way would be a lot easier than having to include a datasocket read. I thought shared variables were supposed to take the place of datasockets.

George

The variable is the preferred method. The datasocket read is useful when you do not know the URL of the variable to connect to at edit time. Datasocket refers to both the diagram API (and, in fact, a front-panel API) and a communication protocol. The shared variable very definately replaces the datasocket communication protocol. The diagram and front-panel APIs were adapted to work with the underlying shared variable technology.

[george seifert]

... but unfortunately I still haven't be able to check it, because the shared variables crash my PC :-(.

Saludos,

Aitor

I've gotten shared variables to work between VIs in two projects with a small example. Now when I scale it up to my large project, LV crashes when I have both VIs running and the code gets to the point where it's trying to write to the shared variable. I backed out the shared variable of each project and the VIs function fine independently. When I put the shared variable back in it crashed again. Has anyone else run into this? Seems to me that the size of the project shouldn't matter.

George

[REM1]

I've gotten shared variables to work between VIs in two projects with a small example. Now when I scale it up to my large project, LV crashes when I have both VIs running and the code gets to the point where it's trying to write to the shared variable. I backed out the shared variable of each project and the VIs function fine independently. When I put the shared variable back in it crashed again. Has anyone else run into this? Seems to me that the size of the project shouldn't matter.

George

The size of the project should not matter. Could you post a snippet of your code for us to look at?

[george seifert]

Write your first application and have it include a library with your variable in it. Choose to have the library automatically deployed.

Now you have three options:

1. Assuming that you prefer to have the ability to choose the variable to which your 2nd application connects at runtime, place a shared variable control (located on the I/O palette) on the front panel of your application. Clicking the drop-box control you will be presented with the option of browsing the variable space. This will allow you to choose the variable to which you are connected. The output of this control must be wired into a datasocket read/write (depending on whihch you want to accomplish.)

2. You can determine the URL of the variable from the 1st application and wire that as a constant to the datasocket read/write rather than having the control on a front panel.

I just tried using the datasocket to do the shared variable read. I fed the URL of the variable I'm reading into the "connection in" input and the type of my shared variable into the "type" input. I'm getting confusing info back from the Datasocket Read VI. The "quality" indicator reads 0. The help says that means "The data item is of good quality". However I get an error 42 (general error) from the VI, which tells me nothing. The URL I used is the same one I used if I use Bind to Source and it reads the shared variable fine that way. Any more hints on how I can programatically tell my VI where to read the shared variable?

George

[Aitor Solar]

Well, I re-installed LabVIEW and I have managed to communicate between exes through a shared variable with no problem at all. I suppose something was bad with the previous installation

Saludos,

Aitor