SLAS

Visual Programming

From LabAutopedia

Jump to: navigation, search
Invited-icon.jpgA LabAutopedia invited article


Authored by: Mark F. Russo

Contents


As laboratory automation systems become increasingly complex, so does the creation of their custom methods. Many a non-programmer can attest to the surprising level of frustration associated with an attempt to “get right” the arcane syntactical detail often demanded by a text-based programming language. The problem of exposing the functionality of a complex system so that it is usable by a non-programmer is the subject of much ongoing research. One very successful solution can be found in the class of software tools that adopt a programming style called 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.

A visual program offers numerous benefits, especially to those for which computer programming is a tool, and not a profession.

  • The graphical representation of a visual program can often convey at a glance its core function. It is not necessary to carefully study a detailed textual representation to form an understanding of its behavior.
  • Creating a visual program can be substantially easier because syntactical vagaries can be avoided, and graphical constructs permit only what is legal within the visual framework. For example, in a block-based visual language, fitting together two blocks may only be possible when the blocks are compatible. In a visual language that uses the “blocks and wires” paradigm, connecting an output port of one block to an input port of another may only be possible when the two ports are labeled with compatible data types.
  • Visual languages are exceptional at representing concurrency. A fork in a diagram can indicate that the two processes are intended to run in parallel. The inherent concurrently executing components of an integrated automation system fit well within a visual programming framework.

The concepts underlying a visual programming toolkit can vary widely. To understand them better, it is useful to classify the potential flows expressed by a visual programming language as falling into one of three categories:

  • flow of data
  • flow of material
  • flow of control

Data Flow

The most common flow paradigm adopted by visual programming languages is the flow of data, also called data flow programming.

Textual languages often follow the imperative programming model. Imperative programming involves specifying a sequence of commands or operations that are executed one after the other. A side effect of executing these operations is the manipulation of program data. The flow of data itself is hidden from view.

By contrast, a data flow programming model makes data the primary focal point upon which its programs are assembled. Operations that occur become side effects of the flow of data through the program. Data flow programs are triggered by the input of data and continue to run as long as data flows.

Because of the natural way that data flow programs can be visualized, it is not surprising that many visual programming languages adopt the data flow programming model as its foundation. Data flow programs are visualized as data processing blocks that are connected with wires. Data flow along some wires into blocks, and out of blocks along other wires. A block initiates execution as soon as data are available on all of its input wires. Specific block data processing tasks vary widely, and it is possible for multiple blocks to be executing in parallel.

LabVIEW

One of the best known visual programming languages based on the data flow programming paradigm is the G language implemented by National Instruments’ LabVIEW. A LabVIEW G program is represented as a graphical block diagram that closely follows the block and wires visual programming paradigm.

What makes LabVIEW of particular interest to the laboratory automation community is its vast library of ready-made software components capable of accessing instrumentation and communication busses of all kinds. These components are available in the visual programming framework as graphical blocks that can be wired into the graphical block diagram.

Another advantage of LabVIEW is the inclusion of an extensive library of graphical widgets that can also be accessed as part of a G language’s graphical block diagram. With this library sophisticated graphical user interfaces can be created for LabVIEW programs and directly integrated into the program’s flow of data. The focus of LabVIEW as a tool for engineers is clear when considering the kind of graphical widgets that are provided. Beyond the standard button and text box graphical widgets, LabVIEW provides many additional widgets including everything from stripcharts through widgets that display and manipulate video. Furthermore, all widgets can be seamlessly integrated into the underlying data flow programming paradigm.

Material Flow

To an automated laboratory, an item as important as the flow of data is the flow of material. This includes raw materials such as chemical reagents or media, newly produced materials such as newly synthesized molecules or oligonucleotides, as well labware such as vials and pipette tips. Automated experimental procedures cannot proceed with an adequate supply of these items. Material flow is not important to general purpose visual programming tools, but certainly can be to visual programming tools geared for the laboratory. This has been reflected in commercial products that have been created for the laboratory including laboratory workflow tools.

Control Flow

A simple flowchart.

The final type of flow considered is the flow of control. This style of flow is much more comparable to standard imperative programming than data or material flow. The most common tool used for graphically representing control flow is the flowchart (see diagram on right). A standard flowchart is a diagram made of a small set of geometric symbols connected by arrows. Control flows from symbol to symbol along arrows that connect the symbols.

A flowchart opens and closes with oblong symbols typically marked Start and End. Other common symbols found in between Start and End include processing (drawn as a rectangle), the conditional or decision (drawn as a diamond), and input or output (drawn as a parallelogram). The arrows that connect these symbols show the flow of control as the process progresses forward. When conditionals are encountered a single input leads to a decision that directs flow to one of many possible outputs. Conditionals in a flowchart can represent simple everything from Yes/No questions to decisions of any complexity. Labeled arrows leaving a decision determine the many possible flow options. Flowcharts may include many other symbols that represent items such as data stores and connectors that direct flow to other flowcharts.

Several other excellent options exist for visually representing the control of flow, and for specifying programs in a visual manner. Two excellent examples are Statecharts and Activity Diagrams, both part of the larger set of diagrams that make up the Unified Modeling Language (UML) standard.

Another visual programming option is the Petri net [1], which is both a graphical and mathematical formalism. Petri nets have been used for decades to graphically model and study the behavior of diverse complex systems, especially those that display concurrent behavior. Petri nets have been used extensively in automated manufacturing [2] as well as the underpinnings of workflow systems [3]. More recently Petri nets have begun to be used as the basis for modeling and visually programming laboratory automation systems [4].

References

  1. Petri, C.A., "Kommunikation mit Automaten." Bonn: Institut für Instrumentelle Mathematik, Schriften des IIM Nr. 2, 1962. Also, Technical Report RADC-TR-65--377, Vol.1, Suppl. 1, 1966. New York: Griffiss Air Force Base, English translation.
  2. F. DiCesare, G. Harhalakis, J.M. Proth, M. Silva, F.B. Vernadat, Practice of Petri Nets in Manufacturing, Chapman and Hall, New York, NY, 1993.
  3. W. van der Aalst and K. van Hee, Workflow Management – Models, Methods, and Systems. MIT Press, Cambridge, Mass, 2004
  4. R. Vanijjirattikhan, D. Kaber, M. Chow, N. Stoll, "Timed Petri Net Modeling and Simulation of a High-Throughput Biological Screening Process," Proceedings of the 3rd Annual IEEE Conference on Automation Science and Engineering, Scottsdale, AZ, USA, Sept 22-25, 2007, pp. 442-447, IEEE New York, N.Y.
Click [+] for other articles on 
Programming automation(1 C, 10 P)
The Market Place for Lab Automation & Screening  Automation Software