Hacker News new | past | comments | ask | show | jobs | submit login

So, this is cool and it's nice to have an open standard with got traction from an active company.

When setting up lab automation, instrument communication is the biggest headache. There's lots of variability in how instruments communicate (serial, gpib, analog voltage, ftp/email from a contractor,...) and in how easily accessible their protocols are (published by manufacturer, closed, too old to know). Moreover, really old equipment is still in use and new equipment isn't likely to be 'designed for autoprotocol' for a while. How do you think managing instrument communication is going to work?

What are previous similar works like? I imagine stuff like this was made, way long ago, for doing combichem and hts... did it all remain in-house?

Support for extra parameters, like constant current vs constant voltage for gels, or that kind of thing? Or will this be in the name, like "op": "gel_separate_constant_I"

Support for timing, e.g. thaw out reagentB in time to mix it with reagentA which is being centrifuged, etc?

Reagents-- Any standardization for names/concentrations, or integration with inventory management?

Any planned integration with lab notebook/management software?

Any plans for 'preventing catastrophe' or 'forbidden operations' like centrifuging asymmetrically, or mixing stuff that precipitates+clogs (vs. intentional precipitation of, e.g., dna)? Not that we should need this, but increasing abstraction makes it easier to break stuff.

Looking forward to using this and contributing, etc.




> Moreover, really old equipment is still in use and new equipment isn't likely to be 'designed for autoprotocol' for a while. How do you think managing instrument communication is going to work?

This is obviously a big issue; it's what we spend most of our time on at Transcriptic. (That, and building new hardware when it makes sense.) Only a few devices are designed for being controlled by 3rd party software and even fewer are designed for real automation like motorized lids for sample loading. Internally we have a layer that handles all of the device communication, but we haven't open sourced that and it wouldn't make sense without the rest of our infrastructure anyway: not something easy to just pick up on part of.

This is kind of outside the scope of Autoprotocol. I think that in reality there will be three big uses of it right now:

- generating eg a PDF to take into the lab - using it for more semantic information about the methods being used in conjunction with analysis of data you get from running stuff in lab - running experiments on Transcriptic

In terms of automating communication and data capture in your own lab, I think Riffyn's doing the most interesting work here and it will be interesting to see what they come out with.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: