Picking up tips from a plate

[willem]

Hi,

I’ve gotten a bit further (thanks for the previous replies), but I ran into a quite specific issue. The machine has 7 plateholder locations and a chute, like so:

Two of these can hold a plate with tips (they’re not bouncy), stations 7 (top right portrait one) or 1 (top left landscape one).

Q1: x-axis is back to front, y-axis is left to right, z-azis is bottom to top - is that correct?

Q2: How do I set up a suitable tip-plate?
I am trying to pick up a tip from a Plate on a PlateHolder as follows

lh.pick_up_tips( tipplate["A1"], )

where the tipplate is an actual plate. This results in an error, as it expects TipSpots, not Wells on a Plate

TypeError: Resources must be TipSpots, got [Well(name=plate_07_well_0_0, location=(009.600, 070.000, 001.200), size_x=8.0, size_y=8.0, size_z=42.0, category=well)]

Since the backend I have written exports to CSV, I only need to tell it to pick up a tip from a location (plate#,wellid) and it does not matter what I pick it up from, as the machine takes care of that…

So I tried to set up a TipRack and stick it onto the PlateHolder (works in reality), but that results in:

TypeError: PlateHolder can only store Plate, PlateAdapter or ResourceStack resources, not <class 'pylabrobot.resources.resource_holder.ResourceHolder'

So, if I understand things correctly, I need to set up a separate TipCarrier, assign a TipRack to it, and access that through LiquidHandler lh.deck.get_resource(“tipcarriername”)?

I think I can work with current setup but it would be nice if I could directly stick a TipRack with TipSpots onto a PlateCarrier just like a Plate with Wells? The SPT machine does not have a separate tip carrier, it has stations that take a plate or a tip rack.

Thanks,
w

PS I saw these, they may be related:

Can we make Tips a Container resource?

question by @naikymen let’s discuss here

Revising TipRacks

TipRacks are one of the last resources which we have not discussed or revised after my initial implementation. That means how it is currently implemented models VENUS somewhat closely. There are some issues with this (see below). Current implementation In the current implementation, Tips aren’t resources. Their pickup and drop-off location is determined by the TipSpot, a location in the TipRack. The z-location of the TipSpots is below the “surface-level” of the rack (not counting the border), …

[rickwierenga]

q1:

a bit annoyingly, plr uses the convention of x is left to right (y on yours), y is front to back (x on yours), z is top to bottom (same). The Tecan EVO also has the orientation you use. For interoperability, the backend will have to transpose the axes when sending commands to the machine.

@willem

Q2: How do I set up a suitable tip-plate?

I would use a TipRack to model them. But LiquidHandler expects TipSpots, which are typically children of TipRack, but you can have a custom resource that also has TipSpots as children.

Do you have a picture of your tip plate? If it is similar to other tip racks in PLR i recommend calling it a TipRack instead of a TipPlate.

@willem

So I tried to set up a TipRack and stick it onto the PlateHolder (works in reality), but that results in:

The PlateHolder might need to be a ResourceHolder. PlateHolder is a specialized class for dealing with pedestals, which your spots do not seem to have.

The Opentrons Deck is actually similar to this. I modelled it without ResourceHolder or PlateHolder (pylabrobot/pylabrobot/resources/opentrons/deck.py at 1f60be4ce25c2e0270f609120d4cbe97ed0f404e · PyLabRobot/pylabrobot · GitHub), but that might not be the most optimal. I would probably use ResourceHolder if I were to refactor OTDeck.

@willem

So, if I understand things correctly, I need to set up a separate TipCarrier, assign a TipRack to it, and access that through LiquidHandler lh.deck.get_resource(“tipcarriername”)?

Tip carries are actually seperate resources that are incompatible with your robot:

Given the rest of your post, I suspect you may have defined a PlateCarrier to model the deck. Plate carriers, like tip carriers, are specialized resources for rail-based decks (like hamilton and tecan). I would define your deck as the top level class and have 7 ResourceHolder children and one trash child. Lmk if i can help with that.

[willem]

Thanks - I hacked it with a separate PlateCarrier and a TipCarrier, then stuck Plates and TipRacks (with TipSpots) on there, and a Trash.

Because my CSV output does not need coordinates, just the plate station number (1-7) and Well Id (A1 etc) I got that to work, but it would be nice to set that up more appropriately.

So that would be
Deck->ResourceHolder[i]->Plate
Deck->ResourceHolder[j]->TipRack->TipSpots)
Deck->Trash
?

I’ll need to have closer look at the code but that might harmonise it. Any input appreciated.

Holidays starting though! Merry xmas,
w

PS1 No don’t have a pic of a rack - I’ll need to ask a coworker for that.
PS2 only_fans. Really.

[rickwierenga]

@willem

Deck->ResourceHolder[i]->Plate
Deck->ResourceHolder[j]->TipRack->TipSpots)
Deck->Trash
?

exactly

@willem

PS2 only_fans. Really.

it is a module just for fans!