Monitor COM port communications

[jacky Wang]

I try to build an EXE application, which is used to monitor the COM port communications. The issue I'm facing is everytime when I try to get to know the input queue of a COM port, it will get away of thos input queue. How can I know the input queue value while not reading  empty the queue?

Thanks!
Jacky

[RobertoBozzolo]

You can use GetInQLen (portNumber);

[jacky Wang]

But in that way, I can not know what's the values in the input queue?

[RobertoBozzolo]

Oh, I see! So you want to read the com buffer without freeing it. I am afraid you cannot fulfil such a specification with CVI native RS232 library. You should go to low-level function or windows API to see if it is possible. I have read for example in the SDK that the serial port can be read in overlapped mode, which sounds as if it can meet your needs; however, I am not familiar with it and I may be in error...

Let's see if somebody else can help you.

[Mert_A.]

I believe the the overlapped mechanism just allows an operation to be performed asynchronously.  What you are looking for is some way to peek the entire input queue without actually removing any bytes.  I don't believe the Windows serial driver provides any way to do this; neither does the CVI RS-232 library since it is built on top of the Windows driver.  If you were trying to monitor the port from inside a particular application, you could of course have a thread constantly read data from the port into an intermediary queue.  Your application could then just request bytes from that queue instead of the driver, and you could alway know what bytes were currently queued.  However, since it sounds like you want a general purpose port monitor, this probably won't be a solution for you.

Sorry the news isn't more helpful.

Mert A.
National Instruments

[Ray.R]

Hi Jacky,

Actually, if you describe why you need to do this, we may be able to suggest another method.

For instance we "tap" into the serial lines going from the UUT to the Test PC, which allows us to look at the communication transactions between the two using a third PC.    I guess you could call it non-invasive monitoring or "sniffing"... 

The above is just an example of doing something non-conventionally to work around a limitation... 

Let us know what you are trying to achieve and why... Maybe there's another solution..

Ray

[menchar]

My two cents

You could use an eavesdrop cable to allow a PC / monitor to watch the serial traffic.

But Mert's got it - build yourself a second queue external to the driver/library that immediately reads any incoming byte from the driver, looks at it to do whatever you need, then enqueues it for the application.  You can easily do this using the rs-232 library.  Just schedule a com callback on receipt of any incoming byte.  If you've got multiple threads reading the queue, just implement a lock (critical section, mutex, signal, semaphore, etc).

You can find c code to implement a queue without much trouble I would think rather than write it yourself. 

We've used this approach with good results to catch an "abort" character off of a serial terminal so we could react to it quickly without waiting for it to eventually get dequeued by the app.

BTW as I understand it the newer NI serial cards (843x) don't use the native win32 driver, they come with their own kernel mode serial driver.

Menchar

[jacky Wang]

Thanks for your all kindness, it seems that I can only use the way of "add another monitor lines and wire it with the serial lines going from the UUT to the Test PC",, like attached picture.

Anyway, thanks for your help!

Jacky

[Ray.R]

Yes.  Now all you need is an "eavesdrop" cable.  You can make your own.