> I am able to open port COM4 with Terminal emulator.

> So, what can cause PySerial to generate the following error ...

> C:\Wattcher>python wattcher.py
> Traceback (most recent call last):
>    File "wattcher.py", line 56, in <module>
>      ser.open()
>    File "C:\Python25\Lib\site-packages\serial\serialwin32.py", line 56, in
> open
>      raise SerialException("could not open port %s: %s" % (self.portstr,
> ctypes.WinError()))
> serial.serialutil.SerialException: could not open port COM4: [Error 5]
> Access is denied.

>> I am able to open port COM4 with Terminal emulator.

>> So, what can cause PySerial to generate the following error ...

>> C:\Wattcher>python wattcher.py
>> Traceback (most recent call last):
>>    File "wattcher.py", line 56, in <module>
>>      ser.open()
>>    File "C:\Python25\Lib\site-packages\serial\serialwin32.py", line 56,
>> in
>> open
>>      raise SerialException("could not open port %s: %s" % (self.portstr,
>> ctypes.WinError()))
>> serial.serialutil.SerialException: could not open port COM4: [Error 5]
>> Access is denied.

>     Are you trying to access serial ports from a virtual machine?
> Which virtual machine environment?  Xen?  VMware? QEmu?  VirtualBox?
> I wouldn't expect that to work in most of those.

>     What is "COM4", anyway?   Few machines today actually have four
> serial ports.  Is some device emulating a serial port?

> John Nagle

>>> I am able to open port COM4 with Terminal emulator.

>>> So, what can cause PySerial to generate the following error ...

>>> C:\Wattcher>python wattcher.py
>>> Traceback (most recent call last):
>>>    File "wattcher.py", line 56, in <module>
>>>      ser.open()
>>>    File "C:\Python25\Lib\site-packages\serial\serialwin32.py", line 56,
>>> in
>>> open
>>>      raise SerialException("could not open port %s: %s" % (self.portstr,
>>> ctypes.WinError()))
>>> serial.serialutil.SerialException: could not open port COM4: [Error 5]
>>> Access is denied.
>>     Are you trying to access serial ports from a virtual machine?
>> Which virtual machine environment?  Xen?  VMware? QEmu?  VirtualBox?
>> I wouldn't expect that to work in most of those.

>>     What is "COM4", anyway?   Few machines today actually have four
>> serial ports.  Is some device emulating a serial port?

>> John Nagle

> Thanks, and yes, I am using VirtualBox.  My laptop does not have a serial
> port so
> I use a USB-to-serial converter, which is assigned COM4.

> "John Nagle" <na...@animats.com> wrote in message
> news:jse604$1cq$1@dont-email.me...
>> On 6/26/2012 9:12 PM, Adam wrote:
>>> Host OS:    Ubuntu 10.04 LTS
>>> Guest OS:    Windows XP Pro SP3

>>> I am able to open port COM4 with Terminal emulator.

>>> So, what can cause PySerial to generate the following error ...

>>> C:\Wattcher>python wattcher.py
>>> Traceback (most recent call last):
>>>    File "wattcher.py", line 56, in <module>
>>>      ser.open()
>>>    File "C:\Python25\Lib\site-packages\serial\serialwin32.py", line 56,
>>> in
>>> open
>>>      raise SerialException("could not open port %s: %s" % (self.portstr,
>>> ctypes.WinError()))
>>> serial.serialutil.SerialException: could not open port COM4: [Error 5]
>>> Access is denied.

>>     Are you trying to access serial ports from a virtual machine?
>> Which virtual machine environment?  Xen?  VMware? QEmu?  VirtualBox?
>> I wouldn't expect that to work in most of those.

>>     What is "COM4", anyway?   Few machines today actually have four
>> serial ports.  Is some device emulating a serial port?

>> John Nagle

> Thanks, and yes, I am using VirtualBox.  My laptop does not have a serial
> port so
> I use a USB-to-serial converter, which is assigned COM4.

