You might want to check if you're getting "garbage" characters in the InQueue (including CR's) that cause a return without the expected data. Some devices when you power them on will emit characters on a serial port that are meaningless.
You can flush the Inqueue, I've had issues with that function and now I just probe the InQLen and just read all the data that's in the queue. If your device is in the mode of continuously emitting messages with the terminator, this can be a problem - how to get exactly the right message and not pieces of other messages.
You might want to verify that you're not timing out the first couple of times you try to read. I see you hard coded the opencomconfig to com 5, is your timeout being set for that same port? The bit rate is just that, the rate at which a frame of data is emitted from the sending port - but the timeout is for the time until the first byte appears and then the time in between bytes. If any of these times exceeds the timeout, you'll get a timeout return. A device configured for a specific baud rate doesn't mean it will emit frames at some rate - it just means that the bits in the frame will get emitted at the configured bit rate. A perfectly fine 57600 bps message may take an arbitrarily long time to receive, depending upon the time until the first frame, and the time between frames.
You could just code a loop with ComRdByte that loops, reading every byte available until it sees the CR. Stupid and inefficient, but it might allow you to see if there's anything in the incoming stream that you didn't expect.
Menchar
