Hi!
I am looking for an integrated platform that can be completely (or almost completely) driven from python, better in bi-directional way (i.e. immediately report if something goes wrong).
Minimum setup is liquid handler + hotel + platereader + flow cytometer.
For opentrons, I’m quite happy with scripting experience and I can imagine controlling other labware from protocols with usb, there are semi-official examples of integrations for a couple of arm models.
How would you imagine using pylabrobot if one needed to control e.g. robot arm and hotel?
Are there robot arms / hotels with reasonably pythonic interface or web API?
PyLabRobot currently has interfaces for 3 liquid handling robots (Hamilton STAR, Tecan Freedom EVO, and Opentrons OT-2), and one for plate readers (BMG ClarioSTAR). In addition, it includes a very flexible resource model for representing labware items and layouts.
I think in the context you are describing, you could benefit from using the provided interfaces where they exist.
For other devices, you could create your own interface bridge that uses PLR’s resource model (allowing you to represent your setup in a single context) and communicates to one of the integrations you mention. (The PLR resource model can be used completely independently from the provided interfaces.) For example, you could imagine a RobotArm interface class that accepts PLR Resource objects to find the size and location of resources, and then sends this information to the interface provided by the manufacturer. If the manufacturer has a good and well-documented interface, writing this layer should take very little time.
Then, if you’re interested, I’d be happy to work with you on incorporating the robotic arms into the core library. This way everyone using the PLR ecosystem can benefit from your integration, and in return your interface will be tested and maintained by the community.
Personally, I do not have much experience using robotic arms and cannot advice you on which arms have a good API, but you have certainly come to the right forum for asking about them. Feel free to create a separate post on some of the other boards.
I’m sympathetic to your async-y model for pylabrobot, and I also appreciate it provides a server as well.
But I never really worked on lab automation, and I’d really prefer to have at least some reference point to start.
Furious Rant
Current state drives me mad. Windows apps everywhere and zero valuable public information - how would I know if I can automate something if API is not available? Who are these people reading infinite useless promo and cases?
Like PF400 is seemingly popular - couldn’t find anything but promo videos. How is it controlled?
Eva arm provides SDK, but you can’t buy it anymore.
Tecan - optimistic videos on youtube about sila2 and zero confirmation anywhere on the website.
Stackers keep their RS232 interfaces (that haven’t changed for a decade!) as private info. Sorry, what?
Exactly why I built PyLabRobot. I hope that offering a better developer experience and providing a useful foundation will encourage more manufacturers to open source / document their interfaces. As Stefan and I have said countless times, this is a very smart business decision for companies selling the hardware because it increases their utility by many orders of magnitude. In the meantime, sometimes companies are willing to share documents if asked nicely (many are active on the forum). We were lucky to have some documentation available for the STAR. For the plate reader I had to stare at sniffed ftdi bytes for hours to figure out how the interface works. It’s an exciting but time-consuming territory to explore.
For context, a lot of people rely on (manufacturer) consultants and specialized engineers to write methods for them. User guides are typically provided only after buying a machine. (Would be great if they were posted online.)
I’d of course prefer to have something more universal (384? multi-channel TR-fret?), but these absorabce folks clearly have easy integration as a part of their mindset - so to me they really stand out of the crowd.
I’m in a small startup, I have all kinds of backgrounds (phys/math/cs/ml).
Except for OT2-driven pipelines, I don’t have any experience in lab automation.
I’m the only coding person in the company, I develop LMS + analysis tools (cloud service generating protocols and automatic data analysis, for biofolks that’s futuristic). So I’m trying to design a reasonable path forward for LMS<>automation for an anticipated point when we get funds for automation.
And on the top level it looks to me either:
stick to python, suffer from missing drivers, restrict to instruments that provide at least some API, deal with scheduling.
pick something like GBG, embrace to learn its caveats, restrict company to supported instruments, suffer from LMS <> GBG integration issues, pray that GBG provides sufficiently flexible API for instruments, and maybe prepare for weekly calls with field support. (That’s my impression from prev company).
So if there is some reasonable set of instruments I can use with option 1, I’d try that first.
What makes you think that you can’t write your own drivers for GBG? Have you talked to anyone at BioSero? Also how would handle suffering from missing drivers AND also the scheduling? In fact, what’s your approach to scheduling?
GBG has been around for a while, and one of the early selling points about it is that you can use their drivers or absolutely write your own drivers for it.
Python-based code for an actual driver, if possible.
I don’t put this at doubt. Thread you point is a nice demonstration that approaching company contacts may bring no result. Example: I had zero reasons to go through this loophole with OT2 because code and examples are available.
Now, you say there is interface that is actually used by GBG customers (contrary to saying - fk this, let’s buy another equipment) and available for years but with zero usages at github? I am more likely to believe in mermaids, sorry
I see some unofficial code in gitlab, but I don’t see any official confirmation of support. Nuget packages are also not official.
Pylabrobot uses USB interface not SILA client - assume you folks not ready to rely on this, but maybe I am wrong.
Now, you say there is interface that is actually used by customers (contrary to saying - fk this, let’s buy another equipment) and available for years but with zero usages at github? I am more likely to believe in mermaids, sorry
This is the Fluent Python SDK (also on GitLab) which labs do use.
I am actually not sure if PyLabRobot is officially endorsed by vendor companies? @Stefan or @rickwierenga?
I know that Tecan invests in Open Source and they were happy to promote the Tecan EVO interface on LinkedIn but don’t think that it was “official” in terms of support.
