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.
The NIMBUS384 configuration
Section titled “The NIMBUS384 configuration”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.
Hamilton Nimbus ICC
Section titled “Hamilton Nimbus ICC”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.
At a glance
Section titled “At a glance”| Platform | Hamilton NIMBUS (VENUS ICC) |
| Pipetting technology | Air displacement with CO-RE; CO-RE II tip/tool attachment |
| Instrument software | VENUS (required — Revolution runs VENUS worklists and work steps, it does not replace them) |
| Revolution control | Run a worklist, run a named work step, continue, abort, liveness check |
Supported methods
Section titled “Supported methods”- 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
Continuestep, 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
Abortstep, 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
Integration
Section titled “Integration”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:
| Property | Purpose |
|---|---|
| Venus Communication Mode | File exchange or REST API. Selects which properties below apply |
| File Exchange Folder | Folder the driver and VENUS exchange files through, in file-exchange mode |
| Master To Venus Filename | File Revolution writes work steps into |
| Venus To Master Filename | File VENUS writes its responses into |
| Venus Exchange Format | Format of those exchange files |
| Venus REST base URL | Address of the VENUS REST server, for example https://127.0.0.1:12345 |
| Venus REST authentication token | Sent as the token query parameter |
| Status poll interval | Milliseconds between GET /status polls |
| Request timeout | Per-request HTTP timeout in milliseconds |
| Accept self-signed certificate | Accept a self-signed TLS certificate from the VENUS REST server, which is typical when that server runs on localhost |
| PrePostLoading Worklist | Worklist run around loading, to keep the VENUS deck model in step with what a mover has put on the deck |
| Temporary File | Full 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.
Hamilton Nimbus Demo
Section titled “Hamilton Nimbus Demo”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.