Hamilton Nimbus Integration

Cody · July 9, 2025, 1:17am

Curious if anyone is working on integrating a Nimbus4 backend. Could potentially contribute as I’ve got a working Nimbus4 sitting in a home lab.

rickwierenga · July 9, 2025, 1:26am

welcome to the forum!

that would be amazing! afaik no one is currently working on it

others · October 15, 2025, 5:03pm

Have you made any progress on the Nimbus integration?

rickwierenga · October 15, 2025, 5:12pm

Nugget is shipping one to us. Once it arrives it will take a week or a couple of weeks to integrate it depending on how much time I have for it

others · October 15, 2025, 6:13pm

Awesome! I do have a Nimbus 4, but only the free VENUS 4 (STAR) version, which I think does not support the Nimbus.

Is there any way I could help? I’d be happy to run tests on my system if that would help.

rickwierenga · October 15, 2025, 6:17pm

I am very unfamiliar with this platform

what is ‘the free VENUS 4 (STAR) version’ and how does it differ from the ‘Nimbus’?

I’d definitely like to have people test it once we have something to work with!

others · October 15, 2025, 6:35pm

It’s Hamilton’s software for their fluid dispensing systems. It is catastrophically bad, to the extent that I don’t understand why anyone would ever buy a Hamilton system.

https://www.hamiltoncompany.com/venus

The software only runs on Windows and provides a http endpoint, which is used by the PyHamilton library, dgretton/pyhamilton. PyHamilton can’t run without VENUS, e.g. no Linux support either.

Hamilton does not provide any separate drivers or protocol documentation (despite the tool being hooked up by Ethernet, so it wouldn’t be hard to remote control directly), only VENUS. The current version is 6.3, I only have version 4 for the Microlab STAR.

Their API documentation is here: VENUS Web API

cwehrhan · October 15, 2025, 9:59pm

Ok this is all 6+ years ago:

there’s multiple Venus 4

One which works with Nimbus
One that works with STAR

There was also a tool that could convert STAR methods to NIMBUS, but you’d still have to go through manually and clean a bunch of stuff up.

If I remember correctly (if’s been a while) you connect a Nimbus over Ethernet, not USB. You select the port it resides on. It works differently than a STAR when connecting to Venus. The nimbus would go through this thing called device toolkit which was a Hamilton USA software driver. This device toolkit is also used on the MPE’s. I can’t remember the architecture more than that. I can’t remember how sending firmware commands would go. I think it would go VENUS→ Device toolkit → Nimbus

rickwierenga · October 16, 2025, 12:16am

thanks both for the explanations!

@others so you got a nimbus but only the free version of venus (4), which you say is not compatible with it? how do you currently use the nimbus then?

others · October 16, 2025, 1:18am

I am still trying to get mine to work, the SW version is from the labautomation forum. I connected via Ethernet and ran the SW, but it does not recognize the tool. I haven’t seen the device toolkit that cwehrhan mentioned yet, maybe because the SW is for STAR only.

I am not sure it’s ok to post the link here, but I’ll DM it. There is also a large collection of programming manuals for the tool.

cwehrhan · October 16, 2025, 1:44am

Post on the other forum if you’re trying to get Venus up and running, there’s lots of helpful ppl there tbh!

Yeah that Venus that is posted for download probs won’t work with a Nimbus. When I worked there I had separate VMs for Nimbus machines

Cody · October 16, 2025, 2:25am

Hey all, great that there’s some interest here!

Nimbus systems (At least pre-Venus 6 control software) run on a separate control software called “Hamilton for Biotech”. Seems like just a pared-down Venus 4 like the one on the labautomation forum. Many, but not all, HSL libraries that work in Venus 4 also work in Hamilton for Biotech.
Nimbus communicates through TCP/Ethernet. The Nimbus control software also includes a set of .dll files that make up a (quite poorly documented) .NET based firmware control layer that can be run through pythonnet keeping things OS agonistic.

I’ve added some bare minimum functionality within pylabrobot that let’s me connect, query config/status, and do basic things like door control and initialization. Currently in process of getting it into something that’s patterned like a liquid handler backend (STAR_backend for example) to share.

@rickwierenga : In terms of getting the Nimbus integrated into pylabrobot, what are your thoughts on utilizing the .NET interface that’s provided vs direct TCP communication in Python?

rickwierenga · October 16, 2025, 2:33am

interesting thank you!

is this through the dll or tcp?

like every other integration in PLR it will be a direct-to-firmware interface so we get full control, are OS-agnostic, and have no black box in the middle.

Cody · October 16, 2025, 2:54am

.dll, although the connection runs through a proxy so inspecting the corresponding traffic is straightforward. Figured this would be the easiest approach to reverse engineer direct control through TCP only. I’m not aware of any firmware reference outside of this .dll library and its corresponding documentation.

Would be happy to share any of this if it helps when that system from Nugget arrives.

Got it, so if I understand, no .dll libraries in the middle.

rickwierenga · October 16, 2025, 2:57am

please!

others · October 16, 2025, 5:52am

@Cody Thank you for your comments, this is very helpful. I couldn’t find any reference to the software, do you know whether this SW is available anywhere?

april · October 16, 2025, 2:43pm

It’s basically the same protocol as the ML Prep. I’ve never targeted the Prep so I forget if it’s identical but, if it’s not, it’s very close

github.com/escalante-bio/piglet

piglet_client/src/connection.rs

main

use bytes::{Buf, BufMut, Bytes, BytesMut};
use std::collections::HashMap;
use std::sync::{Arc, Mutex};
use std::time::Duration;
use tokio::{
    net::tcp::{OwnedReadHalf, OwnedWriteHalf},
    net::{TcpStream, ToSocketAddrs},
    sync::{mpsc, oneshot},
};

pub struct Connection {
    protocols: Arc<Mutex<HashMap<u8, mpsc::Sender<Bytes>>>>,
    stop_tx: oneshot::Sender<()>,
    task: tokio::task::JoinHandle<()>,
    version: u8,
    writer: OwnedWriteHalf,
}

impl Connection {
    pub async fn close(self) -> Result<(), anyhow::Error> {

This file has been truncated. show original

rickwierenga · October 16, 2025, 3:55pm

wow, looks very similar to the prep indeed!

I should really merge the prep branch soon. here I have the harp2/hoi2/ip layers.

after that integrating the nimbus into plr should be straightforward. it should just be a matter of getting the correct module/node/object ids and parameters into every command.

Cody · November 3, 2025, 7:26pm

Took a crack at a direct interface. No need for the DLL files with this one!

This notebook implements their IpPacket→Harp2→Hoi communication layer over tcp, with some convenience wrappers for writing interface+method ids+parameters you’d send to run a command and get its output. Not terribly different from STAR once you’re over the wire protocol.

Will add an example with initialization + some pipetting commands (like aspirate) and some logs of the corresponding traffic sent over tcp soon. Just need to pull the method ids from 1.1.257 (the pipetting interface in the notebook) and that should do it.

Thanks @april for linking that example of their introspection interface in Piglet. Used some of those patterns here and it was a great example!

rickwierenga · November 3, 2025, 7:26pm

this is amazing @Cody !