I think I’m going to model it as a TipRack, and then write a wrapper around the pick_up_tips96 command which has the intermediate step of first dropping the tips on the tip adapter.
While I have a good understanding of how to write resources for labware due to the awesome youtube video on defining resources, I don’t have a good grasp of what the various sizes and offsets mean when it comes to tip racks.
Is it like Venus? Where you are teaching the tip rack with the “tip of the tip” as reference? Is there a drawing that shows what PLR expects as the various sizes?
for context, here is a video of the tip adapter in use:
tip racks are currently a bit of a mess
for background: i first wrote tip racks when things were more based on venus (i was just starting out). it has never been refactored since then. in sort of “v2” (refactor) of the resource model, we have been basing things on physical reality rather than whatever OEM software uses (Camillo has really been leading these efforts). this means we can no longer use the definitions (rck, ctr, etc. files) from venus since they actually lack some information (most importantly, material_z_thickness).
currently, the system should look something like this (we hope to refactor it soon):
the tip spot is defined with a negative z-location, below the tip rack. the tip goes up from there The tip spot actually has size_z of 0, so it really is a flat line. Since each tip has a different height, the z-location (always negative) of the tip spot is actually dependent on the specific type of tip that is stored. Which is obviously gonna cause a problem for the tip adapter which should support multiple tip types. And also it’s a problem for the normal hamilton tip racks, because they are all the same plastic rack so really we should be modeling it as one rack. (so we will change in the future. i am just describing the current venus-based system.)
modelling the adapter as a tip rack sounds like the correct thing to do. but i guess before that we need to fix the tip rack definition so they are independent of the tips they store (obviously?)
can you please explain how teaching works in venus?
Couldn’t we just pass the different tips as an argument so that we populate the make_tip dynamically? This still isn’t ideal because you could only assign one tip type per run.
Do we even need to know where the tip bottom is when using a tiprack?
I’ve never taught a well adapter myself, however from my understanding you teach it where the tip will end, so you have a “96 well tip adapter 50uL”, a “96 well tip adapter 300uL”, etc. since the x and y positions will be exactly the same, but the z will depend on what tip you’re using
Ha! So hamilton does do “Couldn’t we just pass the different tips as an argument so that we populate the make_tip dynamically? This still isn’t ideal because you could only assign one tip type per run.”
sure, yes of course that is possible in PLR
but i agree let’s not be blocked on refactoring tip racks, this will instantly work
