The previous fix computed the host-side wait (via a read_tmo_ms query)
after already sending "++read eoi" -- but the controller doesn't answer
any further command while that read is outstanding, so the read_tmo_ms
query itself raced the read it was meant to be timing and could time
out. Reordered so the timeout is resolved first in both query() and
read(); added a regression test pinning the wire ordering.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Found against real hardware: a fixed 2.0s host-side read timeout was
shorter than the device's configured read_tmo_ms (3000ms). The
controller keeps a "++read" outstanding internally until EOI or its
own timeout, so the client gave up and sent the next command first --
that command's reply then got lost/delayed behind the still-pending
read, surfacing as a spurious TransportTimeout on the *following* call
(observed: query("*IDN?") timed out as expected with no instrument
attached, then srq() right after it timed out too, on a device with
read_tmo_ms=3000).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Builds a modern, testable API for the Prologix GPIB-ETHERNET controller
(GPIB-USB structurally supported but untested, no hardware available):
Transport abstraction (Ethernet now, serial later), GpibController for
the full "++" command set, a clean-room netfinder discovery client that
fixes a real chr()/struct-format bug present in vendortools/nfutil.py,
and a CLI (discover/config/info/terminal). vendortools/, pty-gpib-emulator/,
sampledata.txt and the manual PDF are kept untouched as reference material.
Depends on the sibling bits package (editable, not yet pinned -- see its
own commit) for MAC formatting and IEEE-488.2 status-byte bit access.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
