We have the same problem too with Error 8020. We're using Microsoft's USBSER.SYS device driver under Windows 10. This driver should allow a VB application (indeed any application) to communicate via a virtual COM port to an external device. In our case, that device is PIC processor sending ASCII characters at a modest data rate through a Microchip MCP2200 chip into a usb port on the PC. This equipment and application software works fine under Windows XP (SP3+) and Vista and Windows 7 and Windows 8.0 and Windows 8.1 - all of them - but not under Windows 10. This is an operating system issue that we think concerns Microsoft's USBSER driver for Windows 10.

Would jdig77 and orderinn_ltd above please clarify if they are using a 9-pin DB9 hardware COM port or a USB virtual COM port when they encountered error 8020, and if it was a USB port then the device or chip that they plugged into that USB port, and whether both people are using the MSComm control. We have tried our very same application using a serial-to-usb converter cable made by FTDI which uses a FTDI (non-Microsoft) driver instead of having an MCP2200 chip sit in between the PIC and the PC. This combination works under Windows 10 without any error 8020. Under Windows XP to Windows 8.1, we would have to manually install (associate) the Windows USBSER driver with our hardware by installing an INF file. That's not the case under Windows 10 'out of the box version' which seems to know about the MCP2200 chip already. We simply plug in our hardware and *immediately* it appears as a virtual COM port in Device Manager without having to install any INF file.

Jan 27, 2016. To handle the packets and move data in and out of the program accessing the USB device, a software driver is needed. The software driver sits. A poorly constructed cable could have components that fail in a short period of time—perhaps even by the time you receive the cable. I have seen several cases.

This is a significant difference in the behaviour in Windows 10 compared to all previous versions of Windows back to XP and therein likely likes the problem. My expectation is that Windows 10 is not configuring its built-in USBSER driver for some mode in which the MScomm control is working in VB. We've seen this kind of thing before. Years ago we used a Prolific serial-usb adaptor cable with a Prolific driver. Suddenly quite out of the blue this stopped working, you've guessed, with error 8020. This was due to a new Prolific driver being installed over Windows Update. We got rid of that unwanted update and it then worked again.

Eventually Prolific issued a newer driver that did work, but by that stage we had switched to FTDI's product. So, this was a driver issue, where one particular version of Prolific's driver did not support some operating mode of MSComm. We've tried re-installing the device driver for our USB device from Device Manager in Windows 10, using an INF file for our chip's particular VID/PID, and we still get Error 8020 in VB, and windows continues to use it own driver and info - ignoring the settings that we've supplied in our INF file. As our app is built on Microsoft's VB platform, the USBSER driver producing error 8020 is a Microsoft driver, and MSComm is a Microsoft control, and Microsoft has made the recognition of a MCP2200 chip automatic in Windows 10, we thank you in anticipation of Microsoft looking into this. I’m not 100% sure it’s only a Microsoft problem. Let me explain.

My students used to make an interface based on an USB stick from piccircuit.com (iCP12) It works with all Windows version accept version 10. The com port is found, but when connecting the error appears. (run time error 8020) A driver for this stick can be downloaded from their site. I contacted piccircuit and they offered the working source code, but only with Visual Studio, not VB6.

However the same kind of interface based on an Arduino (Nano) and almost the same software works just fine under Windows 10. So I think the problem is a bit more complex. I would of course appreciate it when a solution can be offered. We are experiencing similar if not same problem with a PIC18F14K50 USB Module to a VB6 application isolated to Win 10 OS.

Driver versions 5.1.2600.2 and 5.1.26009 work with above USB module and VB6 application on Win XP, 7 and 8.1, but again not on Win 10. The Microchip PIC USB module using these drivers on Win 10 'does' work with non-VB6 applications. Note, above VB6 application works on Win 10 PC with Keyspan USB module and its driver. This run-time error has occurred on every PC tested thus far, potentially in the dozens, hence the isolated Win 10 bug claim.

This issue is critical to our business as our clients aren't able to use our product on Win 10 forcing us to purchase and install older Windows for compatibility. This issue is critical to our business as well. We too are not able to sell our existing products to Win 10 customers. This is forcing us to consider abandoning the Microchip MCP2200 USB chip and find some other way to interface our designs to the Win 10 / VB6 environment using some competitor USB chip that uses a non-Microsoft USB driver.

We do not see simply ignoring Windows 10 as a viable long-term strategy even if Windows 10 itself is the root cause of our difficulties with Error 8020 arising in our VB app. And so we'd like the Windows 10 USBSER device driver to be fixed so it that works just like the XP through 8.1 versions of it do. We would be grateful for any sort of response from Microsoft please. Strange to read you’re having problems with the Arduino. On a 5 year old HP DV7-2180ED Windows 10 32 bit no problems with 2 different Arduino’s. Just tested it on a Surface 3 Pro Windows 10 64 bit also no problem with an Arduino Nano.

I’ve written test software for the Arduino and it works on everything I’ve tried. Print Screen Free software download (.ino file in INO folder) The iCP12 with a 18F2550 doesn’t work with Windows 10. I’ve searched Microchip.com for a new driver but didn’t find anything.

Sure it’s a problem with Windows 10, but in my opinion it could also be related to the supplied driver for the Microchip PIC family. Still hope to activate Micro (chip) and/or (soft) to see this is a serious problem.

