473,573 Members | 2,796 Online
Bytes | Software Development & Data Engineering Community
+ Post

Home Posts Topics Members FAQ

pySerial Windows write problem

We have some equipment that communicates at 57600 baud RS232. The path from
the PC is USB to a Phillips USB hub, then off of that a TUSB3410 USB/Serial
converter. The driver for the 3410 chip creates a "normal" comm port (like
COM3). There is a C++ program that has no problem talking to the equipment,
but two Python programs have trouble. One is a big, scary, controller
program, and the other, since that is the one I'm having trouble with, is a
while() loop.

The while loop program seems to be able to open and close the serial port
all day. It also seems to be able to open, send "blahblahbl ah", and close
the port for the same length of time. But writing anything to the port
quickly (not always right away...like maybe 5-6 iterations through the
loop?) causes the

win32file.Close Handle(self.hCo mPort)

statement in the 'def close(self)' function of the serialwin32.py file of
the pySerial package to hang for a few seconds, then return. The next
open() attempt fails with the 'could not open port: (995, 'CreateFile', 'The
I/O operation has been aborted because of either a thread exit or an
application request.') exception.

The failure mode with the large program is it opens the port successfully
completes a bunch of back and forth talking, then hangs for a few seconds
when the port is closed, and then can't reopen the port. It never seems to
fail in the middle of a bunch of reads and writes, but only when/after the
port is closed. It can also run for the better part of an hour with no
problems then all of a sudden... Like I said, the C++ program never fails.

I've looked at the settings in the C++ program, and in the serialwin32.py
file and tried to set them the same as best I can, but no luck. Digging
into the win32all stuff gets me lost quite quickly. I see all of the
settings, but have no idea what to try. This is all on WinXP, Python 2.4.1,
the latest pySerial and win32all.

Does this ring any bells with anyone?

Thanks!

Bob
Jul 28 '05 #1
13 10993
bob
I forgot to mention that once the Python program(s) fail, THEN the C++
program also fails to opne the port, and the equipment has to be
power-cycled to get things to work again.

Bob

Jul 28 '05 #2
Bob Greschke wrote:
But writing anything to the port
quickly (not always right away...like maybe 5-6 iterations through the
loop?) causes the

win32file.Close Handle(self.hCo mPort)

statement in the 'def close(self)' function of the serialwin32.py file of
the pySerial package to hang for a few seconds, then return.


Are you certain it is this line that is blocking, and not the preceding
line which is a call to SetCommTimeouts ()? How did you prove which line
it is? (I don't have an answer to the problem, just wanted to be sure
of the information...)

-Peter
Jul 28 '05 #3
"Peter Hansen" <pe***@engcorp. com> wrote in message
news:rf******** ************@po wergate.ca...
Bob Greschke wrote:
But writing anything to the port
quickly (not always right away...like maybe 5-6 iterations through the
loop?) causes the

win32file.Close Handle(self.hCo mPort)

statement in the 'def close(self)' function of the serialwin32.py file of
the pySerial package to hang for a few seconds, then return.


Are you certain it is this line that is blocking, and not the preceding
line which is a call to SetCommTimeouts ()? How did you prove which line
it is? (I don't have an answer to the problem, just wanted to be sure of
the information...)

-Peter


Hi!

I had the SetCommTimeouts line commented out. I just have a couple of
prints before and after the CloseHandle line.

I didn't write the C++ program, but it looks like it never closes the serial
port. It opens it when it starts up, then keeps it open until it quits.
Tsk tsk tsk. Sloppy. Maybe they did that to cover up this problem. :)

Bob
Jul 28 '05 #4
Bob Greschke wrote:
I didn't write the C++ program, but it looks like it never closes the serial
port. It opens it when it starts up, then keeps it open until it quits.
Tsk tsk tsk. Sloppy. Maybe they did that to cover up this problem. :)


Actually, I'm curious why you don't do the same. I'd call it very
unusual (in my experience) to have a program open and close a serial
port repeatedly. Among other things, this means that the DSR/DTR lines
are toggling high and low repeatedly, and that alone could cause
undesirable behaviour in certain devices.

In none of my own serial-based programs (perhaps a few dozen such to
date) have I ever opened and closed a port other than at startup and
shutdown (just as your C++ program does). Unless you've got a good
reason to do otherwise, if this solves your problem it's certainly the
most direct approach to do so.

