arduino based open source HPLC

[ScottHorn]

I'd definitely be more inclined to purchase an instrument with an open, thoroughly documented communication protocol over one that hid all that from the end user. An industry wide standard would be even better, kind of like the Hayes "AT" command set, which came to be adopted by pretty much every modem ever made. I think something like that would work very well for pumps, valves and other devices where most of the communication is going from the user to the device. Detectors might be a little more tricky, but for simple single channel absorbance detectors and the like an analog signal would suffice.

Opening up the hardware designs would be nice as well, but I'm willing to bet the people making a living as service technicians wouldn't agree with me. I have some old ISCO fraction collectors, the manual for which contains a detailed schematic, down to the values of every single resistor and capacitor on the board. I'd love to see more manufacturers do that, but I guess they're worried someone is going to take that information and cobble together cheap knock-offs of their design.

I agree with your friend in the sense that the current model is not the best for the end user. What arguments does he have to convince a manufacturer that an open source model would be in their interest?

[EdelweissPirate]

My understanding is that developing and maintaining that proprietary software entails a lot of overhead, and the user base is pretty small. My friend says his company has a substantial backlog of good ideas--mechanical, electronic and software--that they'd like to work on.

Open-sourcing the software would free up resources to develop the software feature his company has waiting in the wings. Plus, open-source developers could contribute their own features, making that software (and the same-branded hardware) more attractive to end users.

Mechanically, selling more pumps means the production costs for each pump go down due to economies of scale. That would give the mechanical engineers more freedom to design better pumps at the same price.

Releasing board schematics and resistor values would be a tougher sell, I'd imagine.

On the other hand, vendor lock-in really only benefits the biggest, most established players. Cisco, the network switch company, is a great example of this. Their hardware, arguably the gold standard for network equipment, runs on proprietary software (IOS, but not Apple's IOS). But now they're being threatened by open-source designs such as this one from Facebook:

https://code.facebook.com/posts/7170105 ... ar-switch/

My friend says that if an open API meant his company's equipment was fully controllable from within, say, Openchrom, and this was a popular option, then his company could focus on what they do best: making chromatography equipment.

That's the theory, anyway.

[bigdawg]

a colleague at work pointed me to this forum today since I have been working on a similar open source HPLC project for a while. I am trying to make an arduino controlled shimadzu LC-6A pump (75 bucks from ebay) and have made some progress regarding that. The next step is the real challenge: connecting a UV detector (most likely from perkin elmer 200 or HP 1050, both around 150-200 bucks), making a data acquisition system, and integrating the whole Frankenstein monster into a workable HPLC system with proper calibration and sensitivity which can match commercial HPLCs. I'll definitely post on this thread periodically showing whatever progress I am making.

[bigdawg]

just to post an update on my whole project. I have come quite far since I last posted in this thread. Too bad the OP (badger) seems to have stop checking here but let me just summarize my progress and I have no intention of hijacking the thread, but since this thread provided me with so many useful tips, I feel like I should continue the discussion here.

1) I have been able to use an aftermarket stepper motor board (Gecko) and run the stepper motor of LC-6A through arduino. Its not perfect, since the pump I am using is a single piston pump, to minimize the pulsation, the original pump accelerated during refill phase. Since, I don't have a complete user manual, I am still trying to figure out how fast I should make the stepper motor run in order to mimic the performance of the original pump. I found an after market pressure transducer and I have put it in my pump so the design is as robust as commercial ones. I would wish to machine my own PEEK pump heads at some point in future, but right now I am a bit occupied with other aspects of this HPLC.

2) I bought a 1050 HP variable wavelength detector from ebay for about 200 bucks. Its electronics seems fine, however, the stepper motor for the grating doesn't work and/or the deuterium lamp is also out so I am trying to deal with that, and maybe find a cheap ebay lamp which works on this one.

3) I have written a program on labview for data acquisition and control for the stepper motor, and right now I am shooting for a binary gradient system with 2 pumps with high pressure mixing since gradient proportioning valves seem to be more expensive than buying the entire pump itself. The next job is to write the program in C/C++ so that I can distribute it by making it open source rather than relying on labview which is over $2000 for non academic users.

