SerialPort.ReadTimeout is Incorrectly Implemented

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

I am reading binary data returned from a serial device using
SerialPort.Read(). I am finding that only the first byte of the 5 bytes I
requested is being returned due to the way SerialPort.ReadTimeout is
implemented. Using .NET Reflector and sysinternal PortMon I can see that
SetCommTimeouts is being called with ReadIntervalTimeout and
ReadTotalTimeoutMultiplier set to -1 (MAXDWORD). According to the
documentation for the COMMTIMEOUTS structure, this will cause an immediate
return if there are any bytes in the buffer, as I am witnessing. This means
that an incomplete packet is returned. If I set a breakpoint after sending a
packet to the serial device and receiving the response, there is enough delay
for the response to build up in the receive buffer and so the code works as
expected.

The correct SetCommTimeouts settings should be ReadIntervalTimeout and
ReadTotalTimeoutMultiplier set to 0. I previously implemented communications
with my serial device in C++ and these settings work as expected.

My first thought for a workaround was to use pinvoke to call
SetCommTimeouts, but the com port handle is internal to SerialPort.

Can anyone suggest another way around this? I don't want to have to resort
to receiving one byte at a time and using a timer as this rather defeats
being able to read multiple bytes with SerialPort.Read().
 
Brian Logan said:
SetCommTimeouts, but the com port handle is internal to SerialPort.
Click to expand...

Ach, and the handle's not even available as a protected property. Yuck,
broken. At one time, GotDotNet hosted an early version of the SerialPort
class (similar public interface anyway). Looks like going back to that might
be an option until 2.1 ships.

MSFT/MVP: Whereto file this type of bug (BCL doesn't act as it should)
 
Hi,

I'll have to take a look at this problem. However... DesktopSerialIO from
my homepage implements the timeout correctly, and the handle IS exposed,
so... (it's free). I prefer my implementation do to its simplicity.

Dick

--
Richard Grier (Microsoft Visual Basic MVP)

See www.hardandsoftware.net for contact information.

Author of Visual Basic Programmer's Guide to Serial Communications, 4th
Edition ISBN 1-890422-28-2 (391 pages) published July 2004. See
www.mabry.com/vbpgser4 to order.
 
dls said:
MSFT/MVP: Whereto file this type of bug (BCL doesn't act as it should)
Click to expand...

Sorry, could you please elaborate on that? Do you mean I should report this
as a problem somewhere else? Is there an official place to report such
problems?
 
Hi Brian

I am having the same problem,i would be more then happy to hear if you solve
this issue.
For unknown reason Microsoft prevented the access to all Timeouts parameters
which Win32 exposes.
Are you familiar with other source code allowing asynchronous serial
communication?




Regards
Shay

(e-mail address removed)
 
Back
Top