Hamilton Star ICC

The Hamilton Star ICC device entry drives a Hamilton Microlab STAR channel-based liquid handler. STAR is programmed and run in Hamilton’s VENUS software; Revolution drives it through VENUS rather than talking to the instrument directly, using Hamilton’s instrument control concept (ICC) work-step interface. The instrument keeps its full pipetting capability, and the schedule decides when each piece of work runs.

Star ICC, Hamilton Starlet ICC, Hamilton Vantage ICC, StarV with extension and the generic Hamilton Venus 5 entry are all the same Revolution driver with the same operations — picking the entry that matches the physical instrument just gets the right model into the cell layout. The same driver also backs the Hamilton Nimbus ICC entry, for the NIMBUS platform.

At a glance

Platform	Hamilton Microlab STAR
Pipetting technology	Air displacement with CO-RE II tip/tool attachment
Deck capacity	55 ANSI/SLAS positions
Pipetting range	1 µL – 5000 µL, depending on configuration
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

Specifications

Figures below are Hamilton’s published numbers for the Microlab STAR. Every pipetting figure is qualified by Hamilton as depending on configuration, so treat the ranges as the envelope of what can be ordered rather than what any one instrument does.

1 mL channels	up to 16
5 mL channels	up to 8
Multi-probe head	96 and/or 384
Device integration	180° (left and right)
Sample loading	automatic, continuous
Height	90.3 cm
Width	1.66 m
Depth	78.1 cm – 1.01 m
Weight	145 kg

Hamilton also states the STAR Line supports up to 66 tracks and “up to 55+” ANSI/SLAS positions with devices integrable on the left and right sides. Device integration decides which side a mover can reach the deck from — worth checking against the physical cell layout before commit.

Pipetting and monitoring technologies

These are Hamilton platform technologies, fitted according to configuration. Revolution does not select them; the VENUS method does.

• CO-RE II tip/tool attachment — precise tip alignment and faster tip coupling, with a range of Hamilton tools also attachable
• Aerosol-free tip ejection — part of CO-RE II, to prevent cross-contamination
• MAD (Monitored Air Displacement) — identifies clots, empty wells and other aspiration issues, and confirms successful aspiration, per channel
• TADM (Total Aspiration and Dispense Monitoring) — real-time pressure monitoring per channel against expected values, with a digital audit trail on each transfer
• Dual LLD — a capacitance sensor for aqueous and conductive liquids plus a pressure-based sensor for non-conductive, viscous and volatile liquids; cLLD alone where only capacitance sensing is fitted
• ADC (Anti-Droplet Control) — pressure sensors compensate for variation to prevent droplet formation, for volatile liquids such as ethanol and acetonitrile
• LFC (Liquid Fractionation Control) — pressure-based detection of liquid interfaces in layered samples, aliquoting up to 16 samples at once with full traceability
• DPS (Dynamic Positioning System) — all channels pipette simultaneously, including across non-uniform patterns, for cherry picking and variable-volume work
• CO-RE Gripper, Internal Plate Gripper and Plate Gripper — on-deck labware transport, with the Plate Gripper also able to reach nearby off-deck devices (access location is platform-specific)
• Autoload — 1D barcode scanning of samples, carriers and consumables as they are loaded, with optional 2D reading

TADM is the one worth knowing about for regulated work: it is Hamilton’s per-transfer audit trail, and it is produced by the VENUS method, not by Revolution.

Supported methods

The pipetting itself is defined in VENUS. Revolution’s job is to trigger the right work at the right point in a schedule, using Hamilton’s instrument control concept (ICC) work-step interface.

• 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

The timeout on the two execute operations is the schedule’s only protection against a VENUS method that never returns, so set it from the real duration of the method rather than leaving a default in place. And the difference between Abort VENUS work step and Abort worklist locally matters at recovery time: only the first one stops the instrument.

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

The PrePostLoading Worklist is the setting people miss. When a mover places labware on the deck, VENUS has not seen it arrive; the short worklist configured here is what tells VENUS the deck changed. Without it, the next method can run against a deck model that no longer matches reality.

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.

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