Having issue VISA Read reading entire serial response

[raycharles]

---

@Bob_Schor wrote:

---

@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.!

My bad. Here is the correct VI attached. There is no .vi that "creates" the text file. I have a text file with the commands on each line.
To further clarify for you, the stages of the code as far as vi's go are:
read_qspi_flash_test_script_from_file:

 - reads each line from text file which are commands to be sent one by one and sends it out as an array

send_QSPI_Flash_cmds:

- takes in the array of command strings from "read_qspi_flash_test_script_from_file".vi and VISA Writes them one at the time.

- Waits for the multiple responses received from the command and puts it out into an array of responses from each command

- checks for "keyword" matches to Pass/Fail

- writes the results to the text file

---

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.

As I have stated in my original post, the behavior is intermittent and 50% of the time when I run my VI it outputs the "correct response" and the other 50% of the time it produces the "incorrect response". I do not do anything to elicit the change hence labeling it as intermittent...

I have attached a zip folder with the text file of the commands, the .vi which reads the txt file, and the .vi which writes/reads the commands then checks for matches in the response.

I have also attached a text file to show what responses are expected to be returned from each command.

[raycharles]

---

@RavensFan wrote:

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.

---

I've run multiple tests to check the response time and it is always less than 10 seconds. I agree that the read shouldn't end early, and the weird part is that it runs fine half the times I run the .vi and the other half will crap out. I do not change anything in between runs, I merely start the .vi again. There is no pattern or order in which it occurs either. It occurs randomly in terms of which response fails and how often. There are times where I can run 5 times in a row without failure and then there are times I run it 5 times and 2 or 3 of those times are fails.

[RavensFan]

First, let's fix some of the code I told you about in an earlier message, along with some other simplifications.

Instead of waiting for a timeout, do a small wait and see if other data has arrived at the port.  (This is one of the very view times I would use "Bytes at Port".)

I'm assuming your device is friendly and receives the multiple lines of data immediately with no more than a tiny break between lines.  I put in a 10 msec wait just in case the next line has not arrived already.

If you aren't receiving the first part of your response, than it is like I said earlier where there is something wrong with your device and it not meeting your timing requirements

[raycharles]

Copy pasted your vi code to see if it would work. It still caused only the tail end of the response to be captured (reference previous response for what it should look like). I am guessing it most likely is my device's response time since I've tried various methods of adjusting the timing through my code... I know that the device is crunching through the Visa Write commands since it does not get hung up at any command and continues to send back responses (albeit sometimes only portions). I think the best way to capture and parse for keywords is to just send out all the commands and capture all the responses into an array, then check after all the commands have been sent for those keywords and see if that functions as I want it to...

Thank you for the revised/cleaner code though.

[RavensFan]

I can almost guarantee the problem is in your device.  I don't know if you'll  have any better luck sending all the commands at once.

Look at the problem from a high level.

1.  You open a configure the port.

2.  You write a command.

3.  You read the response.

There is no way you can be losing the beginning of the response since your port is already open with the buffer ready to receive it.  If you are missing part of the response, it is because the device didn't send that part.

Does it only happen on the first command you write?  Ever on the later commands?

Could you try to resend the first command in the event the first response fails?

[raycharles]

---

@RavensFan wrote:

I can almost guarantee the problem is in your device.  I don't know if you'll  have any better luck sending all the commands at once.

Look at the problem from a high level.

1.  You open a configure the port.

2.  You write a command.

3.  You read the response.

There is no way you can be losing the beginning of the response since your port is already open with the buffer ready to receive it.  If you are missing part of the response, it is because the device didn't send that part.

Does it only happen on the first command you write?  Ever on the later commands?

Could you try to resend the first command in the event the first response fails?

---

I believe my device may clear what is readable from the command line. It outputs the message but then clears it to display the next message. This happens sporadically therefore sometimes it happens on the first command and sometimes on the later commands. There has not been a noticeable trend. It is clear that the responses never "fail" it's more like they are displayed too quickly perhaps and VISA read only captures the tail end.

Hardware wise I am communicating to other usb serial devices through a multiport USB Hub, so I am guessing there is bottleneck occurring while I send commands to other devices and this device just so happens to be on the latter end of the ports therefore gets clipped.

[billko]

---

@raycharles wrote:

---

@RavensFan wrote:

I can almost guarantee the problem is in your device.  I don't know if you'll  have any better luck sending all the commands at once.

Look at the problem from a high level.

1.  You open a configure the port.

2.  You write a command.

3.  You read the response.

There is no way you can be losing the beginning of the response since your port is already open with the buffer ready to receive it.  If you are missing part of the response, it is because the device didn't send that part.

Does it only happen on the first command you write?  Ever on the later commands?

Could you try to resend the first command in the event the first response fails?

---

I believe my device may clear what is readable from the command line. It outputs the message but then clears it to display the next message. This happens sporadically therefore sometimes it happens on the first command and sometimes on the later commands. There has not been a noticeable trend. It is clear that the responses never "fail" it's more like they are displayed too quickly perhaps and VISA read only captures the tail end.

Hardware wise I am communicating to other usb serial devices through a multiport USB Hub, so I am guessing there is bottleneck occurring while I send commands to other devices and this device just so happens to be on the latter end of the ports therefore gets clipped.

---

There's no such thing as "too quickly" for VISA.  If data is sent before the VISA read is executed, it goes into a buffer until it's read.  You get a buffer overrun error if you fill the buffer before reading.  That's what RavensFan was trying to say.

[raycharles]

I understood what RavensFan was saying. Let me reword what I was saying so it is clearer. My device responds too quickly for the hardware in the system to send all the data to the read buffer to be read, therefore Visa Read consequently captures only the tail end of the message because only the tail end of the message reaches the buffer... In no way am I saying that Visa Read is failing to function properly. As I have already discussed with RavensFan above, I believe this is a limitation of my hardware bottlenecking therefore clipping a portion of the response.

I have adjusted my hardware setup so now there are only 2 devices connected to a usb hub which is then connected to the PC. When I run the parent vi, which sends the commands to each device, only the 2nd device seems to be failing now (meaning the 1st device passes and sends all the responses correctly while the 2nd one still sends only snippits of the response).
A consistent result is occurring where the 1st device will pass and send back everything correctly and the 2nd device fails because it only sends back the tail end of the messages. This appears to reaffirm that it is a hardware issue that is causing the 1st device to take priority and the 2nd device cannot send back all of its response due to limiting bandwidth.

Would a better approach to communicating with multiple devices across the USB Hub be to communicate with 1 device at a time instead of simultaneously writing/reading responses in order to allow each device to send back the entirety of the messages without being clipped? Or does labview have a method to successfully do this task?

[RavensFan]

Are you saying there is more hardware involved in the device side of things?  If that is the case, then something needs to be fixed in the device if the device itself is causing data to be lost before it ever gets sent out on the serial wires to your PC.  There is nothing you'll be able to do with LabVIEW to solve that problem.  At best you can keep retrying the communication hoping you get lucky and a complete response comes through.

Is this device manufactured by a third party?  Or is it something your own company makes that you are testing?  You should talk to whoever designed this device about the problems you are having as it sounds like a design problem they need to fix.

[raycharles]

As far as the hardware side of things go my setup & code expand from sending to just 1 device to multicasting the commands to multiple of the same device. Each usb device is identical. When testing the devices individually they perform normally and send back all the commands. It's solely when I attempt to multicast the commands in parallel.

My company makes these devices that I am testing, but as far as their functionality outside of testing, they are singular units (they never have to interact with other units). I am merely attempting to do a scaled up test rig to test their functionalities without having to test each unit one by one.