TCP Read unknown amount of bytes

[1984]

Hi,

I need to communicate with an instrument thru TCP (or VISA I dont think that matters too much). The problem is a classic: I send a command but I dont know how long is the returning message. The instrument doesnt prepend its response with the length of the message. So the question is how can I read the entire message?

Would be nice to have a bytes at port property node like on serial but it doesnt work. VISA events ("wait for term char") doesnt work. The TCP read has a CRLF option, but the termchar is \n only so it doesnt work. 

I could read the TCP port byte-by-byte until I get the termchar but that looks quite an ugly way to get the message.

The TCP Immediate mode seems to work fine. I assume, that messages on the TCP port dont appear byte-by-byte but instead the message appears at once, so its not possible that I only get the part of the message (assuming that its not broken up to different packages, but as the messages are relatively short I dont think it would be a problem.)

Is there any better solution to this problem?

[jjohn1]

I ran in to a similar problem recently with the fixed termination character sequence.  My device had them reversed!

I used VISA TCP, which allows a term character to be specified.  It always returns a warning "termination character found" or some such, which I discard.

When I used the TCPIP::ip address::port::SOCKET form of the VISA resource this worked.

[Bob_Schor]

---

@jjohn1 wrote:

I ran in to a similar problem recently with the fixed termination character sequence.  My device had them reversed!

I used VISA TCP, which allows a term character to be specified.  It always returns a warning "termination character found" or some such, which I discard.

When I used the TCPIP::ip address::port::SOCKET form of the VISA resource this worked.

---

Now that you mention this, we had a bunch of Mettler balances that spoke TCP, but we configured them to look like VISA devices, and did the usual "Read 1000 bytes" with the termination character set (I don't recall if we used the default CR-LF, but with VISA, you can change this).  Seeing the name of the VISA resource above triggered my memory (it's been 5-6 years since I last looked at that Project) ...

Bob Schor

[crossrulz]

---

@1984 wrote:

The TCP read has a CRLF option, but the termchar is \n only so it doesnt work.

---

Use VISA and set the termination character to a line feed (\n, 0xA).  You will also need to set the End On Read to Termination Character.  Use a property node to set these properties.

[crossrulz]

---

@jjohn1 wrote:

I used VISA TCP, which allows a term character to be specified.  It always returns a warning "termination character found" or some such, which I discard.

---

I've never seen a warning for a termination character being found.  I have seen warnings for "the number of bytes read matched the number of bytes requested, so there may be more data in the buffer".  In this case, you typically just need to increase the number of bytes to read.

[1984]

Based on the info above (~kinda) I made this VI which seems working fine, it doesnt timeout at the visa read:

I couldn't find the "End On Read to Termination Character" in the property node though, not sure if its the Send End En.

Could you check?

[Bob_Schor · Accepted solution]

I went back and found the VIs that I used to open a TCP/IP "VISA" connection to a Mettler Balance.  There are 24 of them, and they each had a number that was used to open the specific Balance.

This is "Get Balance IP" that chooses creates the IP for the two (I don't remember what these things are called,but they allow you to create the IP string for the 24 Balances we were using). 

This is the (clone) routine that opens the Balance and configures it for VISA.  The Station ID (from 1 to 24) uses the "Get Balance IP" (shown above) and uses it to open a VISA connection to the Balance.  We (of course) use the TCPIP option to set up the Instrument for enabling Termination and Send End character, and set it to Line Feed, 0x0A.  Note the order of the Properties in the list -- in general, order can be important!  Also note that I wired in a 50 msec "wait" to allow TCP/IP to settle down before I try to do Serial I/O using VISA over TCP/IP.

Hope this helps.

Bob Schor 

[1984]

Thanks everyone for the useful tips, this problem is solved now.