Hello Karl!
> 1.) I need to send data at a 1khz rate from the server to the client,
> the
> customer needs to see in realtime,
Realtime is always a realtive thing. Anyway, 1 kHz is far above what your
display can do, the actual rate depends on how much processing you do. I
would consider to package the data together in time slices of about 50 to
100 ms. My example is thougt for a rate of 1-3 Hz only. I record some
data, and then send it by package (similarly as done in the example with
the random number simulation). That for, I do not mind the overhead
created with data request commands and acknowlegement.
If you do not want to make packages and really want your data exchange to
be fast, remove all the communication from the data channel connection
(third loop in TCPServer.vi) and just send your data. In the "ExecData"
you would than only one case, (Get New Data), you would not check for the
request, and just send data. This is also the place to check for queue
buffer overflow (see below).
Be aware that my implementation allows for the client not to respond, and
so I've put a time out in the TCP send function. Be sure to remove this
since you do not want your client to disconnect.
> He also prefers to
> record the data only on the client, with of course no data loss.
This is no problem in my implementation, there is no data loss. If needed,
just make the buffer bigger, and put a warning if something would go
wrong. Anyway, my solution is thought for allowing the client computer to
crash, to be rebooted by the operator and reconnect to the server, without
loosing data.
I have choosen to record data on the server since my acquisiton runs will
often be overnight, where the client computer is unattended or might be
switched of. But you can easily remove this from my example and only
record on the client. Of course, this should than not crash.
(Which might be a problem with Win95, less with WinNT, but I consider
switching to Linux on the Client machine).
> 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.
This is exactly what my program does. I've just not all implemented yet.
If you run into trouble because your disk on the client computer is two
slow, consider buffering using Queue-VIs the same way as I did on the
server side. Than, give low priority to the saving so it does not disturb
displaying.
> Have you tried 1khz or faster with your software?
As I said, my example is thougt for a lower rate. If you make the changes
I suggested above, you should easily get data transfer rates which lay far
above what your display can do. And this is the important point, if I
understand correctly.
> 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?
If I understand correctly, Datasockets provide functionality very close to
TCP. But, Datasockets only exist on the windows platform. Or, I want my
client to run on all platforms, Linux, Mac, ... Anyway, as much as
possible, I want to be independent of Windows, since I consider it as a
bad OS and think (and hope!) that it will not last for a long time
anymore.
For this reason, I excluded the Datasockets solution anyway.
Hope this helps. If my explanations are unclear, it might be since I'm
just back from holidays and not aware anymore of every detail of my
implementation. I also do not know how experienced you are with Labview
and what will be obvious to you and what not. But do not hesitate to
contact me again and ask more specific questions.
Greetings Gilbert
P.S.: I send a copy of this mail to the mailing list, since I think it
should not only contain questions, but also answers.
P.S.2: Another hint: please be aware that my example uses three distinct
concepts of Labview:
1. The Labview application acting as VI-Server: Used to run
the server-VI from the client computer
2. A custom made TCP Server/client, using the built in TCP
protocol: used for all communications once the VI are running.
3. The Queue-VI on the server side: used for data
communication internally in the Server VI between the two main loops
("Data acquisition" and "TCP server").
"Hanke, Karl G" wrote:
> 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
>
> > Karl G. Hanke
> > Boeing/Rocketdyne Propulsion & Power
> > Santa Susanna Field Laboratory (SSFL)
> > Data Systems/Software - D/343
> > Phone: (818) 586-4428
> > Fax: (818) 586-5753
> > E-mail: karl.g.hanke@boeing.com
> >
> >
