Visa read only during event pulse

[BrKohler92]

Hi all,

I am currently working with a FISO DMI to monitor fiber optic cables and am using the serial portions of Labview to communicate with the device. I have adapted the canned serial continuous read and write from the LabVIEW examples, but I am having some issues. To prevent the code from constantly sending commands I have put the writing portion in an event based on the OK button being pressed. My issue comes from the read portion in that the code will only spit back one line of the response from the machine for each button press when I want it to send back the whole response. I have attached the VI so hopefully, someone can tell me what I am missing. 

Thanks a bunch!

[RavensFan]

What do you mean by one response vs. "whole response"?

What does a whole response look like from this device?

Is it something that consists of multiple lines with line feed or carriage return characters in them?

The key to serial communication is understanding the messaging protocol.  What does it do to let you know it has completed sending a message?

If it is a multi-line message, you might need to do the VISA read several times in a loop.  But the question is how do you know how many times do you need to do the Read?

This might be a time where you do a Bytes at Port.  In a loop, do a read.  Then check if there are any bytes at port after that read.  If there are, then you loop again and you know there is a multi-line message.  If there is not, stop the loop as you probably have the whole message.  To be safe, since there is a very small chance that you could have grabbed a full line, checked bytes at port and saw it was 0, but the next byte of the following line just hadn't hit the port yet, if Bytes at Port =0, perform a small wait, and check one more time before deciding to end the loop.

You could also just use a small timeout in your VISA configure, and do continuous VISA reads until the VISA Read times out.

But ideally, the device protocol tells you how many lines are coming or bytes are coming before it sends the message.

Crossrulz recently did a presentation that you may find helpful.  VIWeek 2020/Proper way to communicate over serial

[BrKohler92]

Dear RavensFan,

Thank you for the response. I will check out the linked video. The instrument I am using can have a varying number of lines returned marked by a carriage return. For example, I have been using the get serial number command to test as I know what should be returned. When I send that command ([SN]) it should return SN with a line feed and carriage return then it sends the actual serial number ending with a linefeed and carriage return. However, as my code is running it will only echo the SN command and then I have to click the write button again with no command to get the second line of the response. I have attached a screenshot of the response window with the whole response of the device, but I had to click the write button twice when I am trying to only click it once.

Thanks again for the help!

[RavensFan]

So try what I said about putting the VISA Read in a Loop until either the VISA Read times out or a check of Bytes at Port is equal to 0 after a VISA Read has been done.

[billko]

I think you should forget about setting the serial port up to end the write on a termination and try explicitly tacking on the line feed and carriage return to the instruction instead.

[crossrulz]

---

@BrKohler92 wrote:

Thank you for the response. I will check out the linked video. The instrument I am using can have a varying number of lines returned marked by a carriage return. For example, I have been using the get serial number command to test as I know what should be returned. When I send that command ([SN]) it should return SN with a line feed and carriage return then it sends the actual serial number ending with a linefeed and carriage return. However, as my code is running it will only echo the SN command and then I have to click the write button again with no command to get the second line of the response. I have attached a screenshot of the response window with the whole response of the device, but I had to click the write button twice when I am trying to only click it once.

---

Follow the link for my presentation (VIWeek 2020/Proper way to communicate over serial).  The page has a link to the example code on GitHub (https://github.com/crossrulz/SerialPortNuggets).  Look at the ASCII Actor code.  That example was based on what I did for this exact situation.

[crossrulz]

Here is my current state of the example code saved in 2015.  I was starting to make some changes to the Binary Actor to use Maps (new in 2019) and see if I can take care of a situation somebody on the forums kind of challenged me to work through.  So you won't be able to do much with that one.  But the ASCII side is just fine.

[BrKohler92]

I appreciate all the help, but maybe I am not fully understanding the VIs you sent, but I am trying to input specific commands to my device which I cannot seem to do in the actor program. Is there something I am missing to do so?

[crossrulz · Accepted solution]

---

@BrKohler92 wrote:

I appreciate all the help, but maybe I am not fully understanding the VIs you sent, but I am trying to input specific commands to my device which I cannot seem to do in the actor program. Is there something I am missing to do so?

---

Yeah, it's not exactly a structure for "fresh" users to understand.  Study up on Queued Message Handler for a better understanding on the general structure.  But the main thought here is that the Actor runs in parallel of your main loop.  Therefore, it is constantly attempting to read data from the port as well as listening for commands via the queue.  On the main, it is set up so that when you send a command string, it will register a response queue and wait for 1 line of response.

Make sure the serial port settings (inside of the ASCII Actor.vi) are correct.  There is also the question on what your instrument wants for a termination character.  I am sending a Carriage Return and a Line Feed (they are appended in the Write ASCII Message.vi).  Also, the read is expected to terminate with a Line Feed (0x0A).  Some devices will only send out a Carriage Return (0x0D).

[BrKohler92]

Thanks again for all the help. I apologize if the "accept solution" is not the correct method for this thread, but I was able to fix the loop using a double while loop rather than the event pulse I had originally started with.