Search these docs, or ask Revo a question — answers link the pages they came from.
Lynx LM1800
Dynamic Devices Lynx LM1800 Lynx liquid handler with the largest deck and volume-verified pipetting. The Dynamic Devices Lynx LM1800 is the largest deck in the Lynx line of automated liquid handlers. What sets the Lynx apart is Volume Verified Pipetting (VVP): Dynamic Devices states that it calculates the actual volume of fluid entering and leaving each tip in real time, and describes the Lynx as the only automated liquid handler offering direct volumetric measurement of every transfer. VVP tools can also run a different volume on every channel of a 24- or 96-channel head at the same time.
The Lynx line shares one platform across five deck sizes — LM1800, LM1200, LM900, LM730i and LM700 — built on linear magnetic motors and encoders and a solid-mandrel tip-loading design with no O-rings or tip seals. Dynamic Devices states the chassis is open for integration from all four sides, and that the instrument is programmed in its own MethodManager4 software.
In Revolution, this driver is a scaffold. It registers the LM1800 so that a system can be configured against it, and nothing more: it opens no connection and sends no command. The rest of this page is precise about where that line falls.
At a glance
Section titled “At a glance”| Type | Automated liquid handler with Volume Verified Pipetting (VVP) |
| Deck | 60–66 SBS positions, per Dynamic Devices |
| Pipetting | 96VVP and 24VVP multi-channel tools, 8-channel; Standard Technology (ST) tools |
| Instrument software | MethodManager4 |
| Revolution transport | None — the driver opens no connection |
| Revolution control | None. One diagnostic operation that writes to the Revolution log |
Specifications
Section titled “Specifications”Dynamic Devices publishes the following deck sizes for the Lynx line on its technology page. Figures are in inches.
| Model | Length | Width | Height | Deck positions |
|---|---|---|---|---|
| LM1800 | 75.7 | 36.5 | 41.8 | 60–66 |
| LM1200 | 52.2 | 36.5 | 41.8 | 42 |
| LM900 | 40.5 | 36.5 | 41.6 | 30 |
| LM730i | 28.8 | 33.1 | 41.6 | 18 |
| LM700 | 27.6 | 28.6 | 33.2 | 12 |
Further published figures for the platform:
| Worktable | SBS-compliant microplate footprint at each position; 96 or 384 tips loadable from any of 66 worktable locations |
| 24VVP tool | 24 channels with variable-volume control, 50 µL to 5 mL |
| Motion | Linear magnetic motors and encoders |
| Tip loading | Solid mandrel, no O-rings or tip seals |
| Integration | Open chassis, integration from all four sides; horizontal conveyors and vertical integration through the worktable |
| Software | MethodManager4, with an API pathway for communication with third-party devices |
Dynamic Devices gives the LM1800 deck as 60–66 positions in its model table and 66 worktable locations in its platform description; the exact count depends on how the deck is configured. No per-model volume range is published for the 96VVP or 8-channel tools.
Supported methods
Section titled “Supported methods”None that reach the instrument. The driver declares a single operation, Debug, which writes the message it is given to the Revolution device log and does nothing else. Initialising the device writes a log line and likewise talks to no hardware.
In practice that means a schedule cannot start a MethodManager4 method, load tips, pipette, or read the instrument’s state or VVP volume records. Anything the LM1800 does while it is part of a Revolution system is started by an operator in MethodManager4, not by Revolution.
The driver declares no fixed set of locations. Any deck location a mover uses to place or pick labware is defined in the system configuration, and Revolution treats it as a plain stop on the labware’s route.
Integration
Section titled “Integration”Revolution reaches the LM1800 only as a configured device. There is no transport, no vendor software in the path and no process model. Dynamic Devices states MethodManager4 offers an API pathway for communication with third-party devices; the Revolution driver does not use it.
Prerequisites
Section titled “Prerequisites”- Methods must be written and run in MethodManager4 at the instrument. A schedule step cannot start one.
- If a mover exchanges labware with the deck, the locations must be taught, and timing must be arranged by hand. Because Revolution cannot ask the LM1800 whether it is busy, a schedule cannot wait on a method finishing.
Device configuration
Section titled “Device configuration”| Property | Purpose |
|---|---|
| — | The driver declares no configurable device properties. Only the standard device settings — name and locations — apply. |
If you need more of this instrument driven from a schedule, get in touch — the driver is extended on demand.
Operations
These are available from a Run Device Operation step.
Debug
Writes the given message to the device log and does nothing else. This driver is a scaffold awaiting implementation, so no command reaches the instrument.
| Parameter | Type | Default | Description |
|---|---|---|---|
| message | string | Lynx LM1800 debug |
Raise Error
Makes this device report a failure on demand: the step fails with an error naming the device, and the operator is offered the usual error recovery choices. No command reaches the instrument and nothing moves, and the failure is raised in simulation as well as on a real system, so this is the step to use when rehearsing how a schedule handles a device failure.