Global variables to share data between separate programs.

[Alf Katz]

Hi guys and gals,
On the advice of a lv consultant, we've used an array of global
variables to share data (about 100 variables) between an acquisition/control
program and a consumer program (datalogging) running on the same PC. This
worked fine in the development environment. However it no longer works when
the two programs are compiled. Is there a trick to get this to work or do
we have to use datasockets or DDE to move the data.

In case you're wondering the idea of two separate programs is to
separate the critical control and data acquisition functions from the less
critical but more likely to error datalogging functions.


--
Regards,
Alf Katz,
alfkatz@removethis.ieee.org

[Koen]

Hello,

A quick and dirty work around could be to use a datalog file or other file type that both programs can access, be sure not to lock the file previleges then. This solution should be quite sturdy though and you even get a last settings file immediately.

[jefferymeyer1]

There are several solutions:
1.) Use VI Server available in LabVIEW 5.1 and Up to provide a communication
path between the two executables.
2.) Use a data file to transfer the data between the two executables.
3.) Use a TCP/IP connection there are several examples included with LabVIEW
showing the mechanics of this.

The simplest method is Number 1. Using the VI server, you open the
connection and then retrieve the data form the Global VI based on the
Parameter Name. It is very fast and requires very little processor
overhead. Make a driver to Open the connection then a Read to get the data.
Do not open and close the connection everytime, there is a lot of overhead
in the Open connection call.

Make sure you configure the VI Server within the development environmen
t.
Also you must include a few statements in the Executables INI file to
correctly enable the VI server capabilities.

Regards,

Jeff Meyer
Consultant
Focused Energy
Suffield, CT USA

"Alf Katz" wrote in message
news:3aaf4bd0@newsgroups.ni.com...
> Hi guys and gals,
> On the advice of a lv consultant, we've used an array of global
> variables to share data (about 100 variables) between an
acquisition/control
> program and a consumer program (datalogging) running on the same PC. This
> worked fine in the development environment. However it no longer works
when
> the two programs are compiled. Is there a trick to get this to work or do
> we have to use datasockets or DDE to move the data.
>
> In case you're wondering the idea of two separate programs is to
> separate the critical control and data acquisition functions from the less
> critical but more likely to error datalogging functions.
>
>
> --
> Regards,
> Alf Katz,
> alfkatz@removethis.ieee.
org
>
>
>

[Greg_McKaskle2]

> On the advice of a lv consultant, we've used an array of global
> variables to share data (about 100 variables) between an acquisition/control
> program and a consumer program (datalogging) running on the same PC. This
> worked fine in the development environment. However it no longer works when
> the two programs are compiled. Is there a trick to get this to work or do
> we have to use datasockets or DDE to move the data.
>
> In case you're wondering the idea of two separate programs is to
> separate the critical control and data acquisition functions from the less
> critical but more likely to error datalogging functions.
>

The global data works in the development system because everything
is running in the same process, the same address space. When
you
make executables, there are now two processes, two addres spaces,
and by default, each EXE has its own copy of the global.

You can have more than one top-level VI within an EXE, and they
will once again share the global, but you will have the possibility
of the VIs bringing each other down.

Another possibilty is to use TCP/IP. It may seem like major overkill,
but on the same machine, it tends to be implemented in shared memory
and be very fast. Also, this solution easily allows for the EXEs to
be further separated to different computers.

Greg McKaskle