>>>> I am able to open port COM4 with Terminal emulator.

>>>> So, what can cause PySerial to generate the following error ...

>>>> C:\Wattcher>python wattcher.py
>>>> Traceback (most recent call last):
>>>>    File "wattcher.py", line 56, in <module>
>>>>      ser.open()
>>>>    File "C:\Python25\Lib\site-packages\serial\serialwin32.py", line 56, in open
>>>>      raise SerialException("could not open port %s: %s" % (self.portstr,
>>>> ctypes.WinError()))
>>>> serial.serialutil.SerialException: could not open port COM4: [Error 5]
>>>> Access is denied.

>>> Are you trying to access serial ports from a virtual machine? Which
>>> virtual machine environment?  Xen?  VMware? QEmu?  VirtualBox? I
>>> wouldn't expect that to work in most of those.

> Then it is a Virtual COM port. Often software will want to
> communicate directly to the COM4 port which is usually at: IRQ3 and
> I/O 2E8h.

>>>> I am able to open port COM4 with Terminal emulator.

>>>> So, what can cause PySerial to generate the following error ...

>>>> C:\Wattcher>python wattcher.py
>>>> Traceback (most recent call last):
>>>>    File "wattcher.py", line 56, in <module>
>>>>      ser.open()
>>>>    File "C:\Python25\Lib\site-packages\serial\serialwin32.py", line 56,
>>>> in
>>>> open
>>>>      raise SerialException("could not open port %s: %s" %
>>>> (self.portstr,
>>>> ctypes.WinError()))
>>>> serial.serialutil.SerialException: could not open port COM4: [Error 5]
>>>> Access is denied.
>>>     Are you trying to access serial ports from a virtual machine?
>>> Which virtual machine environment?  Xen?  VMware? QEmu?  VirtualBox?
>>> I wouldn't expect that to work in most of those.

>>>     What is "COM4", anyway?   Few machines today actually have four
>>> serial ports.  Is some device emulating a serial port?

>>> John Nagle

>> Thanks, and yes, I am using VirtualBox.  My laptop does not have a serial
>> port so
>> I use a USB-to-serial converter, which is assigned COM4.

> Doesn't VirtualBox allow "remapping" serial ports ? I thought you
> could have COM 4 in the host OS, and make it COM 1 or COM 2 in
> the guest. Something like that.

> http://virtuatopia.com/images/6/60/Virtualbox_serial_port_settings.jpg

> Also, Windows (as a host), is notorious for stealing control of
> COM ports. Even Windows software, when you run it, would report
> "COM 4 is busy". Then, you have to track down *why* it's busy.
> Is it that FAX software you installed ? The GPS software
> that talks to your GPS serial interface ?

> In theory, the "Handle" program is supposed to identify what
> is keeping a COM port busy, but I don't get the desired
> results from it very often. You need to know the naming
> convention for virtual COM ports (COM4 via USB to serial, is
> more virtual than physical). That's what makes it harder
> to track down.

> These are some names for COM ports, in Windows. The last two entries,
> are my USB to serial adapters. VCP1 functions as COM3.
> VCP0 functions as COM4. The VCP part is what would be
> listed in "Handle" from Sysinternals. The \device\serial
> format, is more likely to be used with true "native"
> motherboard serial ports.

>    \device\serial

>    ups.exe pid: 1072 NT AUTHORITY\SYSTEM
>       98: File  (---)   \Device\VCP0
>    hypertrm.exe pid: 3404 ComputerName\UserID     (claims to use COM3)
>       E0: File  (---)   \Device\VCP1

> You can download "Handle" and play with it here.

> http://technet.microsoft.com/en-us/sysinternals/bb896655

> Note that, in my Handle results, at the time I was running
> the Windows provided ups.exe to talk to my external UPS
> (uninterruptible power supply). So that's what that
> reference is. The "hypertrm" one, is me using the
> built-in Windows terminal software, to talk to COM3,
> to keep the port artificially busy for the purposes
> of testing.

