Revising TipRacks

resources
41

one second after posting I realize I might have asked prematurely, I’ll let you know when it’s ready to test. I can test some things on the star first …

42

Right on, just let me know when!

43

Ok, some progress on this work.

To clarify: there are two parts to this work:

  1. new model: “what is a tip spot” changed, and therefore the computation from PLR model → firmware command changes
  2. the new model has new parameters / dimensions which we need to measure

(1) works now, (2) is 0.2mm away from working.

In PR Refactor tip racks by rickwierenga · Pull Request #849 · PyLabRobot/pylabrobot · GitHub, I introduced EmbeddedTipRack and EmbeddedTipRackHolder per Camillo’s suggestion. I also added a collar_height attribute to tip: this refers to the height of the tip that sticks out above the tip rack - the part it is hanging from. Further:

  • sinking_depth = 6mm is the distance between the bottom of the tip rack and the site of the EmbeddedTipRackHolder (ResourceHolder in the tip carrier). It is how much the rack sinks into it.
  • tip spots are now flat surfaces at the top of the hole. dz of the tip rack now refers to the size of depth of the hole, the distance from the bottom of the tip rack to the top where the tip will hang from. [As described above, previously the tip spots had their z location defined based on the tip that would be in the rack. Ie the bottom of the tip. This does not really make sense as we discussed.]

this model removes a part of the code that has been mysterious to me since the start:

    # not sure why this is necessary, but it is according to log files and experiments
    if self._get_hamilton_tip([op.resource for op in ops]).tip_size == TipSize.LOW_VOLUME:
      max_tip_length += 2
    elif self._get_hamilton_tip([op.resource for op in ops]).tip_size != TipSize.STANDARD_VOLUME:
      max_tip_length -= 2

this is actually because the firmware command uses the collar height, not the fitting depth to pick up tips. collar height is 6mm for 10uL, 8mm for 50 and 300uL tips, and 10mm for 1000uL tips. Fitting depth is 8mm fixed for all tips.

The new model with these new values works pretty well, although there is one unresolved factor. See data below.

The current implementation on PLR main was validated against venus we had in the esvelt lab, giving these values. I took the labware as it was defined there and figured out the formula to arrive at firmware commands I saw:

PLR main (based on Esvelt venus)

+--------+------+-------+------+
| Volume | Mode |  tp   |  tz  |
+--------+------+-------+------+
| 10 uL  | TP   | 2224  | 2164 |
|        | TR   | 2224  | 2144 |
| 50 uL  | TP   | 2248  | 2168 |
|        | TR   | 2248  | 2168 |
| 300 uL | TP   | 2244  | 2164 |
|        | TR   | 2244  | 2164 |
| 1000 uL| TP   | 2266  | 2166 |
|        | TR   | 2266  | 2186 |
+--------+------+-------+------+

I just retested them with venus at retro to see what I would get:

Retro VENUS in simulation

+--------+------+-------+------+
| Volume | Mode |  tp   |  tz  |
+--------+------+-------+------+
| 10 uL  | TP   | 2224  | 2164 |
| 50 uL  | TP   | 2244  | 2164 |
| 300 uL | TP   | 2244  | 2164 |
| 1000 uL| TP   | 2264  | 2164 |
+--------+------+-------+------+

this version makes more sense, as tz is the same for all tip pickups (the rack is the same).

Unfortunately I was not able to get the TR values because I do not know if venus can put tips back in a rack, “tip eject” steps always go to waste…

Now with the new model I get this …

PLR with new model

+--------+------+-------+------+
|  Tip   | Mode |  tp   |  tz  |
+--------+------+-------+------+
| 10uL   | TP   | 2224  | 2164 |
|        | TR   | 2224  | 2144 |
| 50uL   | TP   | 2244  | 2164 |
|        | TR   | 2244  | 2164 |
| 300uL  | TP   | 2244  | 2164 |
|        | TR   | 2244  | 2164 |
| 1000uL | TP   | 2264  | 2164 |
|        | TR   | 2264  | 2184 |
+--------+------+-------+------+

… as long as I remove 0.2mm from the result computed from the model + measurements above. That means making dz 0.2mm lower or sinking_depth 0.2mm more.

This can be explained in a couple of ways:

  • I measured the numbers for sinking depth and/or new dz incorrectly
  • We are missing a 0.2mm factor in the computation
  • The value as I computed it might be correct and venus might be wrong.

As camillo describes it: “The thing is that Hamilton might - or might not - have adjusted these values based on long-term wear and tear which wouldn’t show up in day to day measurements”. I do not know what is correct here, only that the new model taking my measurements for dz and sinking_depth do not match those generated by the firmware.

1 Like
44

Will digest the rest soon, but fyi Venus can place tips back in tip racks.The nimbus PLR implementation also can do this and has been tested that way.

45

It can – sometimes tip racks will not show up in the eject tips step if the labware associated with the tip sequence doesn’t have the right properties. If you are using the single step and have a sequence for your tips, try right-clicking the labware > properties > edit properties, and assigning the properties IsTipRack and/or MlStarIsWasteRack with a value of 1. Can send a quick screen recording demo if needed, can’t upload a video file to the thread though :slight_smile:

1 Like