Hey all, was spinning up pylabrobot on my home laptop, I don’t remember having this on my work computer. Just went through installation and was looking to run the visualizer. When I ran the example script my visualizer looks like this with no deck:
Here is the code, it’s just the setup script direct from the “using the visualizer”
Is just a link to the repo ok? Or should I copy and paste the code here?
OS Name Microsoft Windows 10 Pro
Version 10.0.19045 Build 19045
Python 3.12.1 (tags/v3.12.1:2305ca5, Dec 7 2023, 22:03:25)
Chrome Version 131.0.6778.205 (Official Build) (64-bit)
Happens in edge and firefox, not browser related at all.
A little bit of background (because I don’t think the recording feature - which is pretty unique to PLR, as far as I know - is explained on the docs yet):
The visualizer recording feature is the brainchild of Joseph Laforet Jr (I think we might have lost him on the transition to the dedicated PLR dev forum?).
“As part of a suite of educational tools we are building for a class at Duke, I extended the functionality of the visualizer to now allow rendering of protocols as .gifs. There are now a few buttons added to the visualizer.”
Pretty neat, and indeed very handy for training purposes and showcasing to pure wetlab bioscientists how the required experiment is not humanly-executable
Why are the plates index 0 at the front of the instrument, are the channels also indexed this way? Traditionally on Hamiltons the back is the first position. This is in line with the channels, they are denoted first position at the back. That way you are always talking about the the first position being in the back of the instrument if its a channel, plate, plate position etc easy for context switching if they share the same language
Is the set liquid just used for visualization or tracking as well? What happens when you mix liquids, say for a normalization?
Question 1: We have to check this and get back to you.
Question 2:
I assume you are referring to the practice of indexing PlateHolder / “sites” on a carrier from front to back in PLR, rather than back to front like in Venus?
Good question: We were very confused by Hamilton machines’ indexing because the Cartesian coordinate system defining a resource starts in the front-left-bottom (flb) of the deck/carriers/plates.
So it made the most sense to us that the first PlateHolder or “site” on a carrier should adhere to the coordinate system that it uses: i.e. the first PlateHolder has the lowest y-coordinate for its origin - it is the first item that a search algorithm finds when going through the coordinate system.
We did ask Hamilton personnel what the rational was and couldn’t get an answer. So we kept the coordinate-system rationale.
However, over time we realised what you are saying: that VENUS’ indexing of carrier sites / PlateHolders is likely back-to-front because it simplifies context switching:
e.g. in PLR, when using a tube carrier: if tubes 0-7 are placed front-to-back in the first 8 tube carrier sites there is a problem →
We easily overcome this problem in Python by filling tubes in reverse and using simple Python logic to process the tubes correctly (Python - yeah )
Regarding channels:
The channels could not be (that easily) changed due to firmware-constraints → the backmost channel is 0 because this is Python (i.e. all the classic arguments for 0-based indexing).
Maybe we should discuss changing the indexing?
But we haven’t done this so far because Python offers an infinite arsenal of solutions, and the “adhering to the Coordinate system for indexing” has worked well for PLR so far.
…a bit of an extensive answer but there are quite some nuances and tradeoffs
Question 3: I’ll leave this question maybe for @rickwierenga ?
I don’t use the liquid visualiser and set the cross-contamination tracker to False because I don’t need them for my applications at the moment.
if it is not working for you, could you see if there are any errors in the javascript console?
Thanks Camillo for the very detailed answer. In more general terms: the goal of PLR is to do what makes sense based on physical reality, rather than inheriting decisions from legacy projects like venus because those decisions don’t always make sense.
the set of liquid is also used for contamination tracking. Mixing liquids is not supported yet. I was considering rewriting the Liquid API for this, so that we can say like solution = Mixture({Liquid.WATER: 0.8, Liquid.ETHANOL})
Hey Rick sorry haven’t had time to get back to this.
lol I just re-ran the entire script and things are working now, maybe I didn’t hit run all.
@CamilloMoschner when doing tubes you’re writing code to fill in reverse order? @rickwierenga I understand wanting to match physical reality, but none of the other assets follow this reality so not sure if it makes sense?
which assets don’t match physical reality? we should probably fix those.
(If you’re talking about numbering along the y-axis, it’s a choice. In physical reality there is no right answer. The transposed excel-style notation is too common for us to fix/match the star y-axis. for carriers, i was willing to be bold and use what makes more sense to me.)
Sorry I’m saying that plates, tube carriers (assets), and channels are numbered from back to front. Isn’t a plate carrier just a big tube carrier with many little tubes in it? I know it makes sense from the instrument having 0,0,0. It just seems like the odd to me since everything else is the opposite way
tube carriers are labeled from the front (0) to the back, like other carriers. as far as i know, plates & tip racks and channels are the only things labeled from the back to the front. these are the choices i made for plr, and this is what it is now