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.
→ 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.
Thank you @rickwierenga , nice writeup with many details regarding the geometry.
Actually there are also Nested Tip Racks. But I agree, there are basically just “normal” tipracks and nested tip racks and both are used for different types of tips.
What prevents us from defining the TipSpot at the z-hight where the collar will sit in the tiprack? This would simplify (obsolete) the pickup height calculation.
they can be separate tip rack definitions, using the same tips. I believe @CamilloMoschner is working on this
Yes, we should have tip spots at the correct location (their lfb). I see the TipSpots as the holes in a tip rack. Currently, it’s wrong because some tip spots are modeled below the tip rack (so that tip sit at the bottom of the spot). With the new approach, tips will sit below (z < 0) TipSpots.
correction from post above: the resource holder sinks by 6.1mm, not 5.9. I measured it incorrectly before. The total height of the hole (“TipSpot”) that overlaps with the tip is 7.7mm.
The tip pickup command on STAR (C0TP) has two primary parameters:
tp: begin_tip_pick_up_process
tz: end_tip_pick_up_process
For every tip pickup, tz is 1.6mm above the tip carrier top, or 1.6+6.1 = 7.7mm above the tip rack bottom. The collar height determines the paramter tp, which is where the pip channels move down slowly. (This parameter can actually be as small as 1.7mm above tz with normal high volume filter tips. turbo mode for pickup )
With what I proposed above:
Define tip racks location.z to be tip_carrier.size_z -6.1
Measure collar height for known tips (this information is not available in venus I think, but believe we have all hamilton tips at retro)
set tz to rack height + 7.7, tp to rack height + 7.7 + collar height
TipSpot z is 0 wrt tip rack, height is 7.7
thoughts? c @CamilloMoschner. @ben does this have sufficient parameters for using the chinese tips?
)