Robot. Happens decently often - if I have a good robot for one protocol I won’t recalibrate for a matter of months. If I move em or get a new protocol I’ll often recalibrate.
man, I wish I had that 
1 Like
this is confusing: if you can run the same protocol without calibrating for months, that means the internal drift on the OT is actually quite low (this wasn’t my experience, but happy yours work better). If you had another fundamentally well-calibrated robot, wouldn’t moving a well-calibrated protocol on there mean the protocol should just work? If both the robot and protocol are correctly calibrated, this should add up to good performance. If not, either you calibrated part of the protocol into the robot or vice versa. That will never scale
Trying to catch up here:
@koeng I would also recommend adding the PLR-integrated Mettler Toledo scale onto your OT-2 and checking your liquid verification protocols 
I love Opentrons for many reasons but I have never heard them talk about liquid transfer verification nor aspiration/dispensation parameter adjustments to make the transfer more accurate (i.e. a “LiquidClass” in classic biowetlab automation engineer jargon) … which always made me very wary about the OT-2’s accuracy.
Reusing modules between different machines is, in my experience, extremely useful:
- you can buy anything and make it work together,
- move small machines / modules between different setups whenever you need that modules functionality,
- I’m even working on making something solely found on Tecan machines work on a Hamilton machine (because buying a Tecan just for one protocol is simply too expensive), …
I’ve not come across another machine control ecosystem besides PLR that enables this functionality.
There is SiLA, but the documentation for it is a mystery to me, and from my understanding SiLA 's functionalities are restricted to “drivers” pre-written, usually on the basis of proprietary software 
One thing I noticed from this thread: PLR plate definitions are missing a lot of crucial information, one example Well.material_z_thickness (please correct me if I’m wrong).
As a result, anytime I actually wanted to use a pre-made Opentrons plate definition I had to make an new PLR definition anyway.
1 Like
this is actually irrelevant for OT since they don’t have pedestals
also: plr definitions are not missing information - thanks to you - everything else is
Ohh no, ambiguity: OT2 definitions are missing so much that their PLR adaptation is still missing a lot, and hence I had to create new PLR definitions of them that fill the gaps left by their OT2 definition.
Apologies for the confusion
1 Like
Modules placed on top of the deck might.
1 Like
Yes. It just so happens that the robot calibrates on labwares, not on XYZ positions, so if you want a protocol to work off of XYZ positions, you gotta go get the XYZ positions as labwares, then do math to figure out the difference. I do often get protocols to just work though.
I’m poor
# Setup variables from https://insights.opentrons.com/hubfs/Applications/General%20liquid%20handling/Viscous%20Liquid%20Handling%20App%20Note.pdf
enzyme_rate = 5.292
enzyme_delay = 7
enzyme_withdrawl = 2
# Setup samples
protocol.comment("End-Prep: Setting up samples")
protocol.home()
# Prepare mastermix
end_prep_wells = ["A1","B1","C1","D1"]
for i,_ in enumerate(samples):
destination = thermocycler_plate.wells_by_name()[end_prep_wells[i]]
p20s.transfer(3, end_prep_buffer, destination.bottom(0.5), new_tip="always")
# Careful enzyme dispense
p20s.pick_up_tip()
p20s.aspirate(2, t4_pnk.bottom(.2), rate=enzyme_rate)
protocol.delay(seconds=enzyme_delay)
p20s.move_to(t4_pnk.top(), speed=enzyme_withdrawl)
p20s.dispense(2, destination.bottom(0.5))
p20s.drop_tip()
p20s.pick_up_tip()
p20s.aspirate(1.5, taq_polymerase.bottom(.2), rate=enzyme_rate)
protocol.delay(seconds=enzyme_delay)
p20s.move_to(taq_polymerase.top(), speed=enzyme_withdrawl)
p20s.dispense(1.5, destination.bottom(0.5))
p20s.drop_tip()
They got some aspiration/dispension parameter adjustments if you dive into their docs. Here is some code that reliably transfers sticky (glycerol) enzymes. No capability to do liquid transfer verification until the flexs. Chiu once had me test out a hacked bluetooth OT2 pipette with pressure sensing built into it, but it didn’t work (as in the pipette couldn’t connect to the robot, something in the electronics must have been fried or something). But it seems like they added that into the OT Flex.
Thinking more about this, I think you are right. In general, moving forward, 3rd party modules would be awesome, and I was simply limited by the fact I couldn’t use them.
2 Likes
automation with offsets everywhere
so true
isn’t there a + on various spots on the deck? if we calibrated to that, wouldn’t that solve the calibration issues? (alternatively, we can machine such an object ourselves
because it is independent of labware
1 Like
Does not work well enough. That’s why they make you also do it for particular labwares on the deck - while yes, still making you calibrate to the +, AND to the machine block. You calibrate:
- Deck calibrations
- Pipette calibrations
- Labware calibrations
and it seems like all 3 are needed.
Originally they meant to autocalibrate, actually, from the limit switches underneath the trash bin. But that didn’t work.
1 Like
why?
and Tip calibration, if I remember correctly?
Or has this been removed?
I’d guess it is because the + is only on one side (the bottom left), and since the robot isn’t consistent across its deck, that means the right hand side or the back don’t have good enough calibration
you are right, there is tip calibration as well.
shouldn’t it interpolate between those points?
there must be a way to calibrate this robot independent of labware
it could be so good: if the robot is properly calibrated, you don’t need to recalibrate for months. if you protocols are also well-calibrated, you can literally just take anything anywhere at any time and it will work
Natively? No, there probably isn’t a way, unless you did some REAL hacky shit. We could probably do it by having a well known labware, calibrating it at several points across the deck, then having some custom software do interpolation between the points. This is the “custom calibration” I was talking about.
It would still be “dependent” upon a labware, but only dependent upon one labware, which is just there because I don’t wanna custom mill a block with calibration points, and it is easy to calibrate plates because you can lift them and stuff to feel distance from bottom
I agree it’d be sick if it worked
1 Like
is there any physical reason this wouldn’t work? seems very possible with your api + plr labware model
If we went with custom calibration, it probably could work. (as an fyi I’ve been working on something using this API, hence why no progress for a little. Will continue working on it once I get the demo out)
2 Likes
seems like the best path, and could enable the OT-2 to be used in production long-term, even if you had the extra capital for STARs