Much like what I do when an error comes about. Normally a timeout error, I simply close the port, completely clear and flush out the VISA, then reconnect RS232 communication through my instrument.
The errors aren't completely visible in my case, the data is never transmitted from instrument to computer. The instrument completes what it should and is then ready to move on, but the data is never sent.
I've been observing this thread with some interest because I've been recently seeing a problem with framing errors as well. It all started when the IS department upgraded some old pc's from NT to XP. The serial routine originally written about 8 years ago with VISA, all of sudden started to detect a framing error. It would only happen when the routine was monitoring a product when it was booting up. At all other times, communication with the product was just fine. I've tried all different versions of VISA from 3.0 to 4.0 but the error persists but only on the XP pc's and it happens with both USB->RS232 and built-in serial ports. I did a quick patch to the program to ignore the framing error so that production could continue but today I've been working on it a little more. I used portmon to capture the serial traffic and the error happens when the ASCII Null character is read. I have no idea why this character would cause a problem and my next step is to wade through Microsoft's web site to see what ms might have changed in XP that could affect the serial port and VISA.
I wish I had an answer and if I find anything, I'll post it here.
@Dennis Knutson wrote:
As I mentioned, this only happens on windows xp with code that has been working with no problem for several years.
The product may be sending a serial port break at this time but I'm unable to see this with portmon. I don't know if NI-Spy would see this either but I'll give it a try when I get some time. I really think Microsoft did something with the serial ports in XP but I haven't been able to figure out what yet.
My problem appears to be similar to your problem and I can convey to you the error because you originally helped me with my vi. Maybe I can shed some light unto your problem as well...
A while back you created this vi for me:
For the longest while it was fully operational and giving us the scanning results we needed and had hoped for. To further our testing procedures we created an excutable of this vi (which you helped me with as well) and things started to fall apart from there. The vi was originally created on a computer operating on Windows 2000. The executable was attempted on computers both with Windows 2000 and Windows NT. Some non updated VISA drivers and port failures were obvious problems as to why they didn't work right away, but there on the original vi didn't work on the original computer.
Perhaps some serial port configuration from the other two computers affected the original serial port, but that doesn't make sense because I can still send full commands to the port. I just don't receive any bytes when I perform the scan. The original vi you made for me had a 2 second wait in it. So I tried waits ranging from a few milliseconds all the way to 20 seconds hoping for a byte count to appear, but it never does. The 100 byte count constant causes the Read to timeout, but when I wire in a VISA Bytes at Serial Port I get the 0 byte count going in and the loop never detects the "END" string and is never ending. Could the termination character prevent a byte count from appearing?
Somehow the switching from serial ports messed up my entire process and it holds some similarity to your problems with Windows XP and serial port malfunctions.
Thank you for any help and input,
Message Edited by Steve.Briggs on 02-28-2007 10:57 AM
There is property that can be set via property node called "Serial Settings:Error Replacement Character". The documentation does not directly say what the default is. I suspect that it is a null character. If that is true, your error may be due to a error in the COM port and not the reception of the null character. You might want to try and put a scope on this and verify the actual character that causes the framing error.
\You're right, the replacement character is a null character. I didn't think it was the reception of the ASCII Null that was causing the error. I'm waiting right now to see if the lab in a different building still has a serial analyzer. We had one once upon a time but it may have been moved to our R&D team in another state.
I'm still convinced that there was a change in XP that causes this. I found one reference to a situation where XP might think a serial mouse has been plugged into a com port. I haven't have time to try their recomended fix yet, though.
I just wanted to say thank you for posting the image of the your VI. I was trying to figure out how to consecutively send commands to my motor driver. The string array didn't occur to me.