Many OEM software restricts microplate reader to 384 wells, and sometimes enhanced version enable to read 1536 wells. I tried commanding via USB and using 1536 wells microplate still fail. But a simple hack was, thanks to how PLR enable copying and modifying any resource definitions like Plate, i just tweak the x0 and y0 offset of a 384 plate to read it many more times at different coordinate so it becomes 6144 wells, successfully. Here’s an example of reading a DNA electrophoresis gel with a microplate reader.
I believe microplate readers are powerful and we need more work using it, so having it integrated more into PLR will help lot more development at high level. Best part is, it is already SBS-format friendly. Lab images can now be produced and stored more?
Disclaimer: It depends on the backend of the microplate reader
This is very cool. One thought I had was adding a masking feature where areas that are of no interest are excluded. Or possibly zone targeting. Running along strips through the middle of where you know there will be activity.
wait, i thot this is already supported in PLR, as long as the backend handles mapping of the wells for the plate reader. in read_abs/flr/lum in the frontend (pylabrobot/pylabrobot/plate_reading/plate_reader.py at main · PyLabRobot/pylabrobot · GitHub), the arguments is wells, so we can directly specify which well we want to read only. hence why, in the new backend i will add, im making sure to has this mapper to support this argument. so that reading wont only be for whole plate but capable for list of wells as well. can @rickwierenga confirm this?
for the cytation, the wells must be in a regular 2d grid, but you can choose which to read (we can theoretically support irregular wells by “redefining the plate” - there is a “set plate” command which takes A1 and then x/y spacing - but we dont do so yet.)
others might be completely arbitrary
backends should raise an error if the requested combination of wells is not supported.
the best for your backend is if we can read the wells at arbitrary locations out of the box (well.location), or potentially even have List[Coordinate] be a valid argument since there aren’t really Wells? what do you think?
your ingenuity is forcing us to rethink what a “plate” reader actually is
I will look through the new backend how to support the List[Coordinate]. Currently what it does it, it reads plates by row by sending SCANX, startx, endx, wellcounts. for this backend, it should be possible to do that, as long as the reverse engineering process thoroughly understand the deep API. However, upon trying to do that, weirdly and for unknown reasons, the backend successfully do the SCANX for 12 columns (96 plate) and 24 columns (384 plate), but not higher. So it is really uncertain if we can just pass list of as much wells/coordinates as the firmware might have unknown way of handling this. I tried to increase the usb read timeout but still failed. So I think, we can introduce that in the frontend but let backend handles what’s supported and understood currently.
Additionally, i think the plate_reader or its backend should also handle which resources is supported physically? For example, most plate readers support the usual foot print sized plates, and not the deep well which is way taller. this is safer for higher level API.
