Echo 650 acoustic dispenser — interest in adding support?

dev discussion
1

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!

4 Likes
2

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 :slight_smile:

3 Likes
3

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