You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Same issue here. Fixed delay is the only workaround.
My setup:
Windows 10
pyserial 3.4 from pypi
python 3.6.5
serial device is a FTDI FT232RL
Tried software flow control, hardware flow control, setting read/write-timeout. In addition I put isOpen() right after serial open and it always returns True, despite silently failing to write (with timeout of 1 second). The read after the write runs into the timeout and does not return the expected repsonse but an empty string.
As a workaround I need to wait for 2 seconds (1 is not enough) and then I can query with the device with read delays of about 30 ms no problem.
If you need to have something tested on my setup, just let me know!
A call to open() always results in is_open returning True, even if the opening actually failed by timing out. There is thus no way to detect a nonexistent or dropped serial connection, which is quite surprising behaviour to say the least.
The issue appears to arise here: is_open is not set to False on an exception, nor is it set to false in _close(). It is in close(), but that is not called.
The text was updated successfully, but these errors were encountered:
is_open = True is set in the else clause of the try/except, so it will be only true if there is no error. Also at the beginning of the function there is a check that is_openis false. So I do not see how is_open should be in the wrong state.
The example quoted in the issue sounds like a device that is not immediately ready after opening, that's not the fault of the serial port, the OS or this library.
Originally posted by @axel-kah in #329 (comment)
I have the same issue as the above user.
A call to
open()
always results inis_open
returningTrue
, even if the opening actually failed by timing out. There is thus no way to detect a nonexistent or dropped serial connection, which is quite surprising behaviour to say the least.The issue appears to arise here:
is_open
is not set toFalse
on an exception, nor is it set to false in_close()
. It is inclose()
, but that is not called.The text was updated successfully, but these errors were encountered: