liquid handling robots -- types and styles

[Jeswin]

I was just reading about the OS liquid handling robots here. You guys
talk about using an XY axis method to move the bot around. I think it
was mentioned (not sure if I read correctly) to use a circular
platform. If that is the case, then you only need to rotate the
platform and move the pipette in a linear motion and down to inject
the fluid. So I guess thats we need XZ axis for the arm and circular
rotation for the well plate. The precision would only be needed on the
well-plate rotation and the arm ouly needs a fixed XZ value. So
instead of 2 precision servos, we can reduce it to one.

These are just some initial thoughts. Are there any commercial robots
like this that I can read about?

I attached my crude rendering.

[Mac Cowell]

Fraction collectors are often designed with tubes in a spiral arrangement.  Somehow they are able to address an arbitrary tube with a single motor for the carousel and a single solenoid for the dispensing tip.

http://www.google.com/search?q=fraction+collector&hl=en&prmd=ivns&tbm=isch&tbo=u&source=univ&sa=X&ei=V7NWTuHcJunjiALuho3QCQ&ved=0CFsQsAQ&biw=1150&bih=806

-- 
Mac Cowell // 775.553.5005 // @100ideas

--
You received this message because you are subscribed to the Google Groups "DIYbio" group.
To post to this group, send email to diy...@googlegroups.com.
To unsubscribe from this group, send email to diybio+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/diybio?hl=en.

Attachments:

- LH_circular_spin.jpg

[Cathal Garvey]

Probably by gearing them together, so it's just a fancy coiled version of a long linear rail?

On 25 Aug 2011 21:42, "Mac Cowell" <m...@diybio.org> wrote:
> Fraction collectors are often designed with tubes in a spiral arrangement. Somehow they are able to address an arbitrary tube with a single motor for the carousel and a single solenoid for the dispensing tip.
>
> http://www.google.com/search?q=fraction+collector&hl=en&prmd=ivns&tbm=isch&tbo=u&source=univ&sa=X&ei=V7NWTuHcJunjiALuho3QCQ&ved=0CFsQsAQ&biw=1150&bih=806
>
> --
> Mac Cowell // 775.553.5005 // @100ideas
>
> On Thursday, August 25, 2011 at 1:36 PM, Jeswin wrote:
>
>> I was just reading about the OS liquid handling robots here. You guys
>> talk about using an XY axis method to move the bot around. I think it
>> was mentioned (not sure if I read correctly) to use a circular
>> platform. If that is the case, then you only need to rotate the
>> platform and move the pipette in a linear motion and down to inject
>> the fluid. So I guess thats we need XZ axis for the arm and circular
>> rotation for the well plate. The precision would only be needed on the
>> well-plate rotation and the arm ouly needs a fixed XZ value. So
>> instead of 2 precision servos, we can reduce it to one.
>>
>> These are just some initial thoughts. Are there any commercial robots
>> like this that I can read about?
>>
>> I attached my crude rendering.
>>
>> --
>> You received this message because you are subscribed to the Google Groups "DIYbio" group.

>> To post to this group, send email to diy...@googlegroups.com (mailto:diy...@googlegroups.com).
>> To unsubscribe from this group, send email to diybio+un...@googlegroups.com (mailto:diybio+un...@googlegroups.com).

[John Griessen]

On 08/25/2011 03:42 PM, Mac Cowell wrote:
> Somehow they are able to address an arbitrary tube with a single motor
for the carousel and a single solenoid for the dispensing tip.

That implies that the radial direction of movement is tied to carousel rotation by
"a good mechanical system". Such as a scroll spiral shape that moves the tip
as the carousel spins.

And like Cathal said.

On 08/25/2011 03:36 PM, Jeswin wrote:
> So I guess thats we need XZ axis for the arm and circular
> rotation for the well plate. The precision would only be needed on the

> well-plate rotation and the arm only needs a fixed XZ value. So

> instead of 2 precision servos, we can reduce it to one.

Motors *are* complexity, but two motors is not too bad, especially
if using them you can get a modularity benefit. If you afford two motors
you can do a system part I've been planning out to allow random access to
spots on a carousel. That random access also means programmable for other uses
of the linear mover with pipette on it. Random access motion gives you speed.

If you don't have speed, you should have the ability to sequences of
steps to get more done without human handling help. If you depend on any human
help loading unloading etc. you want speed.

John

[Simon Quellen Field]

There were these things we used when I was a kid, called vinyl records,

that had a spiral groove cut into them on which a stylus tracked.

All you need are two bits from the microcontroller.

One bit starts the turntable spinning.

The other turns on a solenoid to squirt the liquid.

If you like, you can have another pin sense a microswitch to know

exactly when the tube is in position.

Another way to handle this is to use a bandolier belt, like a machine gun

does. Load the tubes where the bullets go, and pull on the belt.

The belt doesn't even need to be neatly coiled up -- it can be randomly

snaked into a box, and pulled out through a slot.

-----

Get a free science project every week! "http://scitoys.com/newsletter.html"

--
You received this message because you are subscribed to the Google Groups "DIYbio" group.
To post to this group, send email to diy...@googlegroups.com.

To unsubscribe from this group, send email to diybio+unsubscribe@googlegroups.com.

[John Griessen]

On 08/25/2011 05:15 PM, Simon Quellen Field wrote:
> Another way to handle this is to use a bandolier belt, like a machine gun
> does. Load the tubes where the bullets go, and pull on the belt.
> The belt doesn't even need to be neatly coiled up -- it can be randomly
> snaked into a box, and pulled out through a slot.
>

Like the bio-bullet analogy inherent.

[Russell Durrett]

Interesting idea, but if you use a circular platform it would be hard
to work with 96- and 384-well plates - which is kind of the point with
robots.

If you're interested in building your own, think about keeping the
pipette stationary and just moving the platform xyz. We have one in
our lab that does this and it doesn't seem like it would be hard to
replicate.

Or, get a Biomek 2000 off equipnet or labx.

>  LH_circular_spin.jpg
> 476KViewDownload

[Bryan Bishop]

On Fri, Aug 26, 2011 at 12:53 AM, Russell Durrett wrote:

pipette stationary and just moving the platform xyz. We have one in
our lab that does this and it doesn't seem like it would be hard to
replicate.

Just out of curiosity.. do you mean at the Genspace lab?

- Bryan
http://heybryan.org/
1 512 203 0507

[Cathal Garvey]

That ammo-feed concept is rather wonderfully hilarious. I can think of all sorts of subversive uses for an eppie-rifle. :)

>> To unsubscribe from this group, send email to diybio+unsubscribe@**
>> googlegroups.com <diybio%2Bunsu...@googlegroups.com>.
>> For more options, visit this group at http://groups.google.com/**
>> group/diybio?hl=en <http://groups.google.com/group/diybio?hl=en>.

>>
>>
>
> --
> You received this message because you are subscribed to the Google Groups "DIYbio" group.
> To post to this group, send email to diy...@googlegroups.com.

> To unsubscribe from this group, send email to diybio+un...@googlegroups.com.

[John Griessen]

On 08/26/2011 12:53 AM, Russell Durrett wrote:
> work with 96- and 384-well plates - which is kind of the point with
> robots.

We've heard others say, "Why be tied to 96 well plates?"
What is your reason?

The design ideas we are tossing around are about
OSHW (open source hardware), and ultra low costs and flexibility and
programability and modularity to reuse and adapt.

John

[Russell Durrett]

> We've heard others say, "Why be tied to 96 well plates?"
> What is your reason?

The same reason plates exist in the first place - a plate is easier to
handle than a bunch of independent tubes. The successive rows of
reaction wells are good for multichannel pipetting reagents a row at a
time and the grid makes it easy to dictate XY coordinates.

