Having issue VISA Read reading entire serial response

[raycharles]

Hi,
Background on my VI's functionality:

My VI reads from a .txt file a list of commands, puts them into an array and executes each element by VISA Writing each those commands to the device. The device then executes the command and responds with results of the command. It then VISA Reads the response from the respective command, parses through it and checks for a "keyword/string/phrase" which confirms that the device executed the command correctly. It will loop and send the next command on the list which was collected from the txt file and continues to check each response before moving onto the next command.

Issue:
Currently, I am testing my code with a Golden Unit (so I know for a fact the device should pass and works correctly). My issue with the VI is that it is performing intermittently and VISA Reads the response correctly 50% of the time (which means the "keywords" match up correctly with the response) and then the other 50% of the time it fails because the VISA Read buffer response lags/is offset (which means the "keywords" does not match up with the response collected). I know the VISA Read buffer eventually outputs all the responses from the device because I have a data log .txt file which outputs everything VISA read outputs. I also know that there is an offset when a failure occurs because I created a debugging log .txt file which saves each VISA read output immediately after each command write/read.

I have also attempted to fix this 2 ways:

1. Having a set "Byte Count" for VISA Read to read. Initially I set it to 1000 then 300 then to 100. All of those Byte Counts would either create an offset causing the "keyword" search to fail. It would also cause an Error -1073807339  because the amount of bytes I was reading wasn't the correct size... (which is why I switched over to using Bytes at Port)