> If things were working well in your case, you *might*
> see something of this form. If not, you'd instead
> see the name of the process that has "stolen" the
> com port.

>    virtualbox.exe pid: 1234 ComputerName\UserID
>       E0: File  (---)  \Device\VCP0

> HTH,
>    Paul

>>>>> I am able to open port COM4 with Terminal emulator.

>>>>> So, what can cause PySerial to generate the following error ...

>>>>> C:\Wattcher>python wattcher.py
>>>>> Traceback (most recent call last):
>>>>>    File "wattcher.py", line 56, in <module>
>>>>>      ser.open()
>>>>>    File "C:\Python25\Lib\site-packages\serial\serialwin32.py", line 56,
>>>>> in
>>>>> open
>>>>>      raise SerialException("could not open port %s: %s" %
>>>>> (self.portstr,
>>>>> ctypes.WinError()))
>>>>> serial.serialutil.SerialException: could not open port COM4: [Error 5]
>>>>> Access is denied.
>>>>     Are you trying to access serial ports from a virtual machine?
>>>> Which virtual machine environment?  Xen?  VMware? QEmu?  VirtualBox?
>>>> I wouldn't expect that to work in most of those.

>>>>     What is "COM4", anyway?   Few machines today actually have four
>>>> serial ports.  Is some device emulating a serial port?

>>>> John Nagle

>>> Thanks, and yes, I am using VirtualBox.  My laptop does not have a serial
>>> port so
>>> I use a USB-to-serial converter, which is assigned COM4.

>> Doesn't VirtualBox allow "remapping" serial ports ? I thought you
>> could have COM 4 in the host OS, and make it COM 1 or COM 2 in
>> the guest. Something like that.

>> http://virtuatopia.com/images/6/60/Virtualbox_serial_port_settings.jpg

>> Also, Windows (as a host), is notorious for stealing control of
>> COM ports. Even Windows software, when you run it, would report
>> "COM 4 is busy". Then, you have to track down *why* it's busy.
>> Is it that FAX software you installed ? The GPS software
>> that talks to your GPS serial interface ?

>> In theory, the "Handle" program is supposed to identify what
>> is keeping a COM port busy, but I don't get the desired
>> results from it very often. You need to know the naming
>> convention for virtual COM ports (COM4 via USB to serial, is
>> more virtual than physical). That's what makes it harder
>> to track down.

>> These are some names for COM ports, in Windows. The last two entries,
>> are my USB to serial adapters. VCP1 functions as COM3.
>> VCP0 functions as COM4. The VCP part is what would be
>> listed in "Handle" from Sysinternals. The \device\serial
>> format, is more likely to be used with true "native"
>> motherboard serial ports.

>>    \device\serial

>>    ups.exe pid: 1072 NT AUTHORITY\SYSTEM
>>       98: File  (---)   \Device\VCP0
>>    hypertrm.exe pid: 3404 ComputerName\UserID     (claims to use COM3)
>>       E0: File  (---)   \Device\VCP1

>> You can download "Handle" and play with it here.

>> http://technet.microsoft.com/en-us/sysinternals/bb896655

>> Note that, in my Handle results, at the time I was running
>> the Windows provided ups.exe to talk to my external UPS
>> (uninterruptible power supply). So that's what that
>> reference is. The "hypertrm" one, is me using the
>> built-in Windows terminal software, to talk to COM3,
>> to keep the port artificially busy for the purposes
>> of testing.

>> If things were working well in your case, you *might*
>> see something of this form. If not, you'd instead
>> see the name of the process that has "stolen" the
>> com port.

>>    virtualbox.exe pid: 1234 ComputerName\UserID
>>       E0: File  (---)  \Device\VCP0

>> HTH,
>>    Paul

