Temp control device - Venus

Hello,

PyLabRobot uses firmware commands to send commands to Hamilton systems. Thus, if I wanted to integrate a HeaterShaker or HeaterCooler how would I create that backend? Do I need to reverse engineer those firmware commands?

Thanks,
Bradley

Yes. What I did when creating the STAR backend is look at the log files created by Venus.

We also got the firmware documentation for STAR. I believe you should ask Eric from Hamilton about that (he’s on the forum too!).

1 Like

Got it. I have to admit I am not keen on that but I will give it a try. I’ll start with looking at the firmware documentation. Can you point me in the right direction?

I’d recommend sending some simple commands using a Venus script and checking what firmware commands are being sent. Then you can send those same commands using Python. How depends on the type of connection. Does your module connect to your main computer, or the the STAR itself?

Also, if you have an hsl file (Venus library) for the module that’s very helpful. You can open those in VSCode (select c++ syntax highlighting) and get a good sense of the module functionality.

Thanks! I’m going to run create a simple method as you said and see what I get. I appreciate it.

Hey @BirdBare what progress did you make on this? I’m interested in the same thing, and hoping I don’t have to work totally from scratch.

Sadly I did not make it very far. I looked into the trace but did not see any firmware commands. I realized I use the temperature devices by USB.

I do not have any “hacking” or reverse engineering skills so I immediately had to stop and work on other projects.

Hi @BirdBare, are you using the Hamilton Heater Shaker (HHS) and the Hamilton Heater Cooler (HHC)?

If yes, how many of each device are connected to your setup?

We have 3 HHS and 1 HHC right now

That’s fantastic: it means you must be controlling your devices through a Heater Shaker Box (HSB) for which PLR has no integration yet, giving us the opportunity to create one.

In general, there are 2 ways you can control these devices based on how many devices in total you have:

  • For up to 2 devices you can simply plug them into the STAR directly. That means they can be controlled using firmware commands. I am writing the PLR integration for the HHS and HHC for this control method right now.
  • If you have more than 2 devices (but, to my knowledge, not more than 8) then the STAR cannot control all the devices. Instead all devices are connected to the HSB and 1 of the HHSs is connected directly to the controlling PC via a USB connection. Is this what your setup looks like?

I do not currently use more than 2 devices because at the moment I don’t need more and because I didn’t want to buy an extra HSB. Tbh this is actually the reason why I’m inclined to not buy any more Hamilton devices and go for Inheco devices instead (they are supposedly easier to integrate and Inheco is known to help with the integration - and it clearly makes customers move to them, giving them more sales :slight_smile: )
I am happy to try figuring out with you how to integrated the HSB with you though, and @rickwierenga will probably be able to help us as well.

1 Like

Most of our Hamilton integrations include the HSB device. I can’t tell you why but it seems like the majority >80% use the HSB even with only 1 or 2 HHS devices. As for the Vantage, we do plan to expand our HHS capability to the max 8 devices once we integrate our freezer.

The Vantage I speak most of is our “pilot device” for scaling up our capabilities. Eventually once we land on a generic device we will scale it out to other groups. Basically we are trying to create an internal solution for programming Hamilton devices (interface being similar to Andrew +) with scheduler support so anyone can walk up and build “simple” methods, which would free up our time to work on more complex tasks.

I’m happy to use my system as a trial for the PLR HHS driver. But do be warned I cannot install custom USB drivers or anything like that because we do still routinely use this device for many different assays. Thanks for building this out and let me know what I can do to help!

I don’t know who set up your infrastructure but to be fair based on the scale of your automation setup I would have done the same for two reason: standardisation and modularity.
If all you systems operate their devices through the HSB then everything becomes more streamlined, from designing a new work bench with a dedicated box position to maintenance of the systems. Furthermore, having the HSB means you can quickly plug-and-play with devices, adjusting the setup to your needs.

However, if you are interested in performing some initial tests with 2 devices on a STAR, I will be done with the HHS and HHC PLR integration sometime mid-next week. Testing on this small scale whether programmatic control through PLR is useful to you should give you a chance to assess whether you think it is worth trying to do the same for the HSB.

Do you think your users would be comfortable enough with Python to do this using PLR directly?
Otherwise I could imagine a click-and-drag interface for PLR might be able to get you to the same results. But at that point I would ask why not use VENUS?

Regarding writing “simple” methods: I have no doubt that LLMs will be trained on our PLR work soon, just like ChatGPT has been trained on the Opentrons APIv2. Predicting the future is always doomed to fail but I played around and let GPT4 read the PLR GitHub and docs and it created a decent first template from just 2 prompts! This means the more documentation we generate and the more code examples are easily available the better AI-assisted writing of simple automation programmes will become.
So I could imagine in a years time that your users can ask an AI-assistant to write simple programmes for execution on Hamilton devices, because of PLR.

I may be. Once the implementation is finished we can talk about my steps!

I should have expanded more on what “simple” means. I am referencing protein digestions / working with magnetic beads / SPE when I say “simple.” I have no doubt that a LLM could do this but my observations are that lab scientists want methods to be less of a “black box” of code. So we are trying to create visual low / no code interface to build methods that can be scheduled.

I really want to use PLR but until Hamilton officially supports it my hands are tied. Until then we have to continue work on our companies solution.

Edit: Some of our low / no code actions would be:

  • Liquid Transfer
  • Normalize
  • Serial Dilution
  • Incubate
  • Vortex
  • Thermo Cycle
  • UV Measure
  • Vacuum
  • Centrifuge

The list goes on. Now we can worry about robust implementation of these core steps and users can worry about method implementation.

This should not be an issue as it is easy to switch between the two, but I understand you want to be conservative. With PLR, it’s possible to use any computer so if you have a laptop / rpi laying around, you could develop on them.

Just to be realistic: I think an Hamilton endorsement is not gonna happen in the immediate future, and I think pursuing this might actually slow us down.

What’s your company developing? If it also bypasses VENUS, what’s the difference from leveraging PLR?

Building a GUI/drag&drop for PLR protocols is guaranteed to get you community support, which makes development cheaper and more robust for you (not to speak of the inherent value for humanity in building this). People with all liquid handling robots would be able to use the interface at some point. I for one would be happy to contribute to this project and I’m sure others are too.

1 Like

It is being built in 2 parts. PytomatedLiquidHandling that I have posted here before and then the GUI app. We need to finish this first then we are going to start on the GUI app (We already have an internal POC app made in excel that I cannot share because there is too much company info present). Maybe we can move this chat to the thread I started for PytomatedLiquidHandling.

I am seriously push for everything to be open source so I will be sharing the app once we have something substantial.

2 Likes

I do also want to say I am fully supportive of PLR. Our company has limitations on what I can use. Since PLR is firmware commands and voids your warranty I cannot use it. It is a 100% no go that is out of my hands.

2 Likes