Communicating Between Built LV App.s

[nealpederson]

I have several built LabVIEW applications that I need to exchange data
between when they are running simultaneously on the same PC. Data Socket is
probably one of the best ways to accomplish this task but it requires some
extra installation and file handling that could complicate things for the
end user.

Does anyone have a better suggestion for communicating between built LabVIEW
App.s?

[Joe_Guo]

TCP/IP or UDP depends on your data.

Joe

[JDesRosier]

Dear Neal-

I think that you can implement queues to communicate between LabVIEW app's on the same computer. Queues are one of the newer LabVIEW features, and I feel that they will be much easier to use than a Data Socket.

LabVIEW includes several excellent queue operation examples, which can be accessed from a front panel by clicking [Help]>>[Find Examples] and searching for "queue."

Also, you can find more information in the online discussion forum. To access this database, goto www.ni.com, click [KnowledgeBase], click [Search all entries], and search for "queue."

One thing to note: If you're using multiple executables, the queues will not comminucate with each other properly. You must be working within the development environment if you want to
use queues to pass data between various VIs. See this link for more information regarding queue limitations with executables: http://digital.ni.com/public.nsf/3efedde4322fef19862567740067f3cc/ecf9af864fada3e286256d81005e59dc?OpenDocument


I hope this helps. Please feel free to contact me for further assistance. Have a great day!

Kind Regards,

Joe Des Rosier
National Instruments

[Wiebe@CARYA]

HI,

You could use the windows (MS only) way; by using memory mapped files...

Regards,

Wiebe.

"Neal" wrote in message news:403b6c93@newsgroups....
> I have several built LabVIEW applications that I need to exchange data
> between when they are running simultaneously on the same PC. Data Socket
is
> probably one of the best ways to accomplish this task but it requires some
> extra installation and file handling that could complicate things for the
> end user.
>
> Does anyone have a better suggestion for communicating between built
LabVIEW
> App.s?
>
>

[nealpederson]

Joe,

In your first paragraph you state "I think that you can implement queues to
communicate between LabVIEW app's on the same computer" but then in your
last paragraph you say "One thing to note: If you're using multiple
executables, the queues will not comminucate with each other properly."

As I stated, I do need to communicate between multiple LabVIEW built
applications (same as multiple executables). Can I do this or not using
queues???

"JDesRosier" wrote in message
news:506500000005000000E65F0100-1077587809000@exchange.ni.com...
> Dear Neal-
>
> I think that you can implement queues to communicate between LabVIEW
> app's on the same computer. Queues are one of the newer LabVIEW
> features, and I feel that they will be much easier t
o use than a Data
> Socket.
>
> LabVIEW includes several excellent queue operation examples, which can
> be accessed from a front panel by clicking [Help]>>[Find Examples] and
> searching for "queue."
>
> Also, you can find more information in the online discussion forum. To
> access this database, goto www.ni.com, click [KnowledgeBase], click
> [Search all entries], and search for "queue."
>
> One thing to note: If you're using multiple executables, the queues
> will not comminucate with each other properly. You must be working
> within the development environment if you want to use queues to pass
> data between various VIs. See this link for more information regarding
> queue limitations with executables:
>
http://digital.ni.com/public.nsf/3efedde4322fef19862567740067f3cc/ecf9af864fada3e286256d81005e59dc?OpenDocument
>
>
> I hope this helps. Please feel free to contact me for further
> assistance. Have a great day!
>
> Kind Regards,
>
> Joe Des Rosier
> National Instruments

[JDesRosier]

Neal,

I'm sorry for the misunderstanding. If you need to use executables, then queues are not the solution. Your best bet is to stick with data sockets.

According to the newest post, memory mapped files are a possibility, but I don't have any experience with this technique.

I'm sorry that queues won't work for this application. Please let me know if you need any assistance with the data socket programming (provided you go this route).

Kind Regards,

Joe Des Rosier
National Instruments

[Greg_McKaskle2]

> Does anyone have a better suggestion for communicating between built LabVIEW
> App.s?
>

This depends on the type of communication. Datasocket is quite easy and
appropriate for asynchronous data updates. You could use TCP, doing
your own flattening and unflattening. This will take less installation,
but will be more complicated in other ways.

Another choice is the VI Server. This is often the best choice when you
want to have synchronization or handshaking of some sort. This also
takes some installation, as the ini file needs to turn on the server and
designate what types of access will be accepted, but that is about it.

There was one comment about using queues. If you wrap them in VIs that
call through the VI Server, these will work
really well. This technique
means cloning the VI using Save a Copy. Open the copy and delete the
diagram, replacing it with a VI Server Call node. Then arrange for the
VI Ref to be read from a subVI call or add them to the connector pane.
Finally, you might want to make a small change to the icon so that you
can tell that they are remote.

