TCP Read Too Slow in LabVIEW

[Ouinon]

Hi everyone,

I'm working on a project where I transfer data via TCP between a C-based client (using an MCC 128 DAQ) and a LabVIEW server.

The client continuously acquires analog data from 3 channels at 10 kHz each (totaling 30,000 samples/sec).
It collects 1000 samples per channel (3000 total samples) and sends them as text lines like: "1.234, 2.345, 3.456\n"

The issue is that LabVIEW reads the incoming TCP messages too slowly. As a result, I'm unable to properly reconstruct the signal on the server side.

On the client side, I'm currently using a separate send() call for each line, which might be inefficient.
Here’s what I’d like advice on:

1. How can I optimize TCP reading in LabVIEW to handle this data rate reliably?

2. Would buffering multiple lines into a single send() improve performance, and is that approach recommended?

3. Would switching to binary transmission instead of text help significantly?

Thanks a lot in advance for your help!

[PinguX]

Hello Ouinon,

My first thoughts are :

- Separate TCP Read from others actions (display, writing to a file) in multiple While Loops

- Read multiple lines at once, instead of one at a time

[GerdW]

Hi Quinon,

---

@Ouinon wrote:

1. …

2. Would buffering multiple lines into a single send() improve performance, and is that approach recommended?

3. Would switching to binary transmission instead of text help significantly?

---

2. Yes, sure. It always makes sense to collect data to send larger messages with TCP instead of sending a lot of small messages! (TCP needs some overhead for each message!)

3. Sure it could help. Instead of 7 bytes per value ("1.234, " are 7 chars including the space/tab/linefeed at the end) you probably only need 2 bytes (from a 16/12bit ADC) per value. Then add some little overhead to allow easier parsing of your messages…

[cordm]

How do you know that the LabVIEW side is too slow? Is the file you create on the sending side free of gaps?

For testing, I created a fast sender and slow reader on a local TCP connection. The sender ran into a timeout after a short while. Do you get an error on the sending side?

To your third point: you could send data_buffer directly, but you would have to ensure a fixed number of elements to send or transmit the number of samples in an extra call to send.

[Yamaeda]

You've set the read to \r\n as end of message, but only send \n. That is definately an issue.

[Ouinon]

Hi Cordm,

I’m not getting any specific error.

On the client side, messages are sent correctly, and on the server side, I haven’t set any timeout on the TCP functions.

Here’s an example of how it works:
My client measures a 100 Hz sine wave with a 1 V amplitude.
The server receives the data and tries to reconstruct the signal.
The amplitude looks fine, but the frequency is completely off — instead of 100 Hz, I’m seeing something closer to less than 1 Hz.

Another strange thing: when I stop the client, the LabVIEW server keeps displaying data, which makes me think that LabVIEW is too slow to process the incoming data in real-time.
It probably builds up a delay that ends up distorting the signal, especially the frequency ?

Also, I know I'm always sending a buffer of 1000 lines, each containing 3 values. Here's the code:

if (samples_read_per_channel == SAMPLES_PER_CHANNEL) {
    if (send(sock, data_buffer, sizeof(data_buffer), 0) == -1) {
        perror("Send data failed");
        break;
    }
}

[Jay14159265]

some tips for "high speed" data acquisition: 

1) your sample clock is your time reference, you must know its frequency. 

2) data buffers are your friend, know them, use them

3) for data tx/rx over tcp/ip you need to know how tcp/ip works and how to maximize bandwidth, At a high level think about your data to overhead ratio for each packet. 

4) you have to track your samples, use a sample counter so that each end of the server client system is aware of the position of each sample, if you drop a packet (or a sample), you will want to know that. 

5) if you are going to decimate data, do it before you send the data : ) 

[Yamaeda]

Try to avoid Express nodes. Try this change and see if it helps some. If this isn't enough, move the file write to a separate loop and send the data via a queue.

Something like this:

[Ouinon]

Yamaeda, I'm not sure I fully understand what you've done...

Are you taking all the values that I'm plotting and writing them to a binary file?
Is the goal to check in the binary file whether I have all the data I need to reconstruct my signal?
Or is it for a different purpose?

[cordm]

That is not the same code as in the first message. Regarding Yamaeda's message, he replaced the express VI that you used to log data to an excel file which is extremely slow. Did you attach the right code?