[ScottHorn]

With regards to your work trying to replicate the "rapid refill" feature on a single piston pump, take a look around the drive shaft of the stepper motor. Every single piston pump I've taken apart had a "flag" on this shaft that signals the position of the motor. It might looks like a semicircular disk that rotates with the shaft. A portion of this disc will pass between an IR-led and a photo-transducer of some sort (photoresistor, photodiode, etc). Whether or not the disc is obstructing the light to the sensor indicates to the controller what part of the cycle the piston is in. In the pumps I work on most, the disc blocking the led indicates that the piston is on it's refill stroke. This signals the controller to run the stepper motor at or near it's max speed until the sensor sees the light again, at which point the stepper motor either slows down for the "output" stroke, or does so after a slight delay to pre-compress the solvent. The delay is adjustable to account for different solvent compressibility values. If you could tie in to the signal from that photo-transducer, you could replicate this functionality.

As for the lamp, check out http://www.sonntek.com/lamps.html#hp
It looks like it will be $350-400 depending on your model. I don't know anything about the reliability of Ebay lamps.

[joelk]

Hey guys,
My name is Joel Koenka, a PhD student from the University of Basel.

I've been facing a very similar problem like badger and bigdawg.
My aim (two years ago) was to develop an Arduino controlled Capillary electrophoresis system.
At the time I looked for a framework I could use, and didn't find it, so I developed Instrumentino:
https://github.com/yoelk/Instrumentino

It's an open-source GUI framework for controlling custom-made instruments, and I've been using it for some time now for various projects.

I think this might be very relevant to you guys. And if you're interested, you can join me in developing the next version of Instrumentino, which will be based on Kivy (http://kivy.org/#home) in order to let users control their experimental settings from smartphones and tablets as well as PCs.

Instrumentino was also published in scientific magazines. You can find the PDFs in the documents folder in GitHub.

Hope to hear from you guys, I'd very much like to find likely minded people to push this project together.

Cheers,
Joel

[bigdawg]

With regards to your work trying to replicate the "rapid refill" feature on a single piston pump, take a look around the drive shaft of the stepper motor. Every single piston pump I've taken apart had a "flag" on this shaft that signals the position of the motor. It might looks like a semicircular disk that rotates with the shaft. A portion of this disc will pass between an IR-led and a photo-transducer of some sort (photoresistor, photodiode, etc). Whether or not the disc is obstructing the light to the sensor indicates to the controller what part of the cycle the piston is in. In the pumps I work on most, the disc blocking the led indicates that the piston is on it's refill stroke. This signals the controller to run the stepper motor at or near it's max speed until the sensor sees the light again, at which point the stepper motor either slows down for the "output" stroke, or does so after a slight delay to pre-compress the solvent. The delay is adjustable to account for different solvent compressibility values. If you could tie in to the signal from that photo-transducer, you could replicate this functionality.

As for the lamp, check out http://www.sonntek.com/lamps.html#hp
It looks like it will be $350-400 depending on your model. I don't know anything about the reliability of Ebay lamps.

Scott you are absolutely right, the original shimadzu pump had a photointerrupter which was presumably providing the feedback o the stepper motor driver board for a closed loop control. I found a very similar photointerupter online on sparkfun and have ordered it; we will see how it goes.

Yeah Sonntek does have a lamp for HP 1050 for about 400 bucks. I'll have to buy it at some point in time however, right now I am more focused on making the pump right. I've always wondered that since hamamatsu or heraeus seems to be make all the OEM lamps, why are they not interchangeble from one model to another. That can surely make life so much easier, and not to mention make them a bit cheaper too.

[bigdawg]

Hey guys,
My name is Joel Koenka, a PhD student from the University of Basel.

I've been facing a very similar problem like badger and bigdawg.
My aim (two years ago) was to develop an Arduino controlled Capillary electrophoresis system.
At the time I looked for a framework I could use, and didn't find it, so I developed Instrumentino:
https://github.com/yoelk/Instrumentino

It's an open-source GUI framework for controlling custom-made instruments, and I've been using it for some time now for various projects.

I think this might be very relevant to you guys. And if you're interested, you can join me in developing the next version of Instrumentino, which will be based on Kivy (http://kivy.org/#home) in order to let users control their experimental settings from smartphones and tablets as well as PCs.

Instrumentino was also published in scientific magazines. You can find the PDFs in the documents folder in GitHub.

Hope to hear from you guys, I'd very much like to find likely minded people to push this project together.

Cheers,
Joel

Hey Joel it looks like you have already done great work with your instrumentino interface. I'll go through the link you provided and it definitely looks like there is a lot of overlap between what you are doing and what I am trying to do here.

A little bit of background here from my end; I am a chemist and got started on this side project as community outreach activity, and me and couple of other people including my former advisor at my alma mater (Univ of Georgia) decided to make "real" lab instruments available to local high schools so young students can get a true exposure of whats it like to work in science using sophisticated instrumental techniques. we decided to try and make a functional HPLC system from super-cheap 1980s pumps and UV detectors from ebay, write a data acquisition code using labview and get a basic system going. Since, all the money we are spending comes from our pockets and equipment donations from our friends/colleagues at various labs, we decided to use cheap arduinos for DAQ instead of national instrument DAQ which I am way more familiar with using in my day job.

Since, the end goal is to put all the information online, so that in future other high schools can construct a good quality HPLC machine from ebay parts, we plan to make everything open source and use C/C++/.net as our programming language. Unfortunately, I am not very well conversant in any programming language except labview and some C, hence right now, I only have a rudimentary labview VI running. I am also learning python in my free time and more I learn about that, more I feel that it might be a better programming language to use for something like this.

Thanks,

Jay Patel

[joelk]

Hi Jay,
I strongly believe Python is the right choice for such a project, as I advocated in this PublicLab forum discussion (look at the messages from the 23/3 on):
https://groups.google.com/forum/?hl=en# ... hI7TchzmsJ

As I said, I'd be happy to collaborate in pushing this forward, so if you're interested, please contact me.

[bigdawg]

Hi Jay,
I strongly believe Python is the right choice for such a project, as I advocated in this PublicLab forum discussion (look at the messages from the 23/3 on):
https://groups.google.com/forum/?hl=en# ... hI7TchzmsJ

As I said, I'd be happy to collaborate in pushing this forward, so if you're interested, please contact me.

Joel, I have sent you an email at your technion email address.

[andy_s]

Jay + Joel,

As a potential user of both, it would great to see them work together/similarly. I'll be really keen to keep up with this. Will you be posting here as things develop?

Andy

[andy_s]

p.s. You might also talk to these people: imperialcreatelab.com/anywhere-hplc/
I imagine that they're going for the money, but perhaps there is a novel business model in there somewhere......

[bigdawg]

Jay + Joel,

As a potential user of both, it would great to see them work together/similarly. I'll be really keen to keep up with this. Will you be posting here as things develop?

Andy

Andy, I'll definitely post updates on my project here, and long term I am going to put it everything on a dedicated website.

p.s. You might also talk to these people: imperialcreatelab.com/anywhere-hplc/
I imagine that they're going for the money, but perhaps there is a novel business model in there somewhere......

Thanks for the tip Andy, I'll email them and see if they want to be involved in this.

[bigdawg]

Just to update everyone on this thread. We've had a busy summer so far with lots of success. While I've had lots of unexpected delays and problems, we have been able have a working prototype running ioscratic methods with salvaged parts costing less than 500 bucks. There are still some more things to be done like try to make the system run gradient methods, have a dedicated data acquisition software instead of relying on lab-view, use a faster processor board etc so lot of work is still to be done.

For the next step, I am split between trying to figure out gradient proportioning valve and low pressure mixing or to go for an easier solution of sticking a second pump and use a "high pressure mixing" with a dynamic mixer if need be to achieve the gradient. I would love to hear from folks here on disadvantages of the latter approach apart from he obvious one that it requires multiple pumps. Since, I am using cheap ebay pumps, its not that big of a jump in cost to use two pumps instead of investing in a new GPC valve and figuring out its electronics but I would love to hear other ideas on it.

[carlo.annaratone]

Any update?