SERIAL PORT PROBLEM?

[anatolia_levent]

Hi , I'm using LabWindows CVI ver. 5.0 and I have wrote program to read data sent to me via serial port continuously.My program can read some datas ( for example 25 times ) and screen them ,  but after this ( for example at 26. data ), my program stop reading of the serial port.To avoid this problem I have used this code : FlushInQ (com_device); to clear input queue of the port ( because I told that input input queue may fulled after lots of reading and caused this problem).But this problem not removed yet...How can I solve this problem?
thanks...

[RobertoBozzolo]

I have been using CVI for several years running several versions (including 5.0) and I have never found such a system bug while using the serial ports.

Since read functions on the serial port discard read data from the input queue, this one should only fill up if your reading function is not as fast as the process that writes to the serial port from the field. If this is the case you should observe a progressive delay between actual and displayed measurements and the only solutions I can see is to either simplify your reading function or change to a fastest pc (and obviously moving to a more recent version ov CVI will help ).

There are some hints that can help you speed up your process but they depend on how you are operating on your system (how many measures acquired and how fast they are wrote to the com port, single- or multi- thread, display on numerics and / or graphs and how many of them, other operations involved like streaming to disk and so on)

[scomack]

Are you getting an error when it does not read or are you just getting no data?
How are you being prompted to read?  Via clock or data arrival?
Do you read the entire buffer on each read?

Pending these answers, the only advise I could offer is instead of flushing the queue, close and re-open the port.

[Mert_A.]

If you are using the LWRS_RECEIVE event to trigger your reads, you need to be careful to read ALL data that has arrived in your callback, especially if your trigger count for the event is relatively small. 

Suppose that your callback is called, indicating that there are at least N bytes available to read.  Now suppose that there are actually >= 2*N bytes waiting, or perhaps more bytes arrive between when your callback is called and when you call ComRead.  If you always only read N bytes in your callback, you might leave N or more bytes still waiting in the queue.  Because the number of bytes in the input queue never dropped below N since your callback was called, the event will not be re-enabled, and your callback will stop being called.  You can avoid this by putting a loop in your callback that repeatedly gets the input queue length and reads until the input queue length is 0.

Of course, calling FlushInQ should also resolve the problem by dropping the input queue length to 0 (though it would do so by throwing away data), so I'm skeptical that this is the problem you're having.  Some more details about how/when you read and what your callbacks look like might help us.

Mert A.