On 07/18/2017 12:53 PM, FS wrote:
Thank you for your response Andre. I had tried some code like that in the
document but it did not seem to work. However ever leaving my terminal for a
time the code eventually wrote out the records so apparently there is some very
deep buffering going on here. A little more searching on the web revealed the
following:
https://stackoverflow.com/questions/10222788/line-buffered-serial-input
It is apparent that pySerial, or at least the documentation is falling short of
my needs. It is very unclear what module in the layer is handling the buffering
and newlines and so forth. Also unclear is whether the coupled python and OS is
reading FIFO or LIFO--something important in quasi realtime scientific
applications.
This is problematic since the serial port is still so ubiquitous to a lot of
scientific instrumentation. I probably will patch up some byte oriented code
for this or perhaps write the module in C.
Thanks again
Fritz
Handling it .read(1) at a time is probably your best bet. Append them
into a bytearray and pull it all out when you're done.
It's a serial port; it's not like there is any degree of inefficiently
that you could write the code that will make it slow with respect to the
I/O. I write a LOT of serial instrument I/O and I've definitely had to
fall back to this plan. Your code gets a little long, you hide it all
in a function somewhere and never think on it again.
One paradigm I stick for ASCII serial is to have 3 functions:
def command(msg: str):
"""Sends a command, raises CommError if it doesn't get some
expected OK sort of thing."""
def query(msg: str):
"""Sends a commmand, returns a (trimmed) response line."""
def _communicate(msg: str):
The ugliest stuff, all the str->bytes->str stuff, the line-ending and
protocols, goes into _communicate. Query usually just calls
_communicate. Command slaps on whatever checks are needed. It feels a
bit heavy, but it leads to highly-usable code and makes it easy to
integrate logging, retries, integrating "*OPC?" handshakes, whatever
sort of things turn out to be necessary on a given device.
--
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order. See above to fix.
--
https://mail.python.org/mailman/listinfo/python-list