WOW, it's working! I am trying again the sending/receiving data on serial port. I have an ASCII char controlled measuring instrument. Sorry.I forgot one thing.my code is based on writing the data readed by the serial port every time you press a button and this button sends the information to the serial port, but the the macro always write data in the same line at same cells and I wanted it to write the information on line 1, when I press the button again it writes on line 2 etc.

Until I used a button to stop the information sent and received in serial port. Function Write_and_Read(OutputStr as string) as String Dim f as object Dim i as integer Dim linha as integer Dim Doc As Object Dim Sheet As Object Dim Cell As Object Dim OutputChar, InputStr as String oFSO = createUnoService('com.sun.star.bridge.OleObjectFactory').createInstance('Scripting.FileSystemObject') ' READING: Doc = ThisComponent Sheet = Doc.Sheets('Sheet1') CellA = Sheet.getCellRangeByName('A1') CellB = Sheet.getCellRangeByName('B1') CellC = Sheet.getCellRangeByName('C1') f = oFSO.OpenTextFile('COM4:9600', 1) 'for Reading Wait(3500) 'NEEDED a timing! (Maybe it is instrument specific value.) Write_and_Read = f.read(30) '10 character will be readed (Not works if I try read 15 chars! Works if I read less than 10 chars, but the answer will be truncated) col = 1 CellA.string = Mid(Write_and_Read, 1, 7) CellB.string = Mid(Write_and_Read, 8, 7) CellC.string = Mid(Write_and_Read, 15, 7) f.close End Function 'line1', 'line2'.

Means: 'row1', 'row2'. In spreadshhet, or number of serial ports (number of instruments)?

You connect only one instrument to your PC? The instrument is a slave, and your PC is a master? (Request-Answer mode?) my suggestion: If you use only one button, you need use an integer type global variable. Increment it when a data received. Program Laporan Keuangan Sederhana Kemang. Use 'Select case' command to write data separated into destination cells. Reset the variable to start value, when the incremented value >= max.

You can use the same variable for the synchronization the questions (write the serial port) and responses (read the serial port). (First request ->First answer ->Put into First cell.) If you use three button: Write three functions with 3 different output cell controlling. Assign to every button one of three functions.

This method does not require synchronization. Maybe you need write SUB(s), not FUNCTION(s). (and read: post by rudolfo » 2010 Jun 21, 7:34 pm in ). Dear migalhas and Zizi64. Thanks for this interesting information. I am also trying to use the serial port using createUnoService('com.sun.star.bridge.OleObjectFactory').createInstance('Scripting.FileSystemObject') I am factory testing a serial port device by sending it some text and checking that it was echoed back.

So I need to read and write and most important and I need a way to recover if the device under test does not respond with in a second or so. My current read routine simply hangs waiting for the device under test and I have to reload the test. My guess is that there is some sort of time out for the serial port but I have no idea how to set it and how to detect an error due to time out. Suggestions would be appreciated. Dear Tibor Kovacs, Thanks for replying.

Regarding why, 'Why you are want to use the OOo for this task', I thought with a name like basic it would be easy to program (from my days programing in the old DOS BASICA) It never occurred to me that the serial port would be so impossibly hard to use. Unfortunately, We already have invested quit a bit of effort into our OO.org solution which works but slowly and error prone buy shelling out to other programs. I have searched around hoping to find an open source software instrument control / factory test project with out success. So we started with what we had, OO.org basic/macros.

Thanks again, Forrest Erickson. Note that carla23 is doing this on Mac OSX with a BSD Unix based core operating system. On Unix everything is a file, the serial port is just another file with a file descriptor. Unix support blocking and async writing and reading from files (including serial devices). For MS WIndows this is completly different. Serial ports have their own API that you need to use when accessing data on the serial port.

The write command and the read command of Basic (or the one of the Scripting Filesystem Object) are following the old DOS convention of special files COM1, PRT, etc. DOS and asynchronous are a contradiction. In other words with Basic async I/O is not possible. I don't think that the devs have any motiviation to extend OOo Basic with async I/O, because if you need asynchronous I/O you can always swap to one of the other 'adult' macro languages like Python or Java that support this. Thanks for helping me understand what the limitation are against which I am bumping. Regarding, 'if you need asynchronous I/O you can always swap to one of the other 'adult' macro languages like Python or Java that support this.' I have developed some Python scripts to write and read back from the serial port using Python, IDLE and the serial python library pySerial.

But then I could not figure out how to get them to work as macros from OO.org Basic. I could call them, but they would error out on the 'import pySerial' command.

I assume it is because I some how have to add pySerial to the OO.org Python installation or provide a path name. Is it even possible to 'import pySerial' to the Python integrated with OO.org basic?

ForrestErickson wrote.But then I could not figure out how to get them to work as macros from OO.org Basic. I guess you mean calling them from OpenOffice.org.

Calling a pyhton macro from within the code of a Basic macro doesn't make much sense. Actually if you are saying that you get an error in the line 'import pySerial', this error comes from the python interpreter and it surely indicates that you could successfully start the interpreter. Or in other words: you could run a python macro. So as you guessed your problem is that the python runtime that is included in OOo doesn't have the pySerial module or library. It shouldn't be too difficult to locate the python library directory within the OOo installation directory. Just search for.py or.pyc files.

If the major version of the python interpreter of OOo on the one installed directly in the OS is the same copying the files of the pySerial module into the python directory of the OOo installation has good chances to work. You can search this forum for python and modules. I remember two or three threads discussing this constellation of two coexisting python installations. If the search doesn't help, maybe browse through the posts of the user hanya.