Need to bias pads when transferring in liquid to a well

[EvanKirshenbaum]

It is important that when liquid is being transferred into a well, the appropriate pads are on (and off) to prevent the liquid from flowing places it's not supposed to go. The hardware people have been using this macro

acceptvolume = macro(well w) {
  [[
    w[0]: off;
    w[1]: off;
    w[2]: off;
    w[3]: on;
    w[4]: on;
    w[5]: on;
    w[6]: on;
    w[7]: on;
    w[8]: off;
    w's gate: off;
  ]]
};

Before doing the extraction, probably in Well.prepare_for_add(), we should do a Well.TransitionTo(EXTRACTABLE) (or possibly a new WellState), which should have this configuration.

Note that there's currently a bit of a bug in that the well starts out thinking that its in EXTRACTABLE, when it isn't. We probably want an initial OFF (and probably a default_state that defaults to this).

Migrated from internal repository. Originally created by @EvanKirshenbaum on Feb 02, 2023 at 11:47 AM PST.

[EvanKirshenbaum]

This issue was referenced by the following commit before migration:

• ee6734c2b86622fbe8db06b2e71c17135f3632c4 by @EvanKirshenbaum on Feb 13, 2023 at 4:03 PM PST

[EvanKirshenbaum]

Looking at the code, there are currently four WellState values:

class WellState(Enum):
    EXTRACTABLE = auto()    #: The contents are in positition to be removed by a :class:`.Pipettor`
    READY = auto()          #: The :class:`Well` is ready to move to a different :class:`WellState`
    DISPENSED = auto()      #: The :class:`Well` has just dispensed a :class:`.Drop`
    ABSORBED = auto()       #: The :class:`Well` has just absorbed a :class:`.Drop`

In order to do this, I'm going to need to add another, something like INJECTABLE.

As was the case with extraction points (#240), prepare_for_add() and prepare_for_remove() will need to get them into that state by scheduling Well.TransitionTo().

Migrated from internal repository. Originally created by @EvanKirshenbaum on Feb 09, 2023 at 11:46 AM PST.

[EvanKirshenbaum]

The approach I wound up with was to have a StateDefs object as part of the DispenseGroup. It can infer the start state from the actual state of the pads (to better handle the case where they've been twiddled manually or programmatically) and figures out transition sequences, either asserted as part of the device definition, inferred as going through READY or just doing an immediate transition. Inferred sequences (and unknown sequences) are cached.

Migrated from internal repository. Originally created by @EvanKirshenbaum on Feb 13, 2023 at 4:10 PM PST.