serial communication missing bytes

[Ranjeet_Singh]

---

@ArchieC wrote:

Thanks a lot all of you for your suggestions.

I have tried different ways of communicating with the tester in the past week and have come up with some weird observations.
The code works fine on one PC, the one i used to develop the code, but if i change the PC, i start missing bytes.

The PC i used to develop the code is 32 bit, celeron and the other PC is dual core with EM64T.Can this have any effect??

One more thing, in the PC where i am missing bytes, if i connect a pendrive to it, then there is no data loss.

---

Why dont you display the communication response byte and use some error out to see what is going on ?

PC configuration doesn't make any difference according to me. Pendrive doesn't make any difference in serial communication.

[Rasoul]

Hello, Everyone

I am doing almost the thing that ArchieC Is doing, and unfortunately I have had same problem, but just the difference is that the tester is substituted with a microcontroller as a module to collect data, then the collected data should go through PC to be analyzed and so on, I am using Uart on microcontroller (PIC) and Labview 2012, I simplified my program to only that portion which is related to serial communication which will be attached below. I also have observed that some of my bytes is being missed, I changed the timeout of Visa and also modify the timing of my PIC, and what I saw, is that data is coming but the speed of data being transmitted is not appropriate, I mean that when I manipulated the time I got data in each transmission is being shifted. The type of my data also is string.

Dear Ranjeet_Singh

I think that you are expert enough to give some suggestion to solve the problem, the interval time of each transmission should be 400 msec (at least) and there is not maximum value for that.

Please have a look on the blow simple and general code and what is your opinion?

My baud rate is 9600 1 stop bit, no parity, no flow control

One more this that has to be mentioned is the length of data(string)  which at least is 12 and maximum is 19.

Thanks in advance

[RavensFan]

Why are you flushing the receive buffer on every iteration of the while loop?

Any byte that happens to hit the buffer between when you read the number of bytes at port on one iteration, and the flush buffer on the next iteration of the while loop will be lost.  Only the bytes that arrive between the flush buffer and the bytes at port node will ever get read.  That seems like it would be a very small percentage of the overall loop iteration time.

[KathrynB]

Rasoul, one of your issues might be that Flush Buffer, that will clear any data that is hanging around.

To explain what I think has become lost:

With a serial device (and it doesn't matter what it is) all that the serial aspect dictates is the PROTOCOL for talking to it. Sometimes you can write to something on the end without expecting a response, and sometimes you can get responses without having written anything to it, or it can be so slow that you don't get all your information at once (hence my earlier example with cases - what I gave was a subVI for a programmer, not something for a user).

How something communicates will always (as has been mentioned in this thread before) depend on the device in question.

Rasoul - assuming that the PIC is broadcasting data (that is - it is putting data on the serial line at given intervals) then is there an end of message character? How do you know that you have reached the end of a piece of data? Is it always based on time? If you're talking in ms then you can almost ignore it, everything is slow enough that time is unlikely to be a factor. The first thing I would do though is move that flush buffer outside of the loop and see what happens. With the hundreds (and I do mean hundreds) of serial devices that my work place talks to not one of them flushes buffers on reads, only ever just before a write.

[Rasoul]

Dear KathrynB

First, thanks to all of you for your grateful answers,

Second, I took the flush buffer out, But still the problem has not been solved, I have same thing that I had before, I have question have you had ever such this problem when data is being transmitted continuously? I want to resend the new code because it might be needed to figure out the problem...

Third, the time of coming data depends on other factors coming from devices connected to PIC. Actually, I had checked using termination character to realize the end of being transmitted data, but I even got noting any more, So I removed it.

I will be expecting for your professional answers.

Thanks in advance

[Rasoul]

This is the video from that I have resulted. this may help to solve my problem.

[RavensFan]

Something is wrong with your zip file.  Winzip says it is not a valid archive.

[camerond]

In the picture you sent, you are only collecting the character(s) being received during the last iteration of your loop. You need a shift register (accumulator) like the one attached. In this one, 0x83 is the stop charactor, so adapt as needed.

Cameron

(Edit: If you run the loop as fast as possible, you should never have more than one byte at your port at any time, so you can just check for one character.)

[Rasoul]

Sorry, I forgot to mentioned that I had changed the suffix of the compressed file, because it was rar file, but it had not been allowed to upload in the forum so I had to changed it to an admissible suffix. I apologize for that.

Thanks in advance

[Rasoul]

Dear Cameron,

Thank you so much. You are exactly right, it seems to be right. Thank you so much for your answer, tomorrow I will be checking and let you the answer. Thanks again man.

Best regards

Rasoul