Serial read issue

[mike]

I am currently automating a manual test procedure for one of our
system boards using LabWindows and it uses the serial port as the
means for communication for running tests via a CLI interface. I have
the communication working and I dont have any issues with transmitting
the test commands, but I am not very happy with the funtion that reads
the return responses. There is no standardization in the response
messages sent back from the test board after sending a test command
such as the length of the return strings as part of the message and
the messages can be short with a termination prompt or multilple line
messages with fluctuating message returns and sizes that require a
carriage return to end the test. This makes it very difficult to
capture the return responses. Has anyone had to tackle this type of
serial communication where the length and return responses fluctuate
in size and termination and if so, can they make any recommendations?
If need be, I can also post the function that I am using that works,
but it has potential problems and I would like to improve on it.
Thanks for any help that can be offered.

[scomack]

If you are just worried about CAPTURING the return, I would use the plain command

ComRd( port, buffer, count).

Set count (and your buffer size) sufficiently large enough to hold the largest possible response from your board.  You can then parse it on your own.

If you are worried more about PARSING the response, I would need more information.

[menchar]

I've dealt with this issue on a few occasions.

Note that ComRd and ComRdByte, and ComRdTerm will spinlock (busy wait) for incoming bytes and use all available cpu bandwidth. 

You could either probe the inqueue with GetInQLen() or use the com callback mechanism to avoid spinlocking on com reads if that's a problem.  If your app (or any other app on the system) doesn't have anything else it should be doing then this technique may be OK.  It's certainly easy to implement.  Note that you should always get a timeout (-99) status, and that you should set the timeout value to something that makes sense for your application.

You might want to flush the inqueue when you start your app - poorly implemented devices can put out garbage on their serial ports when they are powered up.

rs-232 just isn't a robust scheme compared to IEEE 488 (GPIB) for instance.   GPIB defines low level messages and mechanisms for handling arbitrary length messages (the EOI uniline command), clearing the interface, clearing the device, flow control, etc.