> Thanks (Guru Paul), I've been using the USB-to-serial converter successfully
> without
> enabling/remapping via VBox Settings=>Serial Ports (which are both "not"
> enabled).
> I can see the serial port COM4 under Device Manager though.  So, maybe
> enabling is
> necessary when the host has "native" serial ports, which my laptop does not
> have.

> From the output generated by Handle.exe, here's the section for TeraTerm ...
> --------------------------------------------------------------------------- ---
> ttermpro.exe pid: 596 VBOX_WINXPPRO\adam        (claims to use COM4)
>     C: File  (RW-)   D:\downloads\Tera Term Pro\ttpro313
>    2C: Section       \BaseNamedObjects\ttset_memfilemap
>    44: File  (RW-)
> C:\WINDOWS.0\WinSxS\x86_Microsoft.Windows.Common-Controls_6595b64144ccf1df_ 6.0.2600.6028_x-ww_61e65202
>    54: File  (RW-)
> C:\WINDOWS.0\WinSxS\x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.6195_ x-ww_44262b86
>    70: Section
> \BaseNamedObjects\_ISWINTERNAL_EPT32_SHEX_K32_0_1c9aa25ea688500_7c80_S-1-5- 21-1801674531-1078145449-1957994488-1004
>    78: File  (RWD)   C:\DOCUME~1\adam\LOCALS~1\Temp\IswTmp\Logs\ISWSHEX.swl
>    AC: Section
> \BaseNamedObjects\_ISWINTERNAL_EPT32_SHEX_A32_0_1c98aa70f70ec00_77dd_S-1-5- 21-1801674531-1078145449-1957994488-1004
>   100: Section
> \BaseNamedObjects\CiceroSharedMemDefaultS-1-5-21-1801674531-1078145449-1957 994488-1004
>   108: File  (RW-)   D:\downloads\Tera Term Pro\ttpro313\httplog.log
>   120: Section
> \BaseNamedObjects\CTF.TimListCache.FMPDefaultS-1-5-21-1801674531-1078145449 -1957994488-1004SFM.DefaultS-1-5-21-1801674531-1078145449-1957994488-1004
>   128: Section       \BaseNamedObjects\ShimSharedMemory
>   138: Section       \BaseNamedObjects\MSCTF.Shared.SFM.IAB
> --------------------------------------------------------------------------- ---

>>>>>> I am able to open port COM4 with Terminal emulator.

>>>>>> So, what can cause PySerial to generate the following error ...

>>>>>> C:\Wattcher>python wattcher.py
>>>>>> Traceback (most recent call last):
>>>>>>    File "wattcher.py", line 56, in <module>
>>>>>>      ser.open()
>>>>>>    File "C:\Python25\Lib\site-packages\serial\serialwin32.py", line
>>>>>> 56, in
>>>>>> open
>>>>>>      raise SerialException("could not open port %s: %s" %
>>>>>> (self.portstr,
>>>>>> ctypes.WinError()))
>>>>>> serial.serialutil.SerialException: could not open port COM4: [Error
>>>>>> 5]
>>>>>> Access is denied.
>>>>>     Are you trying to access serial ports from a virtual machine?
>>>>> Which virtual machine environment?  Xen?  VMware? QEmu?  VirtualBox?
>>>>> I wouldn't expect that to work in most of those.

>>>>>     What is "COM4", anyway?   Few machines today actually have four
>>>>> serial ports.  Is some device emulating a serial port?

>>>>> John Nagle

>>>> Thanks, and yes, I am using VirtualBox.  My laptop does not have a
>>>> serial port so
>>>> I use a USB-to-serial converter, which is assigned COM4.

>>> Doesn't VirtualBox allow "remapping" serial ports ? I thought you
>>> could have COM 4 in the host OS, and make it COM 1 or COM 2 in
>>> the guest. Something like that.

>>> http://virtuatopia.com/images/6/60/Virtualbox_serial_port_settings.jpg

