Is someone working on the PyHamilton for Linux feature?
I would be very interested in working on this feature.
1 Like
Not exactly, PyHamilton communicates with the robot through Venus, which is a Windows only application.
We also reverse engineered much of the functionality of Venus into an entirely open source Python library called PyLabRobot. It definitely does not have everything Venus has, but it has a lot of stuff Venus doesnt have. I recommend checking it out!
3 Likes
3 Likes
Thank you for the clarification! I will be checking out today the whole software.
Took a good look on the Hamilton backend and Clario Start module and it’s a excelent software. I’m very surprised by the ammount of effort to programatically automate Hamilton.
How was the process of reverse engineer the Hamilton? Because from the liquid handling backend file, it seems that you have to know a lot of specifities.
2 Likes
We mostly used PyHamilton to send commands through Venus and then looked at logs of firmware commands sent to the robot, and reverse engineered these. We also had firmware documentation for reference.
1 Like
Just thinking about it, you could almost have a server running on the same host as the PC running Venus/connected to the Hamilton, and then send your JSON/requests to that server, instead of it being all local…
That is actually how it works, if I understand what you are describing correctly. Venus hosts a server that takes JSON-formatted HTTP packets from the Python process running PyHamilton. We still keep everything on the same PC, but it’s asynchronous server based communication.
Does the Venus server run on a host accessible to other computers in the LAN?
If not, it’d be easy to proxy using something like this: https://mitmproxy.org.
Some weeks ago I was inspired by a presentation about cloud labs and started looking for some opportunities to work with a liquid handling machine and found a laboratory in my city that has a Hamilton Starlet.
My first idea was to develop an experience of working on the Hamilton much like it would be using a cloud server (and programmable as such). I was very skeptical of this plan at first because of the proprietary software. Taking a good look at PyLabRobot, I was very happy to see a library solving this problem by connecting directly with the machine, instead of wrapping around the proprietary software (at least an important part of the machine features).
So thanks for solving the most important part of the problem. My plan now is to use a raspberry pi zero to connect via SSH to the Hamilton and run some python pylabrobot script through it and improve from there.
2 Likes
So thanks for solving the most important part of the problem. My plan now is to use a raspberry pi zero to connect via SSH to the Hamilton and run some python pylabrobot script through it and improve from there.
That’s a very cool implementation idea.
I think PyLabRobot - STAR is definitely the way to go if you want to invest in a foundation where you will never be limited in the ability to create abstractions. We don’t have as nice of a simulator or layout editor, but we do have a dynamic and programmatic way of modifying the deck state at run time (in any liquid-handler deck) based on a generic resource description model.
1 Like
I’d love to know which presentation inspired you!
Also have a look at LH server in PLR! It’s a basic HTTP server that exposes an API for LH. It’s quite limited at this point, but I’d be happy to work on expanding it! (locally, I already started working on a task oriented version of it)
1 Like
Nice, @rickwierenga! My working it’s getting easier and easier! I will be using LH for the prototype.
One question that I have: How safe it’s to work with USB and FTDI communication for Hamilton machines? Did you guys somehow break Hamilton in an interesting way during the reverse engineering step or while running pylabrobot during development?
I would like to measure some of the risks associated, besides the fact that is not an official library of Hamilton. The laboratory I will be working with use the Startlet weekly for experiments, so I want to know the probability of leaving them without the machine until finding a solution even if some problem emerges.
The presentation was on Groove discord channel (a supported community powered by Ginkgo Bioworks) and it was given by Doug Densmore. He’s a Boston University professor, have a automated laboratory inside the university called DAMP Lab, and he’s founder of some companies, including the one I’m working on called Lattice Automation (is a software house for synthetic biology).
1 Like
I’d say quite safe. We have not had any serious/lasting problems at all when developing the STAR actually! Obviously, it is important to pay attention and not do anything stupid, probably a little more than with Venus, as you can shoot yourself in the foot if you really wanted to. However, I’d say that if you stick to using LH, PLR is extremely safe to use now.
If you do decide to dig into the lower level layers more, a useful tip is to have a Venus machine available in case something unexpected happens. In my experience, Venus almost always has a way of automatically resolving the issue. Also, @Stefan has seen any problem a Hamilton can possibly have, and I’m sure he’d be happy to help as well.
Any chance this is recorded somewhere? 
I ask them right now for the recording. I will put it here if they answer me.
1 Like
Perfect. Thanks for you guys being so helpful.
Hi, I was checking the Star backend file and it says on some features SFCO.
What is SFCO?