DIY microfluidics for continuous liquid flow using toner transfer (How To)
JonathanCline
know.
Here are some super simple directions in brief to try. Since it's a
Friday, it is a perfect afternoon project.
1. Draw the microfluidic "pipes" using any paint or graphics program,
with the following color scheme: White = where the liquid will flow
("channels"). Black = obstruction. The white channels should be at
least 100 um but not wider than 300 um and the black obstruction
should be at least 400 um (depending on the lamination process, see
below). The "in" and "out" should be circles large enough to allow
for drilling (depends on drilling method as below). The "piping
circuit" should be completely surrounded in a black fill color. Draw
four alignment X's at each corner, just outside the circuit.
2. Obtain some polyester paper or transparency paper.
3. Print out (2) copies of the image on a laser printer on highest
quality setting on the transparency: copy #1 is normal, copy #2 is
mirrored on the X-axis. The printer should be at least 600 DPI. The
printing scale should be made accurate 1:1. At 600 DPI, an HP
Laserjet has minimum line width of 42 um.
3a. If only inkjet printer is available, then print (2) copies on
inkjet printer on normal paper. Then copy the images to the
transparency on a copier. (laser printer is preferred)
4. Lay the two transparencies on top, with the printed sides touching,
with the image perfectly aligned, using the alignment marks. Tape
them together in proper alignment.
5. Run the two sheets through a laminating machine, at 120-130 degrees
C, repeat as necessary until the sheets adhere (run through ~5 times
in different directions). Depending on laminating machine, this step
may require some experimentation. It is unlikely to need to exceed
150 degrees C. Check the MSDS of the printer toner cartridge for the
characteristics of the toner if available.
5a. The sheets should be joined at this point, via the adherence of
the toner.
6. Cut the circuit to size using scissors.
7. Drill holes into the circuit at the "in" and "out" points, using a
paper cutter or drill tool.
8. Glue pipette tips, hollow plastic spacers, plastic capillaries, or
5mm length of drinking straws at the "in" and "out" drill holes using
super glue or epoxy, as a method of creating simple reservoirs.
Done.
Channel depth in the range of 8 to 14 µm should result from this
process.
* Note: I am not responsible for any harm to zombies, HP Laserjet
printers, or undergraduates which may occur as a result of performing
this experiment.
## Jonathan Cline
## jcl...@ieee.org
## Mobile: +1-805-617-0223
########################
Marnia Johnston
Thanks,
Marnia
Bryan Bishop
> Hey Johnathan, I'm interested in what a microfluidic diagram looks like
> (before printing). Could you point me to some published images?
These are not necessarily the right shape for Jonathan's instructions,
but here you go:
microfluidics DNA synthesizer
http://adl.serveftp.org/papers/microfluidics_Quake_DNA_synthesizer-20mers-PFPE.png
microfluidics Sanger DNA sequencer
http://adl.serveftp.org/papers/microfluidics_Sanger_sequencer.png
For simple parts, try doing an image search for "t-junction" and
'microfluidic components' (no quotes on that last one).
**eventually** if we ever get a repository going here, I'll get some
code going for constructing microfluidic schematics from a parts
library so that you don't have to draw something in a graphics
program, and instead it will feel like VLSI or VHDL or Verilog.
Meredith L. Patterson
> **eventually** if we ever get a repository going here, I'll get some
> code going for constructing microfluidic schematics from a parts
> library so that you don't have to draw something in a graphics
> program, and instead it will feel like VLSI or VHDL or Verilog.
Note that some folks, e.g. people with more of an artistic background
than a code background, will *prefer* to draw microfluidic schematics
in a graphics program. Best to support both approaches, IMO.
Cheers,
--mlp
Marnia Johnston
-Marnia
Bryan Bishop
There are two ways I can envision that happening. er, three.
(1) People draw in some sort of SVG program. The graphics are then
able to be translated into the other typical format. The user would
have to painstakingly sit around clicking the little icons and so on.
After that, they will have to identify what each component is supposed
to be in some other program if they want to do analysis or annotation
for other people to use on the web automatically (in some sort of
"fancy web interface" like instructables, thingiverse, ponoko,
shapeways, etc., in the way that everyone wants).
(2) People draw in some image format like PNG, GIF, JPEG, BMP. Then
there's almost no way to recover the information for further analysis
or sharing, other than just giving the images to people. But this
means that in the future, for new formats, the data can't easily be
retrieved or converted, especially since-- as I'm sure-- people would
use drawing and art tools that do not just place specific blocks of
pixels, etc. Anyway, I don't think this is long-term sustainable,
do-at-your-own-risk.
(3) Using some standard components library. Draw the picture for a
component once, then specify the connectivity in another file, maybe
in the graphviz dia/DOT format for now (a very simple format- found on
http://graphviz.org/ ). Ideally you draw the image once, preferably in
SVG, and then it's done forever. Yay.
Meredith L. Patterson
> (1) People draw in some sort of SVG program. The graphics are then
> able to be translated into the other typical format. The user would
> have to painstakingly sit around clicking the little icons and so on.
Both Inkscape and Adobe Illustrator support SVG natively, and those
are hardly the only vector-drawing programs out there. I also wouldn't
describe vector drawing as "painstaking"; I do it all the time in
OmniGraffle, and in many ways it's much simpler and less
time-consuming than working in Photoshop.
If you read BoingBoing at all, you've probably seen lots of neat
examples of vector artwork that, at first glance, you wouldn't think
was vector-based; Mark Frauenfelder likes to post about that kind of
thing.
> After that, they will have to identify what each component is supposed
> to be in some other program if they want to do analysis or annotation
> for other people to use on the web automatically
One word: layers.
> (2) People draw in some image format like PNG, GIF, JPEG, BMP. Then
> there's almost no way to recover the information for further analysis
> or sharing, other than just giving the images to people.
Not at all; there exist quite a few tools for converting raster images
to vector images. The best one I've worked with is Vector Magic, which
is neither free as in speech nor free as in beer, though you can
vectorize individual graphics for free using their web service.
http://vectormagic.com/home has more info.
> (3) Using some standard components library. Draw the picture for a
> component once, then specify the connectivity in another file, maybe
> in the graphviz dia/DOT format for now (a very simple format- found on
> http://graphviz.org/ ). Ideally you draw the image once, preferably in
> SVG, and then it's done forever. Yay.
Bryan, you're missing the same point that you keep missing over and
over again: *most people do not like to write out source code*, which
a .dot file certainly counts as. (I can't stand writing .dot files
myself; I write scripts to do it for me.) Using Graphviz under the
hood to specify connections, in such a way that a person *can*
manually write out or generate a .dot file, makes sense, but you're
never going to get critical mass without a GUI.
I've been talking with the Fritzing guys (www.fritzing.org) about
forking Fritzing for BioBricks. The consensus we've come to so far is
that it's going to be damn difficult, but it would probably be pretty
easy to add a microfluidic-components package to Fritzing or even
gEDA. (Fritzing is prettier though.)
Cheers,
--mlp
Bryan Bishop
Patterson<clon...@gmail.com> wrote:
> On Tue, Jun 23, 2009 at 1:45 AM, Bryan Bishop<kan...@gmail.com> wrote:
>> (1) People draw in some sort of SVG program. The graphics are then
>> able to be translated into the other typical format. The user would
>> have to painstakingly sit around clicking the little icons and so on.
>
> Both Inkscape and Adobe Illustrator support SVG natively, and those
> are hardly the only vector-drawing programs out there. I also wouldn't
> describe vector drawing as "painstaking"; I do it all the time in
> OmniGraffle, and in many ways it's much simpler and less
> time-consuming than working in Photoshop.
Okay, great- yes, Inkscape would be my recommendation at this point as
well. I didn't mean to say that SVG is painstaking, but rather that
saying "what is what" would be the painstaking part (making it
reusable).
>> After that, they will have to identify what each component is supposed
>> to be in some other program if they want to do analysis or annotation
>> for other people to use on the web automatically
>
> One word: layers.
So you want people to add each component to a separate layer? Why?
>> (2) People draw in some image format like PNG, GIF, JPEG, BMP. Then
>> there's almost no way to recover the information for further analysis
>> or sharing, other than just giving the images to people.
>
> Not at all; there exist quite a few tools for converting raster images
> to vector images. The best one I've worked with is Vector Magic, which
> is neither free as in speech nor free as in beer, though you can
> vectorize individual graphics for free using their web service.
> http://vectormagic.com/home has more info.
That does not sound reliable. Is there free software that does this?
Maybe something with imagemagick?
>> (3) Using some standard components library. Draw the picture for a
>> component once, then specify the connectivity in another file, maybe
>> in the graphviz dia/DOT format for now (a very simple format- found on
>> http://graphviz.org/ ). Ideally you draw the image once, preferably in
>> SVG, and then it's done forever. Yay.
>
> Bryan, you're missing the same point that you keep missing over and
> over again: *most people do not like to write out source code*, which
> a .dot file certainly counts as. (I can't stand writing .dot files
But most people don't seem to understand that the scripts that you
mention next have to be written first before the fancy interfaces. The
data format matters, not just terrible hacks. heh'
> myself; I write scripts to do it for me.) Using Graphviz under the
I write scripts for graphviz output as well, I'd love to upload some
scripts some time specifically for diybio on that note.
> hood to specify connections, in such a way that a person *can*
> manually write out or generate a .dot file, makes sense, but you're
> never going to get critical mass without a GUI.
I agree, but you're never going to get anywhere if you complain on a
mailing list about how you don't have a GUI already. If you care that
much, go make a GLADE file. But then realize that you'll have to
implement the other stuff too! see?
> I've been talking with the Fritzing guys (www.fritzing.org) about
> forking Fritzing for BioBricks. The consensus we've come to so far is
> that it's going to be damn difficult, but it would probably be pretty
> easy to add a microfluidic-components package to Fritzing or even
> gEDA. (Fritzing is prettier though.)
What is the component package format? I was thinking that I'd do a
writeup on how to do packaging for skdb soon, since this is kind of
what the system is meant for re: toolchains for diybio and
openmanufacturing. But if there's another packaging format, I might as
well work on a few converters at the same time or something.
Meredith L. Patterson
> So you want people to add each component to a separate layer? Why?
Good lord no -- one layer for components, one layer for annotations.
Flickr does this already with the z-index property; were one to create
a 2-layer vector image with a component layer and an annotation layer,
one could conceivably upload it/check it into a web-accessible
repository of schematics, components and annotations, with a trigger
in the repo so that when a multi-layer file is uploaded, different
layers get displayed at different z-indices, and can be turned on and
off.
>> Not at all; there exist quite a few tools for converting raster images
>> to vector images. The best one I've worked with is Vector Magic, which
>> is neither free as in speech nor free as in beer, though you can
>> vectorize individual graphics for free using their web service.
>> http://vectormagic.com/home has more info.
>
> That does not sound reliable. Is there free software that does this?
> Maybe something with imagemagick?
It's a Stanford project that got funded. I don't think it's going away
anytime soon. That said, I'd like to have a FOSS library/app to do
this kind of thing too. I don't know the problem space very well
though.
>> hood to specify connections, in such a way that a person *can*
>> manually write out or generate a .dot file, makes sense, but you're
>> never going to get critical mass without a GUI.
>
> I agree, but you're never going to get anywhere if you complain on a
> mailing list about how you don't have a GUI already. If you care that
> much, go make a GLADE file. But then realize that you'll have to
> implement the other stuff too! see?
Fair enough. I'm just sayin', you keep getting 95% of the way through
a workable idea but stop before you add the step that will encourage
95% of *users* to actually adopt the tool. Cut that out. ;P
> What is the component package format? I was thinking that I'd do a
> writeup on how to do packaging for skdb soon, since this is kind of
> what the system is meant for re: toolchains for diybio and
> openmanufacturing. But if there's another packaging format, I might as
> well work on a few converters at the same time or something.
http://fritzing.org/learning/tutorials/creating-custom-parts/
Cheers,
--mlp
Bryan Bishop
Patterson<clon...@gmail.com> wrote:
> On Tue, Jun 23, 2009 at 2:20 AM, Bryan Bishop<kan...@gmail.com> wrote:
>> So you want people to add each component to a separate layer? Why?
>
> Good lord no -- one layer for components, one layer for annotations.
> Flickr does this already with the z-index property; were one to create
> a 2-layer vector image with a component layer and an annotation layer,
> one could conceivably upload it/check it into a web-accessible
> repository of schematics, components and annotations, with a trigger
> in the repo so that when a multi-layer file is uploaded, different
> layers get displayed at different z-indices, and can be turned on and
> off.
What sort of annotations are you thinking about, anyway? I looked at
the fritzing.org document you linked to, and it actually scares me-
the sort of limited information that they want users to put in. Have
you checked the files yet on the git repo that I linked to a few days
ago? There's a few files there that should show you what I think would
be ideal.
http://adl.serveftp.org/skdb/
http://adl.serveftp.org/skdb.git
see in particular: http://adl.serveftp.org/skdb/skdb.py
(remember kids- package maintainers are peculiar goblins from the
future, so don't be alarmed (at least for quality checking).)
>>> Not at all; there exist quite a few tools for converting raster images
>>> to vector images. The best one I've worked with is Vector Magic, which
>>> is neither free as in speech nor free as in beer, though you can
>>> vectorize individual graphics for free using their web service.
>>> http://vectormagic.com/home has more info.
>>
>> That does not sound reliable. Is there free software that does this?
>> Maybe something with imagemagick?
>
> It's a Stanford project that got funded. I don't think it's going away
> anytime soon. That said, I'd like to have a FOSS library/app to do
> this kind of thing too. I don't know the problem space very well
> though.
if you promise to ping me eventually, I'll be sure to look into it.
This would be useful for retrieving stuff from the literature and so
on. A few months ago, someone asked me to extract a microfluidics
diagram from a watermarked image. Didn't get around to getting it done
yet.
>>> hood to specify connections, in such a way that a person *can*
>>> manually write out or generate a .dot file, makes sense, but you're
>>> never going to get critical mass without a GUI.
>>
>> I agree, but you're never going to get anywhere if you complain on a
>> mailing list about how you don't have a GUI already. If you care that
>> much, go make a GLADE file. But then realize that you'll have to
>> implement the other stuff too! see?
>
> Fair enough. I'm just sayin', you keep getting 95% of the way through
> a workable idea but stop before you add the step that will encourage
> 95% of *users* to actually adopt the tool. Cut that out. ;P
Maybe if there was a repo on diybio.org, I could upload the stuff that
I hack out, and somebody else can go make it pretty if they like it
enough? This way we don't have to repeat each other's work.
>> What is the component package format? I was thinking that I'd do a
>> writeup on how to do packaging for skdb soon, since this is kind of
>> what the system is meant for re: toolchains for diybio and
>> openmanufacturing. But if there's another packaging format, I might as
>> well work on a few converters at the same time or something.
>
> http://fritzing.org/learning/tutorials/creating-custom-parts/
Ack! What on earth. This doesn't sound very useful:
"""
1. Name - it is sometimes useful to choose a name which is
descriptive, specifying for example color and size.
2. Label - helps keep track of the parts in your circuit, by numbering
your parts based on this label. For example, LED1, LED2. When you are
ready to manufacture a PCB, this will be extremely helpful in figuring
out which part gets soldered where.
3. Description - A brief description about your part that gives a few
useful details, tips or links.
4. Properties - the part's technical characteristics. Enter all of the
distinguishing features that make your part unique. First enter the
family your part belongs to such as, LED, photo resister, etc.
5. Tags - makes your part findable. Enter words into the Tags field
that will make your part show up in a search. Family should always be
one of these tags.
6. Author; Created/Updated on - Let your friends know how cool you
are, enter your name! While you're at it, let them know when you were
that cool.
"""
In this case, #4 is just a way of saying "say what type it is", which
doesn't really tell you what the equations describing the part are, or
how the inputs and outputs correspond to the functionality of the
device. For a brief overview of a package or part, sure, yes, this
would be ok, but I think I could whip up a wizard that would do a
better job and fill in more technical information from a user's given
information, or something.
JonathanCline
> Hey Johnathan, I'm interested in what a microfluidic diagram looks like
> (before printing). Could you point me to some published images?
> Thanks,
> Marnia
pictures:
Microfluidic platforms for lab-on-a-chip applications
- Stefan Haeberlea and Roland Zengerleab
Microfluidic devices fabricated in poly(dimethylsiloxane) for
biological studies
- George M. Whitesides
SURVEY AND SUMMARY Miniaturized PCR chips for nucleic acid
amplification and analysis: latest advances and future trends
- Chunsun Zhang and Da Xing
Disposable integrated microfluidic biochip for blood typing by plastic
microinjection moulding
- Dong Sung Kim, Se Hwan Lee, Chong H. Ahn, Jae Y. Lee and Tai Hun
Kwon
Also you can check youtube for videos... Here is one I just found as
an example,
Microfluidics Lab-on-a-chip to determine enzyme kinetics parameters,
Km and kcat
http://www.youtube.com/watch?v=so1Pwg3ymr8
Drawing the "circuit" for the method I posted can be done in any
graphics program as long as the program can print out with proper
scale (1:1) and support a measurement grid in low millimeters. I used
a CAD program. The method I summarized is very simple. Likely the
most complex shape would be "H" or "Y", although I would like to try a
spiral which could tested for PCR (different quadrants would be
different temperatures, input on the outside and PCR'd output on the
inside). There have also been PCR tests using a zigzag side-to-side,
with temperature zones at left and right, and input at top and output
at bottom There was a paper which performed some electrokinetic
operation on the sample (detection or separation, I forget) by using
copper tape as contacts, attached along one of the legs of a "H".
Since the dimensions are small, the electric field worked for whatever
it was they were doing. It should be very possible to do
spectrophotometry using surface mount LED's as well.
The biggest issue is the "world to chip" problem, i.e.: how to get
fluids into and out of these passive devices. Gravity is the
default. Also, these continuous-flow devices are single use - no way
to sterilize them or free the clogs.
Bryan Bishop
> On Jun 22, 6:03 pm, Marnia Johnston wrote:
>> Hey Johnathan, I'm interested in what a microfluidic diagram looks like
>> (before printing). Could you point me to some published images?
>
> pictures:
Do you have these somewhere that we could access them? If not, I'll
grab them maybe tomorrow (I am presently crippled by a slow internet
connection- can't even use ssh). 60% packet loss- blah.
> Microfluidic platforms for lab-on-a-chip applications
> - Stefan Haeberlea and Roland Zengerleab
>
> Microfluidic devices fabricated in poly(dimethylsiloxane) for
> biological studies
> - George M. Whitesides
>
> SURVEY AND SUMMARY Miniaturized PCR chips for nucleic acid
> amplification and analysis: latest advances and future trends
> - Chunsun Zhang and Da Xing
>
> Disposable integrated microfluidic biochip for blood typing by plastic
> microinjection moulding
> - Dong Sung Kim, Se Hwan Lee, Chong H. Ahn, Jae Y. Lee and Tai Hun
> Kwon
Thanks for the references. And if anyone else is interested, there's
still the full bibliography (with downloadable PDFs) that I originally
posted to the list a few months ago:
http://groups.google.com/group/diybio/msg/1197606e3c3dc439
Although not all of them have example schematics.
> it was they were doing. It should be very possible to do
> spectrophotometry using surface mount LED's as well.
That's right. I'm looking forward to these particular projects for
spectrophotometry. Might even be useful for dynamic separation devices
to figure out whether or not something has pelleted sufficiently, etc.
> The biggest issue is the "world to chip" problem, i.e.: how to get
> fluids into and out of these passive devices. Gravity is the
> default. Also, these continuous-flow devices are single use - no way
> to sterilize them or free the clogs.
Have you tried the straw world-to-chip and chip-to-world interface method yet?
JonathanCline
>
> Have you tried the straw world-to-chip and chip-to-world interface method yet?
>
add "spray bottle as vacuum pump" to the to-do list at the output
rather than adding pressure on the input.