-Peter
Jul 29 '05 #5
"Peter Hansen" <pe***@engcorp. com> wrote in message >
Actually, I'm curious why you don't do the same. I'd call it very unusual
(in my experience) to have a program open and close a serial port
repeatedly. Among other things, this means that the DSR/DTR lines are
toggling high and low repeatedly, and that alone could cause undesirable
behaviour in certain devices.
I guess I could. It's just that not releasing the port/not KNOWING that the
port has been closed at predictible times is our chief complaint about the
C++ program. As an aside, when I left work I left a version of the
while-loop program running, opening the port, writing to the equipment,
getting a response, and closing the port. It was up to about 180 sucessful
cycles (in a row -- it will stop if it fails). I think it's a hardware
problem. :)

In none of my own serial-based programs (perhaps a few dozen such to date)
have I ever opened and closed a port other than at startup and shutdown
(just as your C++ program does). Unless you've got a good reason to do
otherwise, if this solves your problem it's certainly the most direct
approach to do so.


One of the serial ports (there are actually two) is used to read some NMEA
sentences from a GPS. It is only rarely read. If it is also opened when
the program starts and kept open would you just dump the buffer and then
read to get the most current info? What happens when the buffer fills up?
The "main" port is just commands sent, responses received kind of traffic.

I'd write a C extension to do the serial stuff, but I don't know a thing
about Windows programming.

Thanks!
Jul 29 '05 #6
Bob Greschke wrote:
"Peter Hansen" <pe***@engcorp. com> wrote in message >

Actually, I'm curious why you don't do the same. I'd call it very unusual
(in my experience) to have a program open and close a serial port
repeatedly. Among other things, this means that the DSR/DTR lines are
toggling high and low repeatedly, and that alone could cause undesirable
behaviour in certain devices.
I guess I could. It's just that not releasing the port/not KNOWING that the
port has been closed at predictible times is our chief complaint about the
C++ program. As an aside, when I left work I left a version of the
while-loop program running, opening the port, writing to the equipment,
getting a response, and closing the port. It was up to about 180 sucessful
cycles (in a row -- it will stop if it fails). I think it's a hardware
problem. :)

Hmm, keep the port open. One bad thing that can happen is that if you
don;t keep the port open then another program running on the box and nip
in and claim ownership of the port. I agree with Peter, I never
relinquish the port in code unless I have a reason to (ie shutdown or
chnaging the COM port I'm using). I doubt that it is a hardware problem
on your device as the RS232 tandard (I prefer to call it a rumour)
doesn't have any kind of RRP. Even if you are running RTS/CTS or
XON/XOFF then you again shouldn't have a problem becuase once the data
is sent.received then the lines should be back to normal. If you wish
to test this and am not happy with writing C code to test it then maybe
you could try it with something that doens;t use C code such as Java
(with the javax.comm or rxtx extensions)?
In none of my own serial-based programs (perhaps a few dozen such to date)
have I ever opened and closed a port other than at startup and shutdown
(just as your C++ program does). Unless you've got a good reason to do
otherwise, if this solves your problem it's certainly the most direct
approach to do so.


One of the serial ports (there are actually two) is used to read some NMEA
sentences from a GPS. It is only rarely read. If it is also opened when
the program starts and kept open would you just dump the buffer and then
read to get the most current info? What happens when the buffer fills up?
The "main" port is just commands sent, responses received kind of traffic.

PySerial doesn;t have any kind of event firing to notify you when data
is available. The way I get round this is to have a loop polling (in a
seperate thread) to see if any data is available (it's a method on the
interface), then read all the data in and fire this off to my
listeners/observers with the read data. That way your buffers will not
fill up. I would also do that on your other port as well to give you a
common way of receiving data. I did this and then started downloading
random stuff of wiki and sending the data from one serial port to
another in huge chunks with no problems.
I'd write a C extension to do the serial stuff, but I don't know a thing
about Windows programming.

Thanks!

I wouldn't bother as well - PySerial works fine for me, as I mentioned
the only thing I don;t like is no evetn firing when data is availabel
but you can code around taht if you wish to.

Cheers,

Neil

--

Neil Benn
Senior Automation Engineer
Cenix BioScience
BioInnovations Zentrum
Tatzberg 47
D-01307
Dresden
Germany

Tel : +49 (0)351 4173 154
e-mail : be**@cenix-bioscience.com
Cenix Website : http://www.cenix-bioscience.com

Jul 29 '05 #7
Bob Greschke wrote:
"Peter Hansen" <pe***@engcorp. com> wrote in message >
I'd call it very unusual
(in my experience) to have a program open and close a serial port
repeatedly.


One of the serial ports (there are actually two) is used to read some NMEA
sentences from a GPS. It is only rarely read. If it is also opened when
the program starts and kept open would you just dump the buffer and then
read to get the most current info? What happens when the buffer fills up?
The "main" port is just commands sent, responses received kind of traffic.


Generally, yes, you just dump data received up to the point you are
about to send a new request (if this is a request/response type of
thing). PySerial has a .flush() method of some kind I believe, or you
can just loop as long as inWaiting() isn't False.

If you aren't using hardware or software handshaking, then the buffer
filling up is a non-issue for you or the sender. If you're using
handshaking, then you do have to keep the buffer from filling. Pretty
much all my interesting code runs the PySerial stuff in a separate
thread, reading whenever data is available, and (this is a
simplification) posting it to a Queue which the main thread can read
from as required. In that scenario, you could just have a flag that
causes the receive thread to stop posting stuff to the Queue where you
currently have close the port to prevent data being seen.

I don't recall: is NMEA 0183 asynchronous? Messages can be sent by the
GPS even when you didn't ask for one explicitly? If so, then it's
possible there are problems even with your current approach: what if you
open the port halfway through a packet, and receive only the last few
bytes? If it's synchronous (data sent only in response to your
requests), then none of this is an issue since there will be no traffic
unless you ask for it, so the serial port will be idle between uses.

