Three more drivers on the protocol description, and a format that stays about the wire

[dccote]

What this does

EchoDevice, IntegraDevice and CoboltDevice now keep their protocol as data and send through performTransaction, as SutterDevice does. communication/commands.py has one user left, IntellidriveDevice.

Converting them turned up a fault in each, which is most of the value here.

What the conversions found

EchoDevice's three commands were timing out, every time, silently. An echo answers with the payload and no terminator, so reading a line ran to the end of the buffer and raised — and the old send() catches every exception into an attribute and returns, so testEchoCommands passed while nothing worked. That test could not fail. Described as fixed-size frames whose every byte is a constant, the echo is now checked: a payload that comes back altered is refused, not merely received.

IntegraDevice had no debug path at all. It opened a USBPort unconditionally, so all twelve of its tests skipped unless the meter was plugged in — nobody without the hardware could change that driver and know. IntegraDevice("debug") now builds a ProtocolDebugPort, and five tests run without it: the description validated against itself, the usage text, and setting a wavelength then reading it back, which goes out as *PWC00532 exactly as before.

CoboltDevice's debug port never updated requestedPower, so GET_REQUESTED_POWER answered 0 forever. On a Cobolt, p sets the power asked for and p? reads it back, while pa? reads the power reached. The description names those two apart, so both read correctly and the mock's power ramp means something again.

The format stays about the wire

A command could state a "sets" clause — what receiving it does to the instrument, for what its bytes do not carry — so that a debug port needed no code. A second clause, "initial", was about to join it for what an instrument reads as when switched on.

Both describe the instrument rather than its protocol, in a format whose whole premise is that it describes the protocol. Measured, they were not worth it:

	pre-existing tests that needed it
"sets"	1 — the other two failures were the tests written to justify it
"initial"	2

All three belong to Cobolt, the one device that already carries a debug-port subclass, because a laser does not reach a new power at once and doSetPower's convergence loop needs something to converge to.

So neither clause exists. Cobolt keeps its power-up state and its four state-changing commands in that subclass, next to the ramp, where behaviour lives. SutterDevice gains a four-line subclass so HOME still sends the stage to the origin — no test required it, but a debug port that lies about homing is what the rest of this design refuses. Echo and Integra need no subclass at all.

Known and deliberate

A ProtocolDebugPort answers 0 for a reading no request ever sets — a measured power, a serial number. Those turn out to be, almost exactly, the properties the capabilities already declare:

	capabilities	readings the store cannot know
Cobolt	OnOff, Power, Interlock, Autostart	isOn, power, interlock, autostart, serialNumber
Integra	WavelengthCalibration	power, version
Sutter	—	—

Making a debug port fulfil declared properties rather than invent zeros is worth doing, and it is a design conversation of its own — the properties belong to the capabilities, not to the protocol, and identity (serialNumber, version) is neither. Left for a separate piece of work rather than smuggled in here.

IntellidriveDevice is not converted. Its do* methods bypass its own command dict and write literals, and its template says t {mode}\n where the driver sends t 1\r; converting it means changing a byte sent to hardware I cannot test.

Testing

666 passed, 250 skipped. Net +4 tests that run without hardware, on drivers that previously had 0 (Integra) or a test that could not fail (Echo).

🤖 Generated with Claude Code