Run-time error '8020' Error reading comm device

hi,

how to solve Run-time error '8020' - (Error reading comm device )

any ideas?

thanks

Please show how you have declared the connection and how you are attempting to open the port

Also check this out

http://support.microsoft.com/default...b;en-us;318784

hi,

This is my port setting procedure. Is anything wrong?
Some times i'm getting " Set comm state failure error" too.

Private Sub Form_Load()
With MSComm1

.CommPort = 1
.RThreshold = 1
.Settings = "38400,n,8,1"
.InputLen = 0
.SThreshold = 1
.InBufferCount = 0
.OutBufferCount = 0
.PortOpen = True
End If

MSComm1.Output = Chr(65) + Chr(80) + Chr(48) + Chr(13)
End With

Waiting for ur suggestions.
Thank you.

There's nothing obviously wrong with the way you are handeling the port. However it may be worth check the Device instructions to ensure that you are using the right kind of 'handshaking'.

Set comm state failure error - often occurs when the 'handshake' is in-correct.

i.e. you might be using odd parity when it should be even.

OK, I know this has been a long time ago. but.... I am using VB5 and have had very good luck with my past Serial comms to 10-20 different RS-232 devices (including USB CDC devices). NOW.. I have a new device to talk to, a "NovAtel GPS systems" ,and my comm problems are the Runtime error 8020. Hyperterminal works fine, but any demo, sample, example, including -my existing Comm programs do not work.

If anybody is still out there monitoring this thread, what do you suggest? I have even thought about using Hooks into Hyperterminal DLL to see if I could get something to work.

Thanks
Keith

Well, get rid of VB5 for one thing. VS2010 is out, and the Express versions are FREE

OK, I tried that, now... all my existing code doesn't load under VB2010. I can not expand my current VB5 programs into VB2010. Am I gonna have to re-write all my existing code to make it run under 2010? Not very efficient.


Also, is there any simple COM terminal examples that I can build off of, since MSComm is gone, but Serial seems to be what to use in 2010.

Keith

Even VB6 isn't upward compatible, in most cases. You're still better off re-writing in most cases, to utilize the newer features of the Net Framework.

It's not hard to open a port in VB.Net. See MSDN, and the link in my signature for 101 Samples

I have written a quick COM program that seems to be working ok. now.... quick question:

What is the equivalent to VB 'unload'? This gets called when there are things you want done when the program quits.

I tried me.close() and me.dispose() but I get errors on each of these.

I want the program to stop running and self terminate - quit when it is done... any ideas?

Keith

Write a CONSOLE app to call the COM and exit

Quote:

---

Originally Posted by ch701builder

What is the equivalent to VB 'unload'? This gets called when there are things you want done when the program quits.

I tried me.close() and me.dispose() but I get errors on each of these.

---

Me.Close is one of the correct methods.. however you have to ensure that you wrap up everything before you issue it ...

IE: Stop all timers. Release all bound objects, Close the Com port, etc ...

Sometimes the easiest answer is the solution. Let me tell at the begining that, I've solved the problem. That is the story:

I have tried lots of things, but when I was talking to a friend about my problem (who knows nothing on computing and VB6), he told me "I used to use a BIOS setting in older PCs, not to halt on any error such as no diskette driver, no keyboard, don't you have a command like that. OK there is an error but don't care about it, don't warn me about it, don't stop even if there are errors".
Yes, what he was talking about is the easy, old, sweety "On Error Resume Next" statement!!!

I hvae used it and my programs started to communicate via MSCOMM32 as they used to.

You should better use "On Error Goto" and "Err.Number" to trap other errors instead of this 8020 error. May be there is a real error, may be the USB to RS232 cable disconnected etc.

And second warning, sometimes On Error Resume Next inludes the subroutines, sometimes it takes a lot of time to understand what is going on (and what is not going on) in your code when you use On Error Resume Next. So, copy your communicating lines to a sub, put an On Error Resume Next at the begining of this sub and call this sub when you need to comminucate devices via MSCOMM32.
I hope this will be helpful...

Given that the question in the OP was asked 11 years ago I doubt they are still looking for an answer.

And yes it is better to use On Error Goto and a proper error handler rather than On Error Resume Next unless you are also coding to check the error number in line so as to know when an error occurs. There are also several other things that you can test to insure things are correct and give the user a better idea of an issue. The CD signal, DSR and such for example.

Quote:

---

Originally Posted by DataMiser

Given that the question in the OP was asked 11 years ago I doubt they are still looking for an answer..

---

Yes it is a 11 years old question and I am sure that it will be helpful in 2026, too. Visual Basic 6 and Windows XP will never die.

VB6 forever!!!!

XP is pretty much dead already, much of the newer hardware will not be offering XP drivers and thus will not work so to stay with XP you would be forced to use an old PC or a VM and even those will not be an option forever.

Using an error trap is always a good idea when dealing with a piece of code that may not work, That does not really address either question in the thread. The first one requires the user to get to the bottom of what is causing the error and correct it. The second one is a totally different question and the answer is actually in the question ;)

In future try not to dig up buried threads