Authored by: Mark F. Russo
The most basic form of laboratory instrument is controlled with on-off switch. As sophistication increases, complex custom software applications step in to provide the scientist with myriad options, settings and experimental methods that can be set and invoked. At some point, it becomes impractical to continue to satisfy the user’s demands for more flexibility by adding buttons or checkboxes to the graphical interface.
One way to extend the flexibility of an instrument that already has a sophisticated software control application is to embed a script engine into the software application itself. Script languages can be thought of as simplified programming languages that are designed specifically to orchestrate the workings of a more complex environment. Numerous proprietary script languages have been developed by instrument manufacturers in an effort to extend the flexibility of customized software applications. As was the case with method development environments, many instrument manufacturers discovered that continuing to maintain a proprietary scripting environment was a costly endeavor that appeared to contribute little to the core instrument business.
After the development of component object technologies it became clear that these technologies could be use for more than just plugging software libraries into host programming environments. It was now technically feasible to do the complement – to plug entire programming environments into pre-existing software applications. When a sophisticated instrument software application already existed, it was more feasible to plug a simplified programming language engine, a script engine, into the software application and expose the existing functionality of the application to the script engine. This way, the existing user interface remained intact, with the added option of controlling the instrument, not through the interface, but by writing embedded scripts.
The path was opened for the adoption of standard script languages by embedding third-party script engines. Once again, similar to the adoption of component object technologies in method building, a standard script engine gave the instrument manufacturer the ability to opt out of the race to maintain and add new features to a proprietary script language.
The breadth of options in commercially available laboratory instrumentation remains diverse. Some instrument manufacturers continue to maintain proprietary scripting languages, and others are adopting more modern script engines, such as those based on Microsoft’s .NET family of programming languages. As always, individual requirements must be carefully compared to the current state of the quickly advancing field of laboratory instrumentation.
|Click [+] for other articles on||The Market Place for Lab Automation & Screening||Automation Software|