Operation: Furious Speed Bump
Systematic impediments to laboratory integration
Twenty years ago this month, I was a junior undergrad taking a course in laboratory instrumentation. As I recall, our project involved the development of a visible absorption spectrometer using a 12-volt auto lamp, some theater gels and a photodiode. We hooked it up to an analog-to-
 |
digital converter circuit that was ported into a 1-MHz Commodore64 personal computer running its own version of BASIC. I was pretty excited at the time to develop a program that asked the user to place the blank and sample cuvettes into our homemade wooden box, collect the intensity readings, calculate percent transmittance and absorption, display the results to the screen and print a report to the thermal printer. If this could be accomplished by some kid in college, I imagined professionals in industry would seize the computer revolution and have laboratories completely automated in short order. However, some folks in the 1950s envisioned flying cars by the turn of the century as well.
Fast forward the picture to today. I’m on the other end of the chalk, so to speak, teaching a course in laboratory instrumentation now called Laboratory Informatics. My juniors are working behind individual 2.8-GHz Pentium-4 computers with 1 GB of RAM running LabVIEW 8 under Windows XP; enough horsepower to operate an aircraft carrier. Having studied transducers and signal processing in a previous course, they have been set to the task of gathering laboratory measurements and stuffing them somewhere. We spend time learning relational database design, MS Access, statistics and confidence tests along with basic programming elements of state machines, multithreading and user interface design. These concepts are integrated into a working laboratory monitoring application to reinforce their importance and the roles they play in the supply chain of laboratory information.
So that we may defer a detailed discussion of instrument interfacing, we use a remote Windows Server 2003 machine to generate synthetic laboratory values and publish them to our student-side Ethernet network using National Instruments’ DataSocket protocol. This data services layer permits us to grab the values from anywhere on the network without requiring a local copy of instrumentation drivers. Our application reads the data, calculates an average with confidence values, and displays them on the screen and in a scrolling virtual strip chart. If the average value does not fall within the given tolerance level, an error is generated that sounds an audible alarm, sends an e-mail to a specified account, dumps the previous values leading up to the error to a file and documents the error, the time and the action taken as an entry into an MS Access database. It’s a nifty solution, but I’ve found the students much prefer working with “real” data being produced by actual processes in the laboratory. DataSocket allows us to write the analysis software and substitute real measurements for the virtual ones as they become available.
During one of last year’s senior projects, a student was using a CO2 incubator for an experiment in our tissue culture laboratory. The student had spent several weeks perfecting his aseptic technique, eventually cultivating the needed cells. Near the conclusion of the project, the temperature controller on our 12-year-old incubator malfunctioned over the weekend and the student returned to find his project had mutated into a puddle of caramelized goo. Although too late to rescue that project, we purchased and installed a new incubator outfitted with digital control modules this past summer. Each module of the dual-chamber incubator has an RJ-45 jack that communicates using the RS-485 protocol. After all of the informatics system development we did during the semester, I thought it would be a simple matter to purchase an RS-485/Ethernet converter and plug the incubator into our monitoring system. But, like the doomed tissue culture project before it, I was in for a surprise. The installation and operation manual shipped with the incubator made no mention of the RS-485 port. There was no e-mail listed, but it did contain a phone number for technical support. After dialing the number, I was informed by the phone tree that the company was recently sold and my call was being rerouted. I sat in the queue for 10 minutes and had to hang up before my next class. A few days later this project recycled to the top of my to-do list, and I reached a technician. After describing what I was looking for, he said he had the documentation I needed and would fax it to me in short order. I stopped camping out at the fax machine three days later. Our laboratory coordinator gave me the cell phone number for our salesman and suggested that may be a quicker route to take. I dialed the number and, no kidding; the phone was in a bad cell and I was unable to leave a message. When I did get a hold of him a few days later, he said he would check into it. About a week later, I got a return message informing me the RS-485 communication software was an $800 option that should have shipped with the unit. After a fruitless search, our salesman needed our original PO number to request a replacement copy. By this time, the semester had ended and our IT department was simultaneously replacing the power supplies to our servers and upgrading our campus-wide purchasing software. They would be able to retrieve the information in a few days.
It is now eight weeks since we wanted to bring the incubators online. Granted, there is a lot of dead time between each of the impediments; but, in many multitasking research environments, that can be common. Our salesman has the needed purchase information and the order should be processed in a couple weeks. I guess my Academic Ivory Tower naiveté is to blame for assuming I would be able to download the communication commands from the manufacturer’s Web site. We turned the ordeal into an object lesson on the importance of information availability, project management and people skills. Perhaps my graduates will apply this experience in their own careers, and I will soon be able to retrieve instrument network commands through the wireless connection of my flying car.
Bill Weaver is an assistant professor in the Integrated Science, Business and Technology Program at La Salle University. He may be contacted at editor@ScientificComputing.com.
