Data-Communication between hosts: "Queues" v. "VI-Server"

[Gilbert Hangartner]

Data-Communication between hosts: "Synchronization->Queues-vi" versus
"VI-Server"
***************************************************************************

My dataacquisition system is composed by two computers:
A: The "Acquisition"-computer, doing the time-critical dataacquisiton.
U: The "User-interface"-computer, doing post-processing and display of
data.
Computer A will send data every second or so to the computer U via
Ethernet. I can not allow for missing data.
If this system would be on one computer, I would think the
straigth-forward solution of this problem is using Synchronization vi's,
especially the "Queues": Process A will send the data to the queue,
process U will read the queue a
nd process data.
Questions:
*********
1) Why is this solution not possible between two computers.
2) What would be a good alternative solution? When using the VI-Server,
I see the problem of possible data loss (which I cannot allow for).
3) Are there any plans from NI to support QUEUES between remote/host
computers? (NI support please comment on this!). In this case, I would
implement the system on one computer for the time being, and break into
two when LABVIEW is ready for it without having to re-write my
application ...

Thanks for any hints.

Greetings, Gilbert

****************************
Gilbert.mail@gmx.net
Institute for physical chemistry
University of Fribourg
Switzerland
****************************

[bubucis]

Instead of queue you could use file. There are some examples on NI website
on how to use semaphores over the network, some of those techniques could
also be applied to your problem.
Or you could use temporary array, which would be read (using VI server) when
your daq computer gives a signal to your dsp computer. If dsp computer does
not respond within timeout, then set a flag and during next daq append to
the array instead of overwriting, or something along those lines.


"Gilbert Hangartner" wrote in message
news:38E9F638.51511A4F@gmx.net...
> Data-Communication between hosts: "Synchronization->Queues-vi" versus
> "VI-Server"
>
***************************************************************************
>
> My dataacquisition system is composed by two computers:
> A: The "Acquisition"-computer, doing the time-critical dataacquisiton.
> U: The "User-interface"-computer, doing post-processing and display of
> data.
> Computer A will send data every second or so to the computer U via
> Ethernet. I can not allow for missing data.
> If this system would be on one computer, I would think the
> straigth-forward solution of this problem is using Synchronization vi's,
> especially the "Queues": Process A will send the data to the queue,
> process U will read the queue and process data.
> Questions:
> *********
> 1) Why is this solution not possible between two computers.
> 2) What would be a good alternative solution? When using the VI-Server,
> I see the problem of possible data loss (which I cannot allow for).
> 3) Are there any plans from NI to support QUEUES between remote/host
> computers? (NI support please comment on this!). In this case, I would
> implement the system on one computer for the time being, and break into
> two when LABVIEW is ready for it without having to re-write my
> application ...
>
> Thanks for any hints.
>
> Greetings, Gilbert
>
> ****************************
> Gilbert.mail@gmx.net
> Institute for physical chemistry
> University of Fribourg
> Switzerland
> ****************************
>




-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 80,000 Newsgroups - 16 Different Servers! =-----

[Greg_McKaskle2]

> My dataacquisition system is composed by two computers:
> A: The "Acquisition"-computer, doing the time-critical dataacquisiton.
> U: The "User-interface"-computer, doing post-processing and display of
> data.
> Computer A will send data every second or so to the computer U via
> Ethernet. I can not allow for missing data.
> If this system would be on one computer, I would think the
> straigth-forward solution of this problem is using Synchronization vi's,
> especially the "Queues": Process A will send the data to the queue,
> process U will read the queue and process data.
> Questions:
> *********
> 1) Why is this solution not possible between two computers.
> 2) What would be a good alternative solution? When using the VI-Server,
> I see the problem of possible data loss (which I cannot allow for).
> 3) Are there any plans from NI to support QUEUES between remote/host
> computers? (NI support please comment on this!). In this case, I would
> implement the system on one computer for the time being, and break into
> two when LABVIEW is ready for it without having to re-write my
> application ...
>

Several questions here. The queue implementation in LV is based on
shared memory for use within a single process. It could be extended
to work over two computers, but that would be a different implementation,
and wouldn't be nearly as useful on a single computer, and thus to the
majority of users.

If you are looking to implement this, you probably want to look at some
of the TCP/IP examples. They tend to be a similar Producer/Consumer
type of setup, and since TCP guarantees data arrival and packet order,
you have a nice foundation to build upon. You need to decide on the
information to transmit, the packet format, and then fit that into the
common client/server format. Each of the computers would then talk to
a queue VI. A parallel loop on each computer can transmit/receive the
queue elements to the other computer as they become available, and post
them on the other computer's queue implementation. Having this built-in
would indeed be a useful thing, and I know that you aren't the first to
need it; so maybe someone will share their code with you, but if not,
you can build it rather easily.

Greg McKaskle

[Gilbert Hangartner]