>>> Also, Windows (as a host), is notorious for stealing control of
>>> COM ports. Even Windows software, when you run it, would report
>>> "COM 4 is busy". Then, you have to track down *why* it's busy.
>>> Is it that FAX software you installed ? The GPS software
>>> that talks to your GPS serial interface ?

>>> In theory, the "Handle" program is supposed to identify what
>>> is keeping a COM port busy, but I don't get the desired
>>> results from it very often. You need to know the naming
>>> convention for virtual COM ports (COM4 via USB to serial, is
>>> more virtual than physical). That's what makes it harder
>>> to track down.

>>> These are some names for COM ports, in Windows. The last two entries,
>>> are my USB to serial adapters. VCP1 functions as COM3.
>>> VCP0 functions as COM4. The VCP part is what would be
>>> listed in "Handle" from Sysinternals. The \device\serial
>>> format, is more likely to be used with true "native"
>>> motherboard serial ports.

>>>    \device\serial

>>>    ups.exe pid: 1072 NT AUTHORITY\SYSTEM
>>>       98: File  (---)   \Device\VCP0
>>>    hypertrm.exe pid: 3404 ComputerName\UserID     (claims to use COM3)
>>>       E0: File  (---)   \Device\VCP1

>>> You can download "Handle" and play with it here.

>>> http://technet.microsoft.com/en-us/sysinternals/bb896655

>>> Note that, in my Handle results, at the time I was running
>>> the Windows provided ups.exe to talk to my external UPS
>>> (uninterruptible power supply). So that's what that
>>> reference is. The "hypertrm" one, is me using the
>>> built-in Windows terminal software, to talk to COM3,
>>> to keep the port artificially busy for the purposes
>>> of testing.

>>> If things were working well in your case, you *might*
>>> see something of this form. If not, you'd instead
>>> see the name of the process that has "stolen" the
>>> com port.

>>>    virtualbox.exe pid: 1234 ComputerName\UserID
>>>       E0: File  (---)  \Device\VCP0

>>> HTH,
>>>    Paul

>> Thanks (Guru Paul), I've been using the USB-to-serial converter
>> successfully without
>> enabling/remapping via VBox Settings=>Serial Ports (which are both "not"
>> enabled).
>> I can see the serial port COM4 under Device Manager though.  So, maybe
>> enabling is
>> necessary when the host has "native" serial ports, which my laptop does
>> not have.

>> From the output generated by Handle.exe, here's the section for TeraTerm
>> ...
>> --------------------------------------------------------------------------- ---
>> ttermpro.exe pid: 596 VBOX_WINXPPRO\adam        (claims to use COM4)
>>     C: File  (RW-)   D:\downloads\Tera Term Pro\ttpro313
>>    2C: Section       \BaseNamedObjects\ttset_memfilemap
>>    44: File  (RW-)
>> C:\WINDOWS.0\WinSxS\x86_Microsoft.Windows.Common-Controls_6595b64144ccf1df_ 6.0.2600.6028_x-ww_61e65202
>>    54: File  (RW-)
>> C:\WINDOWS.0\WinSxS\x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.6195_ x-ww_44262b86
>>    70: Section
>> \BaseNamedObjects\_ISWINTERNAL_EPT32_SHEX_K32_0_1c9aa25ea688500_7c80_S-1-5- 21-1801674531-1078145449-1957994488-1004
>>    78: File  (RWD)
>> C:\DOCUME~1\adam\LOCALS~1\Temp\IswTmp\Logs\ISWSHEX.swl
>>    AC: Section
>> \BaseNamedObjects\_ISWINTERNAL_EPT32_SHEX_A32_0_1c98aa70f70ec00_77dd_S-1-5- 21-1801674531-1078145449-1957994488-1004
>>   100: Section
>> \BaseNamedObjects\CiceroSharedMemDefaultS-1-5-21-1801674531-1078145449-1957 994488-1004
>>   108: File  (RW-)   D:\downloads\Tera Term Pro\ttpro313\httplog.log
>>   120: Section
>> \BaseNamedObjects\CTF.TimListCache.FMPDefaultS-1-5-21-1801674531-1078145449 -1957994488-1004SFM.DefaultS-1-5-21-1801674531-1078145449-1957994488-1004
>>   128: Section       \BaseNamedObjects\ShimSharedMemory
>>   138: Section       \BaseNamedObjects\MSCTF.Shared.SFM.IAB
>> --------------------------------------------------------------------------- ---

