timeout on rs232 ComRd

[menchar]

I've been seeing inconsistent behavior that I don't understand when using the ComRd function in the rs-232 library.

I wrote the code such that I would expect to always get a timeout on the ComRd - I have a device that I want to flush out all of it's output (around 400 bytes). 

So I just do a ComRd into a big buffer, asking for as many bytes as will fit.

iStatus = ComRd (ComPort, Inbuffer, 1024);

iStatus comes back with, say, 340 (read 340 bytes), then I do

iError = ReturnRS232Err();

The problem is that sometimes ReturnRS232Err() returns 0 (no error), and sometimes it returns -99 (timeout).  I have the com timeout set at 250 milliseconds.  My bit rate is 115200, and the InQueue is 32767 bytes long, and frames are 8,n,1.  No handshaking.

So my question is, if ComRd returns the byte count, not a negative error code, does   ReturnRS232Err()   behave consistently?  If, in fact, a timeout occurred, after a read of some number of bytes (and ComRd returning the byte count), shouldn't    ReturnRS232Err()   always return a -99?

I am not using an async write anywhere.  

Is there some sort of indeterminancy in the rs-232 library?

What is the "right" way to read a message of indeterminate length from a serial port?  I don't have a consistent termination character, or I'd use ComRdTerm as I usually do. 

Thanks for any insight into this.


   

[menchar]

Follow up -

It looks to me as if, for weeks / months at a time, the ComRd() / ReturnRS232Err() consistently returns 0 (no error), then for no discernable reason, it then consistently returns -99 (timeout).

Changing the timeout makes no difference.  Running on a different PC makes no difference.  Running on an NI serial card Vs. some generic built-in com port makes no difference.

The number of bytes burped out of the device varies somewhat, but is from 338 - 400 bytes or so, I'm using a big buffer (10,000 bytes) so we always time out.

Weird.  Maybe broken hardware somewhere.

[Mert_A.]

The expected behavior is that ReturnRS232Err returns -99 if ComRd was the last RS-232 function called in that thread, and it timed out.  Why you're getting 0 out of ReturnRS232Err is a mystery.  I wrote a quick test program that does nothing but try to read 100 bytes from the port (and I have another connected computer that just writes a few bytes), then calls ReturnRS232Err.  I get a return value of -99 every time.

Does the thread write to any ports, or do you have any other threads making RS-232 calls?  Perhaps if there was something going on with the thread local storage used for the error code, other threads might be overwriting the error code, though that's just wild speculation.

Mert A.
National Instruments

[menchar]

Thanks Mert.

I've been befuddled with this problem for some time - I suspect it's something changing in the device that's triggering the altered behavior in the library.  I have 10 devices, on ten different systems, that seem to be getting a non-error status on the timeout. And one that does consistently return a timeout as you say they all should.

It's almost as if a termination character is being recognized somewhere in the input stream, even though I'm using ComRd not ComRdTerm.

I'm reading into a char buffer (windows type LPSTR) - there may be embedded nuls in the incoming stream - I wouldn't think that would somehow goof it.

And it could be behavior in the driver, not the NI rs-232 library that's triggering this.  But, we've seen this both on an NI serial card (NI kernel mode driver) as well as generic PC com ports.

If I figure this out I'll post it.

Thanks again Mert.

[Mert_A.]

ComRd will only return when 1) the requested number of characters have been read, 2) the read times out, or 3) some other error occurs.  Clearly, we're not in case 1, and in case 3, a negative error code is returned.  I would suspect something is going on with setting (in ComRd) or retreiving the error code (in ReturnRS232Err).  It is a bit paranoid, but you can run the attached CVI program (rename it to .exe) which tests the Windows thread local storage functions.  If something isn't right, you'll get a popup about it.

Let me know if you make any discoveries.

Mert A.
National Instruments

[menchar]

Mert -

This may be mostly pilot error after all. 

The code that's been working for months on 12 systems, in fact, does normally get a char count from ComRd and a -99 timeout error on ReturnRS232Err().

And I'm getting a -99 error now, with the unit that appears to not be working.

So it's something else, I'll have it run to ground shortly.

I hate when this happens.

menchar

[ebalci]

I have similar problems with ComRd.

In the function help, it says it returns a negative error code if it fails and timeout is -I suppose- one of the error conditions.
However, ComRd returns 0.

Ideally, the return value of ComRd states the number of bytes read from the port. So, having timed out (without getting any data into the port) it is reasonable to return 0.
But in this case the help text is misleading.

In my case ReturnRS232Error() operates consistently but I think the help text and the behaviour is inconsistent.

Any comments?

[scomack]

My help states:

"On a timeout, ComRd returns the number of bytes actually written and sets rs232err to -99."
Timeout, in and of itself, is not an error that causes a return value to be set.  In your case, there are no bytes to be read, so it times out and returns Zero to state that no bytes were read.
If you do not want to sit there for your timeout period, you can make a call to      GetInQLen (int COMPort).  If it returns zero, there is no reason to read the port.