Open theosanderson opened 4 years ago
I've also tried to hack into thinking there was a tip attached so I could then call drop_tip
. Why is this error even a thing? What does it hurt to eject without a tip attached?
Hello again @MarcelRobitaille! Fancy meeting you here.
This is pretty frustrating behavior. I think it's a symptom of tip tracking state living just a little bit lower in the stack than it probably should. The behavior comes from a place of the hardware controller needing to take tip length into account to understand how to move a given pipette. That fact snowballed into "the hardware controller keeps track of tip state" and then, without considering the larger implications, "the hardware controller should check if a tip is attached before trying to drop it".
This is a really good ticket to factor into some foundational protocol behavior work that is happening right now. In the meantime, though, I think we should see if we can remove that check in the hardware controller in a safe manner.
There really doesn't appear to be a good workaround for this; even if you go through private APIs it's messy (and brittle) enough for it to be a pretty bad idea
Thinking is that fixing #5248 will make this moot in practice, though a fundamental fix would still be nice.
@mattwelch why does that make it moot?
@MarcelRobitaille sorry, this looks like a potential typo or miscommunication. Feel free to disregard; unentangling the tip drop procedure from tip attached state is still on our radar
Overview
Trying to run a protocol when a tip is already on a pipette (e.g. due to an abandoned previous protocol) leads to bad times, with collisions etc. Unfortunately one can't just add
pipette.drop_tip
to the top of a protocol because thedrop_tip
command asserts that the instrument has picked up a tip.I've spent a while looking at hacking this and it's not very straightforward.