TCP/IP: Read and Write U32. Sample rate up to 150 Khz.

[A.E.M]

Thanks for the tip - works very well 🙂

The example is now working (code is attached)

Do you have any comments / recommendations? What should my delay times, time-out times, etc. be? Any rules of thumb?

[nathand]

There's no need for the for loop on the sending side, either.

You should pick a timeout appropriate for your situation. If you expect data every n seconds, I would set the read timeout just slightly longer than that, and flag an error (maybe attempt to reconnect) if you see a timeout. There's no need to set a timeout value on the TCP Write. I would use a fairly short timeout on the TCP Open, unless your connection is really slow.

For occasional TCP communication (not at regular intervals) a timeout of -1 (forever) is useful; you can stop the read by closing the TCP connection elsewhere in your code. For a server that's checking for data from multiple connections, a short timeout is reasonable, with the expectation that most reads will time out.

[A.E.M]

Thanks.

With for-loop:

Without for-loop:

Huge improvement  (and YES, the code is running)

Regarding the timing:

Should the server and client loop run at the same rates? Or should the client run faster, because (in my case) it reads the data, and thus needs to run a little faster to be on the safe side?

[nathand]

On the client side I'd remove the Wait entirely, and let the rate of incoming data determine how fast the loop runs. That way you're not at risk of falling behind. As you're aware, any loop that runs continuously in LabVIEW should contain a timing mechanism, but it doesn't have to be a wait function - a timeout on a TCP Read, Dequeue, Wait on Notifier, etc. are all fine too. It's usually a good idea to have only one function in a loop dictate the loop rate to avoid confusion about what actually determines the loop rate.

[Sam_Sharp]

---

@nathand wrote:

On the client side I'd remove the Wait entirely, and let the rate of incoming data determine how fast the loop runs. That way you're not at risk of falling behind. As you're aware, any loop that runs continuously in LabVIEW should contain a timing mechanism, but it doesn't have to be a wait function - a timeout on a TCP Read, Dequeue, Wait on Notifier, etc. are all fine too. It's usually a good idea to have only one function in a loop dictate the loop rate to avoid confusion about what actually determines the loop rate.

---

One caveat with this is that if there is an error out of the TCP Read other than the timeout error, you should add a wait in a case structure or handle the errors correctly so your loop doesn't spin as fast as your CPU allows. If you just have a loop that does a read and a non-timeout error occurs, it won't wait for the timeout.

[A.E.M]

Hi again.

I have a follow-up question for you guys 🙂

A normal dataflow is as follows (like the build-in LabVIEW TCP example).

* Server: Send header with data lengt, Send data.

* Client: Read header with data lengt, Read data based on data length.

I understand this flow. However, say the server is sending a lot of data, but the client is not reading. The connection IS established, but the client simply doesn't read the data.

Then after many hours, the client decide to start reading data. How do I know, that the first data the client will read is the header, not not at some random point in the data stream? If the first reading, isn't the header, then things will go wrong 🙂

[nathand]

If the client's incoming buffer overflows, you'll get an error when you attempt to read from it. It's also possible the connection will disconnect, in which case the server will get an error when it tries to send more data.

[Sam_Sharp]

If the client is connected, but not reading, eventually you will get a full send buffer on the server. If the client isn't connected then you will get a not-connected error on the server. The server always knows if the client didn't get the data with TCP. You can use this knowledge to do some sort of handshaking when you re-establish the connection.

[A.E.M]

Thanks for your quick replies 🙂