View source

From LabAutopedia

You do not have permission to edit pages, for the following reasons:
This page has been locked to prevent editing.
The action you have requested is limited to users in the group Users.
You must confirm your e-mail address before editing pages. Please set and validate your e-mail address through your user preferences.
You can view and copy the source of this page:
{{Header:Invited_article|Programming Automation|[[:Category:Russo, Mark F.|Mark F. Russo]]}}Laboratory robots and other automated instruments must be taught precisely how to perform their actions to ensure that the underlying science is carried out in a manner that produces meaningful results. This activity is referred to as "programming" the automation. A wide variety of tools have developed over time to assist the automation programmer. 

Most automated instruments are complex assemblies of a variety of individual components including motors, actuators, sensors, pumps, structural parts, and other equipment. Coordinating the actions of an instrument rarely involves the direct control of its individual parts. Instead, instrument manufactures often provide some form of [[Command Languages|'''command language''']] that can be used to instruct the instrument to perform functions at a higher conceptual level. The underlying implementation of commands in a command language ensures that the instrument's component parts operate in a coordinated manner. Because instrument manufacturers are rarely programming language designers, instrument command languages tend to be very basic, and rarely incorporate advanced programming language concepts. 

In a command language it is common to find individual commands that cause an instrument or robotic device to move. Rarely do motions involve a single actuator. Robotic motions generally involve the careful coordination of multiple actuators and motors. [[Programming Motions|'''Programming motions''']] can be a complex endeavor, involving complex kinematic computations and numerous other geometrical calculations. Fortunately, motion programming toolkits vastly simplify the task of programming automated instrument motions by hiding the underlying complexity. 

[[Method Programming|'''Method programming''']] is a natural extension of command languages. Once one has the ability to trigger instrument specific actions using the statements of a command language, it’s useful to sequence these commands using procedural programming constructs. For-loops, if-then conditionals, variable definitions, input-output, and basic mathematical operations, all play an important role in building a method that instructs an integrated laboratory automation system to perform an experimental procedure. Standard programming tools fused with instrument specific commands form the basis of method programming. 

One way to extend the flexibility of an instrument that already has a sophisticated software control application is to embed a [[Script Engines|'''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. Not surprisingly, 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. For that reason, when standard script language engines because available, these began to appear in instrument control software. For example, Beckam Coulter used [http://tcl.tk/ TCL] as the basis for Bioscript Pro, their scripting language for the Biomek 2000 Laboratory Automation Workstation. Tecan embedded VBScript in their Gemini Pipetting software application [ref]. Velocity11 uses [http://www.mozilla.org/js/spidermonkey/ SpiderMonkey], a JavaScript script engine, in their VWorks Automation Control Software. 

Another very successful approach for programming automation can be found in the class of software tools that adopt a programming style called [[Visual Programming|'''visual programming''']]. Visual programming involves the use of a graphical palette upon which the programmer creates, arranges and connects graphical diagrams and images that represent various concepts of the programming environment. Once the visual program representation is complete, the diagram can be translated or compiled into a standard executable program, or it is executed directly. Graphical widgets represent various available resources that make up the system under control. 

The most sophisticated of all automation programming options is called [[Automatic Programming|'''automatic programming''']]. In the field of laboratory automation, the term is used to describe an algorithmic procedure that plans and executes an iterative procedure to automatically achieve a stated goal. A good example of automatic programming in laboratory automation can be found in novel techniques for identifying optimal assay conditions. The automation programmer first designs the fundamental procedure that evaluates the assay performance with a single set of conditions. Using techniques from the Design of Experiments, the automatic programming software selects conditions, automatically performs experiments, collects results, and evaluates results to select a new set of assay conditions. It repeats this process until a set of assay conditions has been identified that achieves some stated goal.{{Category_Tag:Laboratory_automation_system_architectures}}

[[Category:Russo,_Mark_F.]]{{Category_Tag:Programming_automation}}
Templates used on this page:
Return to Programming Automation.
Retrieved from "http://www.labautopedia.org/mw/index.php/Programming_Automation"