-Peter
Jul 29 '05 #8
Neil Benn wrote:
PySerial doesn;t have any kind of event firing to notify you when data
is available. The way I get round this is to have a loop polling (in a
seperate thread) to see if any data is available (it's a method on the
interface), then read all the data in and fire this off to my
listeners/observers with the read data.


On that note, I've got a preliminary version of something I call "Bent"
(think "slightly Twisted") which is focused for now on providing an
asynchronous version of PySerial which is designed around the
event-driven model instead of its current polled scheme.

It shares a number of features with the Twisted-based PySerial port
(also done by Chris Liechti, for the Twisted team, judging by the code
comments) but doesn't require one to adopt the whole Twisted framework.
Basically it provides you with the equivalent of one "reactor" per
thread for PySerial stuff. On Win32 only for now. There are other
limitations too. Not ready for prime time.

On the plus side, it's been letting me convert my serial stuff to be
fully event-driven and with the resulting much lower latencies and
better CPU efficiency, while keeping my code more "traditiona l" instead
of having to force it entirely into the Twisted point of view.

Just an FYI. And, obviously, to hear back from those interested. I
don't know if this is something that should be contributed to the
PySerial project (it's more of a rewrite than an add-on), or set up as a
new project, or passed around quietly behind the scenes for a while.
No docs yet, no contrived examples (but various pieces of working code
in real daily use). Did I mention it wasn't ready for prime time?

If you've ever been annoyed having to do .read(1) to get characters one
at a time in PySerial, or .read(100) with a timeout, or whatever, this
might be of interest to you...

-Peter
Jul 29 '05 #9
I use PySerial in a 16 line data collection system
with LOTS of threads, and yes am frustrated by read().
This sounds excellent, keep us updated.

BTW, haven't done any event driven Python except Tkinter.
Would this a class library which would let you
define an event and a handler?

Do you have a one line code example?

Thanks.

Peter Hansen wrote:
Neil Benn wrote:
PySerial doesn;t have any kind of event firing to notify you when data
is available. The way I get round this is to have a loop polling (in a
seperate thread) to see if any data is available (it's a method on the
interface), then read all the data in and fire this off to my
listeners/observers with the read data.


On that note, I've got a preliminary version of something I call "Bent"
(think "slightly Twisted") which is focused for now on providing an
asynchronous version of PySerial which is designed around the
event-driven model instead of its current polled scheme.

It shares a number of features with the Twisted-based PySerial port
(also done by Chris Liechti, for the Twisted team, judging by the code
comments) but doesn't require one to adopt the whole Twisted framework.
Basically it provides you with the equivalent of one "reactor" per
thread for PySerial stuff. On Win32 only for now. There are other
limitations too. Not ready for prime time.

On the plus side, it's been letting me convert my serial stuff to be
fully event-driven and with the resulting much lower latencies and
better CPU efficiency, while keeping my code more "traditiona l" instead
of having to force it entirely into the Twisted point of view.

Just an FYI. And, obviously, to hear back from those interested. I
don't know if this is something that should be contributed to the
PySerial project (it's more of a rewrite than an add-on), or set up as a
new project, or passed around quietly behind the scenes for a while.
No docs yet, no contrived examples (but various pieces of working code
in real daily use). Did I mention it wasn't ready for prime time?

If you've ever been annoyed having to do .read(1) to get characters one
at a time in PySerial, or .read(100) with a timeout, or whatever, this
might be of interest to you...

-Peter


Jul 29 '05 #10

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

8
9137
by: Alejandro | last post by:
Hi: I'm using pySerial to talk to a RS232 to RS485 converter. In order to control the converter, I need to control the DTR line to enable/disable de RS485 driver. In particular, I need to : write a character to the serial port set the DTR line to level 1 _after_ the last bit of the character is send
2
3733
by: Jon | last post by:
Hi, I wrote some code to read in info from a port using pyserial. the code reads info sent by a box that is connected to my computer by an rs232-to usb adapter. When I was writing the code and testing it on my computer it worked fine. I ran py2exe on the program (which uses wxpython for its gui) and sent the output from the py2exe to...
15
16812
by: Lone Wolf | last post by:
I'm trying to get data through my serial port from a CMUcam. This gizmo tracks a color and returns a packet of data. The packet has nine data points (well, really eight since the first point is just a packet header) separated by spaces as follows: M xxx xxx xxx xxx xxx xxx xxx xxx Here is the code I am using (python v24): import serial
0
596
by: pauland80 | last post by:
<snip> <snip> Late thanks for your both answers! (Please excuse me for that) The problem was a bug in the device firmware. But before finding this, I dugg lightly in the pyserial source and found (to take with care!) :
0
2058
by: [david] | last post by:
http://pyserial.sourceforge.net/ "port numbering starts at zero, no need to know the port name in the user program" But the implementation in SerialWin32 is just (Portnum +1)
3
11559
by: naveen.sabapathy | last post by:
Hi, I am trying to use virtual serial ports to develop/test my serial communication program. Running in to trouble... I am using com0com to create the virtual ports. The virtual ports seem to be working fine when I test it with Hyperterminal . I am using the example program that comes with pyserial, as below. --------------- import...
6
6640
by: terry | last post by:
Hi, I am trying to send a character to '/dev/ttyS0' and expect the same character and upon receipt I want to send another character. I tired with Pyserial but in vain. Test Set up: 1. Send '%' to serial port and make sure it reached the serial port. 2. Once confirmed, send another character.
3
6190
by: Rainy | last post by:
Hello! I'm having some trouble with pyserial package, I'm sending commands and reading responses from a custom pcb, and sometimes I get a proper response, at other times I get nothing, and sometimes I get about half of the response string with beginning cut off. About half the time an empty string is returned, the other ~half time good...
6
10634
by: Joe G \(Home\) | last post by:
Hi All, Background =================== I have installed Python for windows today from the python web site .I also installed pySerial using the Windows installer from the sourceforge web site..... Both installs use the default directories. Phyton version : Python 2.5.2 (r252:60911, Feb 21 2008, 13:11:45) on win32
0
7771
marktang
by: marktang | last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However, people are often confused as to whether an ONU can Work As a Router. In this blog post, we’ll explore What is ONU, What Is Router, ONU & Router’s main...
0
7686
by: Hystou | last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can effortlessly switch the default language on Windows 10 without reinstalling. I'll walk you through it. First, let's disable language...
0
8009
Oralloy
by: Oralloy | last post by:
Hello folks, I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>". The problem is that using the GNU compilers, it seems that the internal comparison operator "<=>" tries to promote arguments from unsigned to signed. This is as boiled down as I can make it. ...
1
7771
by: Hystou | last post by:
Overview: Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows Update option using the Control Panel or Settings app; it automatically checks for updates and installs any it finds, whether you like it or not. For...
0
6406
agi2029
by: agi2029 | last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing, and deployment—without human intervention. Imagine an AI that can take a project description, break it down, write the code, debug it, and then...
1
5580
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome a new presenter, Adolph Dupré who will be discussing some powerful techniques for using class modules. He will explain when you may want to use classes...
0
5289
by: conductexam | last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and then checking html paragraph one by one. At the time of converting from word file to html my equations which are in the word document file was convert...
0
3730
by: TSSRALBI | last post by:
Hello I'm a network technician in training and I need your help. I am currently learning how to create and manage the different types of VPNs and I have a question about LAN-to-LAN VPNs. The last exercise I practiced was to create a LAN-to-LAN VPN between two Pfsense firewalls, by using IPSEC protocols. I succeeded, with both firewalls in...
0
1036
bsmnconsultancy
by: bsmnconsultancy | last post by:
In today's digital era, a well-designed website is crucial for businesses looking to succeed. Whether you're a small business owner or a large corporation in Toronto, having a strong online presence can significantly impact your brand's success. BSMN Consultancy, a leader in Website Development in Toronto offers valuable insights into creating...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.