Is it possible to access LabVIEW Global variables from a built LV Application?

[Greg_McKaskle2]

> Thanks for the response. Do you know for sure that regular LV Globals
> are out of bounds from a built LV application? Is it physically in a
> different memory space that is inaccessible? No one has said for
> sure, but I have a feeling that it's true. I also read something from
> Greg McKaskle that eluded to that fact that LV2 Globals are in the
> same boat. I want to make sure the first option is out before trying
> LV2 globals.

If you have VIs in two processes, they are protected from one another by
the OS. They cannot commumincate through normal globals or normal
subVIs. The VI server can be used to either access globals or to run
subVIs, and this will work for both out of process and in proc
ess.

Greg McKaskle

[Rolf]

"Rolf Østvik" wrote in message

> I guess that the LabVIEW executable will run in another memory space than
> the VI's run under TestStand/normal LabVIEW and therefore you will not be
> able to exchange information through globals in any variant.

In fact it is even so that each built application although making use of
lvrt.dll as
runtime library is really a seperate process. So each application as well as
the
development system are entirely isolated from each other and can't read
memory
from each other directly. You need some sort of interapplication
communication
as explained in the remainder of this message.

Additional options might be DDE, VI server, shared memory, pipes, Apple
Events
and such.

> Do you really need to have your mo
nitor as a executable? Would it be
> possible to get TestStand to start the monitoring application as a VI and
> just let it run in the background. (In a small test i managed to start a
> test vi and let it run while my main vi exited.)
>
> I don't know anything about ActiveX so i can't tell suggest anything about
> that.
> Other suggestions:
> Instead of letting the VI's you want to monitor write to Globals could
you:
> - log to a file
> - use tcp/ip or udp (if you have installed network on the PC)

[John_Morrissey]

Greg,
Thanks for the insight. So you're saying that I should be able to access the LV Globals in another process with VI Server? Is there something I have to do so that it knows I want the global in the other process? Also, do you know if the VI Server will access out of process globals in LV 5.1.1. I'm trying to use that now, and I can see the (a) global, but the data isn't there. It does look like it's a copy. I also noticed a note in the online reference saying that globals and custom controls were not accessible, but that they might be in future versions.

Is it time to actually install one of the new LV versions that've been piling up on my desk for the last 3 years? I'd love to have
a good reason for my boss.
John

[JeanPierre]

From your built app, you can access data from a VI running in LabVIEW using either the AvtiveX or TCP VI Server.

However, you can't drop the Global VI and use it like a normal global. You open a reference to the LabVIEW application (ActiveX or TCP VI Server) and use the refnum to open a reference to the global VI. Then you can use the methods "Set Control Value" and "Get Control Value" to access data in the controls.

[John_Morrissey]

Jean-Pierre,
Thanks for the response. I tried doing that with ActiveX, but it didn't work. It's possible that the reason is I'm still using LabVIEW 5.1.1. Do you know if it was something that changed in a later version? If not, I will keep trying. I'm currently using using the "GetAllCtrlVals" methods, but I will try "GetCtrlVal". Is there also something I need to do to designate that it is running in another process (not the run time engine)? Right now I'm passing it the absolute path to the Global variable.
John

[JeanPierre]

It should work for LabVIEW 5.1.1. You should check the error output to see where the error comes from.

[John_Morrissey]

I found my problem. Just to close out the thread, it turns out that it wasn't working because I was trying to access an array of clusters (in a global variable), which apparently is not a supported type (in LV 5.1.1). When I changed to a 2D String array it accepted it in both the LV VI and the built Application. I also had problems accessing a 1D Numeric (U32) array for some unknown reason. The version that finally worked used the LabVIEW._application ActiveX Class -> pulled the GetVIReference method out and then used the GetControlValue method to produce the ActiveX varient. The "To G Data" function converted to the LV 2d string array.