> The design ideas we are tossing around are about
> OSHW (open source hardware)

Has someone patented the 96-well plate or something?

Brian - one day! but unfortunately the one I was talking about is at
cornell med.

[CrazyCarl]

moving plates >> i like this idea ... less precision equipment being
moved = better


so whats the smallest volume thats regularly used in a lab? or is it
" well go as small as our equipment tolerates" ?

[Russell Durrett]

> so whats the smallest volume thats regularly used in a lab?

I guess it depends on what you're doing. PCR reaction volumes are
typically 10-50ul, but a robot capable of putting a reaction together
on its own would need to be able to pipette volumes as small as 1ul.

[Jay Woods]

It would be interesting to use a pair of plates and spin (slowly) on an axis
between them.

[John Griessen]

On 08/27/2011 01:23 AM, Russell Durrett wrote:
>> "Why be tied to 96 well plates?"
>> > What is your reason?
> The same reason plates exist in the first place - a plate is easier to
> handle than a bunch of independent tubes.

No argument there. Was suggesting radial shapes as a low cost "plate"
in polar coords rather than cartesian.

On 08/27/2011 08:43 PM, CrazyCarl wrote:
> moving plates>> i like this idea ... less precision equipment being
> moved = better

The cost of using that design constraint is more footprint area on the lab bench...
Think plate size, or at least array size X 4 plus margins.

To make a good lab equipment design requires considering a list of all features,
not just one rule of thumb... and if the plate holders are as complex as the
motors so they can avoid misregistration then...it's indifferent design-wise.

A radial "plate" is cylindric and attaches easily to a motor shaft, and being low speed,
is a good candidate for crude, low res, rough surfaced 3D printing as it is now.

[Jay Woods]

Have you seen any 2-D radial printers? A lot of the parts for a 3-D printer
would be better printed on a 2-D radial.

[John Griessen]

On 08/28/2011 10:37 AM, Jay Woods wrote:
> Have you seen any 2-D radial printers? A lot of the parts for a 3-D printer
> would be better printed on a 2-D radial.

Not yet. Cartesian Coords are what the usual math/graphics code toolkits use,
so that's why we have so much cartesian 3D.

I think the developers of 3DP
bots are hoping for higher resolution as volume of interest builds, so
they don't worry with ways to match coordinate system to the task, or
squeak by with crude resolution.

[mad_casual]

On Aug 27, 1:23 am, Russell Durrett <rover...@gmail.com> wrote:
>
> Has someone patented the 96-well plate or something?
>

Nobody's patented it (or everybody has some meaningless variation of
it patented), the reason I said 'Why be tied to 96 well plates?' is
because I think 96-well plates are becoming the 'MS Windows' of
biochemistry from a problem solving standpoint. Every problem
application can be adjusted to fit a 96-well plate and if your problem
doesn't fit in a 96 well plate, it's not worth solving.

Please don't take this as insulting but; How many patients at Cornell
Med. have been diagnosed from a 96 well plate? How much Taq has been
grown and used/sold from 96-well plates? Restriction enzymes?
Molecular motors? How many plasmids are grown up and stored in 96-well
plates? How many colony isolations are done from 96-well plates? What
type of plates do you culture your yeast, arabidopsis, or CHO samples
in, 6-well? 4?

Not saying 96-well plates are bad by any means, but if all your robot
can handle is 96/384 well plates...

[John Griessen]

On 08/29/2011 09:28 AM, mad_casual wrote:
> Not saying 96-well plates are bad by any means, but if all your robot
> can handle is 96/384 well plates...

Now you're talking. Aim higher. Demand more for your money.

The info processing part is getting easier and easier with $20
eval boards for making a system that can run a fixed point python
language for all the steps needed to deal with odd sized plates
as well as a native "plate" that is really a disc and uses polar coordinates.

Changing coordinate systems is not that hard and if it takes some time,
that's OK for a bot that can sequence many steps unattended and handle odd plates
with a small extra programming effort.

So, I can easily see a modular incubator/turbidity meter/liquid handler
used to make a whole liter of culture over days, transferring the output to
a refrigerator. The same machine can have a square plate snapped into place
and prep that plate with ten different liquids with NaOH wash and clear water washes
between UV bombardments to get the pipette ready for the next liquid
without contamination just by loading a different program.

This kind of lab gear could be connected by USB, but having USB for development
connection and using ethernet or radio with IPv6 addresses for ordinary
control and data would be better.

Anyone interested in developing these system parts with me?

John Griessen

[Jeswin]

On Mon, Aug 29, 2011 at 1:50 PM, John Griessen <jo...@industromatic.com> wrote:
>
> Anyone interested in developing these system parts with me?
>
> John Griessen
>

Not sure how I can help but I'm interested and have time until I can find a job.

No idea if this is a needed automation but wouldn't it be nice if we
could put together an auto-cell transformation bot. It would do
everything from inserting the DNA (heat shock is best?) to picking out
the transformed cells. Not sure if its possible to automate the
plating though. This might save the poor undergrad who has to prepare
a set of 30 or so.

[Mac Cowell]

Cool idea. Some guys published a paper documenting an automated stain/destain x3 system for DNA visualization in gel electrophoresis using methylene blue. Their main actuators were fuel pumps from hobby airplanes. They used a stamp for logic (was a while ago).

Seems lake same basic design could be adapted for an automated CaCl / heatshock transformation system.

On my phone, ping me if you want the ref.

Cheers
Mac

231.313.9062 // @100ideas // sent from my rotary phone

[Jeswin]

On Mon, Aug 29, 2011 at 5:08 PM, Mac Cowell <m...@diybio.org> wrote:
> Cool idea.  Some guys published a paper documenting an automated stain/destain x3 system for DNA visualization in gel electrophoresis using methylene blue. Their main actuators were fuel pumps from hobby airplanes.  They used a stamp for logic (was a while ago).
>
> Seems lake same basic design could be adapted for an automated CaCl / heatshock transformation system.
>
> On my phone, ping me if you want the ref.
>
> Cheers
> Mac

put that ref up, Mac. Title and journal, please. Thanks

[CrazyCarl]

@mad_causal
------------------------------------------------------------------------------------------------------------------

'Why be tied to 96 well plates?' is
because I think 96-well plates are becoming the 'MS Windows' of
biochemistry from a problem solving standpoint. Every problem
application can be adjusted to fit a 96-well plate and if your problem
doesn't fit in a 96 well plate, it's not worth solving.

------------------------------------------------------------------------------------------------------------------

^^ so the 96 well plate was my default for NEED of standards /
parellelization...you're both advocating 96 well and saying its not
the solution???

@John Gressen
------------------------------------------------------------------------------------------------------------------

The same machine can have a square plate snapped into place
and prep that plate with ten different liquids with NaOH wash and
clear water washes
between UV bombardments to get the pipette ready for the next liquid
without contamination just by loading a different program.

------------------------------------------------------------------------------------------------------------------
^^ This is EXACTLY what the robotics kids nee d. I was musing about
taking the "online protocols" and translating them into this kind of
thing

EX: Protocol XYZ needs:
- 10 liquids to be dispensed at 10uL accuracy
- 2 of these liquids are highly caustic
- Centrifuging at 300Gs for 10 min
- Incubation at 12C for 2 mins

^^ It is that SIMPLE ... let the real biologist figure out what to put
into the pipes =]


------------------------------------------------------------------------------------------------------------------

This kind of lab gear could be connected by USB, but having USB for
development
connection and using ethernet or radio with IPv6 addresses for
ordinary
control and data would be better.

------------------------------------------------------------------------------------------------------------------
^^ a CoOP called SILA advocates used of ethernet ... This is how my
bot runs ...