> For Handle to give a positive result, the TeraTerm program would need to
> currently have the serial port open. If you haven't started a terminal
> session,
> it might not be listed.

> Handle has some kind of filter function, and you can try searching for the
> name
> of the port that way.

> I don't see anything in that snipping, which looks like a serial port.

>    Paul

> This is a tough one.

>> This is a tough one.

> Try

>    handle -a > allhand.txt

> Then open the allhand.txt with Notepad and look for interesting entries.

> *******

> I tested right now, and first opened a session in HyperTerminal with one
> of my USB to serial adapters. The second serial adapter, is connect to a
> UPS, looking for a shutdown message. So the second entry should be present
> at all times.

> hypertrm.exe pid: 3452
> ...
>   120: File  (---)   \Device\VCP1

> ups.exe pid: 1568 NT AUTHORITY\SYSTEM
> ...
>    98: File  (---)   \Device\VCP0

> I don't have any "serial" entries on this machine. But one of
> my other machines, has a real COM port on the SuperI/O chip,
> so the entries for that would involve the word "serial" in some
> way. The USB ones, at least the ones I've got, say VCP. Possibly
> because one of the driver files sets up virtual COM ports. There
> is a control panel for the driver, that maps a virtual COM port,
> to a COM port number, like COM3 and COM4 in this case.

>   Paul

>> The Python script needed a call to ser.close() before ser.open() in
>> order to work.

> IOW, the port opened OK, but when you tried to open it a second time
> without closing it first, _that's_ when the .open() call failed.

> That's a restriction built in to Win32.  You can't open a serial port
> that's already open.  [Linux doesn't have that restriction.]

> Why do you need to open it a second time?

> --
> Grant Edwards               grant.b.edwards        Yow! Send your
> questions to
>                                  at               ``ASK ZIPPY'', Box
> 40474,
>                              gmail.com            San Francisco, CA 94140,
>                                                   USA

>>> The Python script needed a call to ser.close() before ser.open() in
>>> order to work.

>> IOW, the port opened OK, but when you tried to open it a second time
>> without closing it first, _that's_ when the .open() call failed.

>> That's a restriction built in to Win32.  You can't open a serial port
>> that's already open.  [Linux doesn't have that restriction.]

>> Why do you need to open it a second time?

> As far as I can tell, the wireless hardware connected to the
> USB-to-serial converter is receiving data (which may have the serial
> port open?).  I can see the data being received in TeraTerm (using
> COM4).  After closing TeraTerm, I start up the Python script and get
> the following error message ...

> C:\Wattcher>python wattcher.py
> Traceback (most recent call last):
>   File "wattcher.py", line 56, in <module>
>     ser.open()
>   File "C:\Python25\Lib\site-packages\serial\serialwin32.py", line 56, in
> open
>     raise SerialException("could not open port %s: %s" % (self.portstr,
> ctypes.WinError()))
> serial.serialutil.SerialException: could not open port COM4: [Error 5]
> Access is denied.

> Searching for similar encounters of this error message, some people
> said that calling ser.close() before ser.open() solved the problem.
> And, it worked for me as well.

> Is this considered a chicken & egg situation?

>> As far as I can tell, the wireless hardware connected to the
>> USB-to-serial converter is receiving data (which may have the serial
>> port open?).  I can see the data being received in TeraTerm (using
>> COM4).  After closing TeraTerm, I start up the Python script and get
>> the following error message ...
[...]
>> Searching for similar encounters of this error message, some people
>> said that calling ser.close() before ser.open() solved the problem.
>> And, it worked for me as well.

