I’m late to the party (how come it’s May '25 already?) but I’ll throw this in here:
One of the things that bugs me is setting up plates. These are hardcoded, which is a bad idea : a new code release for every new plate, and they are not centrally stored in any way. Nor can they be searched, or same plates be used across machines easily (you need to know where they are defined), etc.
I am very much wedded to Django, so what I would do is -
-
set up a generic
PlateBaseconcrete base class (data model) which covers all the basic info (nx,ny-layout, size, height, origin, wellbottomshape, has-a-lid, whatever) -
derive any instrument-specific
XxxPlateimplementation from this (containing, say, additional special Hamilton parameters or functionality, as required by that particular machine) -
Store all plates in a database (export/import from JSON format dump)
-
have a
filter_plates()routine that allows finding a (list of) matching plates by name, any parameter etc. Resulting objects would be cast back to their relevantXxxPlatederived type, but generic PLR routines would take anyPlateBasetype generically.
I use this concept routinely in my Django apps, instantiating objects from a database, as required, on the fly. Django further offers the option to create web interfaces to manage that. I’ll admit it is daunting, but I find its data model approach really versatile and powerful.
Hth
W