Hi
I just came across PylabRobot an really like what I am seeing here. We have an SPT Apricot DC1 liquid handler and I don’t see a backend for it.
Having had a bit of a look, should I work from the SaverBackend or LiquidHandlerChatterboxBackend and implement their command interfaces?
In the first instance I’d probably try and make it spit out a csv file with instructions, would it be best to use SaverBackend.get_commands_for_event() for that and take it from there?
Thank you!
W
thanks!
you’re right, we don’t have an SPT Apricot DC1 backend yet.
Either the saver backend or chatterbox would work as a starting point as both have the required methods for an lh backend, just doing different things, but both are “virtual” backends for testing. The abstract LiquidHandlerBackend may also be a good starting point.
Could you explain more about spitting out a csv with instructions? Do you know how the dc1 communicates with the host computer? In plr, backends send commands to the machines to execute the operation as they are called: when the user calls aspirate, the robot aspirates.
get_commands_for_event is a command that is probably specific to the saver backend.
Hi,
Thank you for the quick response and pointers.
With regard to direct communication, I am trying to find that out from the vendor. I don’t know yet whether that’s an option.
I do know it can take a csv input in the form of the example below
| Command | Selected | Depth | Speed | Station | Row | Column | Volume | Option |
|---|---|---|---|---|---|---|---|---|
| Loadtip | Y | 1 | A | 1 | ||||
| Aspirate | Y | 20 | 40 | 5 | E | 4 | 400 | 50 |
| Pause | Y | 0 | not Homing | |||||
| Dispense | Y | 70 | 60 | 7 | K | 15 | 200 | Y |
| Dispense | Y | 70 | 60 | 6 | B | 12 | 100 | Y |
| Empty | Y | 40 | 80 | 8 | H | 24 | Y | |
| Pause | Y | 0 | Homing | |||||
| Loadtip | Y | 3 | 0 | 0 | ||||
| Aspirate | Y | 20 | 80 | 5 | B | 1 | 300 | 0 |
| Dispense | Y | 40 | 30 | 7 | J | 20 | 100 | N |
| Dispense | Y | 50 | 50 | 8 | M | 24 | 100 | N |
| Empty | Y | 50 | 50 | 6 | H | 12 | N |
So in the first instance I think I could add a CSV writer to the SaverBackend - though I need to figure out what the args and kwargs are that are passed in…
Is there a minimal API interface I need to define specifically? I probably need to read the docs in more detail. Where is the pylabrobot front end API specified (if you see what I mean) - or is it all the functions defined in the backend?
Thank you,
W
PS I am not an experimentalist - so getting my head round stations, racks, plates and tips still !
is “it” the robot or a vendor program? is the vendor program open source / does it work on any OS?
yes. checkout backend.py. if a certain function is not supported, raise a NotImplementedError to make that explicit. (like 96 head perhaps)
the front end class is in liquid_handler.py for liquid handlers, and equivalent files for the other machines we support.
For adding a new machine, a new backend is all you should have to add. It should be 6 atomic, easy to implement functions (setup, stop, pick up tip, drop tip, aspirate, dispense). I have a tiny guide here, which definitely needs expanding. But if you have good ideas for the front end I’d obviously like to discuss those as well.
I do not think the saving part of the saver backend should be used. The saving is done for testing so we can see what calls were made in a run. I will probably replace it in the future with unittest.mock. For controlling a robot, a method should communicate directly with the robot when called - not save an instruction for later use. When I call aspirate, the robot should aspirate.
Now if the robot takes CSV files for running commands, obviously you will need to have the backend write to csv. But the csv can probably exist in memory rather than on disk. In any case, a backend for a real robot shouldn’t save calls.
Thanks, I will try and have a go.
As for the ‘it’ I referred to, I think the csv file is uploaded to the machine, so for producing a csv file I would only need to set up a rough Deck layout (I think!) as the machine knows its coordinates.
Further trying to get my head round how rails, channels, Tips, TipRacks etc relate to each other and in what order they need to be instantiated so that the Deck is ready for use.
Currently also trying to get my head round the async/await approach, have not used asyncio before.
Thanks for the link, that broadly aligns with what I’ve understood from the code.
sweet, that should be easy then
have you used wireshark before? you can use this to confirm what bytes are being sent over the wire
please make a (new) post if i can help clarify anything!