PyLabRobot Liquid Following

General
1

Does PLR support liquid following for STAR backend? I can’t really find it in the docs for aspirate/dispense, and the firmware commands don’t clearly map to it

2

does the surface_following_distance parameter work for you?

1 Like
3

From my understanding, Venus’ “liquid following” is dynamic.

If I set liquid following on, the rate at which the head goes down varies depending on the flow rate of the liquid class and the geometry of the well, so they must be doing some fancy calculations on their end.

surface_following_distance just sets how deep the aspirate will go down right? Doesn’t change the rate?

1 Like
4

it is over the course of the aspiration, so flow rate should not matter (it is cancelled out)

to make it based on the geometry of the well, you need volume functions. these are defined for some plates. which plate are you using? (@CamilloMoschner found out the ‘rational’ computation is often not enough, and uses polynomial fitting)

5

If you add:

lld_mode=[STARBackend.LLDMode.GAMMA]*n,

to lh.aspirate(), lld should dynamically detect the liquid height based on physical detection capacitance and/or pressure (not requiring geometric definition of well)

find more backend cmds here

6

yes, lld is useful for finding the start of the liquid, but it doesn’t automatically follow (liquid following as opposed to liquid level detection). iirc surface_following_distance is the parameter for following

actually None means default and lld is disabled by default. you would have to say

lld_mode=[STARBackend.LLDMode.GAMMA]*n

or one of the others:

  class LLDMode(enum.Enum):
    """Liquid level detection mode."""

    OFF = 0
    GAMMA = 1
    PRESSURE = 2
    DUAL = 3
    Z_TOUCH_OFF = 4
1 Like
7

ah yes, I think you need both

8

Ok so it seems like LLD is for finding where the liquid is, and surface_following_distance lets us choose how much to go down after the surface.

However from my understanding it’s not immediately easy to recreate the boolean “liquid following” option in Venus, which when enabled just follows the liquid after finding its surface and basing its calculations on the geometry of the well, right?

1 Like
9

No (not yet?)

1 Like
10

Linking this here for the future, in case anyone has an answer.

I do think that liquid following is firmware level since the aspirate firmware command asks for the well cross section and other info about the well geometry which would make no sense to ask unless some liquid following calculations are happening under the hood.

11

thanks for the backlink.

the firmware command does not ask for the cross section (on star at least). venus asks for it so it can compute surface_following_distance, same as PLR.

1 Like
12

The firmware command asks for:

  • Tube 2nd section height measured from “zm”
  • Tube 2nd section ratio

So yea, no cross section, but height of second section (the one that can be U, V, flat, etc.) and also ratio between wider and narrower cross sections, which is weird to me. What calculations are those used for at the firmware level?

13

oh you’re right, i guess that counts as geometry of some form. i’m guessing this is for variable speed in the z-dimension during aspiration.

14

I have never seen a Hamilton app person use the 2nd section options. What I believe might have happened here:

Hamilton embedded software/firmware engineers enabled the dividing of containers into 2 sections to accommodate liquid level following based on their different geometries.

But in real automation scenarios it is a huge hassle to work with them.
When you look into VENUS containers they provide a seemingly arbitrary function for liquid level following distance, crucially, that never changes!
This just simplifies the surface following distance parameter calculation - even though it is not accurate.
Why does it not crash if it’s not accurate? My best guess is that VENUS sets min_z_height argument always to the cavity_bottom z-height which stops liquid level following even if the distance given would pierce through the container bottom.

(There is actually some quite complex argument prioritisation logic going on in the firmware background: if lld_detected_z_height - lld_followint_distance < min_z_height the firmware will instantly give you an error to protect its machine … Very clever embedded software engineers!
Now that you know this, you can use this information to your advantage in many ways… )

In short: VENUS massively oversimplifies, probably for simplicity reasons and doesn’t seem to actually ever use the 2nd section arguments (though a Hamilton employee would know better).

In PLR we can either choose to do the same as VENUS or use height/volume functions to be a lot more precise :slight_smile:

1 Like