Thanks to all to answers. Looking at all the suggestions, I seems to me that
the following approach is the most stable, extensible and portable solution
(closely following Greg's suggestion):

* Using VI-Server to lauch Server-VI (Acquisition) from the Client-VI
(Display).
* Using TCP-client-server model to interact between Display and Acquisition.

I created three communications channels, each using a specific TCP-port:
1. Command channel: commands from the client to the server, acknowledgement
from server to the client. No data loss permitted.
2. Status channel: The client can check the current status of the server at
any time (no queue, we just need the most recent state).
3. Data channel: The client requests data, and waits for it if no new data
avaible. The server has two parallel main loops: An acquisition loop which
does actually the acquisition and sends the data in a queue, and the TCP
server loop which takes one data element of the queue and sends it to the
client on every request. Additionally, I allowed the client to reconnect to
the server when the connection is dropped (e.g. when the client computer has
crashed, or was switched of during night, or ...).

All in all, the code got a bit larger than expected, but I can't see how I
could really make things easier ... or do I oversee anything obvious???

This implementation should just be considered as a test model to see if and
how this works. There are a lot of details left to improve, especially error
handling, initialization and time-outs. Anyway, I would be very glad to have
comments and suggestions from you! And if this code might serve as a starting
point to someone, great. Contact me, so we can share experience ...

Greetings Gilbert

Since the VI files are getting rather big, I put them to ftp:

Mac-Archive: ftp://pchsg00.unifr.ch/pub/labview/TCPhostclient.llb.sit
(212 kB)
Windows-Archive: ftp://pchsg00.unifr.ch/pub/labview/TCPhostclient.zip (248
kB)


Stupid question: How to close a vi using the VI-Server??? I really can't
figure it out ... documentation on all that definitively needs some work ...

[kghanke@my-deja.com]

Gilbert,

Thanks for your help concerning TCP/IP usage.
I have looked at your software (TCPhostclient)
and have a question for you:
1.) I need to send data at a 1khz rate from the server to the client,
the customer needs to see in realtime, two (pressure xducers) of the
ten channels on graphs, which are viewed on the client. He also
prefers to record the data only on the client, with of course no data
loss.
So, the server is acquiring at 1khz rate, with the client getting &
displaying the data (two channels) as close to that as possible.
Hence, the server acquire rate should control the client display rate,
not neccessarily the record rate. But really all control (but the
acquire rate)lies with the client. Have you tried 1khz or faster with
your software?
I was told yesterday that the "sync Datasocket vi's" will do everything
concerning the data speed, and integrity; but not the opening & closing
of the server vi. What have you heard about these vi's?

Thanks for your reponse!

Note: I'am on two WINNT 4.0, PC's, with service pack 5, connected by a
100MBbaseT LAN. One of the PC's (server) is actually a CompactPCI/PXI,
8156B Controller, 233MHZ, with 160MB.

Thanks again!
-Karl



In article <38F66C61.F66E4258@gmx.net>,
Gilbert Hangartner wrote:
> Thanks to all to answers. Looking at all the suggestions, I seems to
me that
> the following approach is the most stable, extensible and portable
solution
> (closely following Greg's suggestion):
>
> * Using VI-Server to lauch Server-VI (Acquisition) from the Client-VI
> (Display).
> * Using TCP-client-server model to interact between Display and
Acquisition.
>
> I created three communications channels, each using a specific TCP-
port:
> 1. Command channel: commands from the client to the server,
acknowledgement
> from server to the client. No data loss permitted.
> 2. Status channel: The client can check the current status of the
server at
> any time (no queue, we just need the most recent state).
> 3. Data channel: The client requests data, and waits for it if no new
data
> avaible. The server has two parallel main loops: An acquisition loop
which
> does actually the acquisition and sends the data in a queue, and the
TCP
> server loop which takes one data element of the queue and sends it to
the
> client on every request. Additionally, I allowed the client to
reconnect to
> the server when the connection is dropped (e.g. when the client
computer has
> crashed, or was switched of during night, or ...).
>
> All in all, the code got a bit larger than expected, but I can't see
how I
> could really make things easier ... or do I oversee anything
obvious???
>
> This implementation should just be considered as a test model to see
if and
> how this works. There are a lot of details left to improve,
especially error
> handling, initialization and time-outs. Anyway, I would be very glad
to have
> comments and suggestions from you! And if this code might serve as a
starting
> point to someone, great. Contact me, so we can share experience ...
>
> Greetings Gilbert
>
> Since the VI files are getting rather big, I put them to ftp:
>
> Mac-Archive:
ftp://pchsg00.unifr.ch/pub/labview/TCPhostclient.llb.sit
> (212 kB)
> Windows-Archive:
ftp://pchsg00.unifr.ch/pub/labview/TCPhostclient.zip (248
> kB)
>
> Stupid question: How to close a vi using the VI-Server??? I really
can't
> figure it out ... documentation on all that definitively needs some
work ...
>
>


Sent via Deja.com http://www.deja.com/
Before you buy.

[Gilbert Hangartner]

Hi Mark!

Thanks for the idea!!! I thought of using DataSockets, too. But:

