Serial Read unknown bytes no termination character

[Marcurah]

Hello,

I don't know if there's another topic about this but I have scoured the internet and not been able to find one, so I'm posting my own.

I am trying to communicate with a controller using Serial communication. I am able to send different commands to the controller and should receive different responses accordingly. 

My issue is that the controller sends back the command I entered followed by a termination character before it sends the data on the following line.

IE: I send the command "TC" The controller responds with "TC \n 293.15" 

I don't know how to read all of the data coming back from the controller as the amount of bytes varies depending on what command I send, and I can't use the stop read at termination character as the controller sends multiple of those to separate the data into lines.

My question is if there's an easy way to read an unknown number of bytes from the controller without using the "End read on Termination Character"?

If I have that option on I receive only the first portion of the response back on the first read, and if I have it off I receive the data but the communication then times out.

The code I'm using atm is the "Continous Serial Write and Read" example with minimal changes.

Appreciate any help as I am very new to Labview.

[GerdW]

Hi Marcurah,

---

@Marcurah wrote:

I am trying to communicate with a controller using Serial communication.

My issue is that the controller sends back the command I entered followed by a termination character before it sends the data on the following line.

IE: I send the command "TC" The controller responds with "TC \n 293.15" 

I don't know how to read all of the data coming back from the controller as the amount of bytes varies depending on what command I send, and I can't use the stop read at termination character as the controller sends multiple of those to separate the data into lines.

---

Which kind of "controller" is this? Can you link to a manual?

When you write "data on the following line" does that mean the data is received with one more TermChar appended?

I still would use the LF as TermChar, together with a rather short Timeout value (like 50ms?). This way you can receive these two strings:

1. your command, (due to the TermChar)
2. your data value (due to the TimeOut)

You just need to handle the TimeOut error after VISARead…

[Marcurah]

Hello,

I only have the manual on paper right now, but I have requested it from the company as a PDF.

What I meant was:

IF I send the command "TC"

I am supposed to get back this: 

"TC

+273.15"

As in the data comes in multiple lines and the problem I encountered was that VISA read interprets each line as a termination character and therefore terminates the read. 

How would I handle the timeout error from the controller then?

Right now I have just set it to so that my program exits when it encounters an error from VISA.

I also managed to get it working with using "Bytes at Port" and setting the amount of bytes to read equal to that value, but all the info I've seen online, all help forums and such tell me that we should never really use that command.

[GerdW]

Hi Marcurah,

---

@Marcurah wrote:

How would I handle the timeout error from the controller then?

Right now I have just set it to so that my program exits when it encounters an error from VISA.

---

Don't exit the loop on this error. Use a case structure instead to handle this specific error!

When the timeout occurs you still get the received string with all data received so far. When this string is empty you had a "real" timeout. But usually it should contain the value to your command so you can omit the error and use the received string as you like to.

Set the bytes to read still larger than expected!

---

@Marcurah wrote:

I also managed to get it working with using "Bytes at Port" and setting the amount of bytes to read equal to that value, but all the info I've seen online, all help forums and such tell me that we should never really use that command.

---

Which is good advice! You mostly NEVER need BytesAtPort!

[Kevin_Price]

As GerdW is suggesting, it sounds like you should configure to use "\n" as your termination character and then simply perform 2 consecutive VISA Reads.

That's the theory based on what you've observed so far.  But I'll also say that it's at least a little unconventional for a device to return 2 responses to a command.  That in turn makes me more suspicious about the consistency and accuracy of the serial protocol in general.  The main reason is hard-earned experience.

Very many times that I've dealt with a serial device, I've eventually found that there are a few behaviors that run contrary to the general rule.   In your case, that might mean that some commands might only result in 1 reply line, or none, or >= 3.  Or maybe there are certain conditions where the device blurts out a serial status without prompting.   I've seen all these exceptions (and more!) so I've come to simply expect that short of instrument-grade lab equipment, most other mfgr's docs about serial communication may not tell me everything I need to know and may not be fully accurate in the description that *is* given.

   It doesn't *always* happen, sometimes things do behave exactly as described.  But I've definitely not found it to be an overwhelming majority of the time.  It's quite common to need to spend time tinkering to discover the exceptions.

Sorry, just trying to forewarn you.  Hopefully, you've got one of the devices with a good serial implementation and trustworthy docs.

-Kevin P

[billko]

---

@Kevin_Price wrote:

As GerdW is suggesting, it sounds like you should configure to use "\n" as your termination character and then simply perform 2 consecutive VISA Reads.

