Best practices for serial read

[jrdwight]

I'm communicating with an instrument via serial, and it sends a response that I want to read with an end of line on both ends: "\r\n[information]\r\n".

What's best practice for reading this? Should I use "\n" as my termination character for reading, and just plan to read twice so that I get [information] in the second read? Or should I just read without a termination character and let it time out? And would your answer change if I'm already using "\r" as my termination character for writing?

[santo_13]

I would treat it as two reads by using "\n" as the terminator and verify that the first read is empty and the second one contains information.

[crossrulz]

I concur with leaving the termination character as \n and doing multiple reads.  It will be a lot simpler than figuring out an alternative.

[jrdwight]

Been experimenting with this some more, and I think I've made my decision:  Because I have to use "\r" for the termination character for writing, and I'd rather not change the termination character every time I change between reading and writing, I'll just disable the termination character for reading and allow it to time out. My instrument replies very quickly, so I can set the timeout to something short (50ms) that won't be perceived by the user in real time. And I can programmatically handle the timeout error in my code.

[crossrulz · Accepted solution]

---

@jrdwight wrote:

Been experimenting with this some more, and I think I've made my decision:  Because I have to use "\r" for the termination character for writing, and I'd rather not change the termination character every time I change between reading and writing, I'll just disable the termination character for reading and allow it to time out. My instrument replies very quickly, so I can set the timeout to something short (50ms) that won't be perceived by the user in real time. And I can programmatically handle the timeout error in my code.

---

I advise against that.  What I have learned over the years is that I do not trust VISA to append the termination character when I write.  By default, you just do not enable the Send End On Write during initialization.  I explicitly concatenate the needed termination character before writing.  I even go so far as to create a VI that accepts a command, concatenate the needed termination character (\r in this case), and then send the full command via VISA Write.  This allows you to keep the termination character for the read the same during the entirety of the application.

[jrdwight]

I see. I guess that's not so bad to just append commands with "\r". Additionally, there might be a use case for this instrument where I need to stream information from it quickly (100Hz or faster), so I wouldn't want a read timeout to delay that process.

I'll take your suggestion! Thanks!

[rolfk]

In addition to what crossrulz said: There are instruments that require a different termination character depending on the interface you are using to communicate to them. Pretty stupid design but anyhow! Usually they require a specific termination character for normal RS-232 (or virtual USB-COMM) and TCP/IP and none for GPIB or USB-TMC. By creating a special Write Command.vi subVI you can centralize that special handling if needed and keep the rest of the driver consistent for every communication variant.

The usual design of devices is to simply ignore the termination character for the interfaces that have a different default EOM signaling, which is the sanest implementation, but device firmware developers can sometimes be a bit weird. 😉

When implementing firmware or other software, always try to be as consistent as possible in what you generate and as lenient as possible in what you can accept. Some developers tend to turn that upside down in their ignorance. Requiring messages to be enclosed in two termination character sequences is pretty much insane too.