LabWindows/CVI

cancel
Showing results for 
Search instead for 
Did you mean: 

COM port empty queue in callback

I have a project that involves up to 16 DUTs that are being serially polled for testing, up to 100+ hours.  The testing fixture is a custom PCB.  It's serial channel is via an FTDI USB transceiver chip on the board.

 

In this system, I also have a barcode scanner for getting DUTs into the software.  It is attached to the PC via virtual COM port.

 

All of the above works very well, been in production for 1+ years.

 

However, I have noticed that while a handful of DUTs are actively being tested, using my barcode scanner to load other DUTs appears to not capture serial data.  It's as if the system is getting "bogged down."

 

The software is running on a Win 7 +3GHz machine.  The software is only one thread; I haven't tried multithreading yet.

 

I found this post which very closely resembles what I have tried and confirmed.  That person noticed that his COM callback would get triggered, but that by the time the callback did the ComRd, the data buffer was empty.  Same case for me; if I scan too fast while the system is busy doing other stuff, I can get triggering on my COM port, but the buffer is empty.

 

Here's another close forum topic.  I noticed in the help under the InstallComCallback topic:

 

The callback can get called when there are no bytes in the input queue, even though there were bytes at the time the message was posted. For example, calling ComRd multiple times in the callback can lead to this situation. For this reason, NI recommends that you always check the input queue size before performing any operation in the callback.

So I'm still unclear why that happens.  But regardless, simply checking the input queue is not really enough for me.  My barcoding is processed in a state machine.  There are several codes the user must scan in a certain order for things to work.  So if one or more of those scans fail to input, my software pops up a warning telling them that something went wrong.  So as you can imagine, it's very off-putting to the user to keep getting those warnings when they are following the correct order.

 

My work-around?  I tell the users to "slow down."  That sucks.

 

So am I a good candidate for multithreading?

0 Kudos
Message 1 of 2
(3,789 Views)

 

Hi ElectroLund

 

Seem like you should use multithreading in your application. One thread performs the test of your DUTs and another reads the barcodes. This way you won’t bog the main thread.
Here’s an article of how to use multithreading in CVI.

http://www.ni.com/white-paper/3663/en/

 

Regards                

Chris S.
Message 2 of 2
(3,749 Views)