>> Is this considered a chicken & egg situation?

> Can you post a small example showing what you're doing?

>The best way to get help is to write as small a program as possible
>that demonstrates the problem, and post it.  I'll help you get
>started...

>Does this program work?

>    import serial
>    ser = serial.Serial("COM4")
>    ser.close()

>At the moment, I don't have access to a Windows machine, but I think
>the above should run without any errors.  If it works, then you've
>successfully opened and closed the COM4 port.  Start adding
>"features", in increments as small as possible, until the program
>fails.

>Then try to remove stuff that's not needed while still keeping the
>failure.

>IOW, try to find the smallest possible program that fails.

>Usually, in the process of doing that, you'll figure out what you were
>doing wrong.  If not, post the smallest failing program you can come
>up with, and somebody will be able to help.

>If you won't show us what you're doing, we can't tell you what you're
>doing wrong.

>>> Can you post a small example showing what you're doing?

>>The best way to get help is to write as small a program as possible
>>that demonstrates the problem, and post it.  I'll help you get
>>started...

>>Does this program work?

>>    import serial
>>    ser = serial.Serial("COM4")
>>    ser.close()

>>At the moment, I don't have access to a Windows machine, but I think
>>the above should run without any errors.  If it works, then you've
>>successfully opened and closed the COM4 port.  Start adding
>>"features", in increments as small as possible, until the program
>>fails.

>>Then try to remove stuff that's not needed while still keeping the
>>failure.

>>IOW, try to find the smallest possible program that fails.

>>Usually, in the process of doing that, you'll figure out what you were
>>doing wrong.  If not, post the smallest failing program you can come
>>up with, and somebody will be able to help.

>>If you won't show us what you're doing, we can't tell you what you're
>>doing wrong.

> Actually, I believe someone in an earlier thread in the newsgroup or
> elsewhere pointed out that serial ports automatically open under
> Windows. I'd have to look it back up when I have the time, which I
> don't have at the moment, unfortunately.

> ~Temia
> --
> The amazing programming device: fuelled entirely by coffee, it codes while
> awake and tests while asleep!

>> Actually, I believe someone in an earlier thread in the newsgroup or
>> elsewhere pointed out that serial ports automatically open under
>> Windows. I'd have to look it back up when I have the time, which I
>> don't have at the moment, unfortunately.

> I am just running Python scripts (downloaded), which is not opening
> the serial port more than once (as Grant keeps assuming).

>>> Actually, I believe someone in an earlier thread in the newsgroup or
>>> elsewhere pointed out that serial ports automatically open under
>>> Windows. I'd have to look it back up when I have the time, which I
>>> don't have at the moment, unfortunately.

> What they're referring to is that on startup, Windows used to open
> serial ports and query them to see if there was a serial mouse
> connected.  If it _thought_ it found a mouse, it would then hold the
> port. I don't think that behavior has been enabled by default for a
> long time.

> If that were the case, then your terminal program wouldn't be able to
> open the port either.

> However, IIRC, some versions of windows do open and then close the
> ports during the bus/device enumeration step of startup. However, they
> don't keep the port open, so it doesn't affect the ability of user
> applications to later open the port.

>> Thanks, I think I read that as well but can't recall where.

>> I am just running Python scripts (downloaded), which is not opening
>> the serial port more than once (as Grant keeps assuming).

> Well, I'm assuming your description of what you're doing is accurate.

> If you're telling the truth, then the program is opening the port more
> than once.

> If the port wasn't already open, then calling ser.close() wouldn't do
> _anything_.  Here's the close() implmentation from pyserial:

