Replace dispense sequences by callables

[EvanKirshenbaum]

When designing changes to allow well pads to be properly biased for moving fluid on and off the board (#229), my thought was that if we want to allow users to experiment with dispense sequences written in the macro language (or Python), either for debugging new hardware or to dispense different sized drops, the easiest thing to do was to allow dispense drop() to take an optional function that took a well and did all the appropriate state twiddling.

Stepping back, what happens currently is that we use a WellMotion that asks the board for a sequence of tuples of well pad indices to get from the READY state to the DISPENSED state, and then we walk through, simulating this, stepwise, keeping track of the gate state, and reserving and biasing the exit pad at the appropriate time. The way this is done internally, if another well in the same well group (which, by construction, has its internal pads in the same state) tries to dispense before we've turned the gate off, we can adopt it (turning on the gate if we've just turned ours on), so the two wells can dispense in parallel.

My thought here was that I could switch to taking a function written to assume a single well and just run it, but change the implementation of WellGate.state to look to see whether it was, in fact, the lead drop in a dispense action (or absorb; they would work similarly). If it was, it would forward the state change on to the underlying state objects of all of the gates that were participating, as well as doing other bookkeeping like storing in the WellMotion whether it's still safe for another well to join in and doing any reservations.

This is all reasonably promising, but it dawned on me that if I give users the ability to define their own macros, the first thing they're going to want to try is pulling larger volumes out of the well before turning off the gate and cutting the blob off, and the whole "doing any reservations" and "turning on the exit pad" as part of the gate twiddling isn't going to work.

So, for now, I'm going to stick with dispense sequences and figure that at some point it will be possible to play with defining them in board definition files (#122).

But this is almost certainly the way to go long-term, and I think that two other recent issues will make it possible:

1. Regions (#243) will allow the specification of pads on the board that the function is planning on playing with.
2. Region reservation (#242) will allow those pads to be reserved and cleared before we start or before the gate is first turned on.
3. Transformations (#244) will allow to work in a coordinate space whose origin is the well's exit pad and with a well-known orientation. This will allow the corresponding pads to be seen in all participating wells.

My thought is that I can use a similar notion to what I proposed for gates to have pads ask "Am I participating in an action? If so, what's my transformed coordinate?" If the answer is yes, then for reservations and bit twiddling, pass on the operation to all pads in this action that have the same transformed coordinate.

Migrated from internal repository. Originally created by @EvanKirshenbaum on Feb 11, 2023 at 5:35 PM PST.

[EvanKirshenbaum]

Note that doing this will mean that the region and transform will need to be specified. Each well could have a default transform, specified in the board definition, and the region could default to just containing the exit pad.

Alternatively, the region could be specified dynamically within the macro. If we say that pad reservation checks to see if we're in an action (by looking in the environment in the macro language. For Python we may just have to specify it) we can say that any pad that's reserved gets added to the set, and its mirrors get reserved along with it. Similarly, if a pad in the transformed coordinate system gets twiddled, it gets added to the set.

Migrated from internal repository. Originally created by @EvanKirshenbaum on Feb 11, 2023 at 5:41 PM PST.