Search these docs, or ask Revo a question — answers link the pages they came from.
Labcyte Echo
The Echo acoustic liquid handler transfers liquid by focusing ultrasonic energy at the
meniscus of a source well and ejecting a stream of droplets into an inverted destination
plate — no tips, no nozzles, no tubing, and nothing that touches the sample. Beckman Coulter
describes the underlying technique as Acoustic Droplet Ejection, paired with Dynamic Fluid
Analysis, which uses sound to determine fluid composition and height and adjusts transfer
parameters in real time “without recalibration”. The vendor API this driver builds against
is shipped under the Labcyte.Echo namespace.
At a glance
Section titled “At a glance”| Technology | Acoustic Droplet Ejection — non-contact transfer, no tips or tubing; Dynamic Fluid Analysis adjusts for fluid type and height in real time |
| Generation driven | Echo 550 series (Echo 550, 555, and 21 CFR Part 11 enabled versions) |
| Instrument software | Beckman’s own Echo applications — Echo Plate Reformat, Echo Cherry Pick, Echo Dose-Response — remain the place protocols are authored |
| Revolution control | Run a loaded protocol, cherry pick, dose response, plate reformat, full or partial source-plate survey |
Specifications
Section titled “Specifications”The Revolution driver was built against the Labcyte Echo API. Beckman states the Echo 550 series “entered obsolescence effective March 1, 2021, at which point sales for those models ended”, and that “All eligible Echo 550 instruments will be supported by our service department for 5 years from the date of obsolescence”. Its named successor is the Echo 650 series, which Beckman in turn describes as “replaced by the Echo 650 Plus Series”.
Beckman Coulter’s current catalogue — the Echo 650 Plus Series and the Echo 525 — is not what this driver targets. If you are integrating a current-generation Echo rather than a 550 or 555, treat the driver as a starting point and talk to us — the transport and the vendor API version both change across those generations.
Supported methods
Section titled “Supported methods”Each operation maps onto one of Beckman’s own Echo applications, so the protocol and the pick list stay where the Echo scientist already authors them, and Revolution decides when they run and against which plates.
- Run loaded protocol — run a protocol by name (
protocolName), with atimeoutthat defaults toNever. Use this for a fixed transfer map that does not change run to run - Run cherry pick protocol — run a protocol by name against a separate pick-list file
(
protocolName,pickListFilename,timeout). This is the operation for hit picking and any sparse, run-specific transfer map, because the pick list is a per-run input rather than part of the protocol - Run dose response — run a dose-response protocol by name (
protocolName,timeout), through Beckman’s Echo Dose-Response application - Run plate reformat — run a plate-reformat protocol with a pick-list file
(
protocolName,pickListFilename,timeout) - Run full plate survey — survey the whole source plate (
timeout). The survey is what tells the Echo how much fluid is in each well and of what type; a schedule that has just had a fresh source plate placed will usually want one - Run full plate type survey — survey the whole plate for a specific plate type
(
plateType,timeout). The driver describes it as a full plate survey for a specific plate type, so use it where the plate type must be stated rather than taken from the plate record - Run region plate survey — survey a rectangular region only (
startRow,startCol,totalRows,totalCols,timeout). Surveying only the wells a run will actually touch is materially quicker than a full plate survey, which matters when the survey sits on the critical path between two robot moves
The timeout on every operation defaults to Never, meaning the schedule waits for the Echo
to finish rather than abandoning the run. Set a real timeout only if you would rather the
schedule fail than block.
Integration
Section titled “Integration”Revolution does not load the vendor API in-process. The driver is a WCF client that talks
over HTTP to a separate remote server process on the Echo PC, and that process is what holds
the Labcyte.Echo API assemblies and the COM interops the Echo software brings with it. The
split is deliberate: the vendor stack is 32-bit, COM-heavy and long-lived, and keeping it in
its own process means an Echo-side fault does not take the scheduler with it.
Plate identity is tracked in a plate database, so a barcode read on the way into the Echo can be tied to the run that used it. On placement, the driver reads the barcode and plate type from the location, resolves whether it is the source or the destination position, retracts the gripper, and can start a background survey there and then rather than waiting for an explicit survey operation.
Because the vendor process is long-lived and stateful, the driver can also be configured to relaunch the remote server periodically — a pragmatic guard for unattended overnight runs.
Prerequisites
Section titled “Prerequisites”- The Echo instrument software and its Labcyte API assemblies must be installed on the Echo PC. Revolution drives that software; it does not replace it, and protocols and pick lists are authored in Beckman’s own applications
- The remote Echo server process must be running and reachable on the configured URL before the device is initialised. Initialisation connects to it and toggles the grippers, and it fails outright if the server is not there
- The device needs exactly two locations defined, and the source and destination location names must be configured — the driver decides how to treat a plate based on which of the two it landed in
- A plate database connection is required if plate and run tracking is wanted
Device configuration
Section titled “Device configuration”| Property | Purpose |
|---|---|
| URL | Address of the remote Echo server process. Must match what that process serves on |
| Echo Name Or IP | The Echo instrument itself, as the vendor software addresses it |
| Source Location | Name of the Revolution location the driver treats as the source plate position |
| Destination Location | Name of the Revolution location the driver treats as the destination plate position |
| Plate DB Connection | Connection string for the plate database used to track plates and runs |
| Run Background Survey On Load | Start a source-plate survey automatically when a plate is placed, instead of waiting for a survey operation |
| Background survey timeout | How long that automatic survey is allowed to take |
| Relaunch Server Active | Whether the remote Echo server is relaunched periodically |
| Relaunch server cycles | How many run cycles between relaunches |
| Service Name | Windows service name used when the server is relaunched |
If you need more of this instrument driven from a schedule, get in touch — the driver is extended on demand.