This issue is for:
When one calibrates a second tip-rack behaviour should be as calibrating the first one. I.e. move to correct position, press save, press pick up tip and verify that tips are secure, press drop tip.
When the second rack is being calibrated in fact (for understandable reasons) pressing "pick up tips" will attempt to pick up tips from the first rack. If the pipette has just been placed on tips in the second rack this will often cause a collision as the tips from the second rack are rammed into those in the first rack. This also makes it harder to test correct tip collection from the second rack.
To piggyback off this issue, I also see unexpected behavior when attempting to calibrate 2 tip racks for one pipette on the OT App v2.5.2 on Mac. Specifically, the 2nd the tip rack does not show up in the OT App at all.
Interesting - it did appear for me - did you attach it to the pipette?
I deleted my original post b/c I responded through my gmail account. But yes, I attached the second rack to the pipette using the below code:
p20_rack = containers.load('tiprack-200ul', 'A1', 'p20 rack')
p20_rack_b = containers.load('tiprack-200ul', 'B1', 'p20 rack b')
p20 = instruments.Pipette(
name = 'p20',
axis = 'b',
trash_container = trash,
min_volume = 2,
max_volume = 20,
tip_racks = [p20_rack, p20_rack_b],
channels = 1,
aspirate_speed = 300,
dispense_speed = 500
)
I have the same issue as theosanderson on Linux.
Thanks for reporting this set of calibration issues. We are revisiting calibration procedure in the new version of the app and API and we will add your scenarios to our tests.
@kolaworld the reason for 2nd tiprack not showing up could be that you never run out of tips in the first rack and 2nd tiprack's tips are never being used by the protocol.
I know you're already on it - but a related issue I've just encountered:
If you don't attach a tip box to a pipette at all, but do use the pipette with the tipbox, the same bug occurs. Here pressing "pick up tip" while calibrating that tipbox will just cause the robot to pick up tips from wherever it is currently (even open space) whereas it should always go to the currently saved location of the tipbox selected.
Closing this ticket because incorrect tiprack calibration behavior was fixed for the OT-2 and v3.0.0 of the app. Unfortunately, given how different the OT-2 is to the OT-1, we don't have the engineering resources available to backport fixes to the legacy app.
That being said, if anyone from our community would like to make updates to the legacy app, we're happy to re-open tickets and help out. The legacy version of the app lives in the ot1-stable branch of this repository.
Just to clarify, will v3 not support OT-1? And if so does that mean that no more bugfixes will be made for OT-1?
@cfblaeb the just released v3 of the app and API do not support the OT-1. Long story short, the OT-2 is too different from the OT-1 (Python API running on-board the robot, different deck orientation, electronic pipettes, etc.) and we don't have the resources to develop for both the OT-1 and the OT-2.
It's definitely not an ideal situation, and I'm sorry about that. There's a strong desire among the team to bring the OT-1 into the v3 fold, but the reality right now is that we simply can't. That _may_ change in the future, but certainly not soon.
If we were able to get help from the community, we could definitely look into freeing up some resources to help plan and advise OT-1 work, though.
I'd be happy to discuss more over email if you'd like! mike at opentrons
Most helpful comment
Thanks for reporting this set of calibration issues. We are revisiting calibration procedure in the new version of the app and API and we will add your scenarios to our tests.
@kolaworld the reason for 2nd tiprack not showing up could be that you never run out of tips in the first rack and 2nd tiprack's tips are never being used by the protocol.