How fast can a TCP read happen ?

[MogaRaghu]

LV 2009 + WIN-7 with 6GB Ram.

I am acquiring two analog channels as a 16 bit word each and appending a CRLF at the end. Sample : 1234 567 \r\n

This data is acquired at 50ms intervals and sent through a WiFi link to my note book running LV code.

I am not sure how fast the "TCP - Read"  function can run and which mode ( it has four options ) to choose if I were not to miss any of the incoming data..

Right now I do get some data in - intially quite fast and after some seconds it slows down consdierably . I am running the TCP-Read inside a timed loop and I have tried various intervals starting from 10ms to 500ms. The larger value works OK but I need the fastest possible. Any tips how to handle  this ??

My code is attached. ( The DIO portion is working fine )

[nathand · Accepted solution]

Even though the DIO portion is working, it doesn't make any sense to use a sequence structure.  It would be better to change the mode to Standard and set the Timeout to 100ms instead of "Wait for Next Millisecond Multiple" since that will lead to uneven wait times.

TCP Read should run very quickly, subject to whatever timeout you set.  You should never lose data in any mode, although there's a possibility of receiving a partial when you use Standard or Immediate mode (unlikely in your case since you're reading so little data).  The operating system will buffer unread data for you.  If you want the fastest possible data exchange, split your code into two while loops, one for the DIO and the other for serial.  The serial communication can simply be a normal while loop, with the TCP Read dictating timing.  Set a fairly long timeout in buffered mode and your loop will run as fast as it receives data.

Also, when the loop ends you should close both TCP connections, not just one of them.

[MogaRaghu]

Problem solved after the code was redone as adivsed. Now I can read both the analog channel data at 10ms interval with no missing bytes. The loop for   the DIO still needed a 5ms delay to keep the CPU resources under 5% .

Thanks.

[Been bitten by LabVIEW]

I've never understood this need for polling.  Perhaps it is because it is easier?  The TCP system in other languages can be set so that it can report when data is available.  I know that in LV 7.0 it is a pain that you can't register a TCP for an event.  Has this not been fixed in LV 8+?

I actually wrote a TCP event driver for LV7.0.  No processing/looping is done unless there is actual data to process.  Very clean asynchronous coding.  It was done by having a reader thread that waited indefinitely (-1 timeout) and when it got something, it would execute a callback, that callback could execute some code and/or fire an event.  Unfortunately, the data stream is proprietary, so it wouldn't work with a simple stream due to the data stream expected, but it should be possible to make something similar.

For a one shot deal, the callback is not necessary, just execute the code you want or fire an event.  In the reader loop, just keep an eye on the error out.  By closing the connection (either within LV or the connection dropping), the reader will stop waiting and the error out will show a dropped connection which you can use to stop the reader vi loop.

A

[Been bitten by LabVIEW]

Attached is an example of what I am talking about.

Note that I used a stop button to kill the TCP connection.  This will then stop the TCP event loop.  You can kill the TCP connection anyway you wish.

Hope this helps.

A