Was wondering if anyone here has used PLR just for sequence building and then used their liquid handlers native software to read sequences and do the hardware control from there. For example, running a protocol in a manner similar to the following:
Run a PLR script to generate sequence data prior to method start.
Write the script output to a file (.csv, .json, etc.) to be parsed by Venus.
Use Venus to convert script output to Venus Sequences
Use Venus commands with sequences to execute the method
I’m really intrigued by moving away from Venus to do sequence building, but I don’t necessarily want to lose all of the other tools, libraries, etc. that Venus offers.
I’ve heard of a few people who do that kind of task in different ways and it seems like a common problem, but is usually described as worklist or picklist generation. I think Python and other general-purpose programming languages are great for that, but you wouldn’t be using anything directly from the PyHamilton or PLR libraries to make it happen. I’ve written a lot of PyHamilton scripts that incorporate code like what you are describing and would be happy to give more details on how exactly this might be used in a non-PyHamilton setting.
As for the trade-offs of leaving Venus for PyHamilton, it is a really good point and I’ll give my perspective here according to the different types of functions Venus provides:
For fundamental commands like aspirate and dispense, Venus and PyHamilton give you the exact same thing in a different form. There is a 1:1 mapping of parameters between the two applications. This is the case for every command in the PyHamilton API, including all built-in integrations of Hamilton equipment e.g. the heater-shaker.
For almost all Venus functions that manipulate data, like converting something from x format to y format, Python is probably easier even if you barely know Python, because stack overflow has an answer for almost everything along these lines.
For manipulating Venus-specific objects (typically sequences and labware), Venus provides some libraries for working with these that are not always supported by PyHamilton. Similar to how we are extending the API to handle more equipment, we also would like to expand the API to support the functionality that these libraries provide in order to provide users maximum flexibility.
I’m always happy to get into the weeds of specific Venus libraries and how they can be replaced in PyHamilton. These are just general comments for readers, not trying to persuade anyone any particular way, there are countless tradeoffs.
One more general point to add to this essay: PyHamilton and PyLabRobot are different libraries that provide pretty different behind-the-scenes ways of talking to robots. We also call the overall project PyLabRobot which is undoubtedly confusing. Without going into too many details, PyHamilton provides essentially 100% of the functionality of Venus (minus some equipment integrations). PyLabRobot reproduces ~80% (probably more) of the functionality of Venus but with unlimited open-source flexibility and interoperability across multiple liquid-handling robots.
I agree that dynamically creating sequences in Venus can be a pain.
I think as with anything related to programming there really isn’t just one way to solve this, but Rick is correct that you should have a look at PyVenus.
Scenarios like the one you are describing are in fact one of the reasons why I came up with the package in the first place.
Here is a short code snippet from the Readme where I read a worklist file, convert it to a sequence, read the x/y/z coordinate of every position, sort it using pandas and then push it back to Venus as a sequence. All in one neat block of Python code.
This is just an example, but I think the ability to combine functions from e.g. pandas and the ability to directly generate sequences and access coordinates enables very complex sequence generation in a few easy steps.
I think the advantage over the steps you outlined is that you can do this dynamically within your method (i.e. during runtime).