Controlling A Case Structure with String Numbers.

[altenbach]

---

@Hobbs23 wrote:

That is why I receive one byte at a time.

---

Still, all you need is reading the available bytes at once. No inner loop needed. If they are partial data, use a shift register in the outer loop to append the strings of multiple reads.

[Hobbs23]

Thanks everyone for your responses

I will try those suggestions you all mentioned, as well as uploading a vi. Although it may be equally difficult to troubleshoot without the device I am trying to communicate with.

Would it help to send a page of visa trace traffic?

Lastly, the delay is so I can watch all this in real time on the string indicator. Any faster, and it is just a blur.

[aputman]

How are you going to parse a long string of data to get the information that you need from it?  Is the response from the device always the same length, maybe padded with 0's?  If that is the case, read the data in chunks, as has already been mentioned, with the number of bytes set to the length of the expected response.  If the response is always a different length and there is no termination character, good luck to you.  I'm not sure how you would parse an unknown message format.

[Mark_Yedinak]

Here is an example of reading blocks of data with no termination character. The message is determined to have been read completely when the short timeout occurs. THis would indicate a space between different sets of data.

As for displaying the data I would have a separate loop handle the UI stuff. Use a queue to post the data read from the connection to the UI loop. Have the UI loop update the display once a second or whatever interval you want.

[Hobbs23]

Thanks Mark_Yedinak

there looks to be some real meat to your comments that will take me a bit of testing to even understand. Especially intriguing, is to only worry about the error on the first read but not the latter ones. 

I will revisit that. Maybe over the modifications I am in a different place to understand the responses of not only the Labview code, but the way the unit under test communicates.

Thanks!

[Mark_Yedinak]

---

@Hobbs23 wrote:

Thanks Mark_Yedinak

there looks to be some real meat to your comments that will take me a bit of testing to even understand. Especially intriguing, is to only worry about the error on the first read but not the latter ones. 

I will revisit that. Maybe over the modifications I am in a different place to understand the responses of not only the Labview code, but the way the unit under test communicates.

Thanks!

---

Understand that my example is very basic. Normally when I do this I do check for errors on the inner read. I only ignore timeout errors. Other errors such as the connection has been closed or similar types of things are handled gracefully. Though in the case above the initial read will catch those as well.