I think its a good solution bc we're talking really simple "binary
protocols" ( not to be confused with scientific process protocols )

I cant say I've transferred data over USB.. but I've heard there are
LOTS of drivers involved between machines ( pain in the ass )

the wireless protocol was:
1) design software (C++ on the liquid handlers arduino
microcontroller) to accept in binary
2) design software (Ruby on the server)

^^ nice thing with this is you get to work in nice high level
languages

[John Griessen]

On 08/30/2011 10:46 AM, CrazyCarl wrote:
> ^^ a CoOP called SILA advocates used of ethernet ... This is how my
> bot runs ...
>
> I think its a good solution bc we're talking really simple "binary
> protocols" ( not to be confused with scientific process protocols )
>

SILA sounds good. It may have overhead common with closed hardware vendors
built in -- seems very much oriented at info systems consultant/software vendors.
I'll read more about their standards.

> I cant say I've transferred data over USB.. but I've heard there are
> LOTS of drivers involved between machines ( pain in the ass )

USB is very windowsy, not super quick to develop, but many demand it.

> the wireless protocol was:
> 1) design software (C++ on the liquid handlers arduino
> microcontroller) to accept in binary
> 2) design software (Ruby on the server)
>
> ^^ nice thing with this is you get to work in nice high level
> languages

Tell us more about your "bot" mentioned above...
And are you an equipment user or maker?

John

[JonathanCline]

> 'Why be tied to 96 well plates?'

The primary benefit of 96 well plates is human form factor.
Next on the priority list is the ability to fix the error due to
contamination, i.e. splatter between wells.
The error can be assumed uniform since all wells have
standard spacing (unlike a radial arrangement). Some
protocols dictate that rows and/or columns should be
skipped in order to eliminate contamination.
Third is likely density. A circular plate would have fewer
wells than a rectangular plate in the same space if wells
are the same size.

A while back I saw a poster for a new 104-well plate.
Why 104?
Because it makes the columns symmetrical about the X axis
so it is easier for the coordinate math. I don't think it will
catch on anytime soon.

> ^^ a CoOP called SILA advocates used of ethernet ...

SiLA is staying in the iron age by doing so. It's only
slightly better than the stone age of serial ports.
Wireless should be considered but pick a good
wireless for the application (wifi modules may not be
appropriate due to power consumption and cost and size).
The wireless also has to work within a lab environment
(many walls and arbitrary distance). Tradeoffs between
bit rate and latency are good to look at too. For example
the Nordic chipsets have short payload mode which reduces
bit rate but would allow quicker round-trip time in the data
protocol.

> I cant say I've transferred data over USB.. but I've heard there are
> LOTS of drivers involved between machines ( pain in the ass )

The open source libusb is very good and works across all
typical platforms. It allows for very rapid USB development
of applications on the host machine.

> 1) design software (C++ on the liquid handlers arduino
> microcontroller) to accept in binary

Don't use C++ on a microcontroller if you want it to be
productized.




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

[JonathanCline]

On Aug 25, 3:15 pm, Simon Quellen Field <sfi...@scitoys.com> wrote:

> All you need are two bits from the microcontroller.
> One bit starts the turntable spinning.
> The other turns on a solenoid to squirt the liquid.
> If you like, you can have another pin sense a microswitch to know
> exactly when the tube is in position.

Liquid handlers are a little more complex than that. Depending
on the liquid (viscosity, temp, etc), and the well depth and plate
height, and the contents of the well at that moment, the tip moves
on the vertical axis to eliminate splatter from a falling droplet
plus attempts to link the droplet into the surface so the last
drop doesn't stick to the tip when dispensing finishes. The
axis have step resolution of 1mm down to 0.1 mm to facilitate
the fine tuning.

> Another way to handle this is to use a bandolier belt, like a machine gun
> does. Load the tubes where the bullets go, and pull on the belt.
> The belt doesn't even need to be neatly coiled up -- it can be randomly
> snaked into a box, and pulled out through a slot.

There is a large scale commercial liquid handling robot which
uses plates (or other labware) on a belt like this. The belt is
rolled
inside a very large container and mechanically ejected as needed.
The labware pops out of the belt when the robot is ready to accept a
new plate. Other vendors mentioned that this scheme is not very
popular.


A couple other notes:


- Custom labware can be made on demand for roughly the
same cost as off-the-shelf labware. (It's not the materials which
cost the $1 to $5 or more per plate anyway.) Just send the
CAD files to the manufacturer with quantity needed and they
fab & send the plates. Corning mentioned they provided this
service. Any standard CAD format is OK.


- The big benefit of designing with a circular plate is to re-use
mechanical components of a DVD/CD player or CD cartridge
player.
It is all produced in large volumes (and surplused) so it's very
cheap when compared to custom mechanical components.


- The biggest shift would come from using paper as a substrate
instead of PVC/plastics. The cost of the machinery is one thing..
try iterating through 1,000 plates at $2 a piece while debugging
the automated robot protocol and it makes a lab want to throw the
robot out the window -- and that's even before the experiment
starts to run.

[mad_casual]

On Aug 30, 10:46 am, CrazyCarl <carlcr...@gmail.com> wrote:
> ^^ so the 96 well plate was my default for NEED of standards /
> parellelization...you're both advocating 96 well and saying its not
> the solution???

tl;dr - Sorry, 96 well plates are a standard and widely used. Just be
very much aware that 96-well plates are a recently invented automatic
shotgun in a wide world of biological/experimentation weapons that
need automating.

First, I apologize if I gave the impression that I have all the
answers or that my answers didn't have a significant dose of personal
opinion/philosophy. I don't know your exact goals or personal
experience, nor the details of progress/work you've made automation-
wise thus far, if you've already automated something using 96-well
plates, I wouldn't undo it by any means. None of the above was my
point in originally posting 'anti-96 well' plates.

If I wanted to automate all of DIYBio's data handling needs, what OS
should I use? If I have a NEED of standards/parallelization should I
use Windows (threads), Linux (fork), or should I think network/
embedded/OSless (asynchronously)? Sticking with the weapons analogy,
if I need to shoot something, should I use a rifle, machine gun, a
shotgun, or a gatling gun?

What JonathanCline points out further down as two of a 96-well's
strengths (and plates in general), IMO and with respect, are a hideous
weaknesses. If we were talking test tubes and 5x2, I might agree with
the 'human form factor' but instead we equip humans with an 8-channel
pipette or two and then fit the plate to that. It's plain to see that
96-well plates don't fit humans as no one except laboratory
biochemists working around the robots that require them use them. I
never see biologists using 96 well plates in the field or at the
hospital. Heck I don't even see scientists in the lab next to the
robot using 96-well plates. Eppies? Yes. 12 mm culture tubes? Sure.
Also, IMO, having to sift out contamination in a 96 or 384 well 'blast
radius' isn't even worth the attempt, especially if the information is
time or resource sensitive in any real way. JonathanCline even
recommends spacing them out, which makes it a 48 or 24 well plate
then, right? You hope to minimize the effect by knowing how
contamination would happen and what effect it would have ahead of
time. IMO, this is avoiding taking your leg off with a shotgun by
spreading your legs apart or simply having fewer legs.

