T7 streaming by modbus tcp (low level)

1. Since the Modbus header claims the packet length is 0x04 0A (1034), it seems like you need to read from the socket again, for the length of 1040 - 420 = 620. Have you tried that yet?

2. What platform are you seeing this error on? Can you replicate it on a non-embedded platform?

I haven't been able to reproduce this yet, but here's some suggestsions.

1. For my first suggestion, you can try reading from the socket again in a loop until you've read as many bytes as you expected. For example, you could change the part of spontaneousStreamRead that does readTCP:

    size = readTCP(sock, res, resSize);
    if(size <= 0)
    {
        ret = -1;
        goto end;
    }

...to contain a read loop like this:

    int readBytes = 0;
    while(resSize - readBytes > 0)
    {
        size = readTCP(sock, res + readBytes, resSize - readBytes);
        if(size <= 0)
        {
            ret = -1;
            goto end;
        }
        readBytes += size;
    }

You could change readTCP to do the loop instead.

TCP is a stream-based protocol instead of a message-based protocol, so even if the T7 sends a 1040 "packet", it can still arrive at the host in pieces. This could be due to the way a network switch deals with TCP, for example.

2. You can try reading only 420 bytes every time instead of the full 1040 bytes. To do so change:

samplesPerPacket = STREAM_MAX_SAMPLES_PER_PACKET_TCP;

...to:

samplesPerPacket = 202;

and see if that works for the 420 packet size.

3. Please ensure your T7 is using the most recent firmware. You can use Kipling to do so.

What does errno indicate? (Run man recv to see more details.)

From https://www.systutorials.com/docs/linux/man/2-recv/ , EAGAIN indicates:

a receive timeout had been set and the timeout expired before data was received.

So you can either retry or set the timeout value to be larger.

Edit: fixed link.

To prevent stream buffer overflows which causes auto-recovery and the dummy samples, the application needs to read data from the T7 at a fast enough rate to keep up with the scan rate. The stream read loop in your case needs to keep up with the 8000 Hz scan rate. If your stream read loop has code with enough overhead to prevent it from keeping up with the stream read loop, remove code (such as sleep) causing the delay, or consider using a thread dedicated to streaming only and another thread for stream data processing (logging to file, charting, etc.).

In the Modbus Feedback stream response, bytes 10-11 are the Backlog bytes indicating how many bytes are in the device stream buffer. If this is constantly increasing, that will indicate the stream data is not being read fast enough and a buffer overflow will eventually occur.

A couple of questions:

1. If you time your stream read call or recv, does it sometimes take longer than one second? Where does the delay come from? You can add timing calls to specific spots in your loop. E.g. read the clock once per loop and calculate how long the whole loop took; then add other clock reads to see how long specific function calls took.
2. How is your program sleeping? Is it interval-based (does it account for how long reading from stream took) or delay-based (does it always sleep a set length of time)? See my note on interval timing below.
3. What is happening to the device scan backlog?
4. Can you read smaller amounts of data more often? Since 8000 samples per second / 512 samples per packet = 15.625 packets per second, you should be able to read 512 samples 15.625 times per second (as opposed to 8000 samples once per second)

Interval timing note:

An interval timing system tries to execute a task once per a given time period, regardless of how long the task takes to complete. As described on the LJM_StartInterval page:

In many applications an interval timer is preferable to using a normal delay (sleep), as it is difficult to get an exact interval using a delay.  For example, say a loop makes an I/O call that takes 5 to 15 milliseconds (ms) each time, and this is followed by a 90 ms delay.  The loop will take 95 to 105 ms per iteration, and the average time per iteration over time could be anywhere in that range.  Using interval timers avoids this problem because the loop will always take the specified number of milliseconds (or else LJM_WaitForNextInterval will notify you of skipped intervals).

Assuming you have an interval timer, the task may take longer than the interval length. For your case, that means that perhaps the stream read call may be taking 2 seconds. One reason reading from stream could take a larger-than-normal amount of time is because of real-world network latency.