[DIYbio] Re: Automation flow (was: BioPrinter won 1st Prize)

I think the future is in USB peripherals really, which are then connected to a larger machine (or larger embedded computer, like Raspberry Pi) which in turn is on the network (likely via wifi).  The lab devices present themselves as serial ports and are controlled with simple text commands (aka virtual COM ports for windows people), optionally using USB power where possible.   This keeps the individual lab devices relatively simple.  And a lab could mix-and-match only those devices they need.  USB cables and hubs have come down in price to be near free, and USB extender cables eliminate cable length problems ("active" extension cables with built-in hub to stay within the USB signal limitation). I've never been much of a proponent for embedded network software or embedded network ports -- even after building these devices -- because it adds a big chunk of complexity to an otherwise simple instrument (for example, most bio instruments are really only controlling a couple different things, like sensor on/off or single data acquisition measurement, etc).  USB 2.0 has plenty of bandwidth for higher bandwidth devices like imagers.  Most 90's era devices if they included automation/computer interfaces used industrial-strength serial ports and simple text commands, even complex robots used this method, see the Tecan command set for example (google "perl tecan yaml").  These ports can be replaced with simple USB without limits on the number of physical ports, which was such a problem with old serial devices.  Simple text commands allows any computer software, in any language, to control the machinery (although even Tecan put security in the middle which required paying Tecan $$$ to remove).  The lab automation industry itself has been pushing for ethernet-enabled devices because it means they can sell their proprietary software into the device maker's products and then turn around and sell their proprietary software into the PC application products too (on the similar front, they're trying this with USB device drivers).

Additionally this means there is an intelligent networked device (or PC) which controls these USB lab peripherals.  The PC has virtually unlimited resources so it can act as either a protocol server or web app server or some enterprise-class database-integrated behemoth server (larger scale lab automation absolutely needs to be tied into the inventory database, for pulling the right reagents from the right locations, or checking if needed equipment is online and available, posting results data, etc etc).  Tablets/handsets connect to the devices through the PC web-app server which is the typical model for communication now.   (Even when IPv6 arrives and every device could theoretically have direct internet addressing, the model will still likely be client->server->device, not client->device.)

Lab devices don't move around, so there's not much need for wireless, though it would be "cool".  It's also much tougher to sell a niche wireless device (certification requirements, etc) than to sell a wired device.
 
Years from now the solution will be wireless power (which still presents itself as a virtual COM port for controlling the device, through the wireless power's communication link ;-D ) -- though wireless power is not cheap enough or ubiquitous enough yet (google "wireless blender").

If going ethernet then the natural trend would be to try power-over-ethernet too, to eliminate the power cords, but that also is not cheap enough or ubiquitous enough.  When I say ubiquitous, the measurement is seeing a huge box at Fry's with a big sticker that says "$1.99 surplus".  The world prefers USB to POE.

I think the bigger trend is in killing the silly membrane/touch keypad and LCD/VGA display from the instruments themselves.  That's 50% of the manufacturing cost (or more) right there.  Move the user interface onto the PC or tablet or smart phone and let the lab device just be completely enclosed.  The devices themselves should have no more than 2 push buttons which covers the operations of: power toggle and "go/stop"; and no more than 2 LED's to indicate operational status.  That's old-school getter-done design.


## Jonathan Cline
## jcline@ieee.org
## Mobile: +1-805-617-0223
########################