Why don't the manufacturers do these? a place for ideas...

[leadazide]

Would it be too much to ask for a software that does what I want it to and not what I tell it to do??

I love the idea of a solvent try with a scale built into it.. simple and effective.. I know there is a system out there somewhere that allows mounting a laser and detector on the bottles and when solvent passes below the laser light and blocks the path a shutdown signal is sent to the system..

On the very very top of my list I would have to have "vacuum in a can" so I don't have to wait for a mass spec to pump down.. Just switch it on.. "add" the vacuum and presto.. Run samples.

[Jack Silver]

Set up a webcam -- in fact monitoring liquid level was the first use of a webcam:
http://en.wikipedia.org/wiki/Trojan_Room_coffee_pot

Okay, it was a coffee pot, but still . . .

There seem to be two ends to this discussion:
- shutting down when the solvent is depleted
- shutting down to conserve solvent when something else goes wrong.

For the former, I've always simply set the low-pressure limit on the pump. You should be able to halt the sample sequence in that situation; the only result you would lose is the current sample when the shutdown occurred.

Regarding solvent level sensors, Teledyne ISCO has just such a feature on many of their Flash Chromatography systems. They also do waste level sense, so the waste bottles don't overflow.

[lmh]

Today I want another useful unit for any chromatography system: a defender. This is a box equipped with robotic arms ending in boxing-gloves or a truncheon. If anyone attempts to approach the instrument while holding a disk labelled "MyChrom Upgrade for Win 7", it goes into action....

Had this been invented and installed rigorously from the beginning, we'd still be operating in Win 3.1, but probably collecting results. As it is, we have a particularly impressive paper-weight in the lab today.

[James_Ball]

We need more chemist who know how to write software. It seems that now we have software engineers who try to write software for our use but never learn how we actually use it. The older software was great because it was just someone who actually used the equipment that wrote some simplistic code to make it work.

[juddc]

We need more chemist who know how to write software. It seems that now we have software engineers who try to write software for our use but never learn how we actually use it. The older software was great because it was just someone who actually used the equipment that wrote some simplistic code to make it work.

Sounds like you've identified a gap. Now go learn how to code and exploit it for personal gain! (PS - I know a Ph.D. organic chemist who writes software for a living. Brilliant guy)

[James_Ball]

We need more chemist who know how to write software. It seems that now we have software engineers who try to write software for our use but never learn how we actually use it. The older software was great because it was just someone who actually used the equipment that wrote some simplistic code to make it work.

Sounds like you've identified a gap. Now go learn how to code and exploit it for personal gain! (PS - I know a Ph.D. organic chemist who writes software for a living. Brilliant guy)

I did back when BASIC was a top programming language lol.

I remember right after HP/Agilent moved to DOS/Windows based software one of their CEs was complaining about the same thing. The ones that originally programmed Chemstation on the RTE computers were application chemists, and that was ported over to the first Win3.1 version.

I remember writing macros for the Win3.1 version to include the chromatograms in the reports the way the RTE version did. It wasn't bad back the, the new .net programming in Windows currently I just haven't been able to come up to speed on

[lmh]

what's quite scary is some of the stuff that used to happen even in professional code. I don't know if it still does. I've come across a UV/Vis spectrophotometer with kinetics software that could give a standard error of the slope on a line fitted through only two measured points....

