OpenComConfig sets wrong baud rate

[rorOttawa]

- WinXP 

- CVI 9.0.1

- sealevel 7904 compact PCI

- COM1 on motherboard

When I open a port at 115200 baud it actually opens at 9600 baud.

My software uses OpenComConfig(115200) but the serial port ends up being opened at whatever

the "operating system setting" is for that port in the control panel.

This does not happen when using hyperterm

As soon as the INVALID PARAMETER(Line 10 below) is detected the port is REOPENED at the system settings instead of my  bad = OpenComConfig (port, "", 115200, 2, 8, 1, 50000, -1);
 No error is returned by this function.

Port Monitor Activity for OpenComConfig()  captured for the serial port is:

0 0.00021036 84615u.exe IRP_MJ_CREATE Seacom2k10 SUCCESS Options: Open  
1 0.00000391 84615u.exe IOCTL_SERIAL_GET_BAUD_RATE Seacom2k10 SUCCESS  
2 0.00000279 84615u.exe IOCTL_SERIAL_GET_LINE_CONTROL Seacom2k10 SUCCESS  
3 0.00000279 84615u.exe IOCTL_SERIAL_GET_CHARS Seacom2k10 SUCCESS  
4 0.00000251 84615u.exe IOCTL_SERIAL_GET_HANDFLOW Seacom2k10 SUCCESS  
5 0.00001117 84615u.exe IOCTL_SERIAL_SET_BAUD_RATE Seacom2k10 SUCCESS Rate: 115200 
6 0.00000670 84615u.exe IOCTL_SERIAL_SET_RTS Seacom2k10 SUCCESS  
7 0.00000643 84615u.exe IOCTL_SERIAL_SET_DTR Seacom2k10 SUCCESS  
8 0.00000475 84615u.exe IOCTL_SERIAL_SET_LINE_CONTROL Seacom2k10 SUCCESS StopBits: 1 Parity: EVEN WordLength: 8 
9 0.00000307 84615u.exe IOCTL_SERIAL_SET_CHAR Seacom2k10 SUCCESS EOF:0 ERR:ff BRK:ff EVT:0 XON:11 XOFF:13 
10 0.00000251 84615u.exe IOCTL_SERIAL_SET_HANDFLOW Seacom2k10 INVALID PARAMETER Shake:1 Replace:40 XonLimit:5000 XoffLimit:5000 
11 0.00000251 84615u.exe IOCTL_SERIAL_GET_BAUD_RATE Seacom2k10 SUCCESS  
12 0.00000223 84615u.exe IOCTL_SERIAL_GET_LINE_CONTROL Seacom2k10 SUCCESS  
13 0.00000251 84615u.exe IOCTL_SERIAL_GET_CHARS Seacom2k10 SUCCESS  
14 0.00000251 84615u.exe IOCTL_SERIAL_GET_HANDFLOW Seacom2k10 SUCCESS  
15 0.00001062 84615u.exe IOCTL_SERIAL_SET_BAUD_RATE Seacom2k10 SUCCESS Rate: 115200 
16 0.00000670 84615u.exe IOCTL_SERIAL_CLR_RTS Seacom2k10 SUCCESS  
17 0.00000643 84615u.exe IOCTL_SERIAL_SET_DTR Seacom2k10 SUCCESS  
18 0.00000419 84615u.exe IOCTL_SERIAL_SET_LINE_CONTROL Seacom2k10 SUCCESS StopBits: 1 Parity: ODD WordLength: 8 
19 0.00000307 84615u.exe IOCTL_SERIAL_SET_CHAR Seacom2k10 SUCCESS EOF:0 ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 
20 0.00000475 84615u.exe IOCTL_SERIAL_SET_HANDFLOW Seacom2k10 SUCCESS Shake:1 Replace:0 XonLimit:2048 XoffLimit:512 
21 0.00000251 84615u.exe IOCTL_SERIAL_GET_BAUD_RATE Seacom2k10 SUCCESS  
22 0.00000223 84615u.exe IOCTL_SERIAL_GET_LINE_CONTROL Seacom2k10 SUCCESS  
23 0.00000223 84615u.exe IOCTL_SERIAL_GET_CHARS Seacom2k10 SUCCESS  
24 0.00000251 84615u.exe IOCTL_SERIAL_GET_HANDFLOW Seacom2k10 SUCCESS  
25 0.00001006 84615u.exe IOCTL_SERIAL_SET_QUEUE_SIZE Seacom2k10 SUCCESS InSize: 50000 OutSize: 0 
26 0.00000279 84615u.exe IOCTL_SERIAL_SET_TIMEOUTS Seacom2k10 SUCCESS RI:-1 RM:0 RC:0 WM:0 WC:0 
 

