Hamilton liquid handler (pyhamilton.HamiltonInterface) — device market

Install

Three ways to run this device. Each one serves its fake backend: no instrument, no simulator install and no upstream checkout.

OpenAI4S (one command)

shell

openai4s lab add labs/dgretton__pyhamilton

Installs the device into the OpenAI4S Lab on its fake backend and starts it. First time? See setup below.

Or, in the workbench, open the Lab tab → Market → Install.

Standalone MHS endpoint

shell

git clone --depth 1 https://github.com/PKU-YuanGroup/OpenMHS.git && cd OpenMHS
PYTHONPATH=MHS/sdk/src python3 -m mhs serve labs/dgretton__pyhamilton --port 7400
# in a second terminal, from the same directory:
PYTHONPATH=MHS/sdk/src python3 -m mhs describe --endpoint http://127.0.0.1:7400

Serves the device as an MHS endpoint on port 7400 from an OpenMHS clone (Python 3.10 or later, standard library only); describe prints what it offers.

Any MCP host (Claude Desktop, Cursor, …)

mcp configuration

{
  "mcpServers": {
    "pyhamilton": {
      "command": "python3",
      "args": [
        "-m",
        "mhs",
        "serve",
        "labs/dgretton__pyhamilton",
        "--mcp"
      ],
      "env": {
        "PYTHONPATH": "/path/to/OpenMHS/MHS/sdk/src"
      }
    }
  }
}

Add this server to the host's MCP configuration and replace /path/to/OpenMHS with the path of your OpenMHS clone. The host starts the server and talks to it on stdin and stdout.

What it does

Measures

is_open
server_exited

Adjusts

Nothing declared.

Actions

initialize: Initialize the Hamilton robot (the upstream INITIALIZE command) and wait for its response
aspirate: Aspirate a volume from one well with one pipetting channel and the named Hamilton liquid class; it does not attach or eject a tip
dispense: Dispense a volume into one well with one pipetting channel and the named Hamilton liquid class; it does not attach or eject a tip
move_plate: Move a plate from one Hamilton sequence to another with the iSWAP (ISWAP_GET then ISWAP_PLACE)
set_labware_property: Set one property of one labware item in the Hamilton run (the upstream SET_LABWARE_PROPERTY command)
shutdown_interface: Stop the Hamilton interface (the native stop): signal the server thread and terminate the OEM process; it takes no input
start_interface: Start the Hamilton interface again after a safety reset (the declared re-enable): HamiltonInterface.start() relaunches the OEM process (or the server or simulation process) that the stop terminated; the clone does not say whether that start moves the instrument. It takes no input, is refused while the e-stop is latched and is never run by the reset

Names as the driver declares them. Units, limits and the safety declaration are in the package's REFERENCE.md.

First-time setup

The OpenAI4S workbench with the OpenMHS lab, from a source checkout:

shell

# OpenAI4S workbench with the OpenMHS lab (source checkout)
git clone --recursive https://github.com/PKU-YuanGroup/OpenAI4S.git
cd OpenAI4S && ./setup.sh && source .venv/bin/activate
openai4s lab add labs/dgretton__pyhamilton
openai4s serve        # open the Lab tab

The standalone endpoint and the MCP server need only an OpenMHS clone and Python 3.10 or later. More in the market's getting-started guide and on the OpenAI4S host page.

Source and evidence

Upstream: dgretton/pyhamilton
Pinned commit: 65938d05cc8f
Licence: MIT
Stars: 192
Evidence: contract_checked on the fake backend
Backends: fake, hardware

The driver package MHS/drivers/labs/dgretton__pyhamilton wraps the upstream code at the pinned commit. Its REFERENCE.md documents the full contract: every value, action, unit, limit and the safety declaration.