2. Using "Bytes at Port" on Visa Read (which I know is often condemned by many at NI). I wanted to guarantee that I was receiving the entire message. I also added  time delay between writing and reading to ensure that the entire response had time to be outputted by the device (but that clearly didn't work because it only returns a portion).
 
I have attached a few things to hopefully get some help:
1. 2 Different iterations of my VI. One using "Byte Count" for VISA Read. The second using "Bytes at Port" with a 5 second delay after VISA Write.
2. A text file with the cmd line output that I expect.

3. 2 Debugging text files (one showing the correct debug response which lines up correctly, the second showing the incorrect response). The "BREAK" that appears in the txt files indicates when the "Visa READ" loop finishes an iteration. The biggest difference between correct and incorrect is the first line where right after the "*******" the Incorrect VISA response "BREAK"s too early causing the offset and causing the "keyword" search to not match up ergo failing.

Hopefully I am just doing something stupid and this is an easy fix!

[Bob_Schor]

None of your attachments have the .vi extension.  We already know that there's something "wrong" with your code, so if you continue to "hide" it from us, I'll just have to guess that you have not set the Termination correctly for your device.

Despite being annoyed at not being able to "see" the problem, I'll suggest a test for you.

• Plug your device in to your PC.
• Open MAX.
• Find your Device and open a Test Panel.
• Configure VISA as you think it should be.
• Find the section that talks about the Termination Character sent on output.  Be sure it is enabled and set to 0xA (Line Feed).
• Now open a Terminal Session.  Send a Command (ending with \r\n) that should give a response you know.  See if you can read it and if it makes sense.  If this works, then the Good News is that your device uses Termination Characters and reading VISA should be a piece of cake, with no need for "Bytes at Port".  Check your code (or post it and we'll check it).

Bob Schor

[billko]

Bob - the first two files are VIs.

[raycharles]

That's weird... My first 2 attachments "send_MMC_cmd.vi" and "send_MMC_cmds_2.vi" are ".vi" files dragged straight from my vi folders and I am able to open them up in LabVIEW when clicking on them... (Snapshotted that below)

I'll post snapshots of the main portion of them and try to attach them again below...

I will also try out your suggestion.

[raycharles]

So I tried the MAX Test Panel suggestion and here is what I got:

1: Write Operation (mmc\sdev\s0\s1\r\n)

Return Count: 13 bytes

2: Read Operation
Return Count: 13 bytes
mmc\sdev\s0\s1\r\n

3: Read Operation
Return Count: 29 bytes
switch\sto\spartitions\s#1,\sOK\r\n

4: Read Operation
Return Count: 32 bytes
mmc0(part\s1)\sis\scurrent\sdevice\r\n

5: Read Operation
Return Count: 5 bytes
=>\s\r\n

6: Read Operation
Return Count: 3 bytes
=>\s

The response is what I expect for the command I typed in, but I have to send the "Read" command 6 times in order to receive everything. This is expected since I found this out while making the VI (hence the while loop around VISA Read to ensure that it runs until the Read Operation no longer receives anything). This is because as I mentioned before, the device responds with multiple responses therefore a single "Read" will not capture all the responses from the one "Write".

This exercises basically the same functionality as my code, but does not solve the issue that my code sometimes finishes the "Read" While loop to early (i.e. thinks it is done after doing "Read Operation" 3 times leaving the other 3 "Read Operations" to be done on the next while loop iteration. This causes my "keyword" search to fail at those instances when the "Read" loop ends before capturing all 6 responses.

[RavensFan]

I don't see any reason why your reads would end early.

Your loop reads 100 bytes or until a termination character.  Then iterates.

Your loop only stops if you have an empty string returns, which means it only stops if the VISA Read timeouts, which means nothing was received for 10 seconds (the default timeout for VISA since you didn't change it.)

So is any line being returned taking longer than 10 seconds from the time before it?

Your loops can be greatly simplified.  First, you should have a File Open before your outermost For Loop starts.

You only need to move the file pointer once at the beginning before the loop starts, it doesn't need to be inside of any of the loops.

You can auto-index on your string array which will allow you to get rid of the Index Array and the i terminal wired to it.

In the innermost while loop, you can auto-index on the output of the responses.  No need to initialize the array and do Replace Array subset every iteration.

You should check the timing of your Read Responses.  The only way it ends early is if it takes longer than 10 seconds to get a response.

[Bob_Schor]

Sorry I missed your VIs (thanks for attaching).  Also, thanks for the MAX tests.  Here's a routine that should work for you (Famous Last Words):

Multi-line VISA Read

The VISA Configure Serial Port has the inputs for Termination Characters (so you don't need a Property Node).  I also set the Timeout from 10 seconds to 0.5 seconds, assuming that when you give a Command, you'll get the response within half a second.

     For the Read, I ask for 1024 characters (knowing I should get fewer).  As long as the Read doesn't time out, I stay in the Loop and accumulate the lines in an Indexing Tunnel, using a Conditional Terminal to not output the non-existent line when the Timeout (an Error) occurs.  The Error should be -1073807339, VISA Timeout expired on Read, so I clear this specific Error and can then proceed.  [For this example, I just quit, but you could do multiple Command/Response cycles].

     You had most of this in your first VI, but didn't have the code to do multiple Reads per Command.  To be honest, I've not encountered multi-line Responses (other than when you start an Instrument and say "Send me lines forever at 10 Hz"), so it didn't occur to me to mention this earlier.

Bob Schor

[raycharles]

Thanks. I'll give this a shot and see if the issue goes away then report back. Hopefully this does it otherwise it might be intermittent characteristics of my device's read/write latency.

[raycharles]

Tried out the new method. Attached the .vi below. Results still intermittent.

When I removed the "TermChar" property node for Visa Write, it ended up causing issues and Visa Write would push all my lines from my text file and write the commands in 1 line, so I put it back in to ensure it was terminating after each write.

Code is cleaner, but I am still not capturing the entire response. The result of what I'm capturing is clearer now though since it seems like the "Visa Read" is reading the response too late. To clarify this I have attached 2 text files again, 1 being my expected output and 1 being the failing output. You can see in the failing text file that the "Visa Read" seems to almost be running too slow to capture the first half of the response that happens right after I send my Visa Write command to my device.

You will notice that in the "Correct_Response" file, the Visa Read captures:
=> sf probe
SF: Detected s25fs512s with page size 512 Bytes, erase size 256 KiB, total 64 MiB

While in the "Incorrect_Response" file, the Visa Read reads late and captures only the tail end of the response being:

=> se size 256 KiB, total 64 MiB

Not sure what is causing it to sometimes capture the entire message, then other times capturing only the tail end of the response???

[Bob_Schor]

---

@raycharles wrote:

Tried out the new method. Attached the .vi below. Results still intermittent.  No, you didn't.  You attached a VI that reads the Text file, while we need to see the VI that creates the Text file, that reads a Script, sending each line to the device, gets the (multi-line?) responses, and creates the text file that shows both the Questions and the Answers.!

When I removed the "TermChar" property node for Visa Write, it ended up causing issues and Visa Write would push all my lines from my text file and write the commands in 1 line, so I put it back in to ensure it was terminating after each write.  This also is not shown in the VI you attached.  If you don't show us what you are doing (whether right or wrong), we can't provide help other than to "guess" at the problem.  This wastes our time and wastes your time, as well.

Code is cleaner, but I am still not capturing the entire response. The result of what I'm capturing is clearer now though since it seems like the "Visa Read" is reading the response too late. To clarify this I have attached 2 text files again, 1 being my expected output and 1 being the failing output. You can see in the failing text file that the "Visa Read" seems to almost be running too slow to capture the first half of the response that happens right after I send my Visa Write command to my device.  My assumption is that your output streams are interfering with each other, but as you haven't shown what you are doing, I can only guess that the most likely explanation is that you are doing "something" wrong.  I won't try to guess what.
You will notice that in the "Correct_Response" file, the Visa Read captures:
=> sf probe
SF: Detected s25fs512s with page size 512 Bytes, erase size 256 KiB, total 64 MiB  You provide no indication what the situation was that led to this "correct" response.  How did it differ from the "incorrect" response?  Did you do exactly the same thing and get two different answers?  Did you do two times in a row, and it worked the first (or second) time and failed the other?  We have no idea!!  You have all the information and haven't shared it with us.

While in the "Incorrect_Response" file, the Visa Read reads late and captures only the tail end of the response being:

=> se size 256 KiB, total 64 MiB

Not sure what is causing it to sometimes capture the entire message, then other times capturing only the tail end of the response???  It's either in your code (most likely), in a possible flakey behavior of your Instrument (possible), or something peculiar about your Command File (which would also be a good thing to attach to give us a clue what you are asking, how many commands are being given, if there is a particular order, etc.  It would also be useful to know which command, if any, is expected to give a multi-line response.

---

Once again, you've told us that what you did didn't work, but failed to tell us what you did, so we can't help much except to say "So Don't Do That!".  Please attach all of your VIs, and relevant "Command" files.  If all of your files are in a folder (and/or if you are using LabVIEW Project), compress that folder and attach the resultant Zip file.  You can explain in your reply which files are which.  Don't make us beg to get the data  we need to help you.

Bob Schor