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), at a different height depending on which tip rack is used. This is dz in a hamilton tip rack.
Limitations/issues
- ~In PLR, you can only pick up multiple tips of the same kind in a single command currently. the firmware api supports different tip types on each channel~ (not true)
- While possible, it is a little bit non-obvious how to store tips of different tips in the same Rack
- TipRack.get_highest_known_point doesn’t take into account the height of the tip above the tip rack (the collar that sticks out)
- TipRacks don’t sink into the ResourceHolder (fka CarrierSite) in our model, even though they do physically. Related, the z=0 of a tip rack is not the actual rack bottom
Physical reality / what we should do
The tip racks, the plastic holders, are actually the same for every pip-tip type. Only the sticker is different.
→ we should have a singular definition for this piece.
→ Its lfb should be at the actual bottom, not halfway through.
→ Its height should be 16.40mm, not 20mm (as in venus)
→ It should sink into the ResourceHolder by 5.90mm
→ each tip has a ‘collar height’, which we can use to determine the bottom of the tip. The tip sits at total_tip_length - collar_height - hole_height below the tip rack.
(I measured the the hole-height to be 7.52mm)
These changes will make our model match physical reality. From there, it should be easy to address the issues above.