visa read buffer extra byte problem

[johntrich1971]

Bob, while I've just never really messed with channel wires I thought that they were for communication between parallel loops, not from an outer loop to an inner loop as was shown. Wouldn't the Stop button just be read once and written to the channel wire and then not read again until the next iteration of the outer loop? As for the second program with all of the loops it does need some restructuring. I had suggested state machine only because it would be easy to get there from what the OP had already written, but I agree that a Producer/Consumer is a better approach.

[Laian]

Hi John& Bob

I have attached a very simple VI just reading 566 bytes in each cycle.

without any extra operation

I can see for about 30 correct cycle operation suddenly the string display shows more or less bytes than 566

I think the problem is the read buffer

what is your suggestion?

Thanks

[RavensFan]

---

@Laian wrote:

I think the problem is the read buffer

---

What exactly does that mean?  What "problem" do you think the read buffer has.

Your port is set to not use a termination character.

If your read string indicator has less than 566 bytes, that means your device didn't send a full message before the VISA read timed out.  I suggest you put an indicator on the error wire inside the loop to see what kinds of errors you get.

If your string indicator has exactly 566 bytes, then that error indicator will show a warning message saying you got exactly the number of bytes you asked for.

If your string indicator has more than 566 bytes?  Impossible.

How do you know how many bytes you are getting?  You don't have an indicator on the return count output of the VISA Read or a string length function and indicator on the string.

[Bob_Schor]

This is your VI, cleaned up a bit, and checking for Errors, returning the Byte Count, and giving you a clearer view of what is happening.  This is a 2018 Snippet, but you should be able to make the changed right in your own code.  I got rid of the unnecessary Cluster (everything except Baud Rate is the Default, so just show what is changed), and changed the Error Line tunnel into a Shift Register (so once it "goes bad", it "stays bad", and, more important, I exit the While if an Error occurs (at a minimum, you should "trap" the Error inside the While loop and decide what to do with it -- my decision was "give up").

Bob Schor

[Laian]

thanks

I used return count display its 566 bytes in each cycle

the problem is I lose a byte and instead of this byte at the end of the process one byte (the start frame) from the next cycle is added so 566 bytes shows on return count display

and always the second byte is lost!

I used the other simple terminal softwares all the time its correct I can get 566 bytes correctly but what is the problem by Labview?

• appreciate any suggestions 

thanks

[RavensFan]

One problem you probably have is that there is no synchronization between the device sending the data and your LabVIEW VI.

Since you only read, it seems like this device sends out 566 bytes at some periodic rate, whether your PC serial port and LabVIEW program are ready to read it or not.  So if you happen to open the port in the middle of the message coming in, you are not going to see all the bytes in that packet.  It will wait a while and either timeout, or grab the remaining number of bytes at the beginning of the next packet of 566 bytes coming in.

A proper protocol would have your LabVIEW program send a message to the device that says "Send me the data".  Then the device, upon receiving this message, sends back the 566 packets.  Anything else, you risk a lack of synchronization.

So if you are stuck with dealing with this one way communication, here is what you do.

Read one byte at a time in a loop, if it happens to be your start byte, then exit the loop then do a VISA Read to get the remaining 565 bytes.  If it is not the start byte, then just throw it away, you are obviously in the middle of the message.  You missed the beginning and you'll wind up with an in complete message.

You say "I used the other simple terminal softwares" (sic).  Well, simple terminal software is actually pretty stupid.  It just reads all that it is there at the serial port and immediately displays it in the terminal window.  It really doesn't care if it got a complete packet or not because it will instantly go back and read more and just append it all up on the same screen.  It looks okay to you because you are visually reading the screen and you are mentally breaking things into the different messages.

[Frozen]

Well, if you are dealing with a device that is dumping data, then I recommend you flushing the recive buffer before attempting to collect the information.

When I was dealing with such a device (a scale in my case) I found that I had to add a delay after the port configuration as well, otherwise I would get random errors when starting my application.

[RavensFan]

Flushing the receive buffer doesn't necessarily help.  You could be flushing it right after the data has started to arrive.  Then you will still get an incomplete packet of data for whatever arrives after the flush.

[Eric1977]

I think it would help us immensely if you'd attach the documentation of the device. We're all just going on your assumptions that you've read and understood what your device does.

[Laian · Accepted solution]

solved just by adding Visa close function to my while loop!!

I dont know why but I need to close and again reopen the port each time I read the bytes in my while loop

Thanks