RS232/Serial Communication for peripheral devices

Hi all,

I am keen to integrate peripheral devices, in particular a vacuum pump (VACSTAR control from IKA), with the OT-2 and potentially the Flex.
I have read the following article from Opentrons: https://support.opentrons.com/s/article/Integrating-the-OT-2-with-other-lab-equipment
Neither of these two solutions above seem to be ideal. I think what would be the best solution is to have the serial device connected directly to the OT and have users execute scripts through the OT app rather than ssh. My initial thoughts are if I can sort serial communication then I could at least just skip these bits during simulation to allow running through OT app?
I feel the article glosses over the “USB/serial adapter (FTDI)”, from my (limited) experience you still need a USB driver installed on the raspberry pi to act as as a COM port for this. Alternatively, a lot of peripheral devices have USB ports without the need for a USB/RS232 adapter but have their own USB driver that needs installing and these don’t often advertise drivers for anything but windows. How would you go about installing drivers on the OT PC or are there better alternatives?

I’ve also found the helpful guys at QInstruments have put together a useful guide to their own py drivers for their devices for OT2. They seem to have got round a couple of the issues above by building their own py module, that they drop into the juypter notebook, and using an EEPROM programmed custom USB/RS232 FTDI converter (I don’t really understand how this works). I think this means that py protocols made this way can be simulated and executed through the OT app. Another nice feature is it also allows initialisation of their devices by serial number rather than knowing a virtual COM port number. Details of QInstruments stuff here: https://www.qinstruments.com/knowledge/qinstruments-supports-opentrons-applications/
Does anyone have experience of doing any of this? It would be nice if there was a generic serial adapter/py module for these kinds of applications on the OT already out there! I think I’m happy to put more work in upfront to make a nicer UI solution for users of the system and something that can be duplicated easily if needed in the future. I would also like to caveat all this with I don’t really know what I’m doing!

2 Likes

If you go through the atomic HTTP API then you can run all your integrations from the client computer and not have to go through the robot computer at all, but then using the opentrons app isn’t on the table

Here is a Python interface to the OT-2 API

1 Like

Yeah I think that is a nice and easy way to work and I really like the pyLabRobots philosophy. How well does it work with deck calibrations or do you still have to do that through the OT app? The only reason I kind of discounted this is a lot of the users of the system want a nice, user friendly GUI with user prompts and procedures for calibration before runs and are not always comfortable with lots of code. If that can be done easily through this then I might look into it further but otherwise I might keep digging into connecting through the robot PC. Thanks for the help

I think calibration is handled over the app if you’re using the HTTP API. The API references defined labware and positions on the deck. Here’s the repo: GitHub - Opentrons/http-api-beta: Resources for the HTTP API beta program

I am really not sure how the QInstruments code works at all, the library they provide is bytecode that Python runs a de-obfuscation method on, and which they simply say to copy into your OT-2 computer. Does it automatically execute this script after being uploaded? That seems kind of sketchy to me.

The example they give uses the Jupyter notebook, no example using the app. It seems like it would be really hard to modify the app in a way that supports commands to a new instrument, you’d have to know it front to back and it’s probably 100k lines of React code.

If the question is how to install an FTDI driver and Python code for controlling a device via Jupyter, there is probably a better way to do that than copying a file of bytecode.

Oh yeah the way they have done it is not flexible to adapt to another device that isn’t a QInstrument I don’t think. I thought it was quite a nice solution in principal but I thought there must be a nicer way of controlling serial devices by just dropping some pymodule into the jupyter notbook or something like pip without messing with USB drivers.

@ethan_jones may be able to chime in here!

1 Like

@bhastings Thanks for bringing this up!

All calibration needs to be done via the app. We do not have a method to calibrate the OT-2 outside of the app. If you run a protocol outside the app, you will also need to associate labware offsets with the specific labware.

You should wrap your serial commands in an if not protocol.is.simulating statement to prevent the commands from being sent to your device while the protocol is processed on the OT-2 before the run.

This page has some brief examples of serial communication that should get you going in the right direction.

The HTTP API is also a good option, as @Stefan has pointed out, although that is mainly for protocols used outside our app. The link I provided also has examples of our HTTP API in action!

2 Likes