Abstract
“Computer programming also has advanced in recent years. It is no longer the sole domain of techno-savvy geeks sitting in darkened rooms.”
If a week is a long time in politics, a decade in laboratory automation is a lifetime! When I first started out in the laboratory automation industry, the equipment was often controlled by MS-DOS, MacOS-(not OSX), or OS2-based computers. To program the machines, you needed to know a bit about computer programming to write coding scripts to move the machine around. This was done using Turbo Pascal or a similar computer programming language.
Today, the software supplied with automation systems has a much richer functionality, supplying a Graphical User Interface. This allows the operator to build up scripts to perform elegant and customizable procedures for a wide range of applications across the entire pharmaceutical/biotech industry and beyond. Therefore, one would assume that the need to be able to write computing scripts would now be obsolete. That is not, however, the case. Along with a dramatic rise in quality and functionality of automation software, there has been an equal (if not greater) rise in expectations from users of the equipment. This involves fine-grained control, connection to LIMS systems, remote monitoring, etc.
Computer programming also has advanced in recent years. It is no longer the sole domain of techno-savvy geeks sitting in darkened rooms. Instead, computer programmers and software engineers need to engage with their customers/clients. In addition, programming languages have become simpler, allowing the computer-literate person to be able to write simple scripts to perform basic customization tasks. This opens up a new world of possibilities for extending the use and lifetime of capital investments made in equipment.
Until recently, the de facto programming language for simple “user-based” customization in the laboratory automation industry sector was Visual Basic 6. This was due to a simple syntax and a low entry barrier, allowing users to quickly develop functional and useful programs. However, this has been retired by Microsoft to be replaced with VB.NET. One advantage this offers is the opportunity to take a step back and review the options available to programmers.
Therefore, this special issue investigates the various choices available to the laboratory automation specialist for controlling laboratory automation and related resources. These choices are hugely varied, including proprietary languages such as .NET and LabView, and open source languages such as Python and Ruby. Each article discusses the language to illustrate some of the advantages of that particular language choice. It is important to note that one language is unlikely to fit all needs, but rather to use these articles as a guide to select the correct tools for your particular circumstance.
In addition, a special article also is included that illustrates the importance of user interface design in producing automation control software. A poorly designed user interface will either result in your software not being used or frustrate the user and make you very unpopular in the staff canteen!
It only remains for me to thank the authors for their contributions and the reviewers for their diligence and wisdom. Finally to thank you, the JALA reader, for continuing to advance the field of laboratory automation!
Yours Sincerely,