After this, you can use these VIs locally and they will perform their
operation on the remote computer. In fact, you don't even need to build
the subVI wrappers, but it makes them much easier to use. If you wrap
the queue, then your local diagram looks pretty much like a local usage
of queues except for the initial connection to get the remote references.

If this didn't make sense, ask questions and I'll go into more detail.

Greg McKaskle

[Wiebe@CARYA]

Hi,

After doing some test with this method, I think it might be a good solution.
There are some disadvantages, but also some advantages.

Disadvantages:
Windows only.
One PC only.
Uses API's.
Low level (unless wrapped).
Memory errors when changing control type (during development).

Advantages:
Fast, little overhead.
Full control over synchronisation etc.
Can also be used from other languages.
All applications can read or write to the "global" at will.
Use as many applications as you like.

If you're interrested, let me know.

Regards,

Wiebe.

"Wiebe@CARYA" wrote in message
news:403f0d05@newsgroups....
> HI,
>
> You could use the windows (MS only) way; by using memory mapped files...
>
> Regards,
>
> Wiebe.
>
> "Neal"
@vicontrols.com> wrote in message news:403b6c93@newsgroups....
> > I have several built LabVIEW applications that I need to exchange data
> > between when they are running simultaneously on the same PC. Data
Socket
> is
> > probably one of the best ways to accomplish this task but it requires
some
> > extra installation and file handling that could complicate things for
the
> > end user.
> >
> > Does anyone have a better suggestion for communicating between built
> LabVIEW
> > App.s?
> >
> >
>
>

[nealpederson]

Since my communication is not critical and is asynchronous, I decided to go
with UDP communications and have it working just fine. I have one question
though: Will UDP or any of the other discussed application to application
communications work on a PC that does not have a network card installed?
This would not normally be the case but could be under some circumstances.
My guess is that File I/O and possibly VI Server would be the only ones that
would work without a network card installed.

"Greg McKaskle" wrote in message
news:Qd10c.13279$lS1.3844@fe2.texas.rr.com...
> > Does anyone have a better suggestion for communicating between built
LabVIEW
> > App.s?
> >
>
> This depends on the type of communication. Datasocket is quite easy and
> appropriate for asynchronous data updates. You could use TCP, doing
> your own flattening and unflattening. This will take less installation,
> but will be more complicated in other ways.
>
> Another choice is the VI Server. This is often the best choice when you
> want to have synchronization or handshaking of some sort. This also
> takes some installation, as the ini file needs to turn on the server and
> designate what types of access will be accepted, but that is about it.
>
> There was one comment about using queues. If you wrap them in VIs that
> call through the VI Server, these will work really well. This technique
> means cloning the VI using Save a Copy. Open the copy and delete the
> diagram, replacing it with a VI Server Call node. Then arrange for the
> VI Ref to be read from a subVI call or add them to the connector pane.
> Finally, you might want to make a small change to the icon so that you
> can tell that they are remote.
>
> After this, you can use these VIs locally and they will perform their
> operation on the remote computer. In fact, you don't even need to build
> the subVI wrappers, but it makes them much easier to use. If you wrap
> the queue, then your local diagram looks pretty much like a local usage
> of queues except for the initial connection to get the remote references.
>
> If this didn't make sense, ask questions and I'll go into more detail.
>
> Greg McKaskle
>

[nealpederson]

I'm now using UDP and it is working well. However, I am interested in the
memory mapped file method you mentioned because I may have problems with UDP
if there is no network card installed. Could you please send an example of
the method you mentioned?

"Wiebe@CARYA" wrote in message
news:40431acb@newsgroups....
> Hi,
>
> After doing some test with this method, I think it might be a good
solution.
> There are some disadvantages, but also some advantages.
>
> Disadvantages:
> Windows only.
> One PC only.
> Uses API's.
> Low level (unless wrapped).
> Memory errors when changing control type (during development).
>
> Advantages:
> Fast, little overhead.
> Full control over synchronisation etc.
> Can also be used fro
m other languages.
> All applications can read or write to the "global" at will.
> Use as many applications as you like.
>
> If you're interrested, let me know.
>
> Regards,
>
> Wiebe.
>
> "Wiebe@CARYA" wrote in message
> news:403f0d05@newsgroups....
> > HI,
> >
> > You could use the windows (MS only) way; by using memory mapped files...
> >
> > Regards,
> >
> > Wiebe.
> >
> > "Neal" wrote in message news:403b6c93@newsgroups....
> > > I have several built LabVIEW applications that I need to exchange data
> > > between when they are running simultaneously on the same PC. Data
> Socket
> > is
> > > probably one of the best ways to accomplish this task but it requires
> some
> > > extra installation and file handling that could complicate things for
> the
> > > end user.
> > >
> > > Does anyone have a better suggestion for communicating between built
> > LabVIEW
> > > App.s?
> > >
> > >
> >
> >
>
>