inqueue overflow semantics in CVI rs-232 library

[menchar]

Does anyone know exactly what the CVI rs-232 library does when the InQueue overflows?

Does it discard incoming bytes and leave the InQueue intact - i.e. despite overflow, the queue can be read and the data is still there as it was when first filled?   Or, does the oldest data get over-written?

Does an application have to be processing system events before a rs-232 library callback will be invoked?  I have CVI 8.1, I know the rs-232 library got reworked recently, and I'm curious if there were any changes in this area.  I know there's a separate thread for managing the InQueue.  Since that's the case, I wonder why my main thread would necessarily have to be processing system events for the InQueue to get processed.

What would be the best way for me to obtain the shortest possible response time to a specific incoming character on a serial port using a callback?  I'd like to not have to "sniff" every incoming character at the application level, but have the library do this for me - but I don't want to be late because the main thread is off processing some other event (or not processing events at all at that moment). 

I suppose I could dedicate a thread to receive the library callback - does the callback always occur on the same thread that installed the callback?

And finally, does anyone happen to know the actual maximum InQueue size for Windows XP Pro SP2, CVI 8.1, native Microsoft serial driver?  We also have the NI kernel mode serial driver - does anyone know the maximum InQueue size for that driver?  Can I make the NI kernel mode serial driver work with a non-NI serial port?

Thanks, I know this is a lot.

Menchar

[Mert_A.]

The CVI RS-232 library does not do any special handling of input data.  The overflow behavior (which, btw, can be detected by checking the condition GetComStat(port) & kRS_InputLost) is defined by the driver.  I believe the standard Windows serial driver throws away incoming data that cannot be buffered, though I'd encourage you to double check to confirm that.  If your application has the potential for input overflow, I would recommend using hardware handshaking to enforce flow control.

There is actually not a separate thread for managing the input queue.  There is a separate thread that monitors for Com event notifications from the driver, and there may be a separate thread that pumps output bytes to the driver if you have passed a non-negative output queue size in OpenComConfig (or called OpenCom instead).

As far as responding to a particular input character, you could do your own "sniffing" as you mentioned, but you should probably just install a com callback for the LWRS_RXFLAG event.  The callback is synchronous, meaning it can only occur when your thread is inside a call to ProcessSystemEvents() or RunUserInterface().  You could spawn off a new thread that does nothing but install the callback (yes, callbacks are always called in the thread they are installed in) and sit in an event processing loop as you suggested, but is there a good reason that your main thread cannot be relied on to process messages in a timely manner?  If you have callback functions that take a long time and block other processing, I would suggest having those callbacks launch new threads to perform their time-consuming tasks asynchronously.

Take a look at this thread for a discussion of input queue sizes.  Apparently you posted to it as well, but may have forgotten about it... I know I did. 😉

Mert A.
National Instruments

[menchar]

Mert -

Thanks for the response.

Well, I've got an odd situation.  The code's inside a DLL being called fom VB, so there's no CVI GUI involved, it's a VB interface.  I'd like to keep the VB interface responsive, it's not clear to me that simply calling ProcessSystemEvents will achieve that.  I can't do handshaking of any kind as it turns out. 

I'm trying to pick a single, non-recurring, asynchronous message out of a 115,200 bps message stream.

Thanks again for the info.

Menchar

[Mert_A.]

I would suggest trying a dedicated thread. You can launch a thread that installs the RXFLAG event, then goes into a loop that repeatedly calls ProcessSystemEvents.  The loop (and the thread) can terminate when you clear some global.  Depending on how you need to respond to the message, your callback function can be as simple or complex as necessary.

You will need to ensure, however, that your application is reading data from the port fast enough to prevent data loss; the callback mechanism only works if the event character is actually received!

Mert A.
National Instruments