VISA Serial Error -1073807312 user abort occurred during transfer

[NickNZ]

VISA read serial port is randomly generating the Error -1073807312 (Hex 0xBFFF0030) User Abort occurred during transfer.

How do I fix this problem? I don't know what is causing the serial read to abort. I have LabVIEW 6.02 and Win 2K.

I am receiving ASCII nibbles with STX and ETX to indicate start and stop characters. I have initialized the serial port so the termination character is ETX. For the byte count input I just add 100 to the number of bytes I expect to receive.

When this error occurs it also seems that the VISA name ends up blank.

Thanks for your help in advance.

[Ben]

I can not give you a straight out answer to this question. I have never run into that error before.

Could you post a copy of your code for us to look at?

I am a little concerned about how you are handling the protocol.

Are you using the "VISA Configure Serial Port.vi"?

There are a number if paramaters that need set and that VI covers the basics.

You did not mention DLX. When I have seen STX and ETX in a protocol, DLX was also included. If you are using DLX then the driver get a bit more complicated because you can not predict ahead of time how many bytes to read and you cannot use the built in termination character feature of VISA without adding extra code to determine if the ETX was a real ETX or if it is embedded data.

Just guessing now,

Ben

[NickNZ]

Thanks Ben

The code I am running has worked in the past OK. I wrote the code middle of last year when I was still new to programming in LV. It is being used to get serial data from one of our products for production testing. I have just had to quickly modify the testing code for a similar product and this error has occurred (I haven't changed the serial VI's). I cannot see anything wrong with what I am doing so I was wondering if anyone else had the same problem. (I searched ni.com and found nothing...). I don’t believe it’s my software.

I have got you confused as to which method of Data Transfer the UUT sends out. There are two methods, one as you mentioned uses a character to identify control values (you mentioned DLX? – guess you m
eant DLE though it doesn’t matter) so to start a transmission DLX STX is sent then the byte values 0-127 and then DLX ETX to end. To send the value of DLX, DLX is sent twice. So you cannot predict in advance how many characters to receive.

The other way that we are using is to send ACII nibbles. Here bytes are sent as two ASCII characters in hexadecimal representation. So STX is sent first. Then each byte of data is sent as 2 ASCII characters (0-1 A-F). Then ETX is sent. Then you don’t have to worry about DTX. The advantage is that you can view the data in HyperTerminal, although it is less efficient (STX ends up as a heart and ETX as a smiley face). Our product sends out the same number of bytes each time (though this number can vary between products). As I wanted the VISA read to return after ETX was received, I wire to the bytes a number I was expecting plus 100 to make sure it didn’t return before ETX was received. It makes it easy in LabVIEW too as you just
strip off STX and ETX and then use string to hexadecimal number.

Yes I am using VISA configure Serial port. I forgot to mention I have VISA 2.6.

[Ben]

OK,
It looks like you have that covered.

Yes, DLE (Data Link Escape). I probably confused my protocols.

Forget my previous ideas.

I can not say I have seen that error, exactly.

So,
does your previous code still work with the previous DUT?

The VISA resource going away is strange. I did see a similar thing where I just could not get the com ports to show up on a couple of machines that had some sort of security software running on it. Same code ran on other machine no problem. In that case if I attempted to select the com port LV would hang big time.

I don't know if that does you any good.

I believe VISA has been updated, that may help.

I think that trying your old code with the other DUT would help rule out the serial por
t or its driver being bad.

When you figure it out, please post what you find.

Ben

[NickNZ]

This is a weird bug. It went away last Friday (Maybe the reboot of the computer helped), but I didn't do anything obvious to fix it in my software.

I have the latest version of VISA.

I tried the code on another computer and it came back, but then went away again. But it gave me a hint that it may be something to do with the error cluster. On the other computer I hadn't installed an OPOS scanner driver for a Symbol USB barcode scanner. (I use ActiveX to interface with the barcode scanner.) After the install of the scanner driver and a reboot it worked fine. So when I have time I will have to experiment.

[NickNZ]

According to an NI engineer, user abort during the data
transfer ( VI_ERROR_ABORT) could be caused by a loose cable/ connection. Which is possible, but I haven't been able to check this.

I found my software was causing the VISA name to be cleared when an error occurred.

Thanks everyone.
Nick