Add Labcyte Echo 525 support

[c-reiter]

Add Labcyte Echo 525 support

Builds on top of PyLabRobot#1001 (Echo 650). This PR is stacked on labcyte-echo-plate-access, so the diff below is the 525-specific work only.

Background

The Echo 525 speaks the identical Medman SOAP-over-HTTP protocol as the Echo 650: POST /Medman, gzip-compressed SOAP 1.1 envelopes, the same RPC method set, the same Host: ip:slot_a:slot_b:epoch:pid token, and the same DoWellTransfer <Protocol><Layout><wp n dn v/></Layout></Protocol> XML.

This was verified end-to-end against a Wireshark capture of a physical Echo 525 (Model = Echo 525, serial E5XX-00000, software 2.7.3) running a HiFi PCR protocol — ~13.8k decoded SOAP messages, every method already implemented by the 650 driver.

What actually differs on the 525

The one functional difference is transfer-volume granularity: the device reported GetTransferVolIncrNl = GetTransferVolMinimumNl = 25 nL (the 650 uses 2.5 nL). Its HTTP headers also advertised Protocol: 2.6 / Client: 2.7.3.

Approach — reuse, don't fork

Rather than fork the 4.3k-line driver:

• echo.py (650) — the volume increment is parameterized (transfer_volume_increment_nl on EchoDriver, threaded through build_echo_transfer_plan → _validate_transfer_volume_nl); all defaults are unchanged so 650 behavior is identical. Echo gains a small driver_class / model_name factory hook so subclasses can inject a model-specific driver. A comment at ECHO_TRANSFER_VOLUME_INCREMENT_NL points to the 525.
• echo525.py (new) — Echo525 / Echo525Driver subclass the 650 classes and override only the 525 defaults (25 nL increment, observed 2.6/2.7.3 versions, Echo 525 model). Everything else (access control, plate survey, grippers, dry-plate, sessions, locking, DoWellTransfer) is inherited unchanged.

Mock server — EchoMockServer (hardware-free testing)

Following the MicroSpinMockServer pattern from PyLabRobot#1047, echo_mock.py adds an in-process asyncio server that speaks the Medman protocol (POST /Medman + gzip SOAP) and replays real responses captured from the physical 525, so Echo/Echo525 can be driven end-to-end with no instrument:

async with EchoMockServer() as srv:
    echo = Echo525(host=srv.host, rpc_port=srv.port)
    await echo.setup()
    info = await echo.get_instrument_info()        # -> Model "Echo 525", serial E5XX-00000
    await echo.driver.lock()
    await echo.driver.do_well_transfer(protocol_xml)
    await echo.driver.unlock()

• Replays 33 captured device responses keyed by SOAP method; the bulky 384-well DoWellTransfer print-map is trimmed to 3 wells, keeping the embedded fixture ~3.5 KB gzipped.
• Models the instrument lock, so motion/transfer RPCs issued without the lock get the Echo's real Caller does not own the lock fault — the locking workflow is exercised deterministically.

Validation

• python -m unittest pylabrobot.labcyte.echo525_tests → 14 passed (incl. 4 end-to-end against the mock)
• python -m unittest pylabrobot.labcyte.echo_tests (650) → 78 passed, no regression
• Reproducing the captured 384-well transfer (150 nL from source A2 into every destination well) through Echo525Driver yields a <wp> set byte-identical (on n/dn/v) to what the instrument actually sent.

Notes

