Hey all,
I’ve been poking around at adding Echo 650 support to PLR and wanted to check in before going too far down the rabbit hole.
Some context: I’ve been working with an Echo 650 for compound management (DMSO transfers, serial dilutions, assay plate prep) and got curious about what the instrument actually does under the hood. Turns out the Echo server exposes a SOAP/XML API over HTTP on port 8000 — no encryption, no auth, just gzip-compressed XML. I captured traffic with Wireshark during a cherry pick run and was able to decompress and read every command.
So far I’ve mapped out ~42 SOAP commands covering the full workflow: instrument status queries, plate surveys, gripper control, session management, and the actual transfer execution (DoWellTransfer). The transfer command takes a straightforward XML payload — source well, destination well, volume in nL, done. It’s honestly simpler than I expected.
The thing I’m less sure about is how this would fit into PLR’s architecture. The Echo isn’t really a traditional liquid handler — there’s no tips, no aspiration/dispense cycle. The core operation is just “move X nL from source well A to destination well B using sound.” So I don’t think it maps cleanly onto the existing LiquidHandler/LiquidHandlerBackend abstraction.
I’m thinking it might need its own module (something like pylabrobot.acoustic_dispensing) with:
- An abstract backend defining survey(), transfer(), etc.
- A frontend that handles plate state, transfer validation, batch operations
- The Echo 650 as the first concrete backend
But I could also see an argument for fitting it under liquid_handling with a different set of abstract methods. Curious what people think.
A few specifics on what I’ve figured out so far:
- Protocol: SOAP XML over HTTP, gzip compressed
- Two ports: 8000 for commands, 8010 for event/log streaming
- Key commands: PlateSurvey, SetPlateMap, DoWellTransfer, BeginSession/EndSession, plus gripper and coupling fluid management
- Transfer volumes specified in nL with fractional precision (e.g. 2625, 3937.5)
- The instrument identifies as a client/server system — multiple clients can connect
Happy to share the full protocol analysis if anyone’s interested. Would also appreciate any thoughts on the architecture question before I start writing code.
Thanks!
5 Likes
awesome! thanks for the interest in adding this! this would be super useful.
we are actually working on remodeling the front end interface to plr right now (see long thread Updating PLR API for machine interfaces discussion).
Would it be possible for you to write the ‘backend’/driver first? (it won’t inherit from an abstract backend yet) Just with a good guess at what functions could be the atomic commands for it, which can be refactored later also. I’d be happy to merge that. Then we can work on a front end interface for dispensers after that, which will probably be after the big refactor. (I know some people are working on the Mantis as well, and we are getting an i-dot soon, so maybe some things can be shared among those …)
ps: saw on your GitHub you’re in Redwood City too! let’s grab coffee some time 
3 Likes
Right on! Sounds good on the frontend/backend thing, I’ll get cranking on it and will stay tuned on the status of the frontend refactor as well. I’ve spent some time over the last few days working to understand the repo and think I could get a functional backend within a week or so.
And would love to grab a coffee! Just added you on X.
1 Like
Hi Alex,
how is the PLR integration going? Is your code of your initial driver somewhere on git?
For context: We have an Echo550 here in our university and I have spent quite some time figuring out its API and integrating it. In the end we got the Echo SDK for free and I wrapped it into a SiLA2 server.
But since the SDK uses some ActiveX 32bit .dll, that requires a windows computer and internal communication layers.
Your solution sounds much better.
1 Like
Hi @Stefan_M sounds super cool. How did you get ECHO SDK? Did you write to Backman?
Forget Beckman. I heavily recommend LabMachines. They consist of ex-labcyte personal, have been much more helpful including giving away the echo-SDK, and their rates are cheaper (also still expensive). The SDK used to be free before backman bought labcyte and started charging enormous sums for it.
3 Likes
Building on @alexgodfrey’s great work on the Echo 650 - I just added Echo 525 support on top of it.
Turns out the 525 speaks the identical Medman protocol (same POST /Medman, gzip SOAP, RPC set and transfer XML); the only real difference is droplet granularity: the 525 dispenses in 25 nL increments vs the 650’s 2.5 nL (confirmed on the wire via GetTransferVolIncrNl).
We verified it against a Wireshark capture of a physical 525 running a HiFi PCR reformat, so it’s grounded in real device traffic rather than guesswork. Implementation is reuse-don’t-fork: a thin Echo525/Echo525Driver over the 650 driver, plus an EchoMockServer that replays captured device responses so you can drive the backend end-to-end with no hardware.
PR (stacked on the 650 branch): Add Labcyte Echo 525 support by c-reiter · Pull Request #5 · alexjamesgodfrey/pylabrobot · GitHub
3 Likes
