Move between two liquid handlers and the first thing you notice is that they seem to disagree about what a correction curve even is. One asks for a table of points, another for a slope and an offset, a third for a list of paired numbers in a definition file. It is easy to conclude the vendors are doing fundamentally different things. They are not. Every one of them is solving the same problem, mapping the volume you request onto the volume that actually comes out, and the differences are surface, not substance. Seeing the shared idea underneath makes each platform easier to learn and makes moving a method between them far less mysterious.
The one idea underneath
Strip away the interface and every system is building a function from requested volume to delivered volume, then applying its inverse so the delivered volume lands on target. The disagreements are about how you describe that function: as measured points to interpolate between, as the coefficients of a line, or as a compact list the software reads. Underneath, it is the same correction.
Four surfaces on the same idea
- Hamilton, on its Venus software, exposes a correction curve as a table of measured points, and its guidance stresses building the curve against the real volumes a tip moves through, including the descending volumes of a multi-dispense rather than the aliquot size. More points buy more trueness across the range.
- Tecan, in the published gravimetric calibration work on its Freedom EVO line, frames the same thing as a slope and an offset, the factor and intercept of Y equals aX plus b, fitted per volume subclass. You tune the line rather than dropping points on it.
- Opentrons, in its liquid class definitions, uses a parameter called correction by volume: a list of paired numbers, each a reference volume and the correction in microliters to apply there, with the software interpolating linearly between them and reading a positive value as grow, a negative as shrink.
- Beckman, on the Biomek platform as documented in Artel's optimization work, treats it as a linear scaling factor and offset volume, so the corrected command is the requested volume adjusted by that slope and intercept, tuned against a photometric measurement.
Four vocabularies, one function. Points, coefficients, tuples, factors: each is just a way of writing down the same line or curve.
Why the surfaces still matter
If the idea is shared, why care about the differences? Because the surface changes what is easy and what is a trap. A point-table interface makes it tempting to correct only at your one common volume and leave the rest of the range guessing. A slope-and-offset interface nudges you toward thinking about the whole line at once, which is healthier, but hides the fact that no single line fits a very wide range, so you still need to know to split into bands. A tuple list in a definition file is precise and version-friendly but unforgiving if you forget that the values interpolate rather than snap. The mental model you carry has to survive the interface, not come from it.
There is also a hard limit that no interface removes. The numbers themselves do not port. A slope and offset fitted on one instrument, or a point table built on another, encodes that specific machine, its tips, and its labware. You can copy the values across, but you are copying a description of a different physical system, and the community consensus is blunt about it: the curve has to be re-measured on the instrument that will run it. The shared idea travels. The fitted numbers do not.
Reading across without getting lost
The practical habit is to translate every platform back to the shared function in your head. When you see Opentrons correction by volume, read line to interpolate. When you see a Tecan factor and offset, read the slope and intercept of that line. When you see a Hamilton point table, read measured samples of the same line. Once every surface collapses to requested-versus-delivered, method transfer becomes a matter of re-measuring the same relationship on the new machine rather than reverse-engineering someone else's dialect.
Points, slope and offset, or tuples: every platform is writing down the same requested-to-delivered function. Learn the function once and every interface reads as a translation of it.