Skip to content

Search these docs, or ask Revo a question — answers link the pages they came from.

Hamilton Microlab NIMBUS

Revolution ships two device entries for the Hamilton Microlab NIMBUS: Hamilton Nimbus ICC and Hamilton Nimbus Demo. They are not the same driver, and it is worth being precise about which is which, because their names invite the wrong assumption in both directions:

  • Hamilton Nimbus ICC is declared in the exact same driver file (HamiltonVenusFiveDevice.cs) as Hamilton Star ICC, Hamilton Starlet ICC, Hamilton Vantage ICC and StarV with extension. Structurally, it is one of those VENUS ICC devices — same driver, same operations — just carrying the NIMBUS model and description instead.
  • Hamilton Nimbus Demo comes from a separate, much smaller driver (HamiltonNimbus384.cs) that does not talk to VENUS, or to any instrument protocol at all. It exposes exactly one operation that just holds the schedule for a configured duration — see below.

Both classes’ own driver source describes itself as controlling “The Hamilton Nimbus 384 liquid handler”, which is the only concrete NIMBUS configuration either entry names.

NIMBUS384 is no longer part of Hamilton’s current Microlab NIMBUS lineup — Hamilton’s product page today lists NIMBUS4, NIMBUS96 and NIMBUS HD instead, and those platform descriptions are not reproduced here because neither Revolution device entry corresponds to them. Installed NIMBUS384 units are still in the field, so its published figures are recorded here for reference. Hamilton’s launch announcement for that configuration states:

  • 384 50 µL air-displacement multi-probe heads, pipetting in 384, 96, quadrant, column, row and single-tip formats
  • A dynamic pipetting range of 0.5 µL to 50 µL
  • An ultra-flat deck with 11- and 12-position layouts, allowing tip stacking and 1,536 pipetting automation

Software on the original NIMBUS384 differed from VENUS too: the launch announcement describes dedicated Microlab NIMBUS software with two programming routes — vector-based and a wizard-driven graphical interface — both stated as 21 CFR Part 11 compliant, rather than the VENUS software the ICC driver talks to. That mismatch is one reason to check, on a real installation, which of the two device entries below actually matches how a given NIMBUS384 unit is being run.

This entry drives a NIMBUS through Hamilton’s VENUS software, using the same VENUS ICC work-step driver as the Star/Starlet/Vantage/StarV entries. The instrument keeps its full pipetting capability, and the schedule decides when each piece of work runs.

PlatformHamilton NIMBUS (VENUS ICC)
Pipetting technologyAir displacement with CO-RE; CO-RE II tip/tool attachment
Instrument softwareVENUS (required — Revolution runs VENUS worklists and work steps, it does not replace them)
Revolution controlRun a worklist, run a named work step, continue, abort, liveness check
  • Execute worklist — run a VENUS worklist CSV on the instrument. The parameter is the full path and folder of the worklist file, with a timeout
  • Execute work step — run a single work step: the method name (for example LoadLabware, Alive, HomeArm) and its parameter/value pairs, compiled into the VENUS exchange payload at runtime, with a timeout
  • Continue VENUS work step — send the ICC Continue step, releasing a VENUS instance that is holding a work step open after a recoverable error or a pause. VENUS then does whatever the operator chose in its own dialog
  • Abort VENUS work step — send the ICC Abort step, telling VENUS to abandon the running work step and return to idle, so the step can be re-sent
  • Is alive — check that the VENUS connection is responding
  • Abort worklist locally — stop Revolution waiting on the current worklist. This sends no abort to VENUS; the run continues on the instrument

Control goes through VENUS, over one of two interfaces: a file exchange on the instrument PC, or the VENUS REST API. The mode is a device setting, and it determines which of the configuration properties below are in use.

Prerequisites:

  • VENUS must be installed and configured on the instrument PC, with the methods and worklists the schedule will call already present. Revolution runs them; it does not author them.
  • In file-exchange mode, the exchange folder must exist and be writable by both VENUS and the Revolution host.
  • In REST mode, the VENUS REST server must be running and reachable from the Revolution host, and its authentication token known.
  • Deck layout in VENUS and the cell layout in Revolution must agree on the positions a mover will load and unload.

Device configuration:

PropertyPurpose
Venus Communication ModeFile exchange or REST API. Selects which properties below apply
File Exchange FolderFolder the driver and VENUS exchange files through, in file-exchange mode
Master To Venus FilenameFile Revolution writes work steps into
Venus To Master FilenameFile VENUS writes its responses into
Venus Exchange FormatFormat of those exchange files
Venus REST base URLAddress of the VENUS REST server, for example https://127.0.0.1:12345
Venus REST authentication tokenSent as the token query parameter
Status poll intervalMilliseconds between GET /status polls
Request timeoutPer-request HTTP timeout in milliseconds
Accept self-signed certificateAccept a self-signed TLS certificate from the VENUS REST server, which is typical when that server runs on localhost
PrePostLoading WorklistWorklist run around loading, to keep the VENUS deck model in step with what a mover has put on the deck
Temporary FileFull path of the driver’s scratch file

A transfer-capable variant of the device adds Venus Device Name (the instrument’s name in VENUS), Transfer Filename, and Ensure Column Transfers, which routes labware within the same column when a deck position is otherwise unreachable for the system.

This entry does not talk to VENUS, or to a real NIMBUS at all. Its driver (HamiltonNimbus384.cs) defines exactly one operation:

  • Operation1 — holds the schedule thread for a configured duration, then returns. Nothing is sent to any instrument.

There is no worklist execution, no work-step interface, and no device configuration beyond the device’s position in the cell layout. Treat this entry as a placeholder that occupies schedule time where a NIMBUS sits in the layout, not as a live integration — for actual VENUS-driven control of a NIMBUS, use Hamilton Nimbus ICC above.

If you need more of this instrument driven from a schedule, get in touch — the driver is extended on demand.