Labview英文文獻(xiàn)翻譯

1、精選優(yōu)質(zhì)文檔-傾情為你奉上精選優(yōu)質(zhì)文檔-傾情為你奉上專心-專注-專業(yè)專心-專注-專業(yè)精選優(yōu)質(zhì)文檔-傾情為你奉上專心-專注-專業(yè)National Instruments LabVIEW: A Programming Environment for Laboratory Automation and Measurement .National Instruments LabVIEW is a graphical programming language that has its roots in automation control and data acquisition. Its graphi

2、cal representation, similar to a process flow diagram, was created to provide an intuitive programming environment for scientists and engineers. The language has matured over the last 20 years to become a general purpose programming environment. LabVIEW has several key features which make it a good

3、choice in an automation environment. These include simple network communication, turnkey implementation of common communication protocols (RS232, GPIB, etc.), powerful toolsets for process control and data fitting, fast and easy user interface construction, and an efficient code execution environmen

4、t. We discuss the merits of the language and provide an example application suite written in-house which is used in integrating and controlling automation platforms.Keywords: NI LabVIEW; graphical programming; system integration; instrument control; component based architecture; robotics; automation

5、; static scheduling; dynamic scheduling; databaseIntroductionCytokinetics is a biopharmaceutical company focused on the discovery of small molecule therapeutics that target the cytoskeleton. Since inception we have developed a robust technology infrastructure to support our drug discovery efforts. T

6、he infrastructure provides capacity to screen millions of compounds per year in tests ranging from multiprotein biochemical assays that mimic biological function to automated image-based cellular assays with phenotypic readouts. The requirements for processing these numbers and diversity of assays h

7、ave mandated deployment of multiple integrated automation systems. For example, we have several platforms for biochemical screening, systems for live cell processing, automated microscopy systems, and an automated compound storage and retrieval system. Each in-house integrated system is designed aro

8、und a robotic arm and contains an optimal set of plate-processing peripherals (such as pipetting devices, plate readers, and carousels) depending on its intended range of use. To create the most flexible, high performance, and cost-effective systems, we have taken the approach of building our own sy

9、stems in-house. This has given us the ability to integrate the most appropriate hardware and software solutions regardless of whether they are purchased from a vendor or engineered de novo, and hence we can rapidly modify systems as assay requirements change.To maximize platform consistency and modu

10、larity, each of our 10 automated platforms is controlled by a common, distributed application suite that we developed using National Instruments (NI) LabVIEW. This application suite described in detail below, enables our end users to create and manage their own process models (assay scripts) in a co

11、mmon modeling environment, to use these process models on any automation system with the required devices, and allows easy and rapid device reconfiguration. The platform is supported by a central Oracle database and can run either statically or dynamically scheduled processes.NI LabVIEW BackgroundLa

12、bVIEW, which stands for Laboratory Virtual Instrumentation Engineering Workbench is a graphical programming language first released in 1986 by National Instruments (Austin, TX). LabVIEW implements a dataflow paradigm in which the code is not written, but rather drawn or represented graphically simil

13、ar to a flowchart diagram Program execution follows connector wires linking processing nodes together. Each function or routine is stored as a virtual instrument (VI) having three main components: the front panel which is essentially a form containing inputs and controls and can be displayed at run

14、time, a block diagram where the code is edited and represented graphically, and a connector pane which serves as an interface to the VI when it is imbedded as a sub-VI.Figure1.Example NI LabVIEW VI.The top panel (A) shows the front panel of the VI. Input data are passed through “Controls” which are

15、shown to the left. Included here are number inputs, a file path box, and a general error propagation cluster. When the VI runs, the “Indicator” outputs on the right of the panel are populated with output data. In this example, data include numbers (both as scalar and array), a graph, and the output

16、of the error cluster. In the bottom panel (B) the block diagram for the VI is shown. The outer case structure executes in the “No Error” case (VIs can make internal errors or if called as a sub-VI the caller may propagate an error through the connector pane).Unlike most programming languages, LabVIE

17、W compiles code as it is created thereby providing immediate syntactic and semantic feedback and reducing the time required for development and testing. Writing code is as simple as dragging and dropping functions or VIs from a functions palette onto the block diagram within process structures (such

18、 as For Loops, or Case Structures) and wiring terminals (passing input values, or references). Unit testing is simplified because each function is separately encapsulated; input values can be set directly on the front panel without having to test the containing module or create a separate test harne

19、ss. The functions that generate data take care of managing the storage for the data. NI LabVIEW supports multithreaded application design and executes code in an inherently parallel rather than sequential manner; as soon as a function or sub-VI receives all of its required inputs, it can begin execu