(explanation: if the instrument was measuring fairly slowly, for example because it was cycling through multiple cuvettes in a cuvette holder, it actually saved interpolated data points. These weren't marked in the data-file in any way as being different to the measured points. I strongly suspect that a second programmer/team wrote the regression bit without knowing).

I've also come across a lab instrument with "secure" user-logins where the passwords were saved in a plain text file. Great, because the person setting up the instrument gave everyone usernames the same as their local domain login name, so most people used a variant on their domain password for the instrument...

I still have a mass spec in the lab that I can persuade to mislabel MS-MS spectra with the wrong parent ion. Very handy.

And my all-time geek-triumph was writing my own implementation of a mass spec processing algorithm that was used in a commercial bit of software, but I did it in 16-bit Pascal for DOS (!!!!!) and it ran nearly twice as fast as the commercial version - without me even trying to optimise it. What makes the speed difference really scary is that the data were big enough that I had to read them from hard disk, being stuck with a 64K segment size. (ever thought about the limit on combined resolution and mass-range in the old, pre-32-bit versions of Chemstation... yup, it guarantees that the mass can be described in not more than 16 bits).

Fortunately these are the exceptions. Most of the commercial software in my lab now does amazing things, the implementation of which I can only vaguely imagine. We are, on the whole, lucky.

[DR]

Well said.

Every time I trip over the results of programmer lassissitude (or incompetence) in a top dollar CDS I swear under my breath and wonder how much money we've paid for it. Things like being unable to paste a block of sample names or weights into a table in the CDS, resulting in my having to copy, alt-tab, click, paste, alt-tab back to my table of sample information for each and every sample. Lately, my CDS table does not even regain focus in Windows when I tab back to it, hence the click.

Another favorite is when I use the CDS to generate pdf files that print well enough, but forget trying to copy a table from one and drop it in a MS document. They're not tabbed in any sort of order, so you end up getting a single column of randomized labels and numbers! Fortunately, you can copy from print preview...

So much for following the basic rules for Windows programs. If the people hwo wrote this stuff actually had to use it for a couple of hours per week, there'd be no such shortcomings.

[shfo]

(2) Calculate the inner product of an LC-MS spectrum and the same spectrum shifted X units left. Soooo useful for neutral losses. This just means take a copy of the spectrum, move it X units leftwards, multiply each intensity of ion in the region where the two spectra overlap by its corresponding value in the other unshifted spectrum, and sum all the values. If you have a peak that fragments to something X units lighter (source fragmentation), it will be intense in both the unshifted and the shifted spectrum, and you get a big signal. This really does work, and is a valuable addition to single quads, and useful in ion-traps, where it will pick up things that weren't chosen for data-dependent fragmentation.

I was doing a lot of carotenoid analysis by LC-APCI, so I added a feature into the last version of Aston to pull out neutral loss abundances from the parent ion (e.g., by typing in "M_18" as a trace, you see peaks for hydroxylated compounds). The inner product method sounds better though (or complimentary, at least) and fairly simple; hopefully I can figure out a way to include it too. Thanks for the idea!

[lmh]

I used the inner-product method very briefly quite a few years ago, when we had an Agilent single-quad with the old 16-bit version of Chemstation, whose data-file format was very easy to read. I stopped when we upgraded to 32-bit. I used it on flavonoids, which fragment in source to quite a noticeable extent. It worked really well, if I say so myself! I have no idea why it's not as routine as the base peak chromatogram as it's really very straightforward to calculate and genuinely useful.

Are you by any chance planning to add support for other manufacturers to Aston?

[shfo]

I used the inner-product method very briefly quite a few years ago, when we had an Agilent single-quad with the old 16-bit version of Chemstation, whose data-file format was very easy to read. I stopped when we upgraded to 32-bit. I used it on flavonoids, which fragment in source to quite a noticeable extent. It worked really well, if I say so myself! I have no idea why it's not as routine as the base peak chromatogram as it's really very straightforward to calculate and genuinely useful.

Are you by any chance planning to add support for other manufacturers to Aston?

I'm in the middle of fixing a bunch of bugs I introduced by changing the database code, but after that's done I have a couple folders of Bruker and Waters files to look at. I'd also like to get netCDF/mzML readers/exporters written for the next version too. I'm always happy to take requests for other manufacturers though!

[lmh]

I'm most interested in doing this with a Shimadzu instrument at the moment, but I know that's a niche market. Fortunately Shimadzu are about the only manufacturer we're using who've really got their mzXML/cdf exporting working gorgeously well, so if you can read those formats, I'm jolly happy!

[Hollow]

If I could wish a usefool thing for lab, it would be an ultrasonic bath with 12 stirring places which is heat- and coolable.

would like that too

[ThermoMarkB]

Keep going, we're listening....

-Mark

[Peter Apps]

How about an equilibrium headpspace sampler that is designed form the ground up for capillary column work rather than being adapted piecemeal from packed column technology ?

Peter