With more sequential handling (e.g. staggering, would it be too sexy
to call it asynchronous?) , detecting and pinpointing contamination on
the fly is so ridiculously easy a computer can do it. Moreover,
because of the staggering, cross contamination errors that are
unchecked, can be accommodated/tolerated and tend to be unidirectional
wrt the workflow and single sample. If not, they are progressively
minimized over fewer samples. Going further, with staggered handling,
you gain the ability to do actual experimentation with the samples and
the robot. The plate robots I've dealt with were extremely difficult
to get to do something like; if samples A1 and A2 are both positive
and B3 is negative, treat well A3 and Row E with reagent Z else treat
column 4 with reagent X and A4 with reagent Y, and when you got them
to do that, that's all they did. And they did it slowly, after you
reconfigured your pipette tips and reagents appropriately, by hand.
Adding a sample or ten unexpectedly halfway through the analysis
wasn't even fathomable. The staggered-sequential bots' handling of
this is comparatively easy. I know plate robots can mitigate and even
do some of these things as I've made some do it, but IMO plate bots
are a standardized way of doing standardized, predictable, and
uninteresting biology. IMO, their greatest application is to sift
through the hundreds, if not thousands of irrelevant drug compounds
and genetic variants to find the handful of useful ones (something,
again IMO, biology does faster and better anyway). IMO, the robots are
built to assemble and sift through libraries, not write books. It's
been almost a decade since I've dealt with plate bots, maybe they've
gotten much better, I could be wrong.

>
> @John Gressen
> ---------------------------------------------------------------------------­---------------------------------------

>  The same machine can have a square plate snapped into place
> and prep that plate with ten different liquids with NaOH wash and
> clear water washes
> between UV bombardments to get the pipette ready for the next liquid
> without contamination just by loading a different program.

> ---------------------------------------------------------------------------­---------------------------------------

> ^^ This is EXACTLY what the robotics kids nee d. I was musing about
> taking the "online protocols" and translating them into this kind of
> thing
>
> EX: Protocol XYZ needs:
> - 10 liquids to be dispensed at 10uL accuracy
>   - 2 of these liquids are highly caustic
> - Centrifuging at 300Gs for 10 min
> - Incubation at 12C for 2 mins
>
> ^^ It is that SIMPLE ... let the real biologist figure out what to put
> into the pipes =]
>

> ---------------------------------------------------------------------------­---------------------------------------

> This kind of lab gear could be connected by USB, but having USB for
> development
> connection and using ethernet or radio with IPv6 addresses for
> ordinary
> control and data would be better.

> ---------------------------------------------------------------------------­---------------------------------------

[John Griessen]

On 09/01/2011 04:40 AM, mad_casual wrote:
> With more sequential handling (e.g. staggering, would it be too sexy
> to call it asynchronous?) , detecting and pinpointing contamination on
> the fly is so ridiculously easy a computer can do it.

By sequential handling, are you meaning drawing a sample into
a bubble separated chem analyzer, or drawing into a handler's pipette
to move somewhere else, then do a pipette
wash cycle to decontaminate the pipette?

Moreover,
> because of the staggering, cross contamination errors that are
> unchecked, can be accommodated/tolerated and tend to be unidirectional
> wrt the workflow and single sample. If not, they are progressively
> minimized over fewer samples. Going further, with staggered handling,
> you gain the ability to do actual experimentation with the samples and
> the robot. The plate robots I've dealt with were extremely difficult
> to get to do something like; if samples A1 and A2 are both positive
> and B3 is negative, treat well A3 and Row E with reagent Z else treat
> column 4 with reagent X and A4 with reagent Y, and when you got them
> to do that, that's all they did. And they did it slowly, after you
> reconfigured your pipette tips and reagents appropriately, by hand.

All the above difficulty would go away with an openly programmable
open hardware design of liquid handler.

On 09/01/2011 04:40 AM, mad_casual wrote:
> If I have a NEED of standards/parallelization should I
> use Windows (threads), Linux (fork), or should I think network/
> embedded/OSless (asynchronously)?

For parallel operations there is one networking method evolving now that could help
keep your recipes, your controlling programs as open and cross platform
as possible -- ethernet with precision time protocol (PTP).

PTP and ethernet between parts of a liquid handler would let you keep the
programmed timing of pipette squirting in a high level program that orders
the syringe pump to "move this way this fast", count time until X, and then "stop ", and then
blah blah low level command, but no commands like "do wash cycle" With such
a division of where the code functions are you can put the high level code on windows
machines and linux and get the same results running them with no trouble.
What I've described is not the usual embedded system, but some low level things
like timer triggered events are handled by embedded controllers independent of
the machine running the recipe. The windows or Mac or linux machine running the
recipe will ask the PTP network about time, then give orders relative to time, and let
the PTP network tell it when to act.

John

[Jonathan Cline]

As a datapoint for the requirements of an automated system,
here is a published protocol which would do well to be automated.
"Species Identification of Marine Fishes in China with DNA Barcoding"

It is typical one using 96 well plates.
As stated, each well of the plate contains
"10.5 μl mixture and 2 μl genomic DNA" for a total of less
than 15 uL. The liquid handler has to handle resolution
of 0.5uL from 1 uL to some upper range determined by
the pipette tips (likely 10 uL to 20 uL).
In this protocol, a liquid handler channel #1 would be
used to aspirate the "mixture" from a reservoir onto
well # XY on plate Dest. Then liquid handler channel #2
would be used to transfer the input sample (2 uL,
previously prepared) from well # RC on plate Src to
well # XY on plate Dest. Then the plate Dest would be
physically moved from the table position A,B to a plate
shaker at table position C,D. The shaker would activate
for some time. Then the plate would be physically moved
again to table position E,F which is the input tray of a
plate-loadable thermocycler (like a DVD tray, eject &
load). Or, a human would have to carry the plate Dest.
Once this is in operation, the original plate Src would be
moved to the discard bin (i.e. picked up from table
position P,Q and dropped at table position R,S which
is above a biohazard trash can). When thermocycling
is done, the tray would eject, then the plate physically
moved from table position E,F into a column loader at
table position J,K and column loader activated to store
the plate until a human collects all for gel analysis on
the "E-Gel 96-well system" (which is not automated
at all, so requires human interaction... labor intensive).
Then repeat the thermocycling (likely by hand) and
then use a pipette to manually move each well's
contents onto another plate for sequencing.

Add to this that different plates have different heights
(for larger total liquid volumes), slightly different
spacing (even if 96 well), and different curvature on
the bottoms. Some plates have pointy wells so very
small droplets collect at the very middle of the well
for easy aspiration. Other plates have flat or rounder
bottoms so the contents can mix more easily (on
a shaking table). etc, etc, etc. However: an open
source platform can choose a single type of plate
to go with as a common platform first, make it work
well for a specific need, then expand from there later.



I hope all this sheds some light on what's going on
in labs right now.



Species Identification of Marine Fishes in China with DNA Barcoding
http://www.hindawi.com/journals/ecam/2011/978253/

doi:10.1155/2011/978253

Research Article

Species Identification of Marine Fishes in China with DNA Barcoding

Junbin Zhang
College of Fisheries and Life Science, Shanghai Ocean University,
Shanghai 201306, China

Received 10 December 2010; Accepted 27 February 2011

....

PCR reactions were carried out in 96-well plates using Mastercycler
Eppendorf gradient thermal cyclers (Brinkmann Instruments, Inc.). The
reaction mixture of 825 μl water, 125 μl 10× buffer, 62.5 μl MgCl2 (25
mM), 6.25 μl dNTP (10 mM), 6.25 μl each primer (0.01 mM), and 6.25 μl
Taq DNA polymerase (5 U/μl) was prepared for 96 wells of each plate,
in which each well contained 10.5 μl mixture and 2 μl genomic DNA.
Thermocycling comprised an initial step of 2 min at 95°C and 35 cycles
of 30 sec at 94°C, 40 sec at 52°C, and 1 min at 72°C, with a final
extension at 72°C for 10 min. Amplicons were visualized on 2% agarose
E-Gel 96-well system (Invitrogen). PCR products were amplified again
with the primers M13F (5′-TGTAAAACGACGGCCAGT-3′) and M13R (5′-
CAGGAAACAGCTATGAC-3′), respectively, using the BigDye Terminator v.3.1
Cycle Sequencing Kit (Applied Biosystems, Inc.). Thermocycling
conditions were as follows: an initial step of 2 min at 96°C and 35
cycles of 30 sec at 96°C, 15 sec at 55°C, and 4 min at 60°C.
Sequencing was performed on an ABI 3730 capillary sequencer according
to manufacturer’s instructions.

