this means that after the update, certain liquid handling operations will have different parameters (the backend default instead of the liquid class default).
you can still use liquid classes, but you’ll have to pass it explicitly as kwargs. same goes for volume correction (note that volume correction cannot be trusted, but they are likely a step in the right direction)
have reverted this until we have a slightly better replacement
It’s a good push imo.
Do other liquid handlers have liquid classes as well?
This change will happen but we need to give people more time to adjust , and in the process of implementing at Retro perhaps I can think of some nice convenience features to make things easier
In the sense that people use parameter sets for specific transfers, yes.
For Tecan, the proprietary Gui supports it formally. For opentrons that’s not the case. For others I don’t know
Liquid classes are a pretty universal concept, yes.
To my knowledge at least Hamilton, Tecan, Beckman and Dispendix machines use them extensively.
The precise nomenclature and parameters inside liquid classes varies though, not just between manufacturers but sometimes even between machines from the same manufacturer.
I’d also agree: some major changes regarding liquid classes are dearly needed.
But at least initially I recommend we generate additional options to the current implementation, battle test these new options, and when people are familiar with the new paradigm and documentation for it is available we can still delete the old way.
What the new, additional option looks like precisely we can figure out over the upcoming weeks?
Pretty much every major liquid handler use liquid classes, Bravos, VPreps, tecans, Beckman NXs, etc. In fact, sometimes liquid class optimization is the most time consuming part of developing a repeatable, robust process. I don’t see a world where a default liquid class would cover all use cases across the industry.
Note that even if the parameters and nomenclature for liquid classes would be normalized by PLR, the parameters will still be device dependent, so a Liquid Class for a Tecan device would not be usable on a Hamilton device because the correction not only covers the behaviour of the liquid but also the interaction between the liquid and the liquid handler.
Continuing the bigger conversation of what should follow classic “LiquidClasses” here What is the next evolution of "LiquidClass" for PLR?