That's the theory based on what you've observed so far.  But I'll also say that it's at least a little unconventional for a device to return 2 responses to a command.  That in turn makes me more suspicious about the consistency and accuracy of the serial protocol in general.  The main reason is hard-earned experience.

Very many times that I've dealt with a serial device, I've eventually found that there are a few behaviors that run contrary to the general rule.   In your case, that might mean that some commands might only result in 1 reply line, or none, or >= 3.  Or maybe there are certain conditions where the device blurts out a serial status without prompting.   I've seen all these exceptions (and more!) so I've come to simply expect that short of instrument-grade lab equipment, most other mfgr's docs about serial communication may not tell me everything I need to know and may not be fully accurate in the description that *is* given.

   It doesn't *always* happen, sometimes things do behave exactly as described.  But I've definitely not found it to be an overwhelming majority of the time.  It's quite common to need to spend time tinkering to discover the exceptions.

Sorry, just trying to forewarn you.  Hopefully, you've got one of the devices with a good serial implementation and trustworthy docs.

-Kevin P

---

I've had a goofy power supply that did just that - have several lines in its response - and a different amount of lines depending on the command.  I suppose that's because it was never meant to be automated; it must have been expecting human interaction with a terminal, and the documentation for automated interaction was just a kludge.

Maybe this is a similar thing?

[Marcurah]

I've been trying to implement GerdW's solution for a while now, but haven't gotten it working yet.

The problem is I can enter a command into the controller called "State" Which then returns the status of the instrument.

This returns 12 separate lines where each line is a parameter and it's state.

That means that I can't only do 2 reads, instead I have to program it to read until it can't read any further, and up until now I have not been able to solve that issue.

Regarding the Instrument: It's a Cryogel Cryocooler with a Gen II Controller, so it is very much a lab-grade piece of equipment that I am using to cool a vacuum down to ~60 Kelvin. That being said, in the manual there is little to no information on how to actually program the interface for it, it suggests to use a terminal emulator software to handle the contact with the end-user which is what I am trying to get to work using Labview.

[Marcurah]

---

@Kevin_Price wrote:

Very many times that I've dealt with a serial device, I've eventually found that there are a few behaviors that run contrary to the general rule.   In your case, that might mean that some commands might only result in 1 reply line, or none, or >= 3.  Or maybe there are certain conditions where the device blurts out a serial status without prompting.  

---

You are describing my device exactly.. Which is why I've been having so many issues getting it to work. The other instrument I have connected took me barely an hour to get up and running and to extract the information that I required.

[GerdW]

Hi Marcurah,

---

@Marcurah wrote:

The problem is I can enter a command into the controller called "State" Which then returns the status of the instrument.

This returns 12 separate lines where each line is a parameter and it's state.

That means that I can't only do 2 reads, instead I have to program it to read until it can't read any further, and up until now I have not been able to solve that issue.

---

But in general you KNOW how many lines to expect FOR EACH COMMAND you send to the device!

So you can read as many lines as expected for each command - as you are using a command-response communication scheme!

(Before this message all we got from you is "I send one command and receive exactly two lines of response…". Now it is "I send a known command and receive a known number of lines…"!)

That's why I asked for a manual.

And as has been said before: when your device expects a terminal you need to emulate terminal behaviour!

[Bob_Schor · Accepted solution]

I think the title of your Post is incorrect -- what you seem to be describing is "Serial Read, sometimes unknown number of lines, all with Termination Character".

From your description, you send a Command, and the Instrument returns possibly one or multiple lines (which implies a termination character).  Presumably the response is relatively fast (say, within a few tenths of a second), so you could do the following:

1. Configure VISA with a 200 ms Timeout, and enable <LF> as the Termination Character (the default).
2. Send a Command.
3. Do a VISA Read of 1000 bytes (many more than one line).
4. Check for Error -1073807339, VISA Timeout.  This indicates that the Instrument did not send a response, so you are finished with all of the lines it had to send back to you.  Clear the Error and go to Step 6.
5. Otherwise, you got a line of "Response" from your Instrument.  Parse it as required (you should know more-or-less what to respect from each Command that you send).  If you expect a multi-line Response, return to Step 3.
6. You have finished this VISA communication -- use the returned Data as required.

Note I "guessed" at 200 msec for the VISA Timeout.  This will, of course, depend on your Instrument and other timing requirements.  Also, if you know how many lines to expect, you can simply have a For Loop that does the specified number of "1000-bytes-per" VISA Reads, returning all of the results.

Bob Schor