Thanks to both of you.
What I'm doing is trying to read a string until timeout from a serial port, with no read termination character, but I get an VisaNS generated exception and no data! In other words, if the read times out, an exception gets thrown and no data is available (even though the string was in fact read prior to the timeout).
So I wind up having to use the termination character, then keep reading until a timeout, and then swallow the exception.
My original problem was seeing what looked like a low - level race condition on the read - the source device can issue two messages one after the other, each terminated with a crg rtn.
E.g. FPA1\r\nFPA1 0x123456789abcdef\r\n
We were using an expression like this:
string reply = string.Empty;
try {
do {
reply += _visaInstrument.Read();
}
while (true);
}
// assume it was a timeout, ignore ...
catch { }
where a second read is getting set on the port immediately after the first read terminates.
We sometimes see what looks like an inqueue pointer glitch, with one of the characters getting doubled up towrds the start of the second string. It looks to me like maybe some low level code is trying to recover from the termination of the first read and gets caught by the second read before it cleans up.
We're running as a 64 bit app on Win7 on a fast, 8 core PC with a lot of memory, so there's true concurrency at a low level if any of the serial sw is multi-threaded (our app is single threaded at the point the serial read is performed).
I've added a delay between the reads, and put a retry mechanism in place as well, but I'm curious if you have any reports of such a race in the NI .NET serial SW. I know the CVI serial library and/or the NI Serial driver had a race condition in it at one point a couple years ago, as I recall it was assoiciated with clearing the inqueue and doing a read immediatley afterwards.
Thanks again for your help.
