labview VISA driver, read port recives information from the write port

[elibarber]

I am using a .NET Framework dll to so I can have a green light when my my device is connected.

The problem happens when I am using NI-Visa to write and read to the port in a similar fashion to how I would do it in C#

SerialPort port = new SerialPort("COM5", 115200, Parity.None, 8, StopBits.One);
port.Open();
Console.Write("help()\r\n"); // This works well, and I can use an event handler in c# to log any response back to the console.

The problem is that my response will vary in length and the end char will be unique at least for now, meaning I must resort to reading at much for a given time. I need to be able to write to a string the whatever is in the buffer after a few seconds (in my case 5 seconds).

• If I use the termination Char, I can only get the first line of the response (but at least it shows I am getting something back; 2nd test screenshot)
• If I use the just the timeout variable (5000/5 seconds I believe?) The write command, "help()\r\n", is sent to the read buffer! How is this even possible?

[crossrulz]

1. You actually do not need the VISA Open.  The resource is opened in the VISA Configure Serial Port.

2. You are not sending what you think you are with the string you are sending.  You should be sending "help()" and a Carriage Return and a Line Feed.  Instead of the CRLF, you are sending the literal characters '\', 'r', '\', and 'n'.  Right-click on the string constant and choose Visible Items->Display Style.  You will notice a little n show up, indicating the string is in normal mode.  Click on the n and choose "\ Codes".  Now when you input "\r\n" it will be CRLF.

3. Instead of using the Run Continuously, use a While Loop around the reading and writing.  You only need to initialize the port once before the loop.  Likewise, close the port after the loop.

4. It looks like you are dealing with a terminal type of device.  What I do with these is use the Bytes At Port to see if there is anything on the port to read.  If there is, do the read knowing the termination character will limit the number of bytes that are actually read.  Do NOT use the Bytes At Port to determine how many bytes to read.  Just try to read the 500 characters and let the termination character do the job.  This will return to you 1 line from the terminal.  But there is nothing that says you cannot read another line whenever there is data.

You may want to give this video a watch.  I talk about this situation exactly. VIWeek 2020/Proper way to communicate over serial

[elibarber]

1. Thank you, I removed VISA open

2. Perfect, switched to '\' Codes Display

3. It should only run once because I have a "Latch when pressed" Statement, but I understand that I could attach an array or list of commands to send and loop through those after reading and writing ( This is my eventual goal ).

4. There is no termination character, currently we are doing R&D with an evaluation board. eventually can/will program our firmware instead of the evaluation firmware, but otherwise, the response can be anywhere from 1 to ~50 characters without a specific end char. If a termination character is the only way, then I would need to program several cases depending on what is written to the board.

Isn't there someway to just:

1. Read as much as you can for 1.5 seconds,

2. If you were able to read anything (return count >0? Is this what you mean by "Bytes At Port"?) , the port is good and you can write another response

I added a stall data-flow for 2 seconds but no luck

[crossrulz]

---

@elibarber wrote:

4. There is no termination character, currently we are doing R&D with an evaluation board. eventually can/will program our firmware instead of the evaluation firmware, but otherwise, the response can be anywhere from 1 to ~50 characters without a specific end char. If a termination character is the only way, then I would need to program several cases depending on what is written to the board.

---

I don't believe that.  If you are sending a CRLF, it is almost certain that the device is doing the same.  So a Line Feed (0xA) is the termination character.

---

@elibarber wrote:

Isn't there someway to just:

1. Read as much as you can for 1.5 seconds,

2. If you were able to read anything (return count >0? Is this what you mean by "Bytes At Port"?) , the port is good and you can write another response

---

The important thing here is knowing you got a full message and you know what the message is saying.

If the device only sends anything as a response, this becomes very easy as the termination character (assuming ASCII protocol) ensures you got the entire message back immediately after you send it a command.

If the device sends messages at any time, you still need the termination character to ensure you got the entire message.  But now you need to check every once in a while to see if a message has at least started before doing the read.

[elibarber]

For the most part, I believe you are correct, help() is just an exception as you can see in the screenshot below, as it returns several lines. I think it usually is one line, but I have not tested every single command on the board to ensure that it is always a newline as the terminating character.

I know I can communicate with the board with a simple C# file. see attached. Changing to another command like "InitEvalNGSD(1)\r\n" should return 1 on success or 0 on fail (with the termination char I assume). Yet somehow labview reads information that is written to the port! How can I create an event handler similar to the c# file? This appears the only way to do it.

[billko]

---

@elibarber wrote:

For the most part, I believe you are correct, help() is just an exception as you can see in the screenshot below, as it returns several lines. I think it usually is one line, but I have not tested every single command on the board to ensure that it is always a newline as the terminating character.

I know I can communicate with the board with a simple C# file. see attached. Changing to another command like "InitEvalNGSD(1)\r\n" should return 1 on success or 0 on fail (with the termination char I assume). Yet somehow labview reads information that is written to the port! How can I create an event handler similar to the c# file? This appears the only way to do it.

---

It feels like this was a terminal program that the vendor had repackaged as a driver.  I've seen this occasionally.  Responses to commands are meant to be seen on a terminal.  That's why "help" has a bunch of linefeeds.  It was meant to separate the end of help by a couple of lines, much a you might end a paragraph.

[elibarber]

That makes sense, especially because this is just an evaluation board.

I think that limits my choices at this point:

1. Start working on the micro-controller driver now. and program it specifically with a linefeed or other unique termination char.

2. Have a really slow serial communication that must timeout every single time before the next command?

Is it possible that I am also getting and echo from the Serial port in which case will simply have to program a double read for each command? If so, how would I be able to tell?

[elibarber]

Is this board usable?

I have ran three test sending the following commands to the boards

test 1: "InitEvalNGSD(1)"

test 2: the previous command and "spi(1,0,74054004)"

test 3: the previous commands and "spi(1,0,0a2070000)"

This time I have logged everything to a text file. Looking at the response, I believe that I am literally getting the string "InitEvalNGSD(1)\r\n> 1\r\n> " for the first response! I definitionally think this is more of a terminal app than something that can be used as a driver.

At this point, should I just start writing a driver for the board? Either that or make a bunch of if statements for each unique response read and write?

[crossrulz · Accepted solution]

---

@elibarber wrote:

This time I have logged everything to a text file. Looking at the response, I believe that I am literally getting the string "InitEvalNGSD(1)\r\n> 1\r\n> " for the first response! I definitionally think this is more of a terminal app than something that can be used as a driver.

---

It is common for devices to use a terminal interface.  The easy solution here would be to send your command, read the echo, and then another read for the response.  This is assuming you follow my previous advice and use the termination character so you can read a line at a time.

[elibarber]

That makes sense, The only thing I would need to add would be would be a termination char that changes during the third read, as in the case of

"InitEvalNGSD(1)\r\n> 1\r\n> "

Or

"InitEvalNGSD(1)

> 1

> "

First Termination Char is 0xA

Second termination Char is 0XA

Third termination Char is 0x20 or whitespace