Add support for Joey 1.5 layout and Wombat, Bilby support

[EvanKirshenbaum]

They've gotten in the first Joey 1.5 boards, and they need Thylacine support for them in order to test them.

The layout has changed a bit in order to give themselves lines to use for RTDs (temperature sensors). The main changes are:

1. The wells have changed shape and gone from 9 shared pads to 6. They've done this by adding one more row (+1) and turning the six pads in the first two rows by the gate into one center pad and one big horseshoe-shaped pad around it (-4). The old an new shapes are
2. Each of the heating zones has two dead pads in the middle column. Note that these dead pads are mirrored, so in the Yaminon configuration, each zone will actually need to have three dead pads so that the top and bottom match.
3. The central dead area is smaller (4x2 rather than 5x3), and there's a horizontal channel down the middle.
4. There's an additional dead pad at (10,19)/K7, the middle row, left-hand side.

A comparison between v1 and v1.5, rotated 90 degrees counterclockwise:

When it comes to the actual lines, which I assume will be important for Wombat/Yaminon but not for Bilby, according to Aaron Bowdle, the following changes have been made, in addition to pads that are no longer there:

BC27 -> K16
C28 -> K18
AB27 -> K17
A04 -> L14
AB05 -> K15
C04 -> B00
BC05 ->J14
K07 -> K14
A28 -> B32

If I understand correctly, this means that, e.g., formerly dead pad K15 (one of the pads in the new central channel) is hooked up to the pin that used to control removed pad AB05.

In addition to supporting the new layout, I'll need a way for the user to be able to specify it. My inclination is to add a --layout-version 1.5 argument, also allowing 1 or 1.0, probably with 1 as the default. I already have a --v1 and --v2 for Wombat pin mappings, which I should probably deprecate in favor of something like --wombat-version. (And similarly for --opendrop-version replacing --4.0 and --4.1).

Migrated from internal repository. Originally created by @EvanKirshenbaum on Apr 29, 2023 at 2:39 PM PDT.

[EvanKirshenbaum]

This issue was referenced by the following commits before migration:

• 0195c358d3b78d1764e9e0a0b1e2763be17172d7 by @EvanKirshenbaum on May 02, 2023 at 1:17 PM PDT
• 39d4feef8353fb07ebc7225a3e48df9f4aee217f by @EvanKirshenbaum on Jun 26, 2023 at 3:46 PM PDT

[EvanKirshenbaum]

Joey 1.5 appears to be implemented for the Wombat/Yaminon controller. Since I don't actually have the hardware, it hasn't been tested. There's no support for Bilby yet.

While doing this, I removed pretty much all of the WombatLayout stuff (including the--v1 and --v2 parameters). Most of that was just supporting the dead cells and the fact that one of the live cells had moved to the other side of the board. Aside from that one pin moving and the fact that the well pads have different cell names, everything is done using the JoeyLayout held in the parent class, which knows which pads are there and which aren't. For Yaminon, I simply have it look at the pads in the lower region, and if it isn't the case that both the pad and its mirror exist, I remove both of them. This will be more flexible as things change in the future. To do this, I had to add Board.remove_pad_at(x,y). Moving the support up to joey also means that the drop size calculation is done there.

Migrated from internal repository. Originally created by @EvanKirshenbaum on May 03, 2023 at 10:10 AM PDT.

[EvanKirshenbaum]

I also added PlatformChoiceTask.board_kwd_args() to simplify the process of getting keyword arguments out of the Namespace returned by the command-line parser. It returns a Mapping[str,Any] that can just be passed into the __init__() method:

    def make_board(self, args: Namespace, *, 
                   exerciser: PlatformChoiceExerciser, # @UnusedVariable
                   pipettor: Pipettor) -> Board: 
        kwds = self.board_kwd_args(args, announce=True)
        return Board(pipettor=pipettor, **kwds)

Unfortunately, this doesn't allow for type checking. What I really want to do is actually implement a RunConfig mechanism (#123) that would allow a Board to simply say

• Here's a class that has properties for all of the things I need to configure myself, possibly with defaults.
• They're all typed, so I know I'm getting the right sort of thing out when I access them.
• They know about all of the parameters that would be needed to add them to an argument parser.
• They would be able to take a Namespace or Mapping (or several) and construct a clone that looked in the namespace first before the defaults, using the namespace before any defaults.
  • The board init would take a Union[Namespace,MyConfigParams], and construct a MyConfigParams from the Namespace if that's what's passed in.

There appears to be an unused RunConfig class in erk.config. It appears to be a vestige of when I had started working on this back in March, 2022, and it got checked in somehow. It looks as though it's based on the ConfigParams class in mpam.types, which is only used by BoardMonitor.

It's probably almost time to revisit this to see if I can do it better.

Migrated from internal repository. Originally created by @EvanKirshenbaum on May 03, 2023 at 10:20 AM PDT.