• No refactors / no new deprecation warnings — this PR only adds a backward-compatible parameter + subclass + tests, staying out of the way of the upcoming machine-interface architecture migration (v1b1 changes PyLabRobot/pylabrobot#1000).
• plr.io transport: I deliberately kept this PR free of transport changes. The HTTP/socket layer lives in the base Add Labcyte Echo Support PyLabRobot/pylabrobot#1001 PR and uses one TCP connection per RPC; migrating it to plr.io (for logging + validation) is best done in Add Labcyte Echo Support PyLabRobot/pylabrobot#1001 so both the 650 and 525 benefit, rather than diverging the transport in a stacked PR. Happy to do that migration in Add Labcyte Echo Support PyLabRobot/pylabrobot#1001 (or a follow-up) if you'd like.
• Protocol/Client default to the captured 2.6/2.7.3 and are constructor-overridable for newer firmware.
• Calibration RPCs are inherited from the 650 driver but were not exercised by this capture.

[c-reiter]

@rickwierenga (cc @alexjamesgodfrey) - a backend-architecture question I'd like your opinion on before I refine this, especially given the v1b1 Device/Driver + capabilities migration.

This 525 work has surfaced three distinct "implementations" behind one Echo:

1. the Medman SOAP driver (real device, pure-Python - part of the PR already),
2. a vendor-SDK-backed path (for sites that own the Labcyte SDK - kept out of this repo for licensing/legal reasons; it can reproduce the Echo Cherry Pick transfer-order/survey optimisation and the exotic ecp modes we deliberately don't clone), and
3. a hardware-free path (the EchoMockServer in this PR, plus the PlateAccessChatterboxBackend).

Looking at how PLR usually does multiple backends per device (frontend + injected backend abstract base class + concrete subclasses + a chatterbox sibling, e.g. LiquidHandler(backend=STARBackend()/OpentronsBackend()/ChatterboxBackend())), two things in the current Echo design look slightly off-idiom and I'd value your opinion:

• Echo525 is a subclass of Echo rather than the variant being a driver parameter. The only real difference between the 525 and 650 is the transfer increment (25 vs 2.5 nL) + version-string defaults - already a constructor arg in this PR. So the convention-aligned shape seems to be one Echo frontend with the model as a driver parameter / thin factory, not a frontend subclass. Is that your preference, or do you want per-model classes (à la STAR vs STARlet)?

• Medman / vendor-SDK / chatterbox feel like they should be sibling EchoDriver implementations under one ABC, injected into a single Echo (Echo(driver=MedmanEchoDriver(...)) / VendorSdkEchoDriver(...) / EchoChatterboxDriver()), rather than today's single concrete EchoDriver + subclassed frontend. The picklist→protocol generator (EchoProtocolGenerator: naive open-source vs vendor-SDK) would stay a separate strategy injected into run_picklist, since it's orthogonal to transport.

Proposal: keep this PR as-is to avoid churning @alexjamesgodfrey's base PyLabRobot#1001, and do a follow-up that (a) makes EchoDriver an abstract base class with MedmanEchoDriver as the concrete impl, (b) collapses Echo525 into Echo(model=...)/factory with a deprecation shim, and (c) adds an EchoChatterboxDriver. Does that match where v1b1 is heading, or would you rather the Echo follow the older Machine/Backend shape until the capabilities migration lands? Happy to adjust either way.

[rickwierenga]

one Echo frontend with the model as a driver parameter / thin factory, not a frontend subclass

yes that sounds reasonable

EchoDriver implementations under one ABC, injected into a single Echo (Echo(driver=MedmanEchoDriver(...)) / VendorSdkEchoDriver(...) / EchoChatterboxDriver()), rather than today's single concrete EchoDriver + subclassed frontend.

yes

Does that match where v1b1 is heading, or would you rather the Echo follow the older Machine/Backend shape until the capabilities migration lands? Happy to adjust either way.

definitely targeting v1b1 with this since it's the future

will also be nice for us once we add the idot we recently bought :)

[c-reiter]

thanks @rickwierenga it's done, implemented as a follow-up so this PR / PyLabRobot#1001 stay clean: c-reiter#1 (stacked on this branch, so the diff there is the architecture change only).

• one Echo frontend; the model is a parameter (Echo(host, model="Echo 525")) backed by an ECHO_MODELS registry -> no more Echo525 subclass (kept as a deprecation shim).
• EchoDriver is now an ABC with MedmanEchoDriver (real SOAP) and EchoChatterboxDriver (logs, no I/O) as sibling implementations, injected via Echo(driver=...). The picklist→protocol generator stays a separate strategy.

102 labcyte tests pass. Kept it transport-abstract so the EchoDriver ABC holds the shared Medman logic and the chatterbox/vendor-SDK siblings only implement the transport seam, which should make the iDOT an easy add when you get to it. Happy to fold it into the main PR or keep it stacked, whichever you prefer for review/merge order.