Request for feedback: higher level methods in LH: aliquot and serial dilution

[koeng]

i was thinking about adding a tip_generator param (generator). If None, it will use the tips picked up before the method is called. Otherwise get them from the tip generator.

Makes sense. I am often pretty explicit about tips (for tip reuse reasons - actually more important for managing deck space than saving $$$ on tips), so I should check out how the tip generators work.

[rickwierenga]

we have docs for this: Looping through tip racks — PyLabRobot documentation

[CamilloMoschner]

I believe this thread has lead to three questions:

1. Should PLR empower more “complex commands” / complex methods of the liquid_handler class? → bool
   → The answer seems a clear True / yes.
2. Should one of these complex commands be a serial_dilute command → bool:
   Questions have been raised on the universality of this potential method. While it might be useful for some people, many scientists prefer executing (1) dilutions in general themselves, and (2) might even define the subset of dilution called serial dilution differently.
   Personally I’m not opposed on integrating such a method, though I’m unlikely to ever use it.
   Serial dilutions represent an experimental design strategy called grid search which I rarely use.
   Question not yet answered, and probably up to the person who needs it to develop it to ensure it will be used.
3. Should one of these complex commands be a smart distribute/aliquot command? → bool
   → The answer seems a clear True / yes.
   Now there is a big question regarding implementation on this too.
   If there is no way of adjusting the aspiration and dispensation parameters, are they just defaulting to the firmware defaults at the moment?
   Because …

…this is what we are ignoring if we cannot modify these parameters.

If I’m not mistaken, any liquid transfer command (i.e. aspirate & dispense) specifies the volume the piston moves!
This is not the same as the volume of the liquid inside the tip.

A “LiquidClass” is meant to adjust the piston_movement_volume and all other parameters to accurately aspirate/dispense what we want to aspirate/dispense.

Funnily I have never seen Opentrons mention the required changes to liquid transfer parameters, are they just ignoring the existence of “LiquidClasses” or maybe leave it to the user to trial out “good-enough” parameters for every pipetting step ever taken?

[rickwierenga]

thanks for summary

@CamilloMoschner

Question not yet answered, and probably up to the person who needs it to develop it to ensure it will be used.

we would use it roughly as i implemented it above.

But if we are the only ones, it might as well be an internal method instead of a method on LH. Are there different names for different serial dilution methods? We could add each. If it’s just like “everyone does it differently” then I’d probably just keep it in my protocol rather than plr.

@CamilloMoschner

If there is no way of adjusting the aspiration and dispensation parameters, are they just defaulting to the firmware defaults at the moment?

this depends on {Aspiration,Dispense}Params classes (like LiquidClass) that i will add in a future PR.

[cwehrhan]

Hamilton just implemented a basic “power step” for serial dilutions for Venus6. Might be useful taking a look at that for a generalized parameters for serial dilutions, as it is a parameterized function that works for most scientific work flows. Something to lean on when designing one for PLR

[rickwierenga]

would you be able to share a screenshot? not many people on this forum have venus6 installed …