Two problems in pslab/pico/transport.py (added in #286):
1. ScpiClient.query accepts a partial line. On USB, PicoUsbTransport.readline() is pyserial's readline(), which returns whatever it has received when the timeout expires, without the trailing newline. query() only rejects an empty result, so a cut-off response is returned as if it were complete:
ser = serial.serial_for_url("loop://", timeout=0.2)
# device only gets "12" of "123\\n" out before the timeout
ScpiClient(PicoUsbTransport(serial_instance=ser)).error_count() # -> 12The Wi-Fi transport already raises ScpiTimeoutError in this situation, because its readline() waits for \\n. The same applies to the text error line read in read_block.
2. PicoWifiTransport.connect() leaks the socket when connect fails. The socket is created, and if sock.connect(...) raises (connection refused, or a timeout), it is never closed:
ResourceWarning: unclosed <socket.socket fd=3, family=2, type=1, ...>
This repeats on every retry against an unreachable bridge.
Expected: a response without its line terminator raises ScpiTimeoutError, and a failed connect closes the socket before re-raising.
Two problems in
pslab/pico/transport.py(added in #286):1.
ScpiClient.queryaccepts a partial line. On USB,PicoUsbTransport.readline()is pyserial'sreadline(), which returns whatever it has received when the timeout expires, without the trailing newline.query()only rejects an empty result, so a cut-off response is returned as if it were complete:The Wi-Fi transport already raises
ScpiTimeoutErrorin this situation, because itsreadline()waits for\\n. The same applies to the text error line read inread_block.2.
PicoWifiTransport.connect()leaks the socket whenconnectfails. The socket is created, and ifsock.connect(...)raises (connection refused, or a timeout), it is never closed:This repeats on every retry against an unreachable bridge.
Expected: a response without its line terminator raises
ScpiTimeoutError, and a failed connect closes the socket before re-raising.