20、tion. In b, all the sub-VIs receive the array input simultaneously as soon as the For Loop is complete, and thus they execute in parallel. This is unique from a typical text-based environment where the control flows line by line within a function. When sequential execution is required, control flow

21、can be enforced by use of structures such as Sequences, Events, or by chaining sub-VIs where output data from one VI is passed to the input of the next VI.Similar to most programming languages, LabVIEW supports all common data types such as integers, floats, strings, and clusters (structures) and ca

22、n readily interface with external libraries, ActiveX components, and .NET framework. As shown in b, each data type is graphically represented by wires of different colors and thickness. LabVIEW also supports common configuration management applications such as Visual SourceSafe making multideveloper

23、 projects reasonable to manage.Applications may be compiled as executables or as Dynamic Link Libraries (DLLs) that execute using a run-time engine similar to the Java Runtime Environment. The development environment provides a variety of debugging tools such as break-points, trace (trace), and sing

24、le-step. Applications can be developed using a variety of design patterns such as Client-Server, Consumer-Producer, and State-Machine. There are also UML (Unified Modeling Language) modeling tools that allow automated generation of code from UML diagrams and state diagrams.Over the years, LabVIEW ha

25、s matured into a general purpose programming language with a wider user base. NI LabVIEW as a Platform for Automation and InstrumentationOur experience creating benchtop instrumentation and integrated automation systems has validated our choice of LabVIEW as an appropriate tool. LabVIEW enables rapi

26、d development of functionally rich applications appropriate for both benchtop applications and larger integrated systems. On many occasions we have found that project requirements are initially ill defined or change as new measurements or new assays are developed. There are several key features of t

27、he language that make it particularly useful in an automation environment for creating applications to control and integrate instrumentation, manage process flow, and enable data acquisition.Turnkey Measurement and Control FunctionLabVIEW was originally developed for scientists and engineers .The la

28、nguage includes a rich set of process control and data analysis functions as well as COM, .NET, and shared DLL support. Out of the box, it provides turnkey solutions to a variety of communication protocols including RS232, GPIB, and TCP/IP. Control structures such as timed While Loops allow synchron

29、ized and timed data acquisition from a variety of hardware interfaces such as PCI, USB, and PXI.DataSocket and VI ServerDeployment of an integrated system with multiple control computers requires the automation control application to communicate remotely with instrument drivers existing on remote co

30、mputers. LabVIEW supports a distributed architecture by virtue of enabling seamless network communication through technologies such as VI Server and DSTP (data sockets transfer protocol). DSTP is an application layer protocol similar to http based on Transmission Control Protocol/Internet Protocol (

31、TCP/IP). Data sockets allow easy transfer of data between remote computers with basic read and write functions. Through VI server technology, function calls can be made to VIs residing on remote computers as though they are residing on the local computer. Both Datasockets and VI server can be config

32、ured to control accesses privileges.Simple User Interface (UI) ImplementationIn addition to common interface controls such as text boxes, menu rings, and check-boxes, LabVIEW provides a rich set of UI controls (switches, LEDs, gauges, array controls, etc.) that are pertinent to laboratory equipment.

33、 These have their origins in LabVIEWs laboratory roots and help in development of interfaces which give scientists a clear understanding of a systems state. LabVIEW supports UI concepts including subpanels (similar to the Multiple Document Interface), splitter bars, and XControls (analogous to OCX c

34、ontrols).Multithreaded Programming EnvironmentThe inherent parallel environment of LabVIEW is extremely useful in the control of laboratory equipment. Functions can have multiple continuous While Loops where one loop is acquiring data rapidly and the other loop processes the data at a much slower ra

35、te. Implementing such a paradigm in other languages requires triggering an independent function thread for each process and developing logic to manage synchronization. Through timed While Loops, multiple independent While Loops can be easily synchronized to process at a desired period and phase rela

36、tive to one another. LabVIEW allows invoking multiple instances of the same function with each maintaining its own data space. For instance, we could drag many instances of the Mean sub-VI onto the block diagram in b and they would all run in parallel, independent of one another. To synchronize or e

37、nforce control flow within the dataflow environment, LabVIEW also provides functions such as queues, semaphores, and notification functions.NI LabVIEW Application Example: The Open System Control Architecture (OSCAR)OSCAR is a LabVIEW-based (v7.1) automation integration framework and task execution

38、engine designed and implemented at Cytokinetics to support application development for systems requiring robotic task management. OSCAR is organized around a centralized Oracle database which stores all instrumentation configuration information used to logically group devices together to create inte

39、grated systems (). The database also maintains Process Model information from which tasks and parameters required to run a particular process on a system can be generated and stored to the database. When a job is started, task order and parameter data are polled by the Execution Engine which marshal