>>> DataSockets are restricted to Windows (please correct me if I'm wrong). So
it is no good. A major reason for using LabView is to have portable,
OS-independent software. I think (and hope!) Windows will not exist for ever,
and I want to be able to move smoothly to another platform. Also, the
Display-Computer might as well be a Linux station or a Macinthosh (where the
data acquisition computer will be Windows for the time being, due to ISA slots
and missing drivers for Linux).
Maybe I'm a bit purist, but I think not that LabView should stick users to the
windows platform. They will do harm to users, and at the long run to
themselfs.

Greetings, Gilbert

"Mark A. Hanning-Lee" wrote:

> Gilbert Hangartner wrote:
> >
> > Data-Communication between hosts: "Synchronization->Queues-vi" versus
> > "VI-Server"
> >
> ***************************************************************************
> >
> > My dataacquisition system is composed by two computers:
> > A: The "Acquisition"-computer, doing the time-critical dataacquisiton.
> > U: The "User-interface"-computer, doing post-processing and display of
> > data.
> > Computer A will send data every second or so to the computer U via
> > Ethernet. I can not allow for missing data.
> > If this system would be on one computer, I would think the
> > straigth-forward solution of this problem is using Synchronization vi's,
> > especially the "Queues": Process A will send the data to the queue,
> > process U will read the queue and process data.
> > Questions:
> > *********
> > 1) Why is this solution not possible between two computers.
> > 2) What would be a good alternative solution? When using the VI-Server,
> > I see the problem of possible data loss (which I cannot allow for).
>
> Use DataSockets. While running on one PC use the name localhost or the
> address 127.0.0.1 . Ask your NI rep for details & a demo.
>
> I've seen good demos of this setup, one PC broadcasting data to many
> others.
>
> Best, Mark

[Gilbert Hangartner]

Gilbert Hangartner wrote:
>
> Hi Mark!
>
> Thanks for the idea!!! I thought of using DataSockets, too. But:
>
> >>> DataSockets are restricted to Windows (please correct me if I'm wrong).

They might be available elsewhere. If not, I think the specs are
available for Unix.

> So
> it is no good. A major reason for using LabView is to have portable,
> OS-independent software. I think (and hope!) Windows will not exist for ever,
> and I want to be able to move smoothly to another platform. Also, the
> Display-Computer might as well be a Linux station or a Macinthosh (where the
> data acquisition computer will be Windows for the time being, due to ISA slots
> and missing drivers for Linux).

Might be, but not many companies will happily support 3 technical
staffs: 1 for Windows 1 for Mac 1 for Unix/Linux.

> Maybe I'm a bit purist, but I think not that LabView should stick users to the
> windows platform. They will do harm to users, and at the long run to
> themselfs.

Windows has developed some very powerful tools like ActiveX which I
don't think are available for other platforms.

They try to keep it platform-independent, but remember: in '99 I think
that 96% of their sales were on the Windows platform. Coprorate suvrival
depends on supporting Windows well.

Anyway good luck with your problem, Mark



Gilbert Hangartner wrote:

> Hi Mark!
>
> Thanks for the idea!!! I thought of using DataSockets, too. But:
>
> >>> DataSockets are restricted to Windows (please correct me if I'm wrong). So
> it is no good. A major reason for using LabView is to have portable,
> OS-independent software. I think (and hope!) Windows will not exist for ever,
> and I want to be able to move smoothly to another platform. Also, the
> Display-Computer might as well be a Linux station or a Macinthosh (where the
> data acquisition computer will be Windows for the time being, due to ISA slots
> and missing drivers for Linux).
> Maybe I'm a bit purist, but I think not that LabView should stick users to the
> windows platform. They will do harm to users, and at the long run to
> themselfs.
>
> Greetings, Gilbert
>
> "Mark A. Hanning-Lee" wrote:
>
> > Gilbert Hangartner wrote:
> > >
> > > Data-Communication between hosts: "Synchronization->Queues-vi" versus
> > > "VI-Server"
> > >
> > ***************************************************************************
> > >
> > > My dataacquisition system is composed by two computers:
> > > A: The "Acquisition"-computer, doing the time-critical dataacquisiton.
> > > U: The "User-interface"-computer, doing post-processing and display of
> > > data.
> > > Computer A will send data every second or so to the computer U via
> > > Ethernet. I can not allow for missing data.
> > > If this system would be on one computer, I would think the
> > > straigth-forward solution of this problem is using Synchronization vi's,
> > > especially the "Queues": Process A will send the data to the queue,
> > > process U will read the queue and process data.
> > > Questions:
> > > *********
> > > 1) Why is this solution not possible between two computers.
> > > 2) What would be a good alternative solution? When using the VI-Server,
> > > I see the problem of possible data loss (which I cannot allow for).
> >
> > Use DataSockets. While running on one PC use the name localhost or the
> > address 127.0.0.1 . Ask your NI rep for details & a demo.
> >
> > I've seen good demos of this setup, one PC broadcasting data to many
> > others.
> >
> > Best, Mark

[Curry]

Hi!

Are these files still available for download?!!!!

Best regards,
Mats