[ebalci]

Maybe the problematic parameter is the Input Queue Size (50000 in your code).

NI's online help for OpenComConfig says:

"... 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 ..." 

[Mert_A.]

Everything between (and including) lines 1 and 20 appear to be resulting from a single SetCommState Win32 SDK call in the implementation of OpenComConfig. It appears that when an invalid option is passed, the port is reset with the default settings, as defined by the system. I agree with ebalci's point about your specified queue size being too large. This could be causing the invalid parameter error, because the XON/XOFF handshaking limits are computed as 10% of the queue size.

You have stumbled upon a bug in the implemention of OpenComConfig, though, in that it should be returning an error instead of leaving the port open with the default settings. I have created a bug report for this (201013). Thanks for pointing it out!

Mert A.

National Instruments

[rorOttawa]

- WINXP

- CVI6.0

The problem is that 10% of the buffer can not be any greater than 4096

So that puts the max buffer size at 40960 bytes

50 0.00000335 IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:1 Replace:40 XonLimit:4096 XoffLimit:4096 

70 0.00000140 IOCTL_SERIAL_SET_HANDFLOW Serial0 INVALID PARAMETER Shake:1 Replace:40 XonLimit:4097 XoffLimit:4097 

So this problem has been there as far back as CVI6.0 or it may have appeared due to WINXP.

I will post results for win2000.

[Mert_A.]

If you are using handshaking, do you really need such a large buffer? Presumably you can read from the buffer at fairly consistent intervals.

Mert A.

National Instruments

[rorOttawa]

why I need the buffer so large is not really the issue here.

2 options:

1) create a large buffer so I can process the data received at a later time.  Easy single buffer serial port.

2) create a small buffer and a task to process the data as it is received. Harder because now I have to double buffer the serial port.

Like you said the function openComConfig() should return an error if there indeed was an error due to too large a buffer size.

The buffer size is limited to some software layer picking 4096 as the max point for xon/xoff. That does not sound correct in this day and age when we have gigabytes available.

If CVI provided an openComConfig() function that allowed us to turn off xon/xoff as an argument would we have this restriction.?

Do we fix the software at the route cause or just work around the bugs?

[Mert_A. · Accepted solution]

Sorry, I think the XON/XOFF limit error mistakenly lead me to assume you were actually using handshaking, but you never indicated that you were. This problem you bring up actually affects opening any port, regardless of if you will use XON/XOFF handshaking. The 4096 limit appears to be imposed by the driver, so it's not something that can be changed in the CVI code layer. However, we can impose a 4096 maximum value for the XON/XOFF limits we pass to the Windows SDK, so that the error can be avoided when you are reserving an input buffer larger than 40960.

We will make both the fixes mentioned in this thread in the next release.

Mert A.

National Instruments

Message Edited by Mert A. on 01-05-2010 12:36 PM

[rorOttawa]

great.

Thanks.

when would we expect to see a fix?

[Mert_A.]

Unfortunately, I can't be any more specific than to say there will be another release in 2010.

Mert A.

National Instruments