For specimens that failed to yield sequences using the primer
combinations above, a second round of PCR using the alternative
C_VF1LFt1/ C_VR1LRt1 primer combination was carried out. C_VF1LFt1
consisted of four primers (VF1_t1/VF1d_t1/LepF1_t1/VFli_t1), and
C_VR1LRt1 also comprised four primers (VR1_t1/VR1d_t1/LepR1_t1/
VRli_t1) [28].

....

[mad_casual]

On Sep 1, 4:25 pm, John Griessen <j...@industromatic.com> wrote:
> By sequential handling, are you meaning drawing a sample into
> a bubble separated chem analyzer, or drawing into a handler's pipette
> to move somewhere else, then do a pipette
> wash cycle to decontaminate the pipette?

The latter, I guess.

> All the above difficulty would go away with an openly programmable
> open hardware design of liquid handler.

I don't know what you mean by 'go away' but if I my supervisor came in
my door tomorrow with the source and specs to a Biomek (or something
similar) and told me to migrate the lab work off the 'serial'
analyzers we have now, I'd tell him he was nuts. The plate systems I
work with represent a unique 'culture' of analysis, sampling is one-
shot, confirmatory testing is 'someone else's job', and done
discretely. What I'm saying is, (e.g.) lots of plate-based ELISA
protocols are slow and include an incubation step that is usually the
bottle-neck in the processing chain. You're stuck waiting for your
analyte/target/product to diffuse to the surface and the incubation
period isn't a hard and fast where all 8-96 samples need to be done AT
ONCE. Automation means a human doesn't have to suffer because of the
bottleneck, but if your robot forces you to incur the bottleneck,
you're no better off than a human or robot who can avoid it.

> For parallel operations there is one networking method evolving now that could help
> keep your recipes, your controlling programs as open and cross platform
> as possible -- ethernet with precision time protocol (PTP).

I appreciate the info. My question about OSes was referring to the
analogy I made earlier; MS Windows addresses the need for
standardization/parallelization the same way 96-well plates do.
They're great if your application needs to be addressed 96-wells at a
time.

[mad_casual]

On Sep 1, 4:25 pm, John Griessen <j...@industromatic.com> wrote:
>

> PTP and ethernet between parts of a liquid handler would let you keep the
> programmed timing of pipette squirting in a high level program that orders
> the syringe pump to "move this way this fast", count time until X, and then "stop ", and then
> blah blah low level command, but no commands like "do wash cycle"  With such
> a division of where the code functions are you can put the high level code on windows
> machines and linux and get the same results running them with no trouble.
> What I've described is not the usual embedded system, but some low level things
> like timer triggered events are handled by embedded controllers independent of
> the machine running the recipe.  The windows or Mac or linux machine running the
> recipe will ask the PTP network about time, then give orders relative to time, and let
> the PTP network tell it when to act.
>

That's what I'm talkin' about;
100 test menu, 1200 tests an hour, < .1 ppm carryover betw. samples,
no tips, no plates;
http://www.youtube.com/watch?v=M72lmQPOy74

or this;

100 test menu, 125 tests an hour, disposable tips (no carryover), no
plates;
http://www.youtube.com/watch?v=ZYela1IdEfg&feature=related

If I didn't want to start from scratch, but rather reverse/modify
something like this to incorporate UV sterilization, imaging, and/or
magnetic particle separation, from the hard/firm/wetware side of
things any advice on where (else) I should be looking (other than the
mfr.)?

[Jonathan Cline]

On Sep 1, 2:40 am, mad_casual <ademloo...@gmail.com> wrote:
> On Aug 30, 10:46 am, CrazyCarl <carlcr...@gmail.com> wrote:
>

> What JonathanCline points out further down as two of a 96-well's
> strengths (and plates in general), IMO and with respect, are a hideous
> weaknesses. If we were talking test tubes and 5x2, I might agree with
> the 'human form factor' but instead we equip humans with an 8-channel
> pipette or two and then fit the plate to that.

This might be a chicken & egg argument, though the plate and
the multi-channel pipettor were developed synchronously (as below).

> It's plain to see that
> 96-well plates don't fit humans

Do we trust wikipedia?

"""History

The earliest microplate was created in 1951 by a Hungarian, Dr. Gyula
Takátsy, who machined 6 rows of 12 "wells" in Lucite.[3] [4] However,
common usage of the microplate began in the late 1950s when John Liner
in USA had introduced a molded version. By 1990 there were more than
15 companies producing a wide range of microplates with different
features. It was estimated that 125 million microplates were used in
2000 alone. The word "Microtiter" is a registered trademark of Cooke
Engineering Company, and Thermo Electron OY is the last listed owner
of the trademark (U.S. Trademark 72,128,338.) It is now more usual to
use the generic term "microplate".

[3] Farkas E.. "Microtitrations in serology and virology – a citation-
classic commentary on the use of spiral loops in serological and
virological micro-methods by Takatsy, G.". CC/Life Sci (30): 10-10 Jul
27 1992. http://www.garfield.library.upenn.edu/classics1992/A1992JC14700001.pdf

""""

"""To save more time, Takatsy exchanged the
original handles for thinner knitting needles.
Thus, it required no special skill to work with
six-to-eight loops in one hand, simultaneously.
For this reason, there were 96 wells
arranged 8 x 12 in each plate of the set. If
loops were blotted, rinsed, and flamed after
each series of dilutions, they needed neither
intense washing nor additional sterilization.
Modified plastic plates, being resistant to
detergents and intense cleaning, saved still
more time and labor."""

[ This was done in 1948. ]


I'm sure the originals were patented, although the patents long
since expired.

Anyway, the point is to re-architect the ideal bio system
for both automation & human, so take the best qualities from
plates and start fresh.

> I
> never see biologists using 96 well plates in the field or at the
> hospital. Heck I don't even see scientists in the lab next to the
> robot using 96-well plates.

I see them in the lab all the time. It depends which lab of
course.
Some labs only work with large liquid volumes (>500mL).
We like tiny volumes because the reagents are $$$ and
reducing liquid volume significantly reduces cost, and multiple
samples can be run in parallel.

> JonathanCline even
> recommends spacing them out, which makes it a 48 or 24 well plate
> then, right?

Here I'm reporting what I've seen in literature. The samples are
alternated depending on purpose. For example, N sample rows
with M control rows are spaced alternately in various patterns,
so cross contamination can be isolated in the results.
All 96 wells are still filled and processed. The reasoning goes:
since the samples and the controls are run on the same plate,
why not alternate them to eliminate this variable; this doesn't
add any extra cost.

> With more sequential handling (e.g. staggering, would it be too sexy
> to call it asynchronous?) , detecting and pinpointing contamination on
> the fly is so ridiculously easy a computer can do it.

Not sure what you mean by that. Not sure how a computer might
detect splatter or etc. In practice the Z-axis is calibrated at the
liquid
level of the well at that particular time, and the Z-axis is drawn
away
from the liquid as the liquid is dispensed, so the robot maintains
the same distance between the pipette tip and the surface of the
liquid.. even as the well fills up. This is quite nifty mathematics
and
a great feature.

