Add support for ESELog to system

In Thursday's meeting with @ViktorShkolnikov and Omer, it was brought up that one of the university teams is going to need support for the ESELog fluorescence detector, both in the MPAM proper and int the macro language. This will require support from Glider (hi, Aaron Bowdle) as well as figuring out how to add support for general detectors.

It was implied that they want to be able to ask it to take a measurement and both use the measurement and passively log it to a file specifiable at the command line (probably as a template). The latter will imply that I'll want a general class of "logging system component", and the former implies that I'll want a notion of a general Measurement, especially since I believe that the ESELog can measure 3 different wavelengths (I'm not sure if this is done simultaneously or dynamically selected). For the macro language, I guess we'll want to index by string, unless I add a specific type that can declare its own attributes. (The latter would be cleaner; the former will probably also be nice to have.)

As the ESElog will (at least as it was earlier talked about) block at least some of the wells when in position to measure, this means that I will have to (1) have a class of "movable system component" and (2) add some sort of traffic control so that the ESELog and the pipettor don't get in each other's way. This will likely mean that the pipettor will also need to be a moveable component, but it will be complicated that the ESELog will only block some of the wells and extraction points (although for others, with a pipettor like the OT-2, it might require a different path to be taken).

Perhaps the more general notion would be that the ESElog, is a "blocking system component" in one of its two positions (as a "moveable system component", and the system as a whole allows reservations of various parts of the board vis-a-vis blocking and components moving. Then the OT-2 would move to a position nearby and try to reserve the path it wants to take (or a region over the board that the path will go over). The ESELog would reserve the parts it blocks when it wants to move into position and releases the reservations when it's finished moving out of the way. With this, the OT-2 would be able to move to unblocked regions even when the ESELog is in measurement position, but they would each block the other for the wells and extraction points in the blocked region. I can probably even set things up so that the ESELog indicates that it's willing to release and move out of the way but doesn't actually move so that if the pipettor doesn't need to use the blocked regions, it stays in place (reserving if it gets another request), but if the pipettor does want something in the blocked region, it will move and unreserve.

This implies that reservations are multistate: probably something like free, obtainable, requested, and reserved, probably as a MonitoredProperty of the Pads. I've redone this paragraph enough times to say that the actual protocol is non-trivial and will need to be designed, but it looks doable. One thing that's pretty clear is that the reservation will need to be atomic over an entire set of Pads (or, more likely, a GridRegion or list of them) or else it will be easy to deadlock. Luckily, this will be coordinating movements that take a lot of time, so locking won't be too expensive.

HPInc / HP-Digital-Microfluidics

Add support for ESELog to system #206

Migrated from internal repository. Originally created by @EvanKirshenbaum on Oct 02, 2022 at 6:04 PM PDT.

Migrated from internal repository. Originally created by @EvanKirshenbaum on Oct 04, 2022 at 11:15 AM PDT.