Hello StevenK,
So the documenation for the TCP Read function mentions:
mode indicates the behavior of the read operation.
| 0 |
Standard (default)—Waits until all bytes you
specify in bytes to read arrive or until timeout
ms runs out. Returns the number of bytes read so far. If fewer bytes
than the number of bytes you requested arrive, returns the partial number of
bytes and reports a timeout error. |
| 1 |
Buffered—Waits until all bytes you specify
in bytes to read arrive or until timeout ms
runs out. If fewer bytes than the number you requested arrive, returns no bytes
and reports a timeout error. |
| 2 |
CRLF—Waits until the function receives a CR
(carriage return) followed by a LF (linefeed) within the number of bytes you
specify in bytes to read or until timeout ms
runs out. Returns the bytes up to and including the CR and LF. If the function
does not find a CR and LF, returns no bytes and reports a timeout
error. |
| 3 |
Immediate—Waits until the function receives
any bytes. Waits the full timeout only if the function receives no bytes.
Returns the number of bytes so far. Reports a timeout error if the function
receives no bytes. |
In particular, I believe the reason why are you seeing a timeout error
(error 56) when you use the Standard mode is because you want to read
back 3000 bytes, but 3000 bytes are not available so the VI eventually
times out. On the other hand, when you use the Immediate mode,
you are returned when any bytes are received. Since these bytes
may not be the full message, when you convert them to a string, it
could end up being unreadable.
How many bytes are you expected back from your instrument? I
would suggest architecting your program around the suggestions listed
in the help documentation for the TCP Read function. In
particular,
bytes to read is the number of bytes to read. Use one of the
following techniques to handle messages that might vary in size:
- Send messages that are preceded by a fixed size header that describes the
message. For example, it might contain a command integer that identifies what
kind of message follows and a length integer that identifies how much more data
is in the message. Both the server and client receive messages by issuing a read
function of eight bytes (assuming each is a four byte integer), converting them
into the two integers, and using the length integer to determine the number of
bytes to pass to a second read function for the remainder of the message. Once
this second read is complete, each side loops back to the read function of the
eight byte header. This technique is the most flexible, but it requires two
reads to receive each message. In practice, the second read usually completes
immediately if the message is written with a single write function.
- Make each message a fixed size. When the content of a message is smaller
than the fixed size you specify, pad the message to the fixed size. This
technique is marginally more efficient because only a single read is required to
receive a message at the expense of sending unnecessary data sometimes.
- Send messages that are strictly ASCII in content, where each message is
terminated by a carriage return and linefeed pair of characters. The read
function has a mode input that, when passed CRLF, causes it to read until seeing
a carriage return and linefeed sequence. This technique becomes more complicated
when message data can possibly contain CRLF sequences, but it is quite common
among many internet protocols, including POP3, FTP, and HTTP.
Also, you might want to take a look at the shipping examples as well:
- labview\examples\comm\TCP.llb\TCP Communicator -
Active.vi
- labview\examples\comm\TCP.llb\TCP Communicator -
Passive.vi
- labview\examples\comm\TCP.llb\Simple Data
Client.vi
Hope that helps.
Wendy L
LabWindows/CVI Developer Newsletter