> The plate robots I've dealt with were extremely difficult
> to get to do something like; if samples A1 and A2 are both positive
> and B3 is negative, treat well A3 and Row E with reagent Z else treat
> column 4 with reagent X and A4 with reagent Y, and when you got them
> to do that, that's all they did. And they did it slowly, after you
> reconfigured your pipette tips and reagents appropriately, by hand.
> Adding a sample or ten unexpectedly halfway through the analysis
> wasn't even fathomable.

All this is the fault of the robot vendor's software application,
not the robot itself. Hence my desire to write a language for
controlling lab robotics which does not rely on "drag & drop GUI
elements" which can not be programmed with such operations
easily. (Not even labview is that good at this "let's make the
logical
operations into GUI elements so the user doesn't have to 'program'"
paradigm, and they've been trying for decades.)

I was able (with my Perl scripts) to perform all sorts of nifty
logical operations, after I wrote everything from the ground up
(meaning: sending raw movement commands directly to the
robot hardware). Although the detection part of your example is
still a tricky operation: detecting color might be relatively simple.

> but IMO plate bots
> are a standardized way of doing standardized, predictable, and
> uninteresting biology.

Standardized and predictable is our M.O.
"Uninteresting" is a subjective term.

> IMO, the robots are
> built to assemble and sift through libraries, not write books.

Your detection example again is a good illustration of
a simple operation which is currently difficult to do, yet if done,
would allow the robotics, in essence, to make it's own decisions
and perform more intelligent operations than just sifting.
For example the Robot Scientist was able to make a novel
discovery based on optimizing the sample space and iterating,
without operator control.

> It's
> been almost a decade since I've dealt with plate bots, maybe they've
> gotten much better, I could be wrong.

Not really much better. Cheaper, yes. I've heard the remark that
liquid handlers are now commodities. (Also indicates a lack of
innovation. Some local minima in the system design has been
reached.)

People in this group can make them much better.

[Cathal Garvey]

Without meaning to intrude on a discussion that I've largely missed, I'd just like to suggest that the first DIYbio liquid handlers focus on the immediately-achievable and add desirable-but-difficult features later on. That is, rather than aiming from the outset to get 10nL resolution repeatably across 96-well plates, it would be far, far easier to start out by making an auto-miniprepper that manages 10-uL resolution in volumes between 100 and 500 uL in rows or rings of eppies.
 
Most of the really successful projects lately in the OSHW realm have done thus; Makerbot is certainly the best example, a machine that started really simple compared to commercial equivalents, but made that simplicity relevant to its intended early adopters and affordable also. Since then they've built up to a machine (the Thing-O-Matic) that looks like it's going to leapfrog the commercial stratasys machines within another year or so, and is already more practical by far (cheaper micro-mass-manufacture) for average users.

If the hardware wizards out there could deliver a miniprepper that can be reprogrammed for tasks such as protein/DNA/RNA precipitation by the userbase, and can be extended over time with better and better features, I think that'll catch on. I'd certainly want one. On the other hand, aiming for immediate perfection with a 96-well-plate mass-experimentation system will definitely result in a more expensive machine..one which I can't afford, no doubt but also one that's not relevant to the fairly simple tasks that I'd currently want automated.

Anyways, that's my two cent. I do find it really interesting to see people from different sides of the industry and hobby discussing their needs, desires and expectations in this field. In the end, it's all down to what experiments you want to run I guess; I've never had a good head for high-throughput I think. :)

--
letters.cunningprojects.com
twitter.com/onetruecathal
http://www.indiebiotech.com

[mad_casual]

On Sep 1, 11:20 pm, Jonathan Cline <jncl...@gmail.com> wrote:

> I hope all this sheds some light on what's going on
> in labs right now.

Other than starting with genomic DNA in a 96-well plate, an accurate
portrayal. Am I wrong in thinking the goal/point of DIYBio or just an
open liquid handler isn't cataloging all the fish in China? In their
garage?

[John Griessen]

On 09/02/2011 11:13 AM, mad_casual wrote:
>> as open and cross platform
>> > as possible -- ethernet with precision time protocol (PTP).
> I appreciate the info.

Since we have not been understanding each other completely in these exchanges,
the info is probably not the kind you need. IOW there is no off the shelf
buyable lab gear I know of that uses this. I have only been talking of how
to make bottom up designed modular pieces that fit in with work flows for
low cost operations, not "today's labs" even. Sorry if I'm too hardware
development focused, but it's what I do.

When I said, "All the above difficulty would go away" I was referring to the
difficulty you mentioned where you could not automate any on the fly
sub recipes.

John

[mad_casual]

On Sep 2, 12:21 pm, Cathal Garvey <cathalgar...@gmail.com> wrote:
> That is, rather than aiming from the outset to get 10nL resolution
> repeatably across 96-well plates, it would be far, far easier to start out
> by making an auto-miniprepper that manages 10-uL resolution in volumes
> between 100 and 500 uL in rows or rings of eppies.

Roche discontinued these about 4 years ago;
http://www.youtube.com/watch?v=1fej625tADU

I know of at least 3 labs that weighed their options between sell them
on eBay or, I guess, find a big enough trash can.

[John Griessen]

On 09/02/2011 11:53 AM, mad_casual wrote:
> That's what I'm talkin' about;
> 100 test menu, 1200 tests an hour,< .1 ppm carryover betw. samples,
> no tips, no plates; http://www.youtube.com/watch?v=M72lmQPOy74

No, the Vitros video says, "meet centralized testing needs" and you can see it in that
touch screen. It's an OS unto itself with automatic full vendor lockin.
Not what I was talking about.

100 test menu, 125 tests an hour, disposable tips (no carryover), no
plates;

And we've been talking plates.

Are these the clinical analyzers that use several to 30 ml blood draws per patient?

I can't see any initial products for diybio that use such large volumes for sample size,
although the idea of an automated culturing liquid handler would gradually fill up
a 30 ml tube...in a fridge.

John

[John Griessen]

On 09/02/2011 12:03 PM, Jonathan Cline wrote:
>> Adding a sample or ten unexpectedly halfway through the analysis
>> > wasn't even fathomable.
> All this is the fault of the robot vendor's software application,
> not the robot itself. Hence my desire to write a language for

> controlling lab robotics which does not rely on "drag& drop GUI

> elements" which can not be programmed with such operations
> easily. (Not even labview is that good at this "let's make the
> logical
> operations into GUI elements so the user doesn't have to 'program'"
> paradigm, and they've been trying for decades.)
>
> I was able (with my Perl scripts) to perform all sorts of nifty
> logical operations, after I wrote everything from the ground up
> (meaning: sending raw movement commands directly to the
> robot hardware). Although the detection part of your example is
> still a tricky operation: detecting color might be relatively simple.

Leaving the robot just the simplest movement commands to itself is what
I thought of for how to work across tools, and simplify development of
modular open lab gear. I hadn't noticed that from your descriptions
of programs for tecan handlers -- makes perfect sense to me.

"Uninteresting" is a subjective term. Agreement from me.
Uninteresting in normal business sometimes means profitable...
Uninteresting could mean works so repeatably there's no
excitement in the lab anymore:-( ?

On 09/02/2011 12:03 PM, Jonathan Cline wrote:
> Your detection example again is a good illustration of
> a simple operation which is currently difficult to do, yet if done,
> would allow the robotics, in essence, to make it's own decisions
> and perform more intelligent operations than just sifting.

I think integrating specific detectors, image sensors and image processing,
light transmission as you handle plates is easier once you use low level motion
commands outside the machine, probably developed as an OSS project. Have you thought
of your perl scripts that way? Do they refer to a generic 3D Cartesian coord. space
so they would work with any machine?

John

[John Griessen]

On 09/02/2011 12:21 PM, Cathal Garvey wrote:
> I'd just like to suggest that the first DIYbio liquid handlers focus on the
> immediately-achievable and add desirable-but-difficult features later on.

Sure.

10-uL resolution in volumes between 100 and 500 uL in rows or rings of eppies.

Oh, I think we can start out better than that. 1 cubic millimeter is a small droplet
to handle by itself, but if your sample size droplet is 100 ul or 50 ul, an easy resolution
of repeatable dispense might be 2 ul.

I'd like to know more about the dynamics
of intake from a plate -- how much will stay on the plate if the ball of liquid on
the end of a pipette tip is < 1 mm dia. for instance? If you use a pointy tipped
container of hydrophobic polypropylene, can all be drawn in? If you can accurately
draw in part of a sample in a plate well, how much extra will stick to your tip?
Is there a decent best practice way to get rid of extra liquid on a tip after taking in?

John

[mad_casual]

On Sep 2, 12:03 pm, Jonathan Cline <jncl...@gmail.com> wrote:
> Here I'm reporting what I've seen in literature.  The samples are
> alternated depending on purpose.  For example, N sample rows
> with M control rows are spaced alternately in various patterns,
> so cross contamination can be isolated in the results.
> All 96 wells are still filled and processed.  The reasoning goes:
> since the samples and the controls are run on the same plate,
> why not alternate them to eliminate this variable; this doesn't
> add any extra cost.

This isn't really or universally true and crystallizes what I'm
describing as a difference in culture. This can depend on the specific
test, but generally controls don't tell you anything interesting, just
that your robot or technician isn't screwing up or your reagents work.
Serial analyzers (autosamplers, etc.) tend to run a control at the
beginning of a batch or at some statistical model of the instrument's
failure rate, you could run 'real time' controls by running a control
after every sample, but nobody does this unless the analyzer/test is
horribly inaccurate/irreproducible. It always costs extra to run
controls that tell you your robot isn't contaminating things.

> Not sure what you mean by that.  Not sure how a computer might
> detect splatter or etc.

If you sample through a septum or only open one or two samples at a
time, this isn't even a problem to begin with. I think it would be a
pain to incorporate a vision system or touch sensor to monitor a 96-
well plate for spatter, I think it could be easily done on a Clinical
Chemistry Analyzer.

> All this is the fault of the robot vendor's software application,
> not the robot itself.  

Fix hardware problems with software? The robot had an 8-channel head.
To pipette anything into one well, you either had to stop the robot or
load a rack with 1 tip, by hand. I worked with other plate bots that
weren't like this, but, in hindsight, this was just another example of
'Why would you need to...' sort of thinking.

> Standardized and predictable is our M.O.

Biologists or Robotics programmers?

> "Uninteresting" is a subjective term.

Agreed, I should've emphasized IMO. I don't mean it in a derisive
sense. I mean it in much the same way I assume you look at the
'challenge' of producing of oligos or taq or pregnancy tests or
detecting cardiac markers. See below.

[mad_casual]

On Sep 2, 1:20 pm, John Griessen <j...@industromatic.com> wrote:
> No, the Vitros video says, "meet centralized testing needs" and you can see it in that
> touch screen.  It's an OS unto itself with automatic full vendor lockin.
> Not what I was talking about.

1. I've got the videos switched, the Abbott system does 1200 tests an
hour. But you're right, the Vitros System is lower throughput.

2. 'Meet centralized testing needs', isn't DIY as centralized as it
gets? We're talking about modularizing and integrating different
analyses in one robot platform, isn't that what's been done here?

3. I haven't used the Vitros Systems themselves. The systems I have
used are programs running on an OS. I'll reread the license, but I
don't think they care at all if you copy the program and will send
copies at a request. It's kinda worthless to have the software without
a robot and if a hospital/clinic calls asking for backup software,
it's better to shoot first and ask questions later. IMO, this software
should be OSS anyway, I should know how "my" sample was analyzed and
how the analyzer arrived at "my" results.

> Are these the clinical analyzers that use several to 30 ml blood draws per patient?

1-50 uL w/ <10% variability of a 3-10 mL blood sample (or ~50 uL- 1mL
dead volume) depending on the analyzer and the test being run.

The anything over ~1 mL blood draws are primarily;
1. So the phlebotomist can handle what is being stuck in your arm.
2. So they can stick you as few times as possible.
3. So that with as few sticks as possible they can get as many
different answers out of your blood as every doctor in the hospital/
clinic might just happen to ask for. From blood cultures to cell
counts to trace analysis, not to mention possibly keeping some of your
sample around for follow up testing, sharing with secondary labs, etc.

> although the idea of an automated culturing liquid handler would gradually fill up
> a 30 ml tube...in a fridge.

The reagent compartments are often refrigerated. The stainless tips
are often known to be heated. I think I could hack the machine at work
to culture in the refrigeration compartments without rewriting any of
the software. Hell, I could probably set it up to screen patient
samples and culture in the reagent compartment based on the sample
results. If I wanted to automate from culture to product (e.g. Taq) or
culture to answer, I'm pretty much going to have to start with
whatever volume my culture is anyway. If I expected genetic testing
would only augment more acute metabolic testing...

[John Griessen]

On 09/02/2011 04:38 PM, mad_casual wrote:
> On Sep 2, 1:20 pm, John Griessen<j...@industromatic.com> wrote:
>> No, the Vitros video says, "meet centralized testing needs" and you can see it in that
>> touch screen. It's an OS unto itself with automatic full vendor lockin.

.
.
.

>
> 2. 'Meet centralized testing needs', isn't DIY as centralized as it
> gets?

No, I think what is needed is better called decentralized. Where every part could be optional
and can be connected however you want to build an experiment from
parts of different makes. Not one brand with a locked touch screen control
software system.

We're talking about modularizing and integrating different
> analyses in one robot platform, isn't that what's been done here?

When I say modular, I mean separate hardware modules, but connectable,
not all in one, until you set it up.
I don't propose a robot platform, just robot pieces that could be controlled
with recipe scripts by telling machines on a network at an IP address to do stuff.
Openness and working along with other brands of generic sensors, movers, handlers
is the main differentiator for any OSHW (open source hardware) machine, not
that it does one thing faster/cheaper than an industry standard one purpose machine.

The moving of plates from one station to another is not a super easy robot task
and I'm not trying to solve that one yet, just move liquid around in tubes
and onto and off plates as has been done for ages.
What I am thinking of offering as a difference in
the lab equip. market is in low cost implementations with open documentation
and so generic modules can be bolted together in odd ways.
I'm bet this is "uninteresting" as it relates to your work, but others will differ.

>> Are these the clinical analyzers that use several to 30 ml blood draws per patient?
>
> 1-50 uL w/<10% variability of a 3-10 mL blood sample (or ~50 uL- 1mL
> dead volume) depending on the analyzer

You're wearing me out with the misunderstandings. Here you take the 30 ml guess and
run with it rather than consider what is the likely size -- more like ul.

Your statement 3. I cannot understand at all.

Your comments about "lab automation that could be useful today" is appreciated,
but I don't have today lab experience, I'm a machine designer. Please just keep
it simple about what recipe needs doing and talk in general terms -- I don't know
the usual suspect machines you use, or even the recipes that would be most valuable.

That's why I'm asking why you want any particular kind of machine feature. Because
my first made machines need to be for popular features or my business plan dies.

John

[Jonathan Cline]

On Sep 2, 2:05 pm, mad_casual <ademloo...@gmail.com> wrote:

> > All this is the fault of the robot vendor's software application,
> > not the robot itself.  
>
> Fix hardware problems with software? The robot had an 8-channel head.

Ok, that explains the problem then. The older Biomeks for example.
The Tecan I used had an 8 pipette head but pipettes moved
independently to control anywhere from 1 to all 8 in z-axis and y-
axis.
Typically liquid handlers should be designed with independent heads.
Although a very useful type of product is a rapid liquid loader,
which I posted a few photos of:
http://88proof.com/synthetic_biology/blog/archives/461



For others reading this thread who are currently using automated
robotics, a quick lab video captured via smartphone & uploaded to
YouTube would do wonders to get everyone on the same page
when viewing robotics & automation.
There's a bunch of hardware hackers here eager to apply the
right fix for the right problem.

[Jonathan Cline]

On Sep 2, 3:39 pm, John Griessen <j...@industromatic.com> wrote:

> That's why I'm asking why you want any particular kind of machine feature.  Because
> my first made machines need to be for popular features or my business plan dies.

It's a niche market so "popular" is a very relative term.

Try working top-down more literally. Find a very commonly used type
of kit,
then automate only that protocol. For example, a previous comment was
a good one
regarding automating ELISA. Those with food allergies might
appreciate
a machine which could verify if gluten is in their flour (google
"gluten elisa kit").

From the DIYbio FAQ ( http://openwetware.org/wiki/DIYbio/FAQ/Projects
)
there is a larger-scale automated fermenter, which could be cost
reduced
and made digital & wireless (aka, often-touted "real time blah blah"
techniques
which add thousands to the price tags of commercial equipment -- if
made
wireless, the result would beat all commercial products today):

"""An automated home-built low-cost fermenter suitable for large-scale
bacterial expression of proteins in Escherichia coli. We have
developed an automated fermentation system for cost-efficient
upscaling of protein expression in bacteria. The system, built for use
by nonbiotechnologists, can be assembled mostly from standard
laboratory equipment and allows a largely unattended growth of
bacteria to OD 25 (at 600 nm) in a 12 L vessel""."
http://www.ncbi.nlm.nih.gov/entrez/utils/fref.fcgi?PrId=6660&itool=Abstract-def&uid=18687068&nlmid=8306785&db=pubmed&url=http://www.biotechniques.com/article/000112830



Regarding DNA barcoding, I'm often too far ahead of the market, though
I'd
bet that both investigators at the FDA and restaurant owners would
love a
laptop-sized machine which could be taken to a seafood supplier to
verify
the fish species being sold is as advertised. That is a a slice of a
billion dollar
business. The device will be made, the question is when (tomorrow or
years
from now), and with what technologies.


More liter-sized automation: the following chemostat is being used by
leading researchers right now for yeast experimentation etc, and
needs
better & cheaper hardware; all parts of this design (hardware and bio)
is
open sourced to solicit improvements:
http://dunham.gs.washington.edu/chemostatv2.htm

Take a look at some of the figures -- this is all done by hand:

http://dunham.gs.washington.edu/chemostatv2_files/image043.png
"Figure 17. Example of typical sampling: Preparing tubes and plates
ahead of time."

[mad_casual]

On Sep 2, 7:31 pm, Jonathan Cline <jncl...@gmail.com> wrote:
> Ok, that explains the problem then.  The older Biomeks for example.
> The Tecan I used had an 8 pipette head but pipettes moved
> independently to control anywhere from 1 to all 8 in z-axis and y-
> axis.
> Typically liquid handlers should be designed with independent heads.

'Independent' as in all 8 heads move together in the x and y when only
one needs to actually do anything or truly independent as in one head
can pickup/dispense sample/reagent/wash into a well while another head
can pickup/dispense sample/reagent/wash into any other arbitrary well?

If the latter, this would represent a quantum leap over the systems I
used to work with. And I may very much stand corrected. Maybe time to
go back to AACC or Pitcon again.

[mad_casual]

This robot;

http://www.bio-rad.com/prd/en/US/adirect/biorad?cmd=BRCatgProductDetail&productID=153901&vertical=CDG&country=US&lang=en

Would make for some 'interesting' biochemistry!

[Jonathan Cline]

On Sep 2, 7:15 pm, mad_casual <ademloo...@gmail.com> wrote:
> On Sep 2, 7:31 pm, Jonathan Cline <jncl...@gmail.com> wrote:
>
> > Ok, that explains the problem then. The older Biomeks for example.
> > The Tecan I used had an 8 pipette head but pipettes moved
> > independently to control anywhere from 1 to all 8 in z-axis and y-
> > axis.
> > Typically liquid handlers should be designed with independent heads.
>
> 'Independent' as in all 8 heads move together in the x and y when only
> one needs to actually do anything or truly independent as in one head
> can pickup/dispense sample/reagent/wash into a well while another head
> can pickup/dispense sample/reagent/wash into any other arbitrary well?

The former. The plate geometry is programmed in first.
Then the software algorithm to perform an action on a set
of wells in a plate column automatically separates each
pipette tip by delta-y distance (to fan out the tips) when that
plate is accessed. The selected tips move in delta-z to
perform the operation. All 8 tips are still fixed
to the same arm and remain in the same x axis.

[CrazyCarl]

I thought c+ is the defacto microcontroller standard?

[Matthew Bertram]

Stumbled on this interesting automated liquid handler. Looks very DIY...

http://www.metrohmusa.com/Products/Titration/Automation/815-Robotic-Sample-Processor/index.html

On Sat, Sep 3, 2011 at 5:25 PM, CrazyCarl <carl...@gmail.com> wrote:

I thought c+ is the defacto microcontroller standard?

--
You received this message because you are subscribed to the Google Groups "DIYbio" group.
To post to this group, send email to diy...@googlegroups.com.
To unsubscribe from this group, send email to diybio+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/diybio?hl=en.

[mad_casual]

On Aug 25, 5:15 pm, Simon Quellen Field <sfi...@scitoys.com> wrote:
> There were these things we used when I was a kid, called vinyl records,
> that had a spiral groove cut into them on which a stylus tracked.

>
> All you need are two bits from the microcontroller.
> One bit starts the turntable spinning.
> The other turns on a solenoid to squirt the liquid.
> If you like, you can have another pin sense a microswitch to know
> exactly when the tube is in position.
>

> Another way to handle this is to use a bandolier belt, like a machine gun
> does. Load the tubes where the bullets go, and pull on the belt.
> The belt doesn't even need to be neatly coiled up -- it can be randomly
> snaked into a box, and pulled out through a slot.

Don't forget reel to reel!;
http://www.labmanager.com/?articles.view/articleNo/5133/
76,800 reaction wells per 8 hour shift, scalable to 230,000.

Does it make anyone else want to run out and back up all of their
genetic information?

[M.Shah]

Hi,

Interesting concept. I am trying to make a simple lequid handeling robot. I need some help.
Do you have any perticular pipetor or pipating module in mind which can be controlled electronically not by buttons by electrical voltage or current (I mean just like electronic valve - solenoid valve). I am searching for this since ling time.
Sorry for posting on very old thread but if poossible please help.


On Friday, August 26, 2011 at 2:06:29 AM UTC+5:30, phillyj wrote:

I was just reading about the OS liquid handling robots here. You guys
talk about using an XY axis method to move the bot around. I think it
was mentioned (not sure if I read correctly) to use a circular
platform. If that is the case, then you only need to rotate the
platform and move the pipette in a linear motion and down to inject
the fluid. So I guess thats we need XZ axis for the arm and circular
rotation for the well plate. The precision would only be needed on the
well-plate rotation and the arm ouly needs a fixed XZ value. So
instead of 2 precision servos, we can reduce it to one.

These are just some initial thoughts. Are there any commercial robots
like this that I can read about?

I attached my crude rendering.

[Koeng]

Check out OpenTrons