>    def close(self):
>        """Close port"""
>        if self._isOpen:
>            if self.hComPort:
>                # Restore original timeout values:
>                win32.SetCommTimeouts(self.hComPort, self._orgTimeouts)
>                # Close COM-Port:
>                win32.CloseHandle(self.hComPort)
>                win32.CloseHandle(self._overlappedRead.hEvent)
>                win32.CloseHandle(self._overlappedWrite.hEvent)
>                self.hComPort = None
>            self._isOpen = False

> There's only _one_ place where self._isOpen is set to True, and that's
> at the end of the open() call:

>    def open(self):
>        """Open port with current settings. This may throw a
> SerialException
>           if the port cannot be opened."""
> [...]
>        self._overlappedWrite.hEvent = win32.CreateEvent(None, 0, 0, None)
>        self._isOpen = True

> If you have to add the call "ser.close()" before you can open the port
> with "ser.open()", then that means that the port _was_already_open_.

> --
> Grant Edwards               grant.b.edwards        Yow! World War III?
>                                  at               No thanks!
>                              gmail.com

> Trying to open a serial port with pyserial on WinXP -> "Access denied"

> http://stackoverflow.com/questions/2063257/trying-to-open-a-serial-po...

>> Obviously pySerial considers the serial port open

> Because it's already been opened by the Python program.

>> and will not open an already open serial port.

> Pyserial will happily try if you call the open() of a port that's
> already open, but Windows will return an error.

>> However, why is it that TeraTerm can open the serial port?

> Because TeraTerm only opens it once.

>> Here's the link where I read about calling ser.close() before
>> ser.open() ...

>> Trying to open a serial port with pyserial on WinXP -> "Access denied"

>> http://stackoverflow.com/questions/2063257/trying-to-open-a-serial-po...

> That code is broken.

> The port is opened by this line:

> self.ser=serial.Serial(port='\\.\COM1', baudrate=9600,
> bytesize=serial.EIGHTBITS, parity=serial.PARITY_NONE,
> stopbits=serial.STOPBITS_ONE, timeout=1)

> And then the author tries to _open_it_a_second_time_ here:

> self.ser.open()

>> Here's the Python scripts ...
>> https://github.com/adafruit/Tweet-a-Watt/downloads
>> Click on the "Download as ..." button for the Python scripts

> Like I kept telling you, those programs are trying to re-open a port
> that they've already open.  Here's the erroneous code:

> wattcher.py:

>    53
>    54  # open up the FTDI serial port to get data transmitted to xbee
>    55  ser = serial.Serial(SERIALPORT, BAUDRATE)
>    56  ser.open()
>    57

> Line 55 opens the serial port.

> Line 56 tries to _open_it_again_.  _The_port_is_already_open_.
> Windows doesn't allow a serial port to be opened twice, therefore the
> ser.open() call raises an exception.

> Just delete line 56.

> The same thing happens here:

> gmeter-wattcher.py

>    83
>    84  # open up the FTDI serial port to get data transmitted to xbee
>    85  ser = serial.Serial(SERIALPORT, BAUDRATE)
>    86  ser.open()
>    87

> Just delete line 86.

> See how simple it was to get the problem solved once you posted the
> actual code?

> --
> Grant Edwards               grant.b.edwards        Yow! HUMAN REPLICAS are
>                                  at               inserted into VATS of
>                              gmail.com            NUTRITIONAL YEAST ...

> That doesn't have anything to do with Windows, but with how pySerial
> works. See the documentation for __init__():

> "The port is immediately opened on object creation, when a port is given.
> It is not opened when port is None and a successive call to open() will be
> needed."

> So if your script does something like

> prt = serial.Serial('COM4')

> then pySerial automatically opens the port, and you shouldn't call
> prt.open() anymore.

> If, on the contrary, you do something like

> prt = serial.Serial()
> prt.port = 'COM4'

> then pySerial doesn't open the port, and you have to call prt.open() to do
> it.

> PySerial has this same behavior on both Windows and Linux. The difference
> might be that on Linux it is possible to open serial ports more than once,
> while that doesn't work on Windows.

> Best regards,
> Roel