40、s tasks to each device and updates task status in the database in real time. Maintaining and persisting task information for each system has two clear benefits. It allows easy job recovery in the event of a system error, and it also provides a process audit trail that can be useful for quality manag

41、ement and for troubleshooting process errors or problems.Figure2.OSCAR component diagram.Each OSCAR component is distributed across the company intranet and communicates with a central database. Collections of physical devices controlled through OSCAR Instrument packages (OIP) make up systems. Users

42、 interact with systems through one of the several applications built on OSCAR. Each application calls the RTM which marshals tasks from the database to each OIP. OSCAR has sets of tools for managing system configurations, creating Process Models, monitoring running processes, recovering error-state

43、systems, and managing plate inventory in storage devices.OSCAR uses a loosely coupled distributed component architecture, enabled in large part by LabVIEWs DSTP and remote VI technologies that allow system control to be extended beyond the confines of the traditional central control CPU model. Any n

44、etworked computer or device can be integrated and controlled in an OSCAR system regardless of its physical location. This removes the proximity constraints of traditional integrated systems and allows for the utilization of remote data crunchers, devices, or even systems. The messaging paradigm used

45、 shares many similarities with current Service Oriented Architectures or Enterprise Service Bus implementations without a lot of required programming overhead or middleware; a centralized server is not required to direct the XML packets across the network. An additional benefit to this loosely coupl

46、ed architecture is the flexibility in front-end application design. OSCAR encapsulates and manages all functionality related to task execution and device control, which frees the developer to focus on the unique requirements of a given application. For example, an application being created for the p

47、urpose of compound storage and retrieval can be limited in scope to requirements such as inventory management and LIMS integration rather than device control, resource allocation, and task synchronization.The OSCAR integration framework consists of multiple components that enable device and system c

48、onfiguration, process modeling, process execution, and process monitoring. Below are descriptions of key components of the framework.Integration PlatformThe Oscar Instrument Package (OIP) is the low level control component responsible for communicating with individual devices. It can support any num

49、ber of devices on a system (including multiple independent instances of the same type of device) and communicates to the Runtime Manager (RTM) via serialized XML strings over DSTP. This allows the device controller and RTM components to exist on separate networked computers if necessary. Additionall

50、y, the OIP controller communicates with a device instance via LabVIEW remote VI calls which provide a lower level of distribution and allow the device drivers to exist on a separate networked computer from the controller. At Cytokinetics, we currently support approximately 100 device instances of 30

51、 device types which are distributed across 10 integrated systems.System ManagementAn OSCAR system is a named collection of device instances which is logically represented in the database. The interface for each device (commands and parameters) is stored in the database along with the configuration s

52、ettings for each device instance (i.e., COM port, capacity). The System Manager component provides the functionality to easily manipulate this information (given appropriate permissions). When a physical device is moved from one system to another, or a processing bottleneck alleviated by addition of

53、 another similar device, system configuration information is changed without affecting the processes that may be run on the system.Process ModelingA process model is the logical progression of a sequence of tasks. For example, a biochemical assay might include the following steps (1) remove plate fr

54、om incubator, (2) move plate to pipettor, (3) add reagent, (4) move plate to fluorescent reader, (5) read plate, and (6) move plate to waste. The Process Modeler component allows the end user to choose functions associated with devices and organize them into a sequence of logical tasks. The resultin

55、g process model is then scheduled via a static schedule optimization algorithm or saved for dynamic execution (). A process model is not associated with a physical system, but rather a required collection of devices. This has two important benefits: (1) the scientist is free to experiment with virtu

56、al system configurations to optimize the design of a future system or the reconfiguration of an existing system, and (2) any existing process model can be executed on any system equipped with the appropriate resources.Figure3.Example OSCAR applications.The top panel (A) shows the Process Schedule Mo

57、deler, an application that graphically displays statically scheduled processes. Each horizontal band represents a task group which is the collection of required tasks used by a process; tasks are color coded by device. The bottom panel (B) shows the UI from the Automated Imaging System application.

58、The tree structure depicts the job hierarchy for an imaging run. Jobs (here AIS_Retrieval and AIS_Imaging) are composed of task groups. As the systems runs, the tasks in the task group are executed and their status is updated in the database.Process ExecutionProcess execution occurs by invoking the

59、OSCAR RTM. The RTM is capable of running multiple differing processes on a system at the same time allowing multiple job types to be run in parallel. The RTM has an application programming interface (API) which allows external applications to invoke its functionality and consists of two main compone

60、nts, the Task Generator Module (TGM) and the Execution Engine. External applications invoke an instance of a Process Model through the TGM at which point a set of tasks and task parameters are populated in the OSCAR database. The Execution Engine continually monitors the database for valid tasks and