Advice for TCP Wait for Asyncronous Messages with non-standard Term Chars

[7Ronin]

Hello All,

I have a PITA instrument I need to communicate with as part of a larger control system.  This instrument communicates via RS232 to an OEM server application  running on the PC.  In order to communicate with the instrument I have to use TCP to a specific port on the Localhost-  So far so good as long as the protcol is command-response.

 The issue is that the instrument sends several asyncronous messages of varying sizes with a double linefeed as a termination char (there are many CR/LFs througout these messages so they can't be a EOM) and I am struggling to find a way to handle recieving asynchronous messages of varying length with a cusom term char. without simply having a dedicated loop for rapid TCP Reads trying to catch these asynch status messages. 

I wish the VISA TCP functions worked with the localhost as there are properties that can be set to change the term char non-standard.

Open to any and all suggestions-

Thanks,

Ronin

[MichaelBalzer]

---

@7Ronin wrote:

...without simply having a dedicated loop for rapid TCP Reads trying to catch these asynch status messages. 

---

 Is there a problem with this approach though? If you read a byte at a time from the TCP port into your own buffer, then perform a check on that buffer for a double line feed, then that should do the trick.

Also is there any reason you're using VISA to do TCP rather than the TCP pallette?

[Sam_Sharp · Accepted solution]

Yes, I would be reading continuously into my own string buffer and then picking the messages out of the buffer once you find the termination character.

One technique to improve performance rather than reading a single byte at a time is to use the 'immediate' mode on the TCP read and use a large value for the 'bytes to read' - this way it will return all of the data that is there without waiting for all of the bytes specified or the timeout. It will only wait the full timeout if 0 bytes are received (which you can ignore) - set it to a low value like 100ms.

[PhillipBrooks]

---

@7Ronin wrote:

Hello All,

I wish the VISA TCP functions worked with the localhost as there are properties that can be set to change the term char non-standard.

---

Please consider voting for my Idea:

Add regex based termination string option to NI-VISA

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Add-regex-based-termination-string-option-to-NI-VISA/i...

[7Ronin]

---

@MichaelBalzer wrote:

---

@7Ronin wrote:

...without simply having a dedicated loop for rapid TCP Reads trying to catch these asynch status messages. 

---

 Is there a problem with this approach though? If you read a byte at a time from the TCP port into your own buffer, then perform a check on that buffer for a double line feed, then that should do the trick.

Also is there any reason you're using VISA to do TCP rather than the TCP pallette?

---

Well my first attempt seemed to be a memory hog but I have fixed that.  Also, I am not using the VISA TCP as my understanding is that those will not work with the local host (must be a remote system).  I brough it up because you can set custom termination characters for the VISA TCP stuff.

Appreciate the input and I have implemented the suggestions made here.  I am just going to have to parse the asyncronous messages appart from the commands.

-Ronin

[7Ronin]

---

@Sam_Sharp wrote:

Yes, I would be reading continuously into my own string buffer and then picking the messages out of the buffer once you find the termination character.

One technique to improve performance rather than reading a single byte at a time is to use the 'immediate' mode on the TCP read and use a large value for the 'bytes to read' - this way it will return all of the data that is there without waiting for all of the bytes specified or the timeout. It will only wait the full timeout if 0 bytes are received (which you can ignore) - set it to a low value like 100ms.

---

This is what I ended up implementing in the end, I just wanted to make sure I was not going all Rube Goldberg when there is a simpler solution.

Much appreciated-

-Ronin