Input queue limit of 4096 on serial communication

[IEE_newsoft]

Hi,

could you please help me in solving the following problem:

I programmed a Keithley multimeter to store scanned readings. When I request the data from the multimeter, there can be a very large string in the input queue of the PC's serial port. When I put a GetInQLen()-call in my code, it reports 4096, although the string is much longer.
It cannot be a Windows-related problem because a datalogging via terminal on a spy line reports the whole string on another serial port of the same PC.

I reviewed the CVI-help and this forum but could not find any hints about a limitation to 4096. In the help for OpenComConfig() no limitation on the input queue is pretended.

I would be able to program a workaround (instruct the multimeter to deliver the data in portions), but maybe it could be an interesting information if this is a known problem....

Thanks in advance

[jr_2005]

Would it help to employ hardware handshaking (RTS/CTS) to control the flow of the RS-232 communication, or is this something that you are already doing? It is a fairly common technique for controlling large data transfers whilst only using relatively small port buffers. Does the Keithley Multimeter support this handshaking?

JR

[IEE_newsoft]

Hi jr_2005,

thanx for your fast reply,

currently I'm using software handshake (Xon/Xoff) in my application. My terminal on the spy line is set to "no handshake"
I didn't try handware handshake but I will try it now....

[menchar]

CTS / RTS works better than Xon / Xoff, you need the extra wires in your serial cable though.  With Xon / Xoff, you're using characters in the data stream and if you're sending non-ASCII sooner or later you'll get burned by seeing your data stream grind to a halt because an Xoff char was detected.  Plus, the Xon / Xoff "skids" to a stop because the chars have to be assimilated and recognized by software.  With CTS / RTS, the data stream starts / stops at the UART level.  Heck, for all I know, modern UARTS are able to do Xon / Xoff in hardware but I suspect they don't.

The Keithly may well have an IEEE-488 (GPIB) interface included.

GPIB inherently is able to handle this problem by manipulating the three wire handshake that tranfers each byte.  The "not ready for data holdoff" works just fine to throttle back an incoming data stream. 

You have to spend the extra $ for a GPIB controller, and there are limits on data rates and cable lengths, cabling costs, etc., but that bus is designed for instrument control and it's tried and true.  It's how NI got into business in the first place.

Lately I see more and more people trying to implement with serial control only - and it has a bunch of limitations, and you often wind up spending a bunch of money for extra serial ports - why not buy a GPIB controller?  I've seen incredible wastes of time trying to get funky USB / rs-232 dongles to work, com port cards that break when hyper-threading is enabled, etc.

[mvr]

Are you calling OpenComConfig() to access the serial port and configure the input buffer?  What size are you trying to set the buffer too?  4096 is actually the smallest queue size that windows NT/2000 will normally allow and if you did not specify a queue size, or let it default to the 512 that CVI trys to use, that is what you would get.  Depending on the serial driver installed on your system it should at least allow around 32K.  If you need more than you can get with the default CVI serial buffer and windows serial driver just attach a callback to the serial port.  In the callback remove the data and place it into a thread safe queue.  They work very well at very large data sizes.

[Mert_A.]

Hello,

The GetInQLen function calls the ClearCommError Windows function which returns the number of bytes not yet read via the cbInQue field of the COMSTAT structure.  I would guess that you are being limited by the size of the input queue, and that there really are only 4096 bytes available.  Using any sort of handshaking will stop data transmission when the buffer is full until you call read, freeing up some space in the input queue and allowing the rest of the string to be transferred.  I don't know what the terminal spy is doing, but it is plausible that it is reading all characters as soon as they arrive, allowing the full string to be incrementally read in.

Try setting the input queue size to something larger than 4096 in OpenComConfig and see if this increases the number reported by GetInQLen.  The Input Queue Size parameter help for OpenComConfig recommends that you set the size no larger than 32,767 bytes, but this is probably plenty big enough for most uses.  From the parameter help:

There is no maximum limitation on the queue size. However, some serial drivers have a maximum of 32,767 and give undefined behavior when you use a larger queue size. NI recommends that you use a queue size no greater than 32,767.

LabWindows/CVI passes this number to the Windows serial driver, which might use a different number. For example, the Microsoft serial driver imposes a minimum input queue size of 4,096 and requires that the input queue size be an even number. If you pass an odd number for inputQueueSize, LabWindows/CVI rounds it to the next highest even number.

I hope this helps.

Mert A.
National Instruments

[IEE_newsoft]

Hi everyone,

thanks for your kind help and hints!

In the meantime I succeeded in splitting the data by requesting data portions from the instrument.
I think, this is the more elegant way because my data-string can have a